appsappsapps

Isn't Elm built on top of maybe the most mainstream "platform"? JavaScript? If all else fails you can glue in some JavaScript via its ports system[1].

[1]Languages like PureScript provide a much more convenient FFI for this glue, but the glue and escape hatch is still there with Elm.

The best ideas are those that you can share between languages. When you get hung up on idioms, or when you recreate idioms that don't matter in another language, that's where the problems are. Exposure to a lot of languages allow a person to figure out that union of computation that benefits all languages.

The "no" was probably aimed at the fact that you were splitting hairs against their use of "sequence".

Optional can generally be thought of as a "sequence" of one or zero values. You could use an array of "[some]" or "[] /* none */" to manage control flow in an almost identical way (you'd just be adopting and managing an API that doesn't statically ensure that these arrays never have more than 1 value).

"map/flatMap" are predictable functions that can be used to manage the transformation of data (which is generally the entire point of code). The type/context that a computation is lifted into communicates a lot: Optional, for example, can be returned for a computation that may or may not return a value, and it can be "mapped" into another value by a pure computation that _always_ returns a value, or "flat-mapped" through a computation that may produce another nullable value. Anyone familiar with these basic functions can jump in, read the code, and generally know that every computation lifted into "map" can't fail, while every computation that is "flat-mapped" can. And in static languages it's all checked by the type system! No testing for "null" everywhere!

Elm on the frontend and Haskell on the backend is a sensible choice, though at that point you may be better off with PureScript on the frontend.

Every single comment here is focused on just one aspect of this article: speed. Far more interesting points the article covers are around _how_ Elm optimizes and _how_ developers optimize Elm code. From the conclusion:

- Optimizing Elm only touches view code, unlike everyone else.

- Optimizing Elm cannot introduce sneaky bugs, unlike everyone else.

- These results should generalize to apps of any size.

Also interesting is how Elm's immutability allows it to use requestAnimationFrame by default, which plain vanilla JS libs can't use by default.

Curious: what is your definition of performance and how do you view this complaint?

What typed languages have you used and what aspects do you find tedious? I find that the experience of writing brittle type-checking logic and tests in dynamic languages is rather tedious in its own right.

I'm not sure what you're getting at with "useful," but it looks like it's going to be incredibly fun to play with, and I wish it were available when I was a kid messing around with HyperCard stacks.

What about Dwarf Fortress?

First two tries:

  ~ % curl "http://api.genderize.io?name=pat"
  {"pat":null}%

Shouldn't that be "unisex"?

  ~ % curl "http://api.genderize.io?name=patricia"
  {"patricia":null}%

Hm...

I saw a couple engineers from Craigslist present at a Mongo event within the last year, and they strangely acted as if Mongo were a joke—that is, they treated it like a playground, continuously talked about how and where it broke, and continuously reminded us that they didn't care about its data integrity because they were just messing around.