Hi, author here. Thank you so much for this unfudging! I knew I was fudging things up a bit, and I didn't really understand the relationships between Prolog, Datalog, Horn clauses, and first-order logic. This clears things up a lot, though I think I'll need to read it a couple more times for it to sink in! Thanks again.

Thank you for your article! Also note tom_mellior's corrections above, particularly about datalogs with two head literals. I'm fudging things up also!

Oh hey Sam! Been a while! Thanks for reading man :)

Really sad to hear this; you guys were doing really cool work.

Maybe the answer is for elm-html to put a cursor-state attribute on textual input elements, and have event handlers for selection change? Then you can have the cursor state in your atom if you need it without ports....

That might solve the cursor issue, but it's a bigger issue than cursor state.

The real issue is that Elm doesn't treat its programmers like grown-ups. That sounds harsh, so let me explain . . .

I've drank enough of the Haskell Kool-Aid to realize that, despite the surface discourse, Haskell is not about religious devotion to purity and lazy-evaluation. It's about managing side-effects, and being honest about them in your type signatures. Yes, Haskell allows functional purity but its real genius lies in how well it helps you manage state. (I did an imperative Algorithms course completely in Haskell, and the language really shines. Mutable unboxed arrays, mutable atomic references . . . it's all there when you really need it.)

Unfortunately, the folks driving Elm development take a paternalistic tack. (If someone seeks to argue this point, it's not hard to come up with many, many examples from the Elm mailing lists.)

Here's a few examples:

- Elm shouldn't have type-classes because, allegedly, they are too hard for JS-folks to understand. (https://groups.google.com/forum/#!searchin/elm-discuss/type$...)

- Elm doesn't publish how you are supposed to write native modules (you must discern it from the code and it's subject to change without notice), because Elm's author thinks you can't be trusted to use FFI wisely. (https://groups.google.com/forum/#!searchin/elm-discuss/nativ... and the can was kicked here: https://groups.google.com/forum/#!searchin/elm-dev/native/el...) And, no, Elm's ports are not the equivalent of FFI.

- In the most recent release, operators were removed because synonyms for map (<~) and apply (~) are allegedly to hard understand.

- Appartently, you shouldn't even mention Haskell as a resource for learning Elm. (https://groups.google.com/forum/#!topic/elm-discuss/OlzLOPix...)

I think it's healthy for programming languages to have a point of view; that is, languages should lead you in a direction. (Clojure does a great job at this.) Yet, ultimately, a language shouldn't censor its programmers.

Upshot: Component local state should be an option in Elm when you really need it.

Evan has described a lot of the thinking behind his decisions in this talk: https://www.youtube.com/watch?v=oYk8CKH7OhE

The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the first place, like type classes) because design is not finished when there is nothing more to add but when there is nothing more to remove.

I've seen Evan's talk. Evan confuses the presentation of features with the value of those features. (I suppose one could solve the difficulties people have in learning Mathematics by throwing out everything after Algebra I; another solution, however, might be to do a better job teaching the more difficult stuff.)

Just because you shouldn't expose new programmers to advanced concepts on the first day doesn't mean they shouldn't be a part of the language. Similarly, the fact (<~) might confuse someone new to Elm isn't a reason for removing it from the language.

I'm sympathetic to the concern that some code is too "clever" or dense; but Elm swings the pendulum too far.

(Btw, type-classes are not incidental complexity:

https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=hIZxTQP1ifo )

It seems backwards to me to optimize a language for newbies.

This is what I expected would already be setup - it'd be a pain to deal with cross-browser stuff when implementing it, but it'd be a dream for app developers (me).

`elm-make --report=json MyFile.elm` gives the error messages as JSON; very easy to parse out line & col. It's how the vim plugin that there's a video of in the post was made.

Yes, but most text-editors can already parse out the format that the gnu compilers emit, so why not do that?

Both the Light Table team (http://www.lighttable.com/2014/06/10/light-table-and-apples-...) and the Apple Swift lead (Playgrounds feature: http://nondot.org/sabre/) have explicictly cited Bret as an important influence — his ideas are certainly not going to waste.

Hopefully we can hope to see some of this good design thinking in Android, since the design lead of webOS, Matias Duarte, is now design lead at Android (http://en.wikipedia.org/wiki/Matias_Duarte)