Elm at Prezi

http://engineering.prezi.com/blog/2013/05/21/elm-at-prezi/

by enum • 13 years ago

175 100 13 years ago

engineering.prezi.com

zsol2• 13 years ago

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

zem4• 13 years ago

livescript is a more haskellish descendant of coffeescript: http://livescript.net/

gonehome• 13 years ago

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.

SCdF• 13 years ago

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

lucian1900• 13 years ago

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

zem4• 13 years ago

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.

Ixiaus• 13 years ago

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

jallmann• 13 years ago

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

rtfeldman• 13 years ago

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/

zem4• 13 years ago

i like the looks of opa too: http://opalang.org/

klibertp• 13 years ago

I would like it, but why oh why does it have Algol-like syntax? It started with ML-like one IIRC, so whyyyy? (it's just an expression of disappointment, not actual question)

AndreasFrom• 13 years ago

Elm 0.8 was recently announced with a range of improvements for those interested: http://elm-lang.org/blog/announce/version-0.8.elm

steveklabnik• 13 years ago

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

jcurbo• 13 years ago

Me too, I did a project for grad school using FRP. https://github.com/jcurbo/functionally-reactive-solar-system

aristidb• 13 years ago

It seems like Haskell users are quite intent on not using Javascript... Elm is written in Haskell. So is Fay. And of course ghcjs.

halacsy2• 13 years ago

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.

IanChiles• 13 years ago

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

chongli2• 13 years ago

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!

weego• 13 years ago

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.

stakecounter• 13 years ago

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

baddox• 13 years ago

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

fabokzs• 13 years ago

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

abesto• 13 years ago

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

efnx3• 13 years ago

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

nahname• 13 years ago

Inversion of control is a good thing. Why would you want to avoid it?

laszlok• 13 years ago

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.

zeckalpha• 13 years ago

It's not avoided, it just has a different syntax. (Monadic rather than callbacks, but since they are the same thing...)

icarus1272• 13 years ago

I'm genuinely curious, why do you think inversion of control is an unqualified Good Thing™?

alipang4• 13 years ago

Because of certain limitations in Java-style type systems...?

revelation2• 13 years ago

[..] 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.

halacsy2• 13 years ago

is there any theoretical limitation?

revelation2• 13 years ago

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.

jerf2• 13 years ago

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

rbanffy2• 13 years ago

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.

icarus1272• 13 years ago

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.

tieTYT2• 13 years ago

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

mercurial3• 13 years ago

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.

PuercoPop• 13 years ago

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.

mercurial3• 13 years ago

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.

executionhalted• 13 years ago

It's not much, but you should still be able to print things to a console.

weavie2• 13 years ago

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!

triplepoint217• 13 years ago

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!

jlatt• 13 years ago

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

j_s2• 13 years ago

See also Microsoft Research's Reactive Extensions for JavaScript, released under the Apache License 2.0:

https://github.com/Reactive-Extensions/RxJS

alipang4• 13 years ago

Or even better, Bacon.js

https://github.com/raimohanska/bacon.js

Nekorosu• 13 years ago

Elm is the future and I'm glad to see it now has some good company's support.

cuttooth2• 13 years ago

Elm is the future as much as Java is dead in the software development industry.

encoderer• 13 years ago

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

jluan• 13 years ago

Congratulations, Evan!

wheatBread2• 13 years ago

Ahhhh, I recognize that user name! Thank you!! :D

egonschiele• 13 years ago

I am so excited! It's nice to see a functional language like Elm getting financial support from a company.

jessedhillon2• 13 years ago

I find function application without parentheses enclosing the parameter list to be highly unreadable. Is there something wrong with me?

d0m• 13 years ago

Lol, nothing wrong with you. Just not used to it.

tikhonj2• 13 years ago

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.

jessedhillon2• 13 years ago

Can you give an example of composed function application? E.g.,

  f(a, b, g(x, y))

Thanks

epidemian2• 13 years ago

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:

is the function itself, and it is a usable value.

    f 42

is a function of type Int -> Int, and a perfectly valid value too. And

    f 42 33

is just and Int.

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

Dewie• 13 years ago

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.

efnx3• 13 years ago

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

sixbrx• 13 years ago

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.

epidemian2• 13 years ago

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

egeozcan• 13 years ago

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

subb• 13 years ago

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

aero142• 13 years ago

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.

snprbob86• 13 years ago

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.

tingletech• 13 years ago

not to be confused with the elm, the old unix mail client:

http://www.instinct.org/elm/

obviouslygreen• 13 years ago

I knew this was unlikely to be the subject of the article but clicked through anyway... oh well.

kbenson• 13 years ago

I was really hoping someone had compiled Elm to JS. That would give me some hope that mutt would be next...

205guy• 13 years ago

I'm not the only one. Hey, you can still run pine if you want.

jfb• 13 years ago

Listen, pine is not elm, ok?

saosebastiao• 13 years ago

Awesome...you have me intrigued. I would worship the ground you walk on if you targeted asm.js.

boothead2• 13 years ago

Slightly off topic but does anyone know of ans FRP library for python?

Elm at Prezi

Related Stories