Here's the problem with your post - and it has nothing to do with what you think it does. It attacks two things at once and quite distinctly. On one hand you're defending JavaScript - and that's separate from your attack on the Haskell community. It's just unfocused and confusingly conflated. I'm not going to down vote you, but you need to organize your thoughts a little more coherently if you don't want to get down voted.
PS The reason there are so many JavaScript sucks posts is because JavaScript, a language designed for very menial things in 10 days in the mid 1990s, has become the lingua franca of the world and is used for sophisticated applications outside of its wheelhouse. A lot of very respectable people believe it's a poor tool for the complex applications that it's being used for and the less respectable people just reiterate this as "it sucks". It's not that it sucks for making a photo gallery, it's that it sucks compared to other languages for making a rich, modern, immersive, large application. They key word there is large. All of the reasons they reiterate about the "why" it sucks are only relevant when you couple it with the "large".
Apologies about the lack of cohesion of my post. It's tough to make posts on a phone.
I have to confess that my interactions with the Haskell community have not been positive as I would like. My development preferences are not respected by Haskell fans. I'm ok with disagreement. However, if I do "defend" javascript, I'm attacked as being ignorant because I don't see things the same way.
My point is javascript can be an amazing experience, and very scalable, if approached in certain ways.
I acknowledge that Haskell is amazing too.
>It's not that it sucks for making a photo gallery, it's that it sucks compared to other languages for making a rich, modern, immersive, large application. They key word there is large.
Very large apps have been made in c. I'm making a fairly large app in javascript. It's been pretty fun. I'm confident that the app im working on can be scaled to be considerably bigger.
A problem is most people try to use techniques that are more appropriate in other languages.
I think the "very large app" idea is something of a strawman. It's used by all languages from time to time in order to say "hey, look, I can be serious too!" but it's clear that with enough effort and familiarity you can write a large app in anything.
I think the real distinction between Javascript and Haskell runs much more deeply and is difficult to talk about. As a hint to the moral here, many of the posts defending Javascript here try to talk about its syntactic flaws as being not so bad. I don't think anyone in the Haskell community gives a damn about syntax—not in that kind of way—because they've all learned quite nicely that syntax is a tiny fraction of what makes a language interesting.
So the real distinction is semantics. Semantics are hard to argue about because it's difficult to distinguish between semantics until you've either studied them in the abstract or experienced several wildly different kinds. It's also hard to argue about the value of different semantics until you've seen those different kinds used in anger.
Prolog is different from C is different from Erlang. Lisp isn't so different from C, but it does have some cute functional tricks. Clojure is different from Lisp in spirit as its semantics are often distributed and immutable, though as a language it cannot be trusted that way, only as a community.
Haskell is far different from all of those because it's pure, lazy, stupidly committed to its System F and Hindley-Milner heritage, and has one of the most interesting and powerful subtyping systems of any language today. It's completely different from everything in my prior list, though there's passing similarity to Scala and OCaml.
Someone might argue that the semantic island where Haskell lives is better than the one where Javascript lives. They might argue historically by noting that Haskell builds upon 30 years of PL research while Javascript is lightly influenced by one, interesting historical point. They might argue categorically by saying that Haskell's semantics benefit so much from being mathematical. They might argue theoretically by saying that Haskell's semantics can be shown to subsume the semantics of other languages (by the uni-typed argument and Dynamic coupled to monadic regions).
Javascript seems to be relegated to saying that it's not so bad because you can get stuff done in it, it's more interesting than C or Java, and dynamic typing is not that bad once you get into it.
From the Haskell perspective, the first two are givens and the last one is silly knowing that in Haskell you can choose to use Dynamic types whenever you like and they become quickly relegated to just the problems they're most appropriate for.
> They might argue historically by noting that Haskell builds upon 30 years of PL research while Javascript is lightly influenced by one
Javascript, since it has not "evolved" over a long period of time, is more of a blank slate & more flexible in it's semantics. It does not force you into a particular tradition, so you are free to develop your own semantics. There is much life into what you can do. It's up to the programmer to evolve the practice.
I'd like to explore the root of our differences. I have a hard time assimilating deep traditions. I respect my autonomy as an individual & creative being.
I prefer to be directly exposed to the problem and create solutions & practices based on that. I can't blindly follow a teaching or tradition. I'm always questioning.
There are advantages & disadvantages to this. A disadvantage is I may be repeating mistakes that others have already done. In my case, I have a hard time fully appreciating other's mistakes because I was not presented with the same situation. Group oriented developers tend to despise this "independent" approach because it does not follow already established conventions. I've gone years with the mindset of if it's not a standard approach, then the code is "unmaintainable". I have since evolved to realize that code is like an interactive story or engine. If you can clearly express intent & purpose and there's automated verification (testing, type systems, etc.), then it's maintainable.
Advantages to this "independent" approach are it's easier to assimilate the good parts of multiple traditions. You can also reject the legacy overhead of a particular tradition. Like how Bruce Lee rejected the extraneous movements of Kung Fu when he created Jeet Kune Do, which is an assimilation of Kung Fu, Karate, Boxing, Fencing, etc. The approach is "Absorb what is useful, discard what is useless". http://en.wikipedia.org/wiki/Jeet_Kune_Do
Bruce Lee, like most true innovators, was criticized by his contemporaries. However, when the rubber hit the road, he kicked everybody's ass.
That can be great when there are 1 to a few programmers with a like mindset. I prefer to be in such environments. It can be quite difficult in projects with large teams. I don't like such environments. Politics become necessary & it feels dehumanizing.
I'd argue that you're correct in highlighting a certain tradition but that most arguments about the advantages of Haskell are completely orthogonal to this idea.
Haskell is more powerful than JavaScript as you can embed JavaScript into the semantics of Haskell. This is where the ideas of existential types and unityped languages come into play. Haskell is sufficiently rich to directly emulate JavaScript as a type-contained embedded language. Thus, all of the same exploration is available.
This idea is highly idiosyncratic Haskell. Nobody would honestly suggest it as Haskell guides the intuition of the programmer quite strongly. This embedded language must also immediately throw away much of the machinery and speed of Haskell.
The reasoning again is not that Haskell is right but instead that its semantics are a superset of those available in JavaScript.
But given this inclusion, most people rarely use features like pervasive state and dynamic typing while programming in Haskell. Part of this can be answered as language convention force and regularity, but these techniques do show their advantage at times. This is what gives the Haskell programmer confidence that they understand the value of many language features: they've constantly redefined "Haskell" in many miniature, well-interleaved parts to be whatever makes sense for the problem at hand and thus have seen the value of a variety of language features.
So I'll end by suggesting that once you learn Haskell this notion of "design your own solution" is actually even greater than the one in JavaScript. I don't take this argument to be ground truth, but instead just a challenge. JavaScript and Haskell both allow the programmer great control over the semantics of their language, and Haskell has many mechanisms which give that power greater leverage than JavaScript can.
But by doing so, the post marks a real problem: The critique of JS seems to be mostly based on the prestige the languages is enjoying -- or rather the lack thereof -- in a community.
Any of those features is to be found in highly respected languages, too. Most of the rants are about respect and not being willing to respect the specifics of the language. Why has JS to be built to suit test suites and tool chains originally designed for C/C++? Why not adapt those tools for the use with JS? Isn't this, what a universal machine is for? "Sucks" may be an easy answer, but it shouldn't be a general one.
Edit: There are only few high level languages which would adopt to such a wide range of programming patterns like JS does, or which would allow to be redefined by such large an extent. (This is mostly for the much frowned on late binding.) Isn't this rather adorable than awful?
Other reasons, why JS would "suck" seem to be quite deliberately: Curly brackets -- what about C or Java? Semicolons -- In the beginning, JS was critiqued for not requiring them and using them rather as a separator (in the first syntax version). Verboseness -- isn't the lack thereof why APL used to be quite a horror? Type coercion -- Isn't this, what made Perl that useful as a glue-language? The critique is quite à la mode.
Nope. JS has technical problems which were all stated clearly and with references to academic works and industry examples (Google). You simply choose to ignore my carefully worded criticism calling it a “rant” and an “easy answer” and “à la mode”, with talk of irrelevant things like C/C++ and platitudes about Turing machines.
Sorry to see you downvoting a comment which doesn't please your expectations.
1) You are ignoring the notion of some, if not most, of the incriminated features being also present in highly regarded languages.
2) "Most of the rants" (please mind the plural) doesn't address your post, but is on certain communities which are producing anti-JavaScripts post in series.
3) "easy answer" is quite what it means. There are so many patterns that are just reproducing approaches to be found in other languages for things that are already built in or are overriding built-in features. (My favorite one is using "var self = this;", while `self` is a predefined variable in JS, pointing to the global object. What does this mean for code maintainability? What is "self.location" in a browser? Mhm. Just read the whole code to know.) At least some of these pattern do in deed reflect some laziness in coping with the language. Also, "easy answer" was meant to address the stereotypical use of "sucks". (P.e.: There is much criticism on the behavior of `this` in the DOM-interface, which is, by the way, not part of the language. So, read the specs and use "Object.handleEvent". Criticize deprecated implementations of the DOM-interface in older IE for lacking this, but do not qualify the language for this by "sucks"...)
4) "à la mode", again, isn't specific on your post, but on various historic positions and utterances on JavaScript to be found over the last 19 years. If you would try to read this carefully, you would find them to be contradictory and mirroring the popular notions of programming styles of the day. This is, what "à la mode" means. Take the criticism on the semicolons, for example: In the times when JS was critiqued for not requiring them (à la "a serious language has explicit statement delimiters as a requirement"), CoffeeScript would have been regarded as being even worse. Obviously, this perspective changed over time.
5) The notion of test suites (and the tradition of having analysis tools especially for C/C++) is not deliberately, but reflects a real raison d'être of most of the frameworks attempting to fix the "problems". While these frameworks highly depend on late binding themselves, the most critiqued feature -- which is also a real problem for analysis tools -- is late binding. I would be optimistic that these issues could be theoretically overcome, based on the concept of "Turing completeness". (There is no reason, why paths that can be resolved by a runtime wouldn't be to be resolved by an analysis tool. Modifying the language instead of adapting the analysis tools is what I would call an "easy answer".)
I would be grateful, if you would bother to read a comment, or just would simply ignore it, rather than just taking it as an apparent aggression. There are developers who have committed to this language and who are quite happy with its working. (As another recent post, on JS framework reproducing the schemes of enterprisy backend schemes, put it: "You are ruining it".) There are different notions on this issue and there is no need of demonizing contrary perspectives.
So you didn't read this (again)? Yes, it's a carefully worded criticism on my side, too. And as is clearly stated in the intro of the initial post, it's on criticism on a language from the point of view of a community formed around an other language in general. (I'm in the JS-business for 18 years now and have contributed some to its use, so I would appreciate it, if you would consider this to be more than just a deliberate utterance.)
And BTW, you accused me of things (in the post above) that weren't in my statement at all. I was just pointing out that there was in deed a point made by briantakita by noting that the various articles on JS published lately are mostly originating from communities grouped around other languages. And that perspectives may vary. Even the criticism on JS varies over time.
PS The reason there are so many JavaScript sucks posts is because JavaScript, a language designed for very menial things in 10 days in the mid 1990s, has become the lingua franca of the world and is used for sophisticated applications outside of its wheelhouse. A lot of very respectable people believe it's a poor tool for the complex applications that it's being used for and the less respectable people just reiterate this as "it sucks". It's not that it sucks for making a photo gallery, it's that it sucks compared to other languages for making a rich, modern, immersive, large application. They key word there is large. All of the reasons they reiterate about the "why" it sucks are only relevant when you couple it with the "large".