3 ms·

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'

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".

briantakita 13y ago
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.
- tel 13y ago
  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.
  - briantakita 13y ago
masswerk 13y ago
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.
- chrisdone 13y ago
  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.
  - masswerk 13y ago
    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.

briantakita 13y ago

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.

tel 13y ago
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.
- briantakita 13y ago

masswerk 13y ago

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.

chrisdone 13y ago
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.
- masswerk 13y ago
  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.