Comment by innocentoldguy | Hacker News Reader

Comment by innocentoldguy | Hacker News Reader

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), if you're interested in learning it.

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

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

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.

*a pedantic

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

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.

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.

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.

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

After further consideration, I believe this is incorrect. This usually isn't done because integers are closed under addition, subtraction, and multiplication, so the "promote according to argument type" C behavior doesn't lose accuracy in those cases. There obviously is a platonic correct result when you divide two integers, but it is not in general an integer, so the C behavior introduces bugs (explaining the popularity of divide_and_return_float() -- I don't care what types the arguments were, as long as I get the result I'm looking for).

Async only interop to JS is a bit sad though

Though there's the weakly documented escape hatch of writing native modules.

Reply on news.ycombinator.com