Live data from Hacker News

The JavaScript Problem

haskell.org

121–130 of 183 posts

Re: The JavaScript Problem

#121
post #100
post #95

Earlier quoted context omitted.

Do you have an example?

Call a function "foo" that expects 3 arguments with 5 or 2 arguments, instead. Javascript will gladly accept that and not yield any error, not just at compile-time, but even at run-time! Unless the function explicitly checks that the argument list is correct, it will simply hide the bug. When changing function signatures in any language, it is the programmers' collective responsibility to fix all callers (some of whi…

How is that an issue ?

Re: The JavaScript Problem

#122
post #97

I'm surprised that lack of module system is the first thing brought up. Is that really such a big deal? It's very much just a nice to have for me and has plenty of third-party implementations if you want it.

It's just another annoying thing on the list of warts with Javascript that make maintain a large codebase a pain in the arse. Plenty of third party implementations is half the problem. Want to import a module by somebody using a different module format? More pain in the arse!

Most large projects use AMD and it works just fine.

Re: The JavaScript Problem

#123
The problem you see is what I like about the language.

The javascript languages is great because I'm not forced into other peoples way of thinking. With javascript I can choose my own paradigms.

module system: You can implement your own. Node JS has one built in.

verbose syntax: Use an editor that support macros. But compared to dot net and Java, the JS syntax is not verbose at all.

getters and setters: I actually love not having to to write getters and setters every time I want to add a property.

One important part in JS though is good naming. You can't get away with naming everything x, y, z, a, b, c, etc.

Once you figure out that everything in JS is objects, it will be much easier.

Re: The JavaScript Problem

#124
post #35

Earlier quoted context omitted.

> Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) I've never really heard the term untyped before -- I guess I'm old school and still call that dynamic typed. But JavaScript is also weakly typed. It will automatically convert strings to numbers, etc. Some languages, like Python, are dynamically typed but also strongly typed: No type declarations but no a…

It's been popping up lately. It's meant as a smear on dynamically typed languages, because dynamic has a positive connotation and untyped is decidedly negative. Pretty similar in intention to uni-typed. http://stackoverflow.com/questions/23282683/is-clojure-uni-t... Edit: Sorry, learned something new just now. I'm very, very wrong. Untyped is where operations are valid on everything because it's all a sequence of bit…

Uni-typed is actually a very specific technical term. Mathematically you can prove type theorems about languages regardless of whether they implement types as language features. Dynamic languages are thus modelable like this and when you do so the first approximation is to say that a dynamic language is a language with a single type (uni-typed).

The reason this is valuable is it opens up directly the techniques for "hybrid typing" such as PHP->Hack and Javascript->Typescript. It also is the basis for the compiler using type inference to accelerate certain portions of the code.

Re: The JavaScript Problem

#125
post #43
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.

Javascript is a tiny language, but it pack a serious amount of gotcha. If you learn the javascript way, you just realise that the core language provide little to no tooling around it. Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own. Of course, javascript run in the br…

> Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own.

Hmm, this is definitely something of an exaggeration. With old-school cross-browser JS you just need something like Backbone's `extend` implementation (jashkenas posted a shorter example a while back [1]) for inheritance and underscore.js [2] for your functional aspects (assuming that's the sort of thing you mean).

If your criticism is that those things had to be written, then this was solved with ES5 which gives you `Object.create` [3] for your inheritance needs and `map()`, `filter()` et al for your functional stuff.

I certainly don't see why you'd ever need 'to write a whole set of utilities and extensions of your own', that reads like pretty hand-wavey and unfair criticism.

> if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile.

I think you are depicting a pretty broadly-shit scenario that I don't think you can say any other language ecosystem deals with well. Trying to support many different clients is a nightmare across e.g. mobile and the desktop using any other language/ecosystem too, with same 'regular team'. And I don't agree there's anything particular about JS that will make you 'cry more often that smile' in that scenario, but that's obviously subjective.

  [1] https://news.ycombinator.com/item?id=7244023
  [2] http://underscorejs.org/
  [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create

Re: The JavaScript Problem

#126

Earlier quoted context omitted.

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…

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

Re: The JavaScript Problem

#127

I accept that I will be downvoted for this. 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…

> People have different styles and preferences. 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 t…

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?

Re: The JavaScript Problem

#128

Earlier quoted context omitted.

> JavaScript and HTML are a lot more bloat than machine language code written to the wire. http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web). And if you're talking platform-dependent machine code, that's likely _wors…

That's not how you measure bloat. There's a huge runtime associated with that JS code, and you ignored performance.

Ah, you mean client memory bloat, not transfer bloat (i.e. pageload time). That part was not very clear at all.

You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving.

I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.

Re: The JavaScript Problem

#129
post #84
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…

> We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. Obvious - because you just said "with better defined as has more static typing, static typing is better". That's an empty statement if I ever saw one.

>because you just said "with better defined as has more static typing

No I did not. Haskell's type sistem is not "more static" than javas. It is more powerful. This makes it better. There are not varying degrees of "staticness". There are varying degrees of expressiveness. Haskell is on the "very expressive" end of that scale. So it makes sense to assume that haskell people consider more expressive type systems to be better.

Re: The JavaScript Problem

#130

Earlier quoted context omitted.

> People have different styles and preferences. 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 t…

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.

Post reply on HN