Elm at Prezi
engineering.prezi.com
engineering.prezi.com
http://ocsigen.org/js_of_ocaml/
The site has some cool demos including webgl, canvas, and a OCaml toplevel (REPL).
At this point, go to the next blackboard. Write after me:
You can not debug Elm. There is no debugger. You can not debug Elm. There is no debugger.
I have no problem with that, but please don't go on about how you are much more productive in this language than in JS, and how much cheaper the code will be to maintain.
Chrome has some sort of support for it too, which Closure can apparently use. (That's Closure the JS library, not Clojure the JVM Lisp.)
OTOH, the way one codes in functional languages is also different. Lack of a debugger may not he a problem as big as it would be with, say, Java.
I disagree. That may be true in Haskell because it's static and the compiler finds a lot of problems.
This isn't true for all functional languages though. I REALLY want a debugger in Clojure code and it's pretty functional*.
Static typing can do a lot of good, but the stricter semantics of Haskell also goes a long way into writing code with fewer bugs.
It's because with Haskell you find a ton of errors at compile time and Clojure finds most issues at runtime.
However, there is one thing you want a debugger for in Haskell: checking when thunks have been forced.
Also, the type system can catch much more issues than "normal" compiled languages, not to mention the safety of immutable values. But there still numerous classes of issues which will not be caught by the type system. And of course, you have exceptions. Even if your code catches them, figuring out what triggered the exception can be tricky.
I'm not sure how you'd create a language that would solve that problem, though I guess since the bug I was chasing down was a classic state problem, maybe it would have been caught by a compiler in Fay/Haskell.
I assume that will change, but it made it pretty hard for me to get started with the language.
That said, I hope it changes, because Elm looks really neat!
Every time I see such strongly worded statements, I get amazed by how the authors got to analyze the skills of every developer in the world.
For us/In my opinion, the cost of writing Javascript is just too high.
See? Now the rage is gone! I think I'm going to sell this trick...
I didn't realize how many there were.
In terms of Foo->JS there seem to be two main camps, at least that I've noticed: writing a "better" JS (CoffeeScript / Dart et al), and writing something that converts your language to JS so you don't have to learn JS (ClojureScript, Scala.js etc) at all.
The latter can have ~700 of those before you've even started to duplicate yourself, so there is still a ways to go :P
Arguably there are only half a dozen or so "real" contenders in the former category (in the same way when you decide you want to learn a new programming language you don't pick from all ~700).
So you don't have to use a language you find deficient, so you can share code with your backend, so you can use the same tools you're used to ...
not gained much traction so far, but it's a useful place to post interesting links as i find them.
And built some simple GUIs using Shoes: https://github.com/steveklabnik/frp_shoes
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.
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.
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 ;)
If you use it for a while, you'll get used to it. After a while, I've found it makes the most sense. I think it's better because it reduces the amount of syntactic noise in the code.
It's a simple design decision. Function application is the most important part of the language. So it gets the best syntax: none.
f(a, b, g(x, y))
f a b (g x y) f a b (g x y)
f a b <| g x y -- EDIT: flipped the operator around
f a b $ g x y
f a b <| g x y
(I think its that, I'm a little rusty..)
Suppose you have a function f with type Int -> Int -> Int (you can read it as "it takes two integers and returns an integer" or "it takes one integer and returns a function that takes an integer and returns an integer"), then:
f
f 42
f 42 33
It's like with each application you take one arrow from the function type; until you get something that's not a function any more :)
Do you have time to explain why bacon is better than Reactive Extensions, and thus the only frp library for JavaScript that you chose to link to? I don't have too much experience with frp in general (primarily just the Reactive Extensions for .NET), and even less with JavaScript implementations, so I'm not really in a position to begin making the comparison.
Edit: ah, found https://github.com/raimohanska/bacon.js#for-rxjs-users for starters!
Correct me if I'm wrong, but it seems like what you've done here is just take one narrow interpretation of Nekorosu's comment and used that as the basis for a dismissive reply that offered no value.
--- Dateline 1995:
Nekorosu: "Java is the future"
Cuttooth: "Java is the future as much as C is dead in the software development industry" ---
It's a big industry, cut. There's room for everybody.