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

61–70 of 183 posts

Re: The JavaScript Problem

#61

Post by copergi »

briantakita wrote: post #23

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…

>I accept that I will be downvoted for this.

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.

Re: The JavaScript Problem

#62

Post by AnthonyMouse »

jmspring wrote: post #41
kenjackson wrote: post #32

Earlier quoted context omitted.

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a…

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

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 that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.

Re: The JavaScript Problem

#63

Post by copergi »

owenversteeg wrote: post #14

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…

Javascript is weakly typed. And untyped does not mean no type declarations. It means no types, just like it says. Assembly is untyped. Javascript is dynamically typed. Very different. http://en.wikipedia.org/wiki/Programming_language#Typed_vers...

Javascript does not define the implementation details. It does not have to be interpreted, and in fact I don't believe any modern implementation is interpreted. Javascript is generally compiled to byte code which is then run in a VM, or native machine code (V8 at least does this). There is no reason javascript could not have a static type system, there are statically typed scripting languages. It is dynamically typed by deliberate decision, not "we can't do it any other way".

Re: The JavaScript Problem

#64

Post by AnthonyMouse »

_delirium wrote: post #56
kenjackson wrote: post #46

Earlier quoted context omitted.

JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.

I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?

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 you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.

Re: The JavaScript Problem

#65

Post by bzbarsky »

kenjackson wrote: post #46
jmspring wrote: post #41

Earlier quoted context omitted.

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.

> 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 _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?

Re: The JavaScript Problem

#66

Post by camus2 »

fiatmoney wrote: post #55

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

Re: The JavaScript Problem

#67

Post by Twirrim »

bratsche wrote: post #58
jmspring wrote: post #41

Earlier quoted context omitted.

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

Why do you care what the target of the compile is if you're happy with the language you're writing in? That seems like being upset that some code you wrote in a language you like might be running on some processor you don't like.

Because it requires some really difficult conversion work under the surface. For example, JS has no concept of integers. To shoe-horn other languages in involves a lot of extra work, which by nature is going to be less efficient. Worse, the javascript engine's JIT can't take advantage of some of the semantics of the language being converted, e.g. if the JIT knew for sure that the number was an int, it could take advantage of that in various ways, or make a smarter decision based on the known performance characteristics of the hardware it's running on.

Re: The JavaScript Problem

#68

Post by mseepgood »

dfkf wrote: post #6
WoodenChair wrote: post #4

Pretty strange to mention TypeScript and not Dart... which solves a lot of his criticisms and is arguably more popular. I respect the functional guys a great deal but the use of Haskell for front-end dev is realistically going to only be an interesting option for those already using it for the backend. It has nothing to do with the merits of the solution and everything to do with people's comfort zones.

The page is about JS. TS is a superset of JS, and Dart is an entirely different language.

All other languages listed on that page are entirely different languages as well.

Re: The JavaScript Problem

#69

Post by teacup50 »

djur wrote: post #53
teacup50 wrote: post #28

Earlier quoted context omitted.

> Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff. This is the Haskell wiki. I would expect most participants to view having a single global implicit union type to be a flaw , not a trade-off .

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

There's nothing chauvinistic about it. If you want to hear people honestly and accurately describe "static" type system's flaws -- talk to type system theorists.

Type systems can be provably flawed.

What you can prove about a uni-typed late-bound ("dynamic") languages is quite simply that they're unilaterally flawed.

Re: The JavaScript Problem

#70

Post by kenjackson »

bzbarsky wrote: post #65
kenjackson wrote: post #46

Earlier quoted context omitted.

JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.

> 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.
Post reply on HN