I prefer to alienate potential converts than convert JavaScripters! Just joking of course. It is hard to hide hate to a non-language treated as a super cool language. But you are right, I've never thought about it this way. I will change it, thank you!
in what way is javascript a non language? i write c, python and javascript- i dont see how one is any more of a language than another? you are baselessly pretentious
the_cat_kittles I did not wanted to hurt your feelings. Of course it is a language. By saying it is not I just wanted to express my strong anty-JS feelings, but they are of course very subjective :)
If I had to guess, I would point out that JavaScript was originally hacked out in 10 days, and features a number of unforgivable flaws, such as a non-transitive equality operator, weird implicit conversions, or just plain trying to make sense of quite obviously nonsensical operations.
To someone used to the mathematical rigour of typed functional languages, this is not even worth looking at. As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it.
Now don't get me wrong, I don't want to disparage Brendan Eich. I couln't do a tenth of what he did in 10 days. It's just that you get what you pay for. They should have taken the time to fix JavaScript's flaws instead of marketing the hell out of it right away. (Or should have they? Maybe JavaScript would have failed if released a few months later? Damned market. Damned path dependence.)
No one is using the language Eich wrote "in 10 days" anymore, so that's a ridiculous comparison to make. You're dismissing all the effort TC39 has put into improving the language for many years.
The initial design severely limits the improvements you talk about. Sure, you can add better stuff like the === operator, but the crappy old == is still there. However stellar a work TC39 has done, they cannot fix the language without breaking everything.
I don't think anyone ever expected it to become a success, let alone a language used on everything from text editors to terminal emulators to embedded devices.
"To someone used to the mathematical rigour of typed functional languages,
this is patently false, just check out brian lonsdorf
"As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it."
Man people who would bail out of the entire project just because of one of the members' likes or dislikes on his bio snippet are petty, please don't optimize for those people...
It's not some dramatic "bailing out of an entire project". A more realistic scenario would be:
> "Oh here, that link sounds interesting."
> "Hmm, another visual programing system, I wonder how it works."
> Read for a few minutes, then clicks link to the about page
> Reads part about hating javascript. "Huh.. I wonder why they hate it so much"
> Gets distracted, makes some coffee
> Comes back, and without really thinking about it, closes tab, and goes back to previous task
In this scenario, they might have possibly investigated further and checked the project out. Overall, most people probably won't care, but I would guess the statement is slightly net negative.
Taking a step back, this entire sub-thread is a fairly ridiculous bikeshedding, and I do feel a little bad about participating in it, heh.
JS devs encounter a lot of low effort BS/FUD from JS-haters who are clearly talking out of their ass or obviously haven't advanced their understanding of JS since 2005. If you're making something awesome, somebody's going to genuinely be interested if it's genuinely awesome regardless of their "fake language" background. So yeah, if I see "hates <literally any language>" in a profile, I'd probably assume the developer is pretentiously arrogant or will have the propensity to build a toxic community that focuses on bashing alternatives instead of building itself up.
This was a super-valid position until Sept. 14, 2015, when Node.js and io.js combined to establish a stable runtime. From that day forward, JS/ES have been fast to change and stable.
I don't care what they done in terms of stable runtime. I mean, I care, but not in the context of the language itself. Language is all - combined! The runtime, syntax, libs, everything. I call it "experience" or "feeling". I like the idea to treat JS as web assembler, but as a language, JS is just a garbage. It will be garbage until you will be able to write code, that seems completely valid unless you are super JS geek and know that it will break. I will not reconsider my hate until you will be able to write `['10','10','10','10','10'].map(parseInt)` and get `[10, NaN, 2, 3, 4]` as a result (just a small example of many). Sorry if that puts you off.
The `map(parseInt)` example is an obscure strawman that exists solely due to historical purposes; it's very difficult to change this sort of thing in a language because it would involve one of two things:
1. Change the API of `parseInt`, break everything
2. Change the API of `Array::map`, break everything
If you want JS devs to respect your voice you may want to attack the more fundamental problems with the language, like its lack of type-safety, rather than the remnants of its "upbringing".
Sorry dude, I'm going to have to step in; you're being too strong in your counter attitude. I've been writing and teaching JavaScript professionally for many years, and while I don't hate the language, I don't blame those who do. After learning and using a statically typed language, it becomes absurd how much effort you have to put in to debug a JavaScript type error – a problem that is amplified by the language design.
What happens when you add 1 + undefined? Other dynamic languages make the sane choice of throwing an error immediately. JavaScript, however, silently gives you back NaN and continues chugging along. By the time a "real" error happens, you're stack traces away from the cause.
What happens when you call a function f with one argument when it expects two? Other languages would throw immediately. Instead, JavaScript silently sweeps in an undefined and continues chugging along. Combine that with the other flaw I mentioned, and your runtime error will, again, be distant from the true cause.
There's a reason TypeScript is getting insanely popular. It's the only way to code large JavaScript projects and stay sane.
The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base.
And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do.
Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.
> The problem I have with static typing (as widely implemented)
Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime.
This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance:
if true then 1 else "one"
This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).
I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems.
As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.
I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system.
It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true.
Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc.
protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system.
But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data.
Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools.
Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.
you are entitled to your opinion, and i appreciate that you offer it. and those are legitimate gripes. ive written it professionally for many years as well. there are alot of nice things about javascript as well, so in general i like the language. alot of what i read in the initial answer is a guy who wants to show he is a member of the cool kids club by hating on javascript. its so lame.
Try to be more charitable by seeing it from their point of view. Imagine being used to a language that helps you be rapidly productive and shields you from a huge catalog of mistakes. But one day you're forced to use JavaScript, and suddenly you've got nothing. It'd be like driving in a doorless jeep with no seatbelts on a high rise highway with no guard rails. Sure you can do what you want, and even in some nice, clever ways. But there are so many ways to hurt yourself, and no natural protections to prevent it.
To put it another way, it's like throwing a frontend developer into the world of C. Suddenly you have to be aware of and correctly manage your memory explicitly, whereas before you were safely protected from having to think about it.
Lastly, not everyone can voice their opinions so well. Communication is a difficult thing, and understanding what you're trying to communicate more so. If someone says they hate something, it's not always baseless. Instead of jumping to name-calling, have more patience in trying to understand why.
this is a good characterization of what causes people confusion, and i think the parallel with people going to c from js is totally right. i experienced that myself. its a great way to put it and i will probably use it, thanks!
the second point about being more understanding surely applies more to the person proudly hating a language with no constructive support about why, and little evidence of an effort to overcome the language's obstacles. sure, i dont know everything about this person, but i take the comment at face value, which seems to be the norm. maybe calling them out on it isnt helpful? i dont know, but it didn't seem that bad.
If the hate were towards a person, I would completely agree with you. But OP is only hating JavaScript-the-tool, so I have no contempt towards his opinion.
In contrast, if OP were hating on JavaScript programmers, then your indignation would be completely justified. But he's not, and I admit to holding a similar position: I hate C++ and prefer to never lay eyes on it again, but I have nothing against C++ programmers :) The difference between C++ and JS is C++ is less forced upon someone's career as the only language to work with.
thats a good distinction, and i suppose its defensible. but imagine you are a trumpet player, and a pianist walks by and says "i hate that non-instrument trumpet" unprovoked. no one is wrong to hate the trumpet. but saying it to a trumpet player, and then saying they aren't even a musician (implied by "non-language"), is going to catch heat.
and its undeniably true that javascript has got loads of warts. i mean, look no further than "javascript: the good parts" as perhaps the most recommended book. (i guess you already know this, but for the maybe 1 other person reading this...) but despite that, i enjoy the hell out of writing good js, and love that people can use what you make by going to web page. and w/r/t the warts, i feel that if they were corrected, my js life woulnd't change much at all. so when people point to the warts as evidence that its a bad language, all i can say is that while they are obviously bad, they dont end up mattering to me. thats clearly not true of everyone, but id bet its true alot. because of this, i find it pretty easy to spot people who are excited to hate js because they are pretty sure its a safe thing to hate and it will make them look in the know. i mean, i was guilty of this when i was younger with mysql and php.
and yes, people being "forced" to use js is surely contributing to the hate, probably the same way people hate having to use css. they look at them as afterthoughts, but its funny because in a lot of cases, its like the main thing that needs work. i just wonder why people cling to the idea that "real programming" has a certain look, when being good at js and css is super helpful and important to good web projects.
i suppose we are arguing for the same thing- basically open-mindedness and willingness to learn.
Two days after you two posted this thread of comments, and I must thank you for it.
The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.
Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.
Am I a bad programmer? Hmm. Identity can be a fragile thing.
> its so obvious that people are just looking for reasons to hate javascript
Why would anyone have the motivation to do that? Either it has given them reasons to dislike it, or it hasn't. Why do you think anyone is predisposed to looking for those reasons?
Even worse though,is to have your personal identity tied up in the language you work in. If you are actually Brendan Eich, then I get you taking it personally, otherwise, who cares?
the_cat_kittles I think you don't get the point of my answer or simply my answer was confusing, sorry for that. I did not wanted to start a big discussion here and just throw a controversial, stupid example. But it very clearly shows my main point. The point is that it is easily to write a code in Javascript that looks ok, but is not. The lack of good type system, legacy of how it was implemented on the beginning and everything connected to lack of general safety leads to this conclusion.
I disliked it myself up until ES6 when it started to be "enjoyable" or..should I say less annoying. I program in 6 languages (it may not be much but enough to draw a conclusion from a sample) and I can't say I have one without it's list of wtf's.
By placing big keywords in your bio like "Serial enterpreneur, haskeller, programming languages design freak, former senior R&D technical director in the biggest film studios in Europe" + "hates java script" and keeping your flag up here makes it look very unprofessional. Of course, who are we to judge if not...your target audience for a "functional programming language", visual or not.
I remember when RoR came out and some [1] "cool dudes" decided to mock everything else on the planet. RoR vs php, RoR vs this and that. It made me feel sick even though RoR was a big step up from everything else back then. It took me 2 - 3 years to even consider it because of that.
