[ablesearcher]

@rtfeldman -- I think your response is a bit disingenuous since only yesterday you wrote, in response to a question about cursor state, this:

"I wouldn't maintain cursor state in the model; I'd just implement the port like this: http://stackoverflow.com/a/14508837/2334666

In other words, you never use the value attribute on the input; rather, you give it a unique key and don't touch it directly. Whenever you want to change its value, just send the desired new value to that port and let the JS snippet do the "stash cursor position, set the new value, restore cursor position" bit.

If you need to do this for multiple elements, send a DOM query string to the port and call document.querySelectorAll (or the like) with it to apply the logic to the correct element."

(See https://groups.google.com/forum/#!topic/elm-discuss/I2JleY8b...)

Clearly, you don't even believe that all component local state belongs in the atom. And kicking the issue to JS-land is just hiding the problem.

Almost everything should be unidirectional, but @boubiyeah has a valid point. Not everything belongs in a single state atom. (I say this having written a 4000 LOC Elm app, which I'm porting Clojurescript/Re-frame due to precisely this issue.) Even Haskell uses mutable references for this stuff.

[rtfeldman]

That's not at all disingenuous; the two are completely unrelated. :)

The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not.

In this case I didn't think the extra work required to wrap the DOM API for cursor position would be worth the trouble.

That's certainly not an endorsement of the DOM's architecture. ;)

[ablesearcher]

> "The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not."

> "Local component state is the new two-way data binding. . . If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "yeah it wasn't awesome so I went back to local component state."

> "I wouldn't maintain cursor state in the model . . . Whenever you want to change its value, just send the desired new value to that port and let the JS snippet do the "stash cursor position, set the new value, restore cursor position" bit."

The question we were addressing is where your state should live. @boubiyeah questioned the wisdom of storing all component state (e.g., the current position of a cursor) in a global atom. You responded that "[l]ocal component state is new two-way data binding." Yet yesterday you advised that component local state should live outside of the global atom.

Maybe it wasn't disingenous, as perhaps you've simply changed your mind. But then you should make clear that your opinion today is different from what you advised yesterday, as it bears on the credibility of your current advice.

[rtfeldman]

Hm...my response was the exact opposite of that. Maybe I need to rephrase?

In bullet points:

1. Yesterday someone presented a case where they needed to interact with a DOM API that used local state.

2. I didn't think it would be worth the trouble to wrap that API.

3. That is not an endorsement of local component state.

Hopefully that clears things up. :)

[rlander]

Don't feed the troll. While @ablesearcher's obviously part of the Elm community, he's using a throwaway account to vomit angry rubish on HN.

[ablesearcher]

When did evidence-backed criticism become synonymous with trolling? Also, which statement exactly was angry? (Let alone rubbish? Or, gasp, vomit?)

It seems you want all Elm news to be positive Elm news. So does the language's author. In fact, when addressing the announcement re: Hacker news, he wrote this:

"Just an FYI, if you go to a HN post via direct link and vote on it, those votes either do not count or are used as demerits because it indicates that people are trying to artificially boost things. I guess getting a kickstarter to the top of HN can be worth a lot of money, so they try to protect against voting rings."

(See https://groups.google.com/forum/#!topic/elm-dev/NQxML4HA4X8 )

Civility is important. But so is the honest, unfettered exchange of ideas.

[rlander]

Well, for starters, use your real name, like the rest of us, not a throwaway account.

I guess if your issues were legitimate, we'd see a post on the mailing list, not an open attack on Richard's credibility.

For the record, this is evidence-backed criticism:

https://news.ycombinator.com/item?id=10081955

Yours is just trolling.

[tomp]

Not everyone disagreeing is a troll.

[nwienert]

So basically you think it's ok to use local state, but only for DOM related stuff?

[rtfeldman]

Nope, just that the effort required to wrap something in a nicer architecture sometimes outweighs the benefits you'd get from the upgrade. This was one of those cases.

[vilterp]

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

[ablesearcher]

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.

[brodo]

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.

[ablesearcher]

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 )

[PeCaN]

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

[sgrove]

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