The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.
And it is extremely successful because it's not a bad language. Sure, there's lots of "wat", but a non-professional programmer is going to say "wat" about every strange error they get from another programming language that js would have just passed silently with a weird result. Then they will replace whatever construct isn't working with one that does, and get on with their life, unlike people who seem to have a lot of energy to waste on complaining.
Are there bad languages? Can you give an example of a such language?
I'm also wondering why JS changed so much lately if it was a great language already.
When I first started learning JavaScript, I wondered how people became proficient at the langue with all these weird quirks[0] that don't raise errors. Turns out that there are a bevy of things to help combat these quirks. Two of them are strict mode[1] (which can be scoped[2] in instances were libraries/frameworks would fail running in strict mode) and linters.
Strict mode and linters do not fix everything. This is doubly so if your developers ignore the warnings and errors that the linter throws. The language isn't inherently bad, but plain old JavaScript is not beginner friendly for new developers. It requires the discipline to not just throw things together.
I think I have used weak equality once, because I needed truthy/falsy. I've always used strong equality. I always tell people that unless there is an absolute need for weak equality and you can thoroughly explain why weak equality works better than another solution, refactor for strong equality.
The all these weird quirks thing was really a naive me talking back then. JS was my second language after Java. Anonymous functions, async execution, implicit typing, weak typing - it requires a different way of thinking when you move from Java to JS and you're just starting. Most everything is explicitly defined, and everything executes in the order that is listed in Java. JS is whole different beast.
There are plenty of times where you want ==, or for that matter, any falsy/truthy expression in JS... about the only points where I have issues with some of the defaults for falsy/truthy come down to the number 0... Outside that, I find that there are times where I'm dealing with inputs that can be a string or number, and the coercion can be handy.
I would never suggest people start learning programming with JS first... although, there is the huge benefit of not needing more than a text editor and browser (already on their machine) to get started with it. One area of JS that I HATE is Date... it sucks, it's woefully incomplete and moment-timezone is huge to download in a browser.
The primitives, coercion and a lot of other bits of JS I really appreciate... but === vs == is pretty low on my list... that said, I tend to prefer the airbnb eslint preset, so it makes me use it anyway.
FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.
> I'm used to javascript enough to think in advance
I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:
1) debugging someone else's code is a lot more time consuming than debugging your own
2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code
3) the docs are simpler to write and easier to read.
It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:
function doStuff(a, b, c) {
if (!c && b instanceof Function) {
c = b;
}
c()
}
"`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it."
I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.
True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.
It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error.
That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".
> If someone calls me with invalid input, and it's coerced and you get invalid output
But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
> And it is extremely successful because it's not a bad language.
Perhaps not a bad language, but I do think it falls into the same category as PHP - just good enough.
It's just good enough to do what we want it to do, and given the lack of choice, we're willing and ready to pile abstraction upon abstraction upon it to try and reduce the pain involved with getting work done.
And like masochists, we look at the results and go "Well, that didn't hurt too bad this time, so I'm willing to go do it again."
> hardly even a language. More like a collection of macros.
You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages.
> an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility
Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as particularly free or flexible. The ability to create and use DSLs directly within those languages really displays true flexibility and freedom, IMO.
Of course, you don't always want unlimited flexibility and freedom in a language; it's why a particular type-safe languages with a very restrictive borrow checker is so popular.
DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation.
Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.
We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted.
i.e.
describe file("foo") do
it { should exist }
it { should be_owned_by "root" }
end
Except your rspec example isn't a change to the underlying language is it? Also, Check out mocha for the JavaScript equivalent.
Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.
Operator overloading in Python made the Pandas library possible where you can treat a DataFrame syntactically like you can in R, which is really nice for data science.
"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.
Also, it adds up (no pun intended). You're right that add() vs. + for a simple case when you only do it a few times is no big deal. But it is a bigger deal when you do it a lot, and the arithmetic can be a little more complicated.
We could by analogy apply this argument to adding integers and floats together. It's more convenient to use the + operator for that, but someone could argue that an add() function is just a minor inconvenience, so why bother overloading the + operator?
That is until you have to use it hundreds of times.
It's not just arithmetic, it's also being able to use comparison operators to filter, which is really convenient. What languages like R do at the syntactic level is make the programming language closer to math, where you can do things like add vectors or multiply matrices using simple operators.
Compared to what? PHP is/was far, far worse than JS has ever been, and I remember when you couldn't declare a function in a function (IE3 iirc). There are a few, well defined quirks, and some other behaviors that are arguable, but JS is one of the most expressive languages around, and with the ES2017+ enhancements really nice.
JS is my favorite language, hands down... C# is a close second, and that's as much for the tooling as the language, though the p/invoke and native interfaces are pretty awesome. After that, there's some functional languages I like, and have been looking for a reason to use Rust or Go for something... beyond that, most languages have a lot of their own warts.
Sure, but there are better alternatives, and now that JS isn't just confined to the web, where it had no real competition, people are complaining because they see it being used instead of better tools that have been available for a long time.
I don't think there is universal agreement on what the better alternatives are. If there were, comments like these would list them. There are however worse examples for desktop development never the less used on the desktop like VBA, java, adobe air, scala.
As with so many choices, there is a trade off. If it were possible to point to some system that is unambiguously better on all axes than javascript and its ecosystem, then you'd have a point, but since there isn't, we're back to arguing trade offs, and really, getting upset about the tools other people choose to make things is a pretty fruitless use of time and energy. If people really want to encourage others to move, they'd be better evangelising the solutions they love than berating people for choosing what they choose.
[edit] ES6 is definitely better than a swift kick in the groin. It is certainly better than the original version of javascript. And it is also better than a lobotomy.
ES6 is definitely a better Javascript. But whether it's better than other languages on the server (or desktop) side is the question. But maybe by ES10 it will be.
I mean, the whole "{} + [] == 0" thing is cute and all, but isn't that just tip-of-the-iceberg hilarity? Isn't the real problem with javascript that it's slow and messy?
I was under the impression modern JS interpreters JIT to machine code and are fast. Kind of like how Java was slow in 1995 but today is kind of amazingly fast. Which I guess implies that there are two ways a language can become fast: one is by being designed for speed, and another is by becoming extremely popular/useful and having tons of millions of hours of thought and work put into making it faster.
Probably because the head guy working on V8 had lots of experience with virtual machines going back to Self in the 80s. But it's kind of silly to say that JS VMs have outpaced Moore's law, given that interpreted JS was very slow to begin with. It's not the same as a compiled languge improving by that much in the same time.
Basically, JS wasn't leveraging much of the computer's power until V8 came along.
It seems that you're complaining about some perceived meaning in my comment, but I'm not sure what it was.
Having written significant pieces of code in javascript over the last 13 years, I've benefitted massively from those speed increases, and while I'm aware of a number of reasons that they have occurred (including but not limited to the v8 engine - I remember reading excitedly about tamarin, tracemonkey and the like), I don't think it's silly to point out the sheer magnitude of the improvement.
I'm not trying to say that JS is going to save us from Wirth's law or anything, I'm just trying to give people context on what a huge jump it has been.
Okay, but we can always replace "slow" by "slower than" and in a desktop environment (which the article is about), we could still compile C++ code to run natively and outperform JavaScript any day. The whole brouhaha about JavaScript being fast stemmed from it suddenly not being 10 times slower than native code in benchmarks. But it's still slower.
By using JavaScript you are, out of the box, sacrificing about 20% of your performance for the comfort of using it. In some cases, maybe only 10%. In others 50%.
I can totally understand how that's a trade-off one is willing to make in many cases. But for desktop apps, I kinda want them to run at full speed. Like, a 0.2 second delay can get annoying if it comes at the wrong time or stacks with something else. And somehow, you can feel that in many hyper-modern apps that are so many layers removed from the hardware, the devs probably don't even know where it touches it.
Pretty much this, although arguably JS's flexibility aided in allowing developers to get around various limitations. That can be seen as a good or bad thing, depending.
The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.