> Let's just call this experiment a failure
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.
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.
[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.
"Better" doesn't necessarily imply "Good".
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.
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."
Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.
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.
Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.
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.
i.e.
describe file("foo") do
it { should exist }
it { should be_owned_by "root" }
end
_.map(["a"], function(s) {alert(s)}) describe("something", () => {
it(should(exist))
it(should(be_owned_by, "root"))
});
_.map(["a"], s => alert(s))
_.map(["a"], alert)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.
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.
Basically, JS wasn't leveraging much of the computer's power until V8 came along.
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.
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.
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.
[0]: https://dorey.github.io/JavaScript-Equality-Table/unified/ [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Why don't you all just use === instead of ==?
Tell me, how long does it take to learn it?
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've never used ==
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()
}
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.
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.
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.
Wait, do you mean to imply that "passing silently with a weird result" is somehow better than throwing a verbose, descriptive error?