Elm at Prezi(engineering.prezi.com)
engineering.prezi.com
Elm at Prezi
http://engineering.prezi.com/blog/2013/05/21/elm-at-prezi/
18 comments
For those interested in compiling down to Javascript with a strongly and statically typed language, there's a brilliant proper subset of Haskell that compiles down to Javascript called "Fay": https://github.com/faylang/fay/wiki
Also Roy, which is statically typed (with type inference) and is designed for JS interop. It's also written in JS and can be installed with just npm install roy http://roy.brianmckenna.org/
There is also js_of_ocaml, which can be used to compile straight OCaml to Javascript:
http://ocsigen.org/js_of_ocaml/
The site has some cool demos including webgl, canvas, and a OCaml toplevel (REPL).
http://ocsigen.org/js_of_ocaml/
The site has some cool demos including webgl, canvas, and a OCaml toplevel (REPL).
i like the looks of opa too: http://opalang.org/
[..] and every line of JavaScript code costs too much time to maintain.
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.
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 haven't written any Elm but having written some Haskell I can say it's surprising how often you _don't_ need a debugger in a functional language. I doubt Elm not having a debugger is as difficult as, for instance, Javascript or Coffeescript not having a debugger would be.
> it's surprising how often you _don't_ need a debugger in a _functional language_
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*.
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*.
Clojure is a great language, but there really is a difference between functional and "pretty" functional; e.g. as in, I know 100% sure that this function has no side-effects.
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.
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.
Any function changes the state of your machine, and you have to pretend your computer doesn't have memory or registers in order for this pure function side effect free stuff to make sense. When you said "know 100%" my ability to accept abstractions like that turned off.
IMO, that has nothing to do with it. Especially because you often do know 100% that this function has no side-effects.
It's because with Haskell you find a ton of errors at compile time and Clojure finds most issues at runtime.
It's because with Haskell you find a ton of errors at compile time and Clojure finds most issues at runtime.
bah side effects what useful thing can you do without side effects? The only way to have no side effects is to frame the problem in a certain way.
Haskell has support for side-effects. It's just able to state the property that something is a 100% pure function, and also makes it very easy to write such code a lot of the time.
Unfortunately, I don't have the opportunity to be paid to write Haskell. Which means I haven't had the opportunity to use it for anything else than side projects.
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.
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.
Paraphrasing a great programmer: "The best debugger is your brain". I have no issue with people using a debugger, but it is not a must in order to debug, imho.
I have found that this advice doesn't work too well when dealing with large, preferably legacy, codebases along with a pile of third-party libraries. Sometimes, the best debugger is a debugger.
A-men. Right now, I'm waist-deep in over 80k lines of JavaScript neither I nor anyone remaining on our team wrote, and just being able to set breakpoints on event listeners in Chrome and step into the functions that are fired probably saved me weeks off a more plodding read-through-the-whole-codebase approach.
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'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.
The bigger problem I encountered trying it out yesterday was that it (at the moment) is fairly happy to generate an empty page and not give any compiler errors.
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!
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!
is there any theoretical limitation?
It looks like the requisite debugger technology is just coming online in dev builds for Mozilla: https://hacks.mozilla.org/2013/05/compiling-to-javascript-an...
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.)
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.)
Do source maps also support tracing values in variables, or do they only map line numbers in source to line numbers in output? Because the former (mapping values) is the hard part of implementing a debugger.
Actually that’s Closure the Javascript compiler. There’s nothing special that has to do with source maps in Closure Library, because it’s regular JS.
That's an interesting question. Debuggers are very different when they target functional languages and the mote you express with fewer lines of code make for somewhat surprising.
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.
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.
No, its plain old lazyness. All these "compiled to JS" language makers would rather add more fancy syntactic sugar or extend the standard library than getting their goddamn bases covered.
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.
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.
I think it's ridiculous to call people "lazy" who wrote an entirely new language from scratch and released it for free, because it's lacking one feature.
Per my sibling post, I do not believe you are technically correct. Debuggers must support the ability to debug compiled languages before anyone can usefully implement support for debugging. I'm curious what exactly you think the developers of languages that compile to JS are not doing out of "lazyness"?
A counterexample is coffeescript, which I think does have a plugin for Chrome to allow a source-level debugger.
You can run (and debug) Dart natively in Dartium.
With all these languages compiling to javascript coming out, I'm sure a debugging solution can't be far behind. The need is definitely there!
It's not much, but you should still be able to print things to a console.
> The cost of writing JavaScript is just too high
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.
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.
Usually, to calm myself, I reword it like this :
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...
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 was taught in early rhetoric and composition classes that it is poor style to include "In my opinion" and other qualifiers in pieces that are clearly rhetorical or opinion based. The repetition is unneeded. In engineering discussions it is very common to differentiate between opinions and knowns. When discussions happen between people who don't agree on these things, someone gets annoyed. The engineers get annoyed when people state opinions as fact and think the other person is making unjustified assumptions. The non-engineers get annoyed and think that the other person is being pedantic.
This is not a statement about the skills of other developers. This is a statement about the applicability of JavaScript to the sorts of problems people are trying to solve with it. There are a lot of nice things about JavaScript that people didn't quite understand or appreciate in the early days, but that doesn't change the fact that the HTML5 stack is deeply flawed in many ways for the needs of application developers. That shouldn't be surprising or controversial: All of these technologies were developed in a simpler time for a simpler set of problems.... and in a rush.
Here's a list of languages that compile down to Javascript:
https://github.com/jashkenas/coffee-script/wiki/List-of-lang....
I didn't realize how many there were.
I didn't realize how many there were.
It's fairly crazy, but then again there are ~700 programming languages listed on Wikipedia, so really, there are just a lot of programming languages in general.
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).
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 learn JS
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 ...
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 ...
i started a subreddit for people interested in compile-to-js: http://www.reddit.com/r/altjs/
not gained much traction so far, but it's a useful place to post interesting links as i find them.
not gained much traction so far, but it's a useful place to post interesting links as i find them.
I recently attended a coding dojo where we wrote code in elm and tests in coffeescript. I was new to both languages but I was surprised how easier elm felt compared to coffeescript (note: I have some haskell background ;]).
Here are the results: https://github.com/dzsodzso63/PreziCodingDojo/tree/master/fr...
livescript is a more haskellish descendant of coffeescript: http://livescript.net/
Great news that Evan can dedicate fully to Elm as his main job. I'm very curious about the language and its departure/simplification over traditional DOM manipulation with JS. I hope the best for the project and would love to see some effort for the compiler targeting asm.js :D
I've really enjoyed playing with FRP, I even wrote a little gem in Ruby for it: https://github.com/steveklabnik/frappuccino/
And built some simple GUIs using Shoes: https://github.com/steveklabnik/frp_shoes
And built some simple GUIs using Shoes: https://github.com/steveklabnik/frp_shoes
Me too, I did a project for grad school using FRP. https://github.com/jcurbo/functionally-reactive-solar-system
It seems like Haskell users are quite intent on not using Javascript... Elm is written in Haskell. So is Fay. And of course ghcjs.
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.
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.
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.
[deleted]
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 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".
I find function application without parentheses enclosing the parameter list to be highly unreadable. Is there something wrong with me?
I think i also got confused the first time i saw that syntax (being used to C-like languages hehe). It started making lots of sense once i got familiar with the concept of currying and functions as first-class values.
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:
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 :)
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 :)
It's just new and you're not used to it. There's nothing wrong with finding new and different syntax confusing, as long as you're willing to keep an open mind.
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.
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.
Can you give an example of composed function application? E.g.,
f(a, b, g(x, y))
You use parentheses only for grouping. So
f a b (g x y)
f a b <| g x y -- EDIT: flipped the operator around
f a b $ g x y
Small revision, the second code line should be:
f a b <| g x y
F# could also write that as g x y |> f a b. Which can read much more intuitively - you are sending the results of g x y to the function f a b.
(I think its that, I'm a little rusty..)
(I think its that, I'm a little rusty..)
The |> looks weird to me. It's the opposite way around to F# (and thus LiveScript). Is that really equivalent to Haskell's $?
f a b (g x y)A lot of modern mathematics also drops the parens, especially in areas related to modern algebra. It really makes the most sense and is less ambiguous, with parens not being overloaded between grouping and application.
It does take getting used to. Also, seeing $ everywhere on a line and . not being property access. Though with lenses...I won't get into that...
Lol, nothing wrong with you. Just not used to it.
I've preferred f x y over f(x,y) ever since I first saw it used in Haskell. Maybe it's just a matter of preference.
I am so excited! It's nice to see a functional language like Elm getting financial support from a company.
Elm 0.8 was recently announced with a range of improvements for those interested: http://elm-lang.org/blog/announce/version-0.8.elm
not to be confused with the elm, the old unix mail client:
http://www.instinct.org/elm/
http://www.instinct.org/elm/
I knew this was unlikely to be the subject of the article but clicked through anyway... oh well.
I was really hoping someone had compiled Elm to JS. That would give me some hope that mutt would be next...
I was really impressed by elm, but I strongly prefer working with a library that provides some of the features without transpiling. If anyone else is interested, I'm looking for some help with my project: https://github.com/jlatt/frp.js
See also Microsoft Research's Reactive Extensions for JavaScript, released under the Apache License 2.0:
https://github.com/Reactive-Extensions/RxJS
https://github.com/Reactive-Extensions/RxJS
Or even better, Bacon.js
https://github.com/raimohanska/bacon.js
https://github.com/raimohanska/bacon.js
Thanks for the heads up!
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!
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!
It's much simpler for a start - you've got a good chance of being able to read and understand all of the code in an afternoon.
Elm is the future and I'm glad to see it now has some good company's support.
Elm is the future as much as Java is dead in the software development industry.
> Elm is the future as much as Java is dead in the software development industry.
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.
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.
The point was that JavaScript is king and this "Elm is the future" suggests that it'll be a major player. Right now it's a niche toy language. There's room for plenty of those, sure, but it takes years of work and development for a language to become worth its salt. Java had its fair share of issues for a while, and arguably still does.
Awesome...you have me intrigued. I would worship the ground you walk on if you targeted asm.js.
Slightly off topic but does anyone know of ans FRP library for python?
Inversion of control is a good thing. Why would you want to avoid it?
I think the idea here is that you aren't /forced/ into inversion of control. That is, if it is clearer to write things side by side, instead of separated into another callback function, you can keep them together.
It's not avoided, it just has a different syntax. (Monadic rather than callbacks, but since they are the same thing...)