Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Problem

haskell.org

Post reply on HN
Print view View original

161–170 of 183 posts

Re: The JavaScript Problem

#161

Post by briantakita »

Peaker wrote: post #72
jurassic wrote: post #31

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is and read a few top books on the language to learn the "javascript way", my life got a lot better. It's really not that bad. I actually like it a lot, but there are still a lot of ignorant people who will look at you as if you're not l33t enough to know that foo la…

IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts. This can easily hide so many bugs, it's amazing it is acceptable to anyone.

In practice, this issue is rarely (like 1-2 times a year) encountered. And then functional tests catch the error. It would not be acceptable if it was a constant thorn.

Re: The JavaScript Problem

#163

Post by jkrems »

michaelsbradley wrote: post #139
jkrems wrote: post #86

Earlier quoted context omitted.

Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.

Getting the JVM installed requires very little effort. On ubuntu linux, for example, apt-get can be used to install openjdk or Oracle's distribution. Travis CI provides java (with a choice of JDKs) in its testing environments. So, I understand your point, but the installation "overhead" seems more like a mole hill, hardly amounting to even a speed-bump sized obstacle.

I recently had write up for a README how to install the JDK and set it up correctly on OSX. You'd be surprised. Thanks to Oracle's policies it isn't even close to where other runtimes/sdks are (e.g. installing ruby, node, gcc, go, ocaml).

Re: The JavaScript Problem

#164

Post by jkrems »

teacup50 wrote: post #132
jkrems wrote: post #84

Earlier quoted context omitted.

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

That it's better to accurately and reliably modeling complex systems and invariants through provable assertions is objectively is no more an empty statement than to say that it's better to apply informed materials and structural engineering to the design of complex physical products than to build ad-hoc designs of unknown parameters through guesswork.

If you think that building software is like building bridges, then yes. If you think that it's the exploration of a problem domain that may not be known to you at the start of the process and is subject to various degrees of iteration (e.g. a process more like writing a script/play), then you get vastly different requirements. That's what I meant by "if you define better as more static typing". "Better" is a normative statement and can never be absolute, it's always relative to a choice.

Re: The JavaScript Problem

#165

Post by cbhl »

chipotle_coyote wrote: post #83
cbhl wrote: post #54

Earlier quoted context omitted.

The web was multi-lingual, it's why script tags have a "type" parameter. I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.

Uh, scripts aren't plugins, right? In theory there could be other scripting languages for use in web browsers, which is what the "type" attribute would have been used to indicate. It's just that nothing else ever really took off. Other than Microsoft's VBScript, the only browsers I can think of that supported other scripting languages were early proof-of-concept attempts like Grail. I think you're a bit confused abou…

I was responding to two statements in one comment; I apologize for the confusing non-sequitur.

I do agree that plugins are OS and CPU specific, but I think the popularity and explicit lack of support in iOS and Mobile Safari (which, to my understanding, are stripped down ports of OS X and Safari) really caused web developers and their clients to move off of Flash (and other plugins). For a number of years, Adobe shipped a version of Flash for Android, and I'm under the impression that they were always willing to port it to other platforms/devices if paid enough money (since the Linux binaries had an explicit restriction from inclusion in devices; you could only use them with general-purpose PCs). Java ME ran on phones for years, too, although I don't recall anyone shipping a mobile browser with Java SE plugin support. If someone (a client or web developer) wanted their website to work on iPhone, they had to remove the plugins, and I think many people just started designing around that constraint.

Re: The JavaScript Problem

#166

Post by AnthonyMouse »

BugBrother wrote: post #102
AnthonyMouse wrote: post #64

Earlier quoted context omitted.

There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler. But why would…

I came into this discussion many hours late, but I have to ask: Why are people discussing as if asm.js didn't exist?! It is fast. (It even support integers!) To me, asm.js looks like a bad kludge -- and a great road ahead, just extend it a little bit over the next decade with the stuff compiler writers will clamor for. Am I missing something?

What you're missing is that there is no need to do that. Using JavaScript as an intermediary representation for other languages on a permanent basis is kind of ridiculous. Improving browser support for JavaScript-as-IR provides no benefit over adding support for a "real" IR and introduces superfluous complexity which is the enemy of both performance and security.

Compiling other languages to JavaScript is a tolerable transition mechanism while browsers that don't support something better are still popular, but trying to improve the ability of browsers to interpret compiled-to-JavaScript code from other languages is farcical -- if you're going to update the browser then update it to support something better than JavaScript, not to improve the performance of the horrible legacy transition kludge.

Re: The JavaScript Problem

#167

Post by teacup50 »

jkrems wrote: post #164
teacup50 wrote: post #132

Earlier quoted context omitted.

That it's better to accurately and reliably modeling complex systems and invariants through provable assertions is objectively is no more an empty statement than to say that it's better to apply informed materials and structural engineering to the design of complex physical products than to build ad-hoc designs of unknown parameters through guesswork.

If you think that building software is like building bridges, then yes. If you think that it's the exploration of a problem domain that may not be known to you at the start of the process and is subject to various degrees of iteration (e.g. a process more like writing a script/play), then you get vastly different requirements. That's what I meant by "if you define better as more static typing". "Better" is a normativ…

I don't see how it follows that iteration reduces the degree to which one must understand a system. That's just a rephrasing of the attractive but ultimately empty "dynamic typing is just more creative."

Bridges (or car engines, or any other engineered product) aren't invented whole cloth sans iteration. However, it's understanding of the invariants of the iterated system that allow for directed iterative design and ultimately better products.

Rather than repeat this argument, I'll refer to https://news.ycombinator.com/item?id=7656184

Re: The JavaScript Problem

#168

Post by djur »

teacup50 wrote: post #149
djur wrote: post #147

Earlier quoted context omitted.

The chauvinism involved is the assumption that a type theory is the only legitimate way to assess the quality of a programming language's type system. Haskell is, of course, a near-ideal language when judged by the values of its creators and advocates. The inability to recognize that those values are subjective is chauvinism.

It's chauvinistic to believe that the only way to assess math is through deductive reasoning? By that measure, all "STEM" fields are inherently "chauvinistic".

Programming isn't math.

Re: The JavaScript Problem

#170

Post by pdonis »

wyager wrote: post #159
pdonis wrote: post #153

Earlier quoted context omitted.

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

I agree, for certain types of applications. But as a general statement applying to all types of applications, I disagree strongly.
Post reply on HN