6 ms·

There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches

There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm. I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy. There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm https://pragmaticstudio.com/courses/elm), if you're interested in learning it.

joshribakoff 9y ago
The recording of steps is called event sourcing and both vuex and redux implement the pattern, I'm sure elm is great but that benefit is not unique to elm https://martinfowler.com/eaaDev/EventSourcing.html https://martinfowler.com/eaaDev/EventSourcing.html
- galfarragem 9y ago
  Elm's creator is a visionary [1]. E.g. Redux took inspiration from his thoughts. Rust's compiler error messages also. It was rather common on elm core newsgroup to see him asking for secrecy on new ideas before releasing a new version of Elm. The negative part is that Elm's development is rather slow and not pragmatic. This is painful on the short term - specially if you come from JS land.. [1] An example of a (great) conceptual talk: https://www.deconstructconf.com/2017/evan-czaplicki-on-storytelling https://www.deconstructconf.com/2017/evan-czaplicki-on-story...
regularhackerer 9y ago
Async only interop to JS is a bit sad though
- always_good 9y ago
  Though there's the weakly documented escape hatch of writing native modules.
thaumasiotes 9y ago
> It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where 1 + "1" "1" + 1 1 + 1 "1" + "1" are all 2, and 1 . "1" "1" . 1 "1" . "1" 1 . 1 are all 11. Letting you specify the result you want by the function you call basically solves that whole problem.
- LeonidasXIV 9y ago
  I think this was only to demonstrate the point. Elm's string concatenation operator is ++, so you never run into a case where this would happen.
- shaki-dora 9y ago
  That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_integers(), sum_integer_and_float() etc... Which would be both extremely ugly and a terrible waste of memory.
  - thaumasiotes 9y ago
    You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc. This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result. That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2). Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.
ratboy666 9y ago
1 + "1" => "11" is not the sign of an "untyped" language. I would expect 1 + "1" => 50 (ascii asm), 1 + "1" => 242 (ebcdic asm) or 1 + 1 => 2 (length tagged string, eg, untyped pascal-ish variant), or 1 + "1" => some seemingly random value (C lang) in an "untyped" language. 1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings". But, on reflection, I am probably an pedantic iconoclast.
- hellohn123 9y ago
  *a pedantic

joshribakoff 9y ago

The recording of steps is called event sourcing and both vuex and redux implement the pattern, I'm sure elm is great but that benefit is not unique to elm https://martinfowler.com/eaaDev/EventSourcing.html https://martinfowler.com/eaaDev/EventSourcing.html

galfarragem 9y ago
Elm's creator is a visionary [1]. E.g. Redux took inspiration from his thoughts. Rust's compiler error messages also. It was rather common on elm core newsgroup to see him asking for secrecy on new ideas before releasing a new version of Elm. The negative part is that Elm's development is rather slow and not pragmatic. This is painful on the short term - specially if you come from JS land.. [1] An example of a (great) conceptual talk: https://www.deconstructconf.com/2017/evan-czaplicki-on-storytelling https://www.deconstructconf.com/2017/evan-czaplicki-on-story...

regularhackerer 9y ago

Async only interop to JS is a bit sad though

always_good 9y ago
Though there's the weakly documented escape hatch of writing native modules.

thaumasiotes 9y ago

> It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where 1 + "1" "1" + 1 1 + 1 "1" + "1" are all 2, and 1 . "1" "1" . 1 "1" . "1" 1 . 1 are all 11. Letting you specify the result you want by the function you call basically solves that whole problem.

LeonidasXIV 9y ago
I think this was only to demonstrate the point. Elm's string concatenation operator is ++, so you never run into a case where this would happen.
shaki-dora 9y ago
That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_integers(), sum_integer_and_float() etc... Which would be both extremely ugly and a terrible waste of memory.
- thaumasiotes 9y ago
  You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc. This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result. That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2). Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.

ratboy666 9y ago

1 + "1" => "11" is not the sign of an "untyped" language. I would expect 1 + "1" => 50 (ascii asm), 1 + "1" => 242 (ebcdic asm) or 1 + 1 => 2 (length tagged string, eg, untyped pascal-ish variant), or 1 + "1" => some seemingly random value (C lang) in an "untyped" language. 1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings". But, on reflection, I am probably an pedantic iconoclast.

hellohn123 9y ago
*a pedantic