3 ms·

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 no

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

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