My impression of the Haskell community is its full of snobbery and complaining.
This has got to be the 4th javascript ducks post on hn in the past week.
I like hearing the positive aspects of Haskell. However, the language x sucks posts are tiresome.
Develop an imagination. Javascript can be wielded very effectively. It's just different. I hope that I or someone else wires posts on what can be done to be effective with javascript and weakly typed systems.
There are advantages to using weakly typed languages, mostly centered around flexibility and rapid iteration. The disadvantages are alleviated by comprehensive functional or black box testing. Skip the unit tests.
I feel liberated by not having a strong type system restricting my options. Ymmv. People have different styles and preferences.
>My impression of the Haskell community is its full of snobbery and complaining.
Probably because the Haskell community is used to having a programming language that is, in and of itself, very good. They complain because they know what they're missing when they have to use inferior tools.
>Develop an imagination. Javascript can be wielded very effectively. It's just different.
The same can be said of x86 assembly. That doesn't mean we don't complain about programming in it, and we don't try to find better alternatives. The entire field of programming language development is about finding tools that are better than the old ones, even if the old ones work OK.
>The disadvantages are alleviated by comprehensive functional or black box testing.
If you think "more testing" alleviates all the problems of weakly typed languages, you have no idea what you're missing.
>I feel liberated by not having a strong type system restricting my options.
If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.
"I like assembly because it lets me do any operation on anything."
>>I feel liberated by not having a strong type system restricting my options.
>If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.
I'm always baffled about how people say that using a dynamic language feels "liberating". I feel completely the opposite; I have to be extremely more careful with a dynamic language since either there is no compiler or it can't detect many errors, so I have to do it myself (because, and this is a very important lesson for absolutely everyone without exceptions: you will commit mistakes, no matter how good you are or how good you think you are). Getting rid of static typing feels to me like, above all, getting rid of a lot of very useful guarantees.
Aren't these two equivalent statements? Liberty to do any particular thing, ever, increases the ability to do something wrong. And so requires more caution. That doesn't stop restrictions that would alleviate said caution from being overbearing themselves. (Maybe they aren't always overbearing, either way...)
> Liberty to do any particular thing, ever, increases the ability to do something wrong.
The difference is that "liberty" tends to increase one's ability to do both right and wrong. Dynamic typing tends to only increase one's ability to do wrong.
> Dynamic typing tends to only increase one's ability to do wrong.
Apparently you place no value on programmer time. Why should I have to waste time with type declarations that add no benefit to my program? Why should I have to construct an artificial type hierarchy just so I can write common code to deal with two different kinds of objects that are duck-type compatible but don't happen to share a common base type that the type system recognizes?
I agree that there are certain kinds of applications where static typing can be a benefit that is worth spending the extra programmer time; but the claim you are making is much stronger than that.
Static typing gives me the liberty to explicitly define much more complex ideas in ways that leverage the compiler to create powerful and beneficial systems that would otherwise be untenable in a language in which one could not leverage the intelligence of the type system to offset their human limitations.
This is why unit testing took over the dynamic language world more than a decade ago.
And at least in Perl, which have a bit of extensible syntax, you can declare parameter types of methods/functions. That is especially a good idea for external APIs to libraries, etc.
All tools have quirks, which forces a bit of change in how you use them. You have to look at the total sum of these effects. How much extra days will it take to learn? How much will the work arounds cost you? Etc.
Granted, e.g. JavaScript have more weirdness than should be possible -- but is is fast, fun and has lots of use cases.
>If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.
Only a perfect type system is capable of preventing only wrong things, and allowing all correct things. In the mean time, we're left with things that are slightly less perfect. Like OCaml, Haskell, SML, Java, Smalltalk, Ruby, Javascript, Python, PHP, Prolog, and everything else that even attempts a type system.
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.
In terms of Haskell, it's not a question of style or preference, but provable correctness of the underlying theory.
I don't think programmers should have to be category theorists to 'effectively wield' a language, but category theorists sure as shit ought to be involved in designing the language being wielded.
I'm not a Haskeller, but I very much respect the research they've done, and continue to do -- and how it significantly improves the languages I do use.
However, the design and culture of languages like JavaScript are very much mired in inconsistent misguided design and cultural anti-intellectualism; they do not and can not benefit from the advancement in the state of the art, and are the programming equivalent of building bridges and skyscrapers without consulting structural/material engineers, based on a back-of-the-napkin sketch.
Personally, I don't prefer static typing -- I simply don't know of any other mechanism by which I can actually have a hope of understanding software I'm writing of any appreciable level of complexity.
I don't see where "preference" fits in here, other than "preferring" to not actually fully understand the system you're building.
Bold claims and strong language do not make up for a lack of citations. You prefer static typing because you admit it is the only hope you have of understanding your complex code. However you dismiss other peoples' preferences by claiming they are ignorant of the systems they are building. Are you, perhaps, the one true Scotsman?
It's not possible for anyone to build complex software in a unityped language while having a full, complete, and verifiable understanding of their own system invariants at any given moment.
Claims otherwise are the literal equivalent of making complex mathematical assertions without a single condensed proof.
This isn't opinion, any more than a formal proof is opinion.
You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. Whatever happened to each his own?
"By understanding the constraints, engineers derive specifications for the limits within which a viable object or system may be produced and operated."
Without understanding one's system, it is impossible to understand its relation to one's constraints, and it is impossible to define the specifications within which that system operates.
It's possible to build a car or an engine without understanding the math and science behind them, but it's impossible to build an engine of known specifications, it's impossible to provably assert that it operates within those specifications, and it's impossible to engage in directed design based on those specifications and defined operational limits.
The best you can hope for is purely empirical evidence, and empirical evidence is of limited utility without a theoretical framework in which it can be applied to extrapolate further knowledge.
As a result, systems designed and implemented without concern for understanding the theoretical basis of their operation invariably perform more poorly and cannot compete with systems designed and implemented based on building and applying a theoretically driven specification and understanding of constraints.
To willfully prefer ignorance is objectively worse.
> Whatever happened to each his own?
Applied maths. It's either correct and verifiable or it's not.
This wiki page is 2 years old, I assure you the Haskell community settled this debate years ago and have moved on with our lives. We've since implemented a bunch of compilers to JavaScript. I suspect, rather, that you are criticizing the part of the HN community that submits links and those that upvote them.
For what it's worth, for someone calling people “snobbish” and “complaining”, it's quite rich to make a comment which is complaining and to say “develop an imagination.” :-)
These rants really seem to be based on the degree of respect some languages are enjoying in a certain community. Take weak typing / type coercion for an example: This is a common feature of scripting languages of the time, e.g.: Perl. I never read Perl being complained on for the same issue, which might well be, because it is a "serious" system language and because you might have to "really" learn it for any advanced use. (Even the boolean testing of int return types in Unix and C could be considered as some kind of premature type coercion.)
Late binding is probably most powerful feature of the language. (The language is built around it.) If it doesn't go with your test suites, considering that both the language and the language the tests are built with are Turing complete, adapt the tests rather than the language. This is a bit like ranting on C not being Logo and for it having other output facilities than a turtle.
Why not just develop in JS -- read: think JS --, for a change?
Horses are okay, but they're expensive, require much more maintenance, can only go about 40mph for a brief period of time, and can only seat two people, uncomfortably. And you're telling people who want to build roads to put cars on “why not just think in horses for a change?”
You might as well say "incorrect human being", but okay.
> I never found javascript to be expensive.
That's very good for you. I'd stick with JavaScript if I didn't find it a horrible maintenance burden. But I do. You're free to differ, but you must accept my experience as part my criticism, you can't discard that and then attack what remains.
Why would that happen? Ignorantly bashing haskell strawmen is pretty common here. Btw, while you hit two of the biggest ones, you did forget to complain about it being "academic" and thus unusable for "real world" programming. That should be pretty much standard by now.
My impression of the Haskell community is its full of snobbery and complaining.
This has got to be the 4th javascript ducks post on hn in the past week.
I like hearing the positive aspects of Haskell. However, the language x sucks posts are tiresome.
Develop an imagination. Javascript can be wielded very effectively. It's just different. I hope that I or someone else wires posts on what can be done to be effective with javascript and weakly typed systems.
There are advantages to using weakly typed languages, mostly centered around flexibility and rapid iteration. The disadvantages are alleviated by comprehensive functional or black box testing. Skip the unit tests.
I feel liberated by not having a strong type system restricting my options. Ymmv. People have different styles and preferences.