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

171–180 of 183 posts

Re: The JavaScript Problem

#171

Post by BugBrother »

AnthonyMouse wrote: post #166
BugBrother wrote: post #102

Earlier quoted context omitted.

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…

I don't disagree with anything you wrote, except the first sentence.

But I'm cynical about the possibility to get a new bytecode standard out, without e.g. MS sabotag... extending it. Half the value of asm.js should be that if there is a working system already in place, the motivations for such shenanigans lessens.

Re: The JavaScript Problem

#172

Post by michaelsbradley »

jkrems wrote: post #163
michaelsbradley wrote: post #139

Earlier quoted context omitted.

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

With homebrew and homebrew-cask installed on Mac OS 10.9, I was simply able to do:

   brew cask install java
That might not cover the bases for every Java developer's needs, but leiningen seems to work fine with the resulting installation.

Re: The JavaScript Problem

#173

Post by teacup50 »

djur wrote: post #168
teacup50 wrote: post #149

Earlier quoted context omitted.

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.

That's really, really funny.

Engineering isn't math either, but you can't do it right without math.

Re: The JavaScript Problem

#174

Post by peterashford »

baddox wrote: post #76
AnthonyMouse wrote: post #62

Earlier quoted context omitted.

The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as…

If there exists a tool that compiles your language of choice to JavaScript, and the stuff you write in your language of choice works on modern browsers and is stable and performant, why do you care that it's JavaScript being compiled to and not byte code?

Because JS will always be compromised by being JS shoe horned into a role it wasn't designed for and not byte code optimised for the purpose at hand.

Shoe horning technologies into roles they weren't intended for could describe the entire scope of why the Web sucks (e.g.: HTML mixing presentation with semantics).

Re: The JavaScript Problem

#175

Post by AnthonyMouse »

BugBrother wrote: post #171
AnthonyMouse wrote: post #166

Earlier quoted context omitted.

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…

I don't disagree with anything you wrote, except the first sentence. But I'm cynical about the possibility to get a new bytecode standard out, without e.g. MS sabotag... extending it. Half the value of asm.js should be that if there is a working system already in place, the motivations for such shenanigans lessens.

EEE wouldn't work here. That only works when you have overwhelming market share. Microsoft has basically no browser market share on mobile and even on the desktop they no longer have so much that developers can afford to ignore everything else.

The way to handle Microsoft in a situation like this is to ignore them. Support the same IR on Firefox, Chrome and Safari and then Microsoft can play along or go home. At that point the worst they could do is implement an extended version that allows sites made for all browsers to work with IE but then encourage developers to make sites using Windows-specific features that won't work on other platforms. That's effectively what they tried with Silverlight and you see how far that got them.

Re: The JavaScript Problem

#176

Post by djur »

teacup50 wrote: post #173
djur wrote: post #168

Earlier quoted context omitted.

Programming isn't math.

That's really, really funny. Engineering isn't math either, but you can't do it right without math.

I know some people really want programming to just be an application of the lambda calculus. It's a model that really appeals to people who prefer a top-down, deductive model to their work. It's similar to the appeal that draws people to Austrian economics.

And yet that is not the original model for thinking about software, nor the only valid one. Haskellers who rely solely on deductive arguments in favor of their method are going to be stuck forever wondering why so few people are using their clearly superior tool.

Re: The JavaScript Problem

#177

Post by masswerk »

chrisdone wrote: post #136
masswerk wrote: post #109

Earlier quoted context omitted.

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

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.

Re: The JavaScript Problem

#178

Post by teacup50 »

djur wrote: post #176
teacup50 wrote: post #173

Earlier quoted context omitted.

That's really, really funny. Engineering isn't math either, but you can't do it right without math.

I know some people really want programming to just be an application of the lambda calculus. It's a model that really appeals to people who prefer a top-down, deductive model to their work. It's similar to the appeal that draws people to Austrian economics. And yet that is not the original model for thinking about software, nor the only valid one. Haskellers who rely solely on deductive arguments in favor of their me…

Less accurate "models" for "thinking about software" are less accurate, and whether they were thought of first or last has no bearing on that. The fact that you're using "earliest date of discovery" as supporting evidence demonstrates that you're not approaching the question as an objective observer.

This isn't a popularity contest, though if you were measuring popularity based on positive impact, that of Haskell has been substantial.

The only advantage to leveraging simpler and less accurate models is that they're easier for the people using them to understand at a micro scale -- at the cost of systemic accuracy and verifiability.

In being less accurate, they create systems that are more difficult to understand, more difficult to abstract and compose, more difficult to optimize, and more difficult to measure.

There's something destructive and anti-intellectual about trying to convince the world that deductive reasoning is just a matter of opinion.

Re: The JavaScript Problem

#179

Post by djur »

teacup50 wrote: post #178
djur wrote: post #176

Earlier quoted context omitted.

I know some people really want programming to just be an application of the lambda calculus. It's a model that really appeals to people who prefer a top-down, deductive model to their work. It's similar to the appeal that draws people to Austrian economics. And yet that is not the original model for thinking about software, nor the only valid one. Haskellers who rely solely on deductive arguments in favor of their me…

Less accurate "models" for "thinking about software" are less accurate , and whether they were thought of first or last has no bearing on that. The fact that you're using "earliest date of discovery" as supporting evidence demonstrates that you're not approaching the question as an objective observer. This isn't a popularity contest, though if you were measuring popularity based on positive impact, that of Haskell ha…

> The fact that you're using "earliest date of discovery" as supporting evidence

It was a fun discussion while it lasted, but conjuring words out of thin air and putting them in my mouth is where it ends. Thanks.

Re: The JavaScript Problem

#180

Post by teacup50 »

djur wrote: post #179
teacup50 wrote: post #178

Earlier quoted context omitted.

Less accurate "models" for "thinking about software" are less accurate , and whether they were thought of first or last has no bearing on that. The fact that you're using "earliest date of discovery" as supporting evidence demonstrates that you're not approaching the question as an objective observer. This isn't a popularity contest, though if you were measuring popularity based on positive impact, that of Haskell ha…

> The fact that you're using "earliest date of discovery" as supporting evidence It was a fun discussion while it lasted, but conjuring words out of thin air and putting them in my mouth is where it ends. Thanks.

"And yet that is not the original model for thinking about software ..."
Post reply on HN