> > First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case.

> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.

So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.

> Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript).

Neither is even remotely as robust — let alone friendly — as Elm's type system.

It's not so black and white :)

Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time.

I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")

Check out ReasonML, great Typesystem and robustness. Tooling is still a little rough though.

> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

You're completely correct, though for whatever reason functional languages almost always have strong type systems.

With the huge exception being Lisp-based languages (closure, scheme, etc....). Heck, Lisp was the first functional language and first one that made full use of dynamic typing.

There is also Erlang and Elixir which while functional aren't typed. There are some static analysis tools though.

I'm just getting into Elixir now but even without it being statically typed, it does catch a ton of errors and present warnings at compile time.

It's remarkably useful so far. I feel like I have an extra level of protection compared to Ruby or Python.

Erlang is dynamically typed. It's certainly not untyped - it's assembly and Forth that are untyped.

Dynamic typing (like static typing) is a spectrum, actually. You can flag method missing errors at a minimum, but in a nominally dynamically typed system, you could flag class mismatches before you ever got to a dispatch error.

Sure, I didn't say it wasn't.

My point was that 'untyped' should not be conflated with 'dynamically typed'. They're worlds apart.

"Functional language" has come to tend to mean a language with an ML-style type system, possibly because almost all serious languages these days have first-class functions and map/reduce/filter. But ultimately the term means different things to different people.

Not at all. The term language determines what type systems are possible. The lambda calculus serves as an excellent base for languages that admit good type systems.

Better than, say, assembly language.

what does orthogonal mean in this context?

It means that the two features are independent: you can have the compiler check types in non-functional languages, and you can have functional languages that do not have static typing. Elm happens to have both static type checking and language features supporting functional programming.