The world seems to be intent on writing mountains of code to avoid writing javascript, and usually ending up with a system that compiles to more javascript than if they just wrote javascript. Saying javascript is broken is a nonsense, they mean they feel they should be above writing javascript due to its quirks and inconsistencies. Whatever they write the end result is still the "broken" language they wanted to avoid. It all seems like a huge waste of resources and smart people's time to me, but then I've been writing javascript for getting on for 15 years so perhaps im past it and don't "get it" anymore.

> and usually ending up with a system that compiles to more javascript than if they just wrote javascript

That's not really a useful or sufficient argument against languages that target JavaScript, since you won't be reading or maintaining the JavaScript code itself. You could say the same thing about assembly code ("languages which target assembly languages usually end up outputting more assembly code than if the programmer had just written the assembly code manually"). If you're really concerned about lines of code (which is itself somewhat troublesome), a more valid comparison would be the lines of Elm code versus the lines of human-written JavaScript code to implement the same thing.

> The world seems to be intent on writing mountains of code to avoid writing javascript, and usually ending up with a system that compiles to more javascript than if they just wrote javascript.

Does it really matter how much javascript gets created? That statement could be made for any higher level language where X lines of the higher level language compiles into 5X lines of the target language. Maybe you could hand write your program in the target language using only 4X lines, but the point of the higher level language is to make it easier for the programmer to avoid mistakes as well as reduce source code size, not necessarily compiled code size.

Except that when JavaScript is the target code size does matter because it has to come up over the wire no? That's why something like Dart advertises the fact that it does tree shaking. (Elm may aim for the same efficiency who knows?)

You can do tree shaking in JavaScript with tools like Google Closure Compiler and uglifyjs (a bit more limited). Any language which compiles to JavaScript aught to be able to make use of these tools.

I think that may not be the case - it may be more that Haskell is a fabulous language to write compilers and parsers in, and so lots of compilers and parsers are written in it :)

It's a bit of both. I will say that it's very frustrating to use other languages after adjusting to Haskell. The way it feels when it feels when you're out on your own without a helpful compiler to guide you? It's like losing your sense of balance!

because JS is flexible, the VMs are really good recently and the web platform is tempting but haskell coders miss safety, succinct syntax and efficiency.

Yes - I think once you start being productive with Haskell you prefer to work in languages with strong type systems that are purely functional (Haskell and subsets of it). When I work in Haskell it feels like a burden has been lifted from my shoulders - for real! Coming back to JS is simply painful.

I think more programmers would experience this if it weren't for Haskell's insane learning curve. It took me a ~year of casual learning and skimming before I could do anything useful. Very casual, though ;)

I'm wondering if we need a different testing approach for these new wave "functional programming languages".

You mean like QuickCheck? http://en.wikipedia.org/wiki/QuickCheck

hear, hear