Live data from Hacker News

The JavaScript Problem

haskell.org

151–160 of 183 posts

Re: The JavaScript Problem

#151
post #126

Earlier quoted context omitted.

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…

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 defendi…

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

Re: The JavaScript Problem

#152

I take issue with the paragraph about how Javascript sucks: * Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem. * Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience. * I think the syntax argument is laughably ridiculous. Programming languages that live…

I guess the Haskellers noticed this HN thread. One moment my comments were at 2 points, the next they are at zero. It seems to be the same for other non-anti-Javascript comments.

If you're trying to solve the perception of being snooty and unpleasant (as mentioned in this thread), downvoting everything isn't going to get you far.

Re: The JavaScript Problem

#153
post #142

Earlier quoted context omitted.

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.

Re: The JavaScript Problem

#154
post #126

Earlier quoted context omitted.

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 defendi…

> 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 pr…

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.

Re: The JavaScript Problem

#155
post #5

Earlier quoted context omitted.

Did you not read my last sentence? I'm actually not free to add the information. There's a special registration process that requires human intervention. If the Haskell Wiki didn't require me to e-mail somebody personally and ask for permission to register, I'd be much more inclined to provide a one-of edit. By the time this person gets back to me (he's probably in Europe), I'll have neither the time nor inclination…

Good point, it was full of spam and registration was closed. I forgot about that. It was because we had a really old MediaWiki version so it was actually unsafe to allow anyone untrusted to post on it due to exploits possible at the time. I say “we”, I don't have access to manage haskell.org. I'mma ping the mailing list to see about fixing this.

I think that's an excellent idea. Well-done.

Re: The JavaScript Problem

#156

> lack of module system ES6 fixes this with, well, a module system. > weak-typing, Yup, this is a problem. > verbose function syntax, ES6 fixes this with arrow functions. > late binding Does this just mean dynamic typing? Well, yes, JavaScript is dynamically typed, but I wouldn't call that a language flaw. Static vs. dynamic typing is a tradeoff. > which has led to the creation of various static analysis tools to all…

[deleted]

Re: The JavaScript Problem

#157
post #96
post #60

Earlier quoted context omitted.

>It's sad that we should expect Haskell users to be chauvinistic about static typing. We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. >I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw". Try looking on the internet. Every "static vs dynamic" argument has 99% of the…

You just proved djur's point.

What's wrong with being passionate about something you believe in?

It seems to me that this "chauvinism" is in the eye of the beholder, offended that others are suggesting that the tools they have invested time in may not be the best way to do things.

Personally, I am quite excited by the prospect of learning and investigating better tools. I think we're only just beginning down the road to finding better ways of programming.

Re: The JavaScript Problem

#158
post #77
post #34

Earlier quoted context omitted.

Javascript's real problem is unfamiliar semantics hidden behind familiar syntax. It throws people off and they hate the language because they think it's weird. Really, they just haven't learned how to actually use it.

Doesn't that argument get weaker as JavaScript gets more widely used? It's already one of the most prominent languages in the world, and is probably increasingly the first programming language encountered and learned by beginners.

One problem is that these users do not necessarily understand the semantics. I helped a friend of mine, a reasonably competent programmer, debug his javascript once. He had no idea that you needed to use "var" in order to make a variable local! He'd written quite a lot of javascript without triggering any funny behavior until this bug.

So, instead, imho, the argument gets stronger. Why is the first programming language encountered by beginners these days full of traps? How cruel! What a poor impression of programming they must get.

Re: The JavaScript Problem

#159
post #153
post #142

Earlier quoted context omitted.

> 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 th…

Static typing can save a lot of time otherwise debugging later, and really isn't that much of a time investment.

Re: The JavaScript Problem

#160

Earlier quoted context omitted.

Just upvoted the post, sorry. ;-) 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…

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?”

I never found javascript to be expensive. Sorry, but incorrect analogy.
Post reply on HN