
New Adventures for Elm - shoover
http://elm-lang.org/blog/new-adventures-for-elm
======
jey
I've been looking at the options for pure-functional languages targeting JS,
and it seems that PureScript is superior to Elm from a technical perspective
for full-stack webdev. PureScript takes the approach of providing a full
Haskell-like language that is "native" to the JS world. It has the features
and type system of Haskell, but atop a cleaned up version of Javascript's
semantics (e.g. strict evaluation, not lazy, by default). It's also well
suited for both server and client code, and even has a C++11 backend in the
works in addition to the native JS backend.

In contrast, Elm is focused on front-end work and is less expressive, but
emphasizes simplicity. Elm's goal of figuring out how to simplify and distill
the Haskell and ML world's abstractions is an admirable one, but as an
experienced programmer interested in practical work I'd rather just go with
PureScript and just learn the Haskell-like abstractions along the way. It also
really helps that the PureScript compiler's javascript output is "natural" and
easy to understand, without any mysterious transformations involved.

Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen
differently?

~~~
rlander
Well, "superior" is subjective in this case.

It's like an OO programmer claiming that Smalltalk is a superior language than
Elm. Besides, Purescript is squarely targeted at experienced Haskell
programmers, which is not the case of Elm. Elm is an ML language, not a
Haskell dialect that compiles to JS.

I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing
Elm precisely for the reasons you chose to stay away from it. I only use JS
for front-end stuff, I value simplicity over expressivity and I don't want to
spend many weeks learning Haskell-like abstractions to start being productive
in a new language (in contrast, it only took me an afternoon to start being
productive in Elm).

~~~
ZenoArrow
> "Elm is an ML language, not a Haskell dialect that compiles to JS."

To be clear, Haskell also comes from the ML lineage.

~~~
hanniabu
ML stands for machine learning, correct?

~~~
thedufer
In this context, it stands for MetaLanguage, which is a language family (and
was at one point a language itself, I believe). The family includes Ocaml (see
the ml there?) and Haskell, among many others.

~~~
pinealservo
As a point of possible interest to people who are interested in programming
language history, I'm going to elaborate a bit on this topic:

The root of this particular family tree is essentially a fusion of the lambda
calculus-inspired parts of Algol 60 and Lisp with some new ideas for syntax
that were promoted by Peter Landin in his highly influential paper from 1966,
"The Next 700 Programming Languages". He called this language ISWIM; it was
studied extensively but never directly implemented. Landin was also associated
with Dana Scott and Christopher Strachey in their foundational work on
programming language semantics.

Robin Milner was interested in the relationship between the logic underlying
the semantics of programming languages and the possibility of using computers
to prove propositions in that logic (a logic developed by Dana Scott in
support of his semantics work). At Stanford, he and a small team (including
Whitfield Diffie, who later went into cryptography...) developed a system
called Stanford LCF (for Logic of Computable Functions). This was an
interactive system in which the user states a main goal in the logic, then
splits it to subgoals and more subgoals until they can be solved directly.
Proofs were represented directly by data structures and were built directly by
the proof manipulation commands, which corresponded to the inference rules of
the system.

Milner moved to Edinburgh in 1973, where he worked on a subsequent version of
LCF, Edinburgh LCF. Stanford LCF was limited by the size of the proof data
structures; for Edinburgh LCF Milner had the idea to forget the proofs, but
store the results of them; i.e. the theorems. The proof steps would be
performed, but not recorded. To ensure that theorems could only be constructed
via valid proofs, a meta-language was developed with a static type system that
would only allow data structures corresponding to valid theorems to be built.
It also allowed more sophisticated proof development, since the meta-language
was a full higher-order programming language modeled after Landin's ISWIM.
Exceptions were included to deal with the possibility of failure of particular
proof strategies. This version was implemented in Lisp.

LCF spread to other universities; it was early on split into two parallel
tracks, ML and Caml. Both have continued to be strongly associated with
implementation of theorem proving systems. ML and LCF have become Standard ML
and HOL; Caml has become OCaml and Coq. A lot of programming language research
has also gone into ML and OCaml as languages in themselves due to their close
association with the logic underlying semantics of programming languages.

Meanwhile, a language called PAL was developed in 1968 at MIT in response to
ISWIM and Strachey's ideas on programming languages. David Turner, while
starting his Ph.D. research at Oxford, got access to the PAL sources and used
a simplified form of the language as the basis for his lectures on functional
programming at St. Andrews; he called this language SASL. It was initially
just a blackboard language, but a colleague surprised him by implementing it
in Lisp.

In 1976, Turner changed the semantics of SASL from eager to lazy, based on a
lazy version Landin's SECD machine. Somewhat later in his career, he combined
ideas from lazy SASL, a cut-down version of SASL called KRC, and the ML-
originated Hindley-Milner type system to form a language called Miranda. And
Miranda is one of the primary influences on Haskell.

So, this leaves out a lot of other languages such as HOPE and lazy-ML that
also were developed in this space. But what's interesting to me is how all
these languages, from ML to Haskell, are so strongly related to Algol and thus
the Pascal, C, Java, etc. languages that are more familiar to industry.

That got a lot bigger than I intended; I hope someone takes some interest from
the digression.

~~~
mgold
I thought that you might be one of my college profs, but then realized that he
would never apologize for a long post.

------
charlysisto
Here's the path I've been following :

(ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux ->
redux -> elm...

But I'm just a backend guy happy with Ror, just waiting to go on the
frontline... with the proper weapons!

My feeling about elm is that it's more than the new kid on the js block. It's
closure without parens, it's Haskell without academy, it's Redux without
facebook, it's duck-typing without quacks, it's MVC without objects and last
but not least evan Czaplisky (the creaor) is the new Aaron Patterson (bright
__and __fun!)

I'm all in (but yeah I've been bitten before)...

~~~
Touche
That's a lot of churn. You should stop and ask yourself if it's worth being on
the cutting edge all of the time. Are you making better projects as a result
of dropping "old" tech the moment something shinier comes around?

Everything has tradeoffs. Elm has no server side rendering, for example.

~~~
vdaniuk
>Are you making better projects as a result of dropping "old" tech the moment
something shinier comes around?

That's a lot of assumptions you are making there. Why "better projects" is the
only metric considered here? Perhaps, OP utility in front end technologies is
based on their learning. Or what's you reason to assume OP is dropping old
tech "the moment something shinier comes around" and not after a reasonable
period of exploration and trial?

Prototype.js was created in 2005, 10 years ago. Angular was released in 2009.
React was released in 2013.

A lot of churn? Absolutely not. Someone staying current, perfecting their
skills and knowledge? Good for them!

The HN trend of "hipster shaming" people trying new, sometimes esoteric
technologies (even if it's only for the novelty factor!) is not conductive to
constructive discussions and really has no place in the community named
_Hacker_ News.

~~~
rixed
Unless building a taste for long lived techs as opposed to favoring the newest
reinvention of old ideas is part of the learning process?

------
mgold
Most of these comments boil down to, "the food's awful and the portions are
too small!". Someone wants better JS interop because Elm will be a small part
of their stack; someone wants server-side and isomorphic apps because Elm will
be a large part of their stack. Yes, the tooling and language features have a
long way to go, and hopefully Evan will make progress while at NoRedInk. If
you enjoy Haskell, you're not really Elm's target audience. If you hawkishly
watch HN, you're probably not the target audience - the point is that it's
sane programming for the rest of us.

------
ghuntley
For those just getting started in FRP or whom may have not seen the
presentations at StangeLoop:

\-
[https://www.youtube.com/watch?v=Agu6jipKfYw](https://www.youtube.com/watch?v=Agu6jipKfYw)
\- Controlling Time and Space: understanding the many formulations of FRP by
Evan Czaplicki (Elm language designer/Prezi)

\-
[https://www.youtube.com/watch?v=1XNATGjqM6U](https://www.youtube.com/watch?v=1XNATGjqM6U)
\- FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts
(Slack/GitHub)

\-
[https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18](https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18)
\- ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

------
ZenoArrow
What's the best programming environment for Elm? I know there's a Light Table
plugin for Elm, which I think is promising (in some ways they seem like a
natural fit, whilst they started separately the direction of both was inspired
at least in part by Bret Victor's ideas), but I wonder what other tools are
being used to code Elm.

[https://github.com/rundis/elm-light](https://github.com/rundis/elm-light)

~~~
redka
Sublime Text with Elm language support[1] does auto compilation and is plenty
enough. It also comes with an extension to SublimeREPL[2]

[1]
[https://github.com/deadfoxygrandpa/Elm.tmLanguage](https://github.com/deadfoxygrandpa/Elm.tmLanguage)
[2] [https://github.com/wuub/SublimeREPL](https://github.com/wuub/SublimeREPL)

------
wtetzner
One of the things I found odd (or maybe just annoying) is how the Elm
Architecture doc [1] keeps mentioning how you can cleanly model your code
using modules. But the module system is about as primitive as you could
imagine. The language would be much more expressive with ML's module system,
and functors would relieve some of the pain of not having type classes.

[1] [https://github.com/evancz/elm-architecture-
tutorial/](https://github.com/evancz/elm-architecture-tutorial/)

------
sotojuan
Congrats! I hope one day to work for NoRedInk. Elm is a big reason why.

~~~
rtfeldman
Please apply! We're hiring. :)

[http://noredink.com/jobs](http://noredink.com/jobs)

~~~
firlefans
Remote US only or remote EU also?

~~~
rtfeldman
We currently have remote developers from the UK, Germany, and São Paulo. (We
do wantjunior hires to be in the office, though, to facilitate mentoring.)

We do a solid amount of pair programming, but remote pairing via ScreenHero is
pretty sweet. :)

~~~
zapu
What would the requirements to apply for remote, "non-junior", position be?

~~~
mtoledo
There are more details for each position at our jobs page :)

[https://www.noredink.com/jobs](https://www.noredink.com/jobs)

------
arvinsim
I am a frontend developer and I wanted to learn Haskell for a long time. But I
just can't wrap my head around it. Is Elm or Purescript a good way to ease
into it? If so, which one is better?

~~~
thinkpad20
One of the major goals of Elm is being easy to learn, both from a language and
a library point of view. PureScript is, for better or worse, no simpler than
Haskell as a language, with all of the power of Haskell but its complexity as
well. Elm is going to be much more approachable, and has a major focus on
readable documentation and simple, straightforward concepts. It takes trade
offs in language features in exchange, but is probably a better bet for
someone who wants to get up and running quickly.

~~~
codygman
> PureScript is, for better or worse, no simpler than Haskell as a language,
> with all of the power of Haskell but its complexity as well

Is it really no simpler? A few common complexity complaints i hear about
Haskell that don't apply to purescript in order of frequency:

\- Haskell is lazy by default

\- has too many language extensions

\- records pollute global namespace

\- has fmap and map

\- $ is confusing

~~~
Kutta
Except that Purescript uses the liberty from Haskell legacy libraries to
become even more hardcore on algebra and categoric language. The relatively
small user base also consist of experienced Haskellers, and the libraries tend
to be quite advanced. For example, the "basic component" in the beginning of
the Halogen tutorial already mentions natural transformations (which made me
instantly intrigued, personally, but I'm one of those experienced Haskellers).

~~~
purescript
> to become even more hardcore on algebra and categoric language

In some of the standard libraries, yes, that's true. However, it's possible to
use PureScript without the standard libraries, and use alternatives such as
Preface (a teaching library) or Neon (an alternative to Prelude)

[https://github.com/paf31/purescript-
preface](https://github.com/paf31/purescript-preface)

[http://pursuit.purescript.org/packages/purescript-
neon/0.1.1](http://pursuit.purescript.org/packages/purescript-neon/0.1.1)

------
hassox
As an experiment I tried rendering elm in the server. It's renders fine but
I'm not sure that it doesn't re-render everything on page load.

[http://blog.overstuffedgorilla.com/server-side-elm-with-
phoe...](http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/)

------
k__
When is back-end elm?

------
sjrd
These are some very exciting news for Elm and its community. Well done!

------
codifyhus
Nice.

------
nanoojaboo
"It's unprecedented for a company our size to hire a language creator," says
R.Feldman of NoRedInk. [http://tech.noredink.com/post/136615783598/welcome-
evan](http://tech.noredink.com/post/136615783598/welcome-evan) This might be
true, but it's also a very smart marketing investment. I would have never
visited NoRedInk otherwise, and it's the kind of company that would benefit
immensely from general word of mouth discussion

------
open-source-ux
My comment is off-topic and likely to annoy people here, but I'll say it
anyway: that entire page appears to have been generated in Javascript. If you
view source, there is no HTML at all. What would a user with a screen reader
hear if he or she were to visit that page?

If the page had been written in plain HTML and CSS, it might be about 10-15k
in size. At the moment, written in Javascript, it's over 300K in page weight.
So both inaccessible and bloated in page weight. This is really bad practice.

~~~
epidemian
> What would a user with a screen reader hear if he or she were to visit that
> page?

Well, the page still renders paragraphs and titles to good ol' <p>s and <hX>s,
so i'd presume a screen reader would just read those things as the page
content. Wouldn't it?

~~~
habitue
the screen reader needs to execute the javascript before it can read the tags.
I'm not sure if they do that

~~~
girvo
Most do, thankfully, and have done for a while now :)

