Apparently a human-readable homoiconic language is still an unsolved problem...
In 0.17, commands and subscriptions mean that, not matter how deep you nest components, you can still send and receive messages to/from the outside world (i.e. ports).
Most of these comments boil down to, "the food's awful and the portions are too small!". Someone wants better JS interop because Elm will be a small part of their stack; someone wants server-side and isomorphic apps because Elm will be a large part of their stack. Yes, the tooling and language features have a long way to go, and hopefully Evan will make progress while at NoRedInk. If you enjoy Haskell, you're not really Elm's target audience. If you hawkishly watch HN, you're probably not the target audience - the point is that it's sane programming for the rest of us.
Morse code, alpha bravo charlie, ASCII... there's actually a long history of doing this. Maybe not one meant for easy of memorization and drawing though. Even Mark Whatney had to be taught Morse code on Mars.
(Yes the phonetic alphabet is meant for ease of hearing by people, but writing a program to understand 26 distinct sounds can't be nearly as hard as natural language transcription.)
I'll opine: git's sense of semantics seems to rival JavaScript's ("sure I'll add an int and a string"). I checkout branches but also checkout files to undo unstaged changes, but staged changes are a reset. How about "undo" as a word people would understand? Nope, doesn't do anything. Can I get a log function that shows the commit history by default? And when I check out a branch it says I'm up to date with origin/branchname but it's lying because that's just the local copy and it hasn't done a fetch. And of course in 2.0 they didn't try to clean anything up, they just changed a few defaults.
I think I deserve a medal for understanding enough git to get by. Specifically, a purple heart.
Probably not in the next few years. However, this sort of thing is in the back of people's minds. There was a question of dropping the Int type a while back, and the objections (besides semantics, e.g. indices are always ints) included wanting to be able to compile to machine code, where (unlike JS) ints and floats were different.
If you mean parsing by machine, the solution is to have a separate machine-readable output (JSON perhaps). If you mean comprehension, that's a valid point that is being discussed elsewhere on the page.
I have tried to talk Evan (Elm's creator) out of the first person, but as you can see he likes it. But I think you bring up an important point: for some people, being able to use the social parts of our brain is like offloading to the GPU, and for others it's like firing up a generator when the power goes out.
It wasn't immediately clear to me, but this library tracks both the state (e.g. "state1") and a payload, some arbitrary value. This already seems like two separate concerns?
As for transitions, it seems that each state has a collection of functions for every other state, which are called with the payload to determine if that state should be transitioned into. This seems error-prone - if there's no transition, is that the end or an error? If there are multiple, how do you choose?
It also seems that the state machine will run immediately to completion unless you return a promise payload. (Bluebird? ES6? It doesn't say.) So if you want a reactive document, this doesn't seem like a fit.
To quote Alan Cooper, you don't want to be first to market, you want to be best to market. Build something great and let your opponent make the painful first inroads.
What happens when you introduce a bug that isn't discovered for 6 months? What happens if you think of a better way to do something? What happens if you're working on something and the power goes out, leaving you with partially-completed and saved work with no editor history? And so on...
Some of the arguments may seem plausible in theory, but as soon as I contemplate doing my 9-to-5 dev work without source control (specifically git)-- yeah, no, not happening.
If someone thinks selectAll is inconsistent, they probably don't understand the central enter/update/exit pattern [1].
D3 is a powerful _drawing_ library and I've used it for totally custom visualizations where no canned tool would suffice. I think there's an un- or only partially-filled niche for more customizable _charting_ library that is more user-friendly.
D3 has nested selections that let you handle cases like this. The data for a single element can be an array, and if that element is a div (HTML) or g (SVG) you can do another join and bind those data to its children. More info: http://bost.ocks.org/mike/nest/
To "substitute the objects with new ones", do another join, pass a key function as the second argument if necessary, and use the enter/update/exit pattern.
In 0.17, commands and subscriptions mean that, not matter how deep you nest components, you can still send and receive messages to/from the outside world (i.e. ports).