lainchan archive - /λ/ - 20555
[ Return /
Go to bottom ]
File: 1480420432125.png (12.56 KB, 300x121, ElmLogo.png)
Just tried Elm out. I have to say I'm really impressed and it changed my view on how useful functional programming actually is for GUI programming.
It basically made me realize that Haskell is bad at GUI's because of a lack of good libraries, not because of the paradigm used. Elm is also statically typed functional, but it is really good for GUI's because the language, the standard library, and the basic tutorials were all built specifically for that task from the beginning.
Having made a few basic browser apps, I'm leaning towards the opinion that pure functional might actually be the very best paradigm for GUI's, better than anything procedural or OOP, as long as you follow a good structured approach similar to the MVC pattern. But then again I'm still in "new toy" mode so my opinion might change over time.
It basically made me realize that Haskell is bad at GUI's because of a lack of good libraries, not because of the paradigm used. Elm is also statically typed functional, but it is really good for GUI's because the language, the standard library, and the basic tutorials were all built specifically for that task from the beginning.
Having made a few basic browser apps, I'm leaning towards the opinion that pure functional might actually be the very best paradigm for GUI's, better than anything procedural or OOP, as long as you follow a good structured approach similar to the MVC pattern. But then again I'm still in "new toy" mode so my opinion might change over time.
>It basically made me realize that Haskell is bad at GUI's because of a lack of good libraries, not because of the paradigm used.
That's plain wrong, though. There are multiple good FRP (the "paradigm" also used by Elm) libraries in Haskell.
I personally dislike Elm because the its lack of type classes make it hard for me to write code, but I do believe it serves as an excellent "first hit" of functional programming for novices.
That's plain wrong, though. There are multiple good FRP (the "paradigm" also used by Elm) libraries in Haskell.
I personally dislike Elm because the its lack of type classes make it hard for me to write code, but I do believe it serves as an excellent "first hit" of functional programming for novices.
File: 1480447684286.png (78.01 KB, 200x130, wow anon.jpg)
Elm looks like an interesting language, but it looks like the only way to learn it is from the tiny online tutorial at the Elm website. There are no books on it out yet. Elm must be a very small language if people can use it just from that tutorial.
>>20581
It is indeed a very minimalistic language, kind of like the smaller Schemes out there. It has very little syntactic sugar and encourages you to get by with just the core ideas of the language, i.e. plain types and plain prefix function application syntax.
If you have a background from any of the languages with ML syntax you can pick it up in an afternoon easily.
You could say that it's more similar to the ML's and to F# than to Haskell. It does not have Haskell's HKT's and support for generics/operator overloading, the latter being intentional. However, it does take type-safety really seriously and while the typing is less expressive for operator overloading/generics, in terms of safety the typing discipline is stronger. The standard library functions do not have runtime exceptions, and instead have return types tagged with Maybe or Either if they can fail so you get warnings at compile time.
Like for example, "head" in Haskell when applied to a list of Ints will return an Int, and throw a runtime exception for empty lists. Elm's "List.head" would return a Maybe Int and as such won't compile unless you handle the exceptional case somehow.
It is indeed a very minimalistic language, kind of like the smaller Schemes out there. It has very little syntactic sugar and encourages you to get by with just the core ideas of the language, i.e. plain types and plain prefix function application syntax.
If you have a background from any of the languages with ML syntax you can pick it up in an afternoon easily.
You could say that it's more similar to the ML's and to F# than to Haskell. It does not have Haskell's HKT's and support for generics/operator overloading, the latter being intentional. However, it does take type-safety really seriously and while the typing is less expressive for operator overloading/generics, in terms of safety the typing discipline is stronger. The standard library functions do not have runtime exceptions, and instead have return types tagged with Maybe or Either if they can fail so you get warnings at compile time.
Like for example, "head" in Haskell when applied to a list of Ints will return an Int, and throw a runtime exception for empty lists. Elm's "List.head" would return a Maybe Int and as such won't compile unless you handle the exceptional case somehow.
>>20565
I bet the author would have a heart-attack if he saw Go.
Anyways, it looks to me that Elm is basically just OCaml, with a MVC library tailored towards the web. Which sounds just fine, but at abstraction, Haskell is definitely better than OCaml.
>Like for example, "head" in Haskell when applied to a list of Ints will return an Int, and throw a runtime exception for empty lists.
The thing is that (afaik) you can't even catch this exception thrown by Haskell, as head in Haskell is supposed to be called very rarely, only when you are absolutely sure that your list has is not empty.
Also, you claim that Elm doesn't have runtime exceptions, but what about a stack overflowing function? It's impossible to force any arbitrary function in a turing complete language to terminate successfuly.
I bet the author would have a heart-attack if he saw Go.
Anyways, it looks to me that Elm is basically just OCaml, with a MVC library tailored towards the web. Which sounds just fine, but at abstraction, Haskell is definitely better than OCaml.
>Like for example, "head" in Haskell when applied to a list of Ints will return an Int, and throw a runtime exception for empty lists.
The thing is that (afaik) you can't even catch this exception thrown by Haskell, as head in Haskell is supposed to be called very rarely, only when you are absolutely sure that your list has is not empty.
Also, you claim that Elm doesn't have runtime exceptions, but what about a stack overflowing function? It's impossible to force any arbitrary function in a turing complete language to terminate successfuly.
>>20587
>The thing is that (afaik) you can't even catch this exception thrown by Haskell, as head in Haskell is supposed to be called very rarely, only when you are absolutely sure that your list has is not empty.
You can, but you have to involve IO:
>The thing is that (afaik) you can't even catch this exception thrown by Haskell, as head in Haskell is supposed to be called very rarely, only when you are absolutely sure that your list has is not empty.
You can, but you have to involve IO:
> evaluate (head []) `catch` (\(_ :: SomeException) -> print "whoopsie")
"whoopsie">>20587
> Also, you claim that Elm doesn't have runtime exceptions, but what about a stack overflowing function? It's impossible to force any arbitrary function in a turing complete language to terminate successfuly.
Good point about stack overflows. Yes, Elm is Turing complete so programs can get stuck in infinite tail recursion or give stack overflows. It's not Idris.
It does avoid null errors pretty well though, and a head function that returns a Maybe type is a beautifully monadic way of handling the exceptional case, while still being simple enough that you can use it without knowing what a general monad is.
> Also, you claim that Elm doesn't have runtime exceptions, but what about a stack overflowing function? It's impossible to force any arbitrary function in a turing complete language to terminate successfuly.
Good point about stack overflows. Yes, Elm is Turing complete so programs can get stuck in infinite tail recursion or give stack overflows. It's not Idris.
It does avoid null errors pretty well though, and a head function that returns a Maybe type is a beautifully monadic way of handling the exceptional case, while still being simple enough that you can use it without knowing what a general monad is.
Elm is a nice project, I use it every time I need to write more complex frontend code and I always enjoy it.
I do believe it sorely lacks something similar to type classes or ML-style modules, but I'm pretty sure they'll be added at some point, the author just doesn't know how to make them simple and easy to use yet. Much of the focus right now is going into making it easy for beginners, the small size of the language and the lack of such more advanced features are a result of that.
There actually are functions that operate on "generic" types (number, comparable etc), but for the moment they're strictly compiler magic.
I do believe it sorely lacks something similar to type classes or ML-style modules, but I'm pretty sure they'll be added at some point, the author just doesn't know how to make them simple and easy to use yet. Much of the focus right now is going into making it easy for beginners, the small size of the language and the lack of such more advanced features are a result of that.
There actually are functions that operate on "generic" types (number, comparable etc), but for the moment they're strictly compiler magic.
>>20610
Haskell is basically *defined* by the presence of higher order typeclasses and lazy evaluation, neither of which Elm has.
You could also probably say that OCaml is defined by its module system and record objects.
Perhaps we can both agree that Elm is just a typed functional programming language without some of the more "mathematical" features of more popular FP languages... but perhaps it doesn't need them...
Pro-tip for language designers: don't skimp out on abstractions (e.g. Go\generics, Elm\typeclasses).
Haskell is basically *defined* by the presence of higher order typeclasses and lazy evaluation, neither of which Elm has.
You could also probably say that OCaml is defined by its module system and record objects.
Perhaps we can both agree that Elm is just a typed functional programming language without some of the more "mathematical" features of more popular FP languages... but perhaps it doesn't need them...
Pro-tip for language designers: don't skimp out on abstractions (e.g. Go\generics, Elm\typeclasses).