> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.
If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all the niceness of Javascript but almost none of the bad stuff. I say this as someone who is primarily a Javascript developer professionally.
Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP), but there are many that are much better. It's worth noting that everything that is good about Javascript already existed in other languages before Javascript got invented. In fact Brendan Eich has stated that his intention was to create Scheme for the browser. If only he had just used Scheme as it existed, things would have been so much better!
> Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP)
Java has an enormous ecosystem, is fast, is stable, has static typing, has more tooling than anything else, is easier to learn, does not have all the gotchas that Javascript has. I don't consider Java a worse language at all.
I use Java since a decade, and frankly I don't understand that rage against it while it is a totally valid option to start a project with, even a startup. If you want to get RESTful and all there's everything you need, etc.
Take it from a guy doing some Golang since more than one year and enjoying it a lot, also well versed in Python, Javascript, and even OCaml.
In fact, the time it took me to write this comment, I decided that I don't care anymore. Use what you need for the job and be prepared to change when something new is out and have a real impact on what you do.
I agree that Java has relatively few WTF-level language design flaws. So on that count it wins against Javascript. But Java also doesn't have the expressive power of Javascript that comes from having 1st-order functions. Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement. I respect that there is a humongous ecosystem surrounding Java, but that doesn't really speak to whether the language is pleasant to work with or not.
Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement.
So then programming in Java with a powerful IDE is like running in wet cement with bionic stilts? I think this is actually an apt analogy, especially for when things don't work quite right or when things get a bit laggy.
I've been working with JS professionally for the last 3 years...priorto that, spent many years with C++/SQL/etc...the statements that people get "burned" by JS (pesumably because of the weird coercion or floating-point comparisons?) I've never understood...maybe I just write my code in a weird way that insulates me from those things...I've never experienced more than a "minor surprise" in dev - certainly never been "burned".
> maybe I just write my code in a weird way that insulates me from those things
Maybe you do. I certainly strive to. But don't you sometimes have to work with other people's code too? I recently inherited a 10 years old codebase written by people who had not heard of implied global and didn't use the var keyword.
In my previous job I had to educate several frontend developers about the dangers of using parseInt without a radix parameter. The ones that already knew did so because… you've guessed it: They had previously gotten burned.
I worked on a project in which the backend had a rest API that served json data. Among the data were some rather long integer IDs. But since javascript doesn't have integers but only floats (of all things), the IDs got rounded off in weird ways. Not very useful as IDs after that! If all everyone ever used was javascript, this would perhaps not have surprised anyone, and it would be known by all that you shouldn't use a Number as an ID, but always only Strings. The problem is that most back-end developers are not Javascript experts and in their world it is only natural that you should be able to use a number as an ID (as it should be IMO).
As time goes by and you get experienced, you begin to learn all of these little 'quirks' of the language, and maybe you start to adopt a defensive style of programming that insulates you from the worst of them. And if you've never experienced anything else, it's easy to tell yourself that this is just the way things are, and that it's probably the same for everyone. But I'm here to tell you, that this is not the case! Sure, other (better) languages have surprising behaviours too, but they are mostly good surprises that empower instead of restrict.
> But don't you sometimes have to work with other people's code too?
Yes, I suppose I have gotten "burned" by other people's JS quite a bit...but not any more than I've been burned by other people's bad SQL or C++ or C#, to be honest.
> Sure, other (better) languages have surprising behaviours too, but they are mostly good surprises that empower instead of restrict.
I am assuming that by "better" languages you are meaning type-safe ones... I know this is not a popular opinion, but I honestly just prefer dynamic typing. When I code, there is only room for one whiny child in the equation: me. Not the language I code in. I would rather not have my language throw a temper-tantrum and break down because I gave it something a millimeter different than what it was expecting. If the object is supposed to have "thing" and it has "thing" then shut your mouth and use it, language. Where JS gets weird is that it tends to put "thing" there in some cases where you didn't expect it, but honsetly after learning the few cases where it does that, I've never had a huge problem with it - I think, like everyone, I bumped into some mild surprises (ya the radix thing with parseInt and [] == false and soforth), but they were never more than just mild surprises in development. I know it drives people insane - and some people will swear that there is no way to build large systems with it. I suspect those people are the same ones who asked the teacher for extra homework for the whole class when they were kids. That was just never me, and I would just respectfully disagree. To me JS is just a ton of fun and there are too many people making too many awesome things with it to ignore. Apparently TJ got tired of it - maybe I will one day, too.
Until then, I just wish people would recognize that the reason JS "won" the language wars of the mid-late aughts was specifically because of the "get-out-of-the-way-and-let-coders-code" dynamic built into it - IMHO the modern web could not have been built with anything else. If you have any recos for "better" languages that share that dynamic, I would be very interested in hearing them.
How do you "get burnt" by parseInt without radix? Yes, I made that mistake before, too. But it's usually in a situation where you detect your error immediately. Then I add the radix, problem solved.
I don't know the libraries of other programming languages by heart either. I would be making lots of mistakes in other languages if I wouldn't look up the correct API all the time.
It's probably because c++ is arguably even worse (harder, with speed advantage to be fair). I haven't seen anything worse than MFC/boost 300 level underscore filled template stack trace, in any language.
> In fact Brendan Eich has stated that his intention was to create Scheme for the browser
No. Read https://brendaneich.com/2008/04/popularity/. "Come to Netscape, do Scheme in the browser!" was the bait. When I got to Netscape, it "had to look like Java". And given timing both internal and due to MS coming after Netscape, it had to be done really, really quickly.
> Python falls through because it doesn't have real lambda.
No it doesn't. Been using it for about 10 years can't remember being bothered by lacks of "real lambdas"
> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.
If there would be minor detail we wouldn't have had the "Good Parts" book. And trying to deals with variables in Javascript is pain, var vs no var, what does this do. Really strange weak typing rules.
Adding [] to {} should not produce some random value (what is it NaN or Object), it should throw an exception.
I assume you're referring to the "Wat" talk by Gary Bernhardt, here.
My question is why does it matter? It's funny and notable behavior, but why is this a problem that a real programmer will face dealing with a real problem?
If you normally only do a couple lines of jQuery per day then I agree that you don't encounter the warts very often.
If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.
As already stated, it depends on what you're doing. I have to calculate lots of numerical things, javascript isn't brilliant for that at all (I'm not against js, I was an early advocate and have used it for years).
Python doesn't have real lambda, who cares? That may or may not matter to you, it mostly doesn't matter for me, most of the time.
You've directly commented on a post about how understanding the context in which you use your tools is the crucial factor by totally ignoring the point.
Doubles do have 53 bits of int precision at least. Did you know libcurl uses doubles to represent file sizes? File sizes that are always integral? Don't ask me why they did that, guess it had better platform support than int64's a hundred years ago.
> Python falls through because it doesn't have real lambda.
True. What it does have though is real closures. Local function definitions with a proper name, capturing lexical state, usable as first class objects. This is a usable replacement for real lambdas, in much the same way functions are used as a replacement for just about everything in Javascript.
There are so many things in Python that have real syntax and language support, and that are lambdas upon lambdas upon lambdas in Javascript.
Carefully configured Flask can get up to 1/3rd the speed of other web frameworks. But misconfigure it, use an ORM, or if you're on django, you're serving 1/10th as many requests/sec with significantly higher latency than other languages.
Template rendering takes an appreciable amount of time. I had to replace django's (slow as shit) stock templates with jinja2 on a project because it was taking tens of seconds to render a very large page. Jinja is far faster, but it's still slow enough that I had to add a caching layer to a website that shouldn't need one.
3. Numerical shit
I implemented a video processing algorithm from a paper for a computer vision class. Python's scientific and numeric libraries were sick and made prototyping delightfully easy--then the final runs on the full dataset took forever. What I re-implemented in C++ was >10x faster. Vectorization and other tweaks can make python numerics go faster, but it's a pain in the ass. One of the goals of the Julia scientific programming language is to make loops fast enough that code doesn't have to be manually vectorized.
I work on bare bones low latency systems. Read from a socket->do some basic work->send on a socket.
I prototype in python and use zeromq so i can simply insert a new piece of code in c++ when the time is right. Throughput generally increases 10x or more for the same algorithm
Yeah, there are tradeoffs. SqlAlchemy is by far the most pleasant and thorough ORM to work with, for example. For any language. Full transactional support + every other feature you can dream of.
So, is that bad? Are my systems inferior because they are not "webscale" or "computational pipelines"? I never said I did that. Python is fast enough for what we do.
Apart from that JavaScript is brilliant. Few other languages can match it's simplicity.
Python falls through because it doesn't have real lambda.