Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Elm faster and friendlier in 0.16

elm-lang.org

Post reply on HN
Print view View original

41–50 of 92 posts

Re: Making Elm faster and friendlier in 0.16

#41

Post by mercurial »

danneu wrote: post #16
methehack wrote: post #11

I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?

I personally like React + Immutable.js (for the store) + Redux ( https://github.com/rackt/redux ) which is more similar to Om and apparently Elm. It's actually the first Fluxlike implementation I willingly use.

I'm using the same stack (minus immutable.js, but I'm thinking on it), combined with redux-simple-router. Apart from the usual problems associated with Javascript, it works pretty well, and I feel it's easy to understand what is going on.

On the other hand, there are some pitfalls. Since you may need to trigger actions based on some transient state (eg, fetching data from the server), you occasionally need to set flags in your store ("my state is dirty"). Forgetting to clean up a flag will lead to tears.

Re: Making Elm faster and friendlier in 0.16

#42

Post by [deleted] »

boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

[deleted]

Re: Making Elm faster and friendlier in 0.16

#43

Post by sgrove »

vilterp wrote: post #39
ablesearcher wrote: post #32

Earlier quoted context omitted.

@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…

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

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

Re: Making Elm faster and friendlier in 0.16

#44

Post by randomNerd »

boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

Regarding global state and React, this looks relevant: https://www.youtube.com/watch?v=Uu4Yz2HmCgE&t=11m37s

Re: Making Elm faster and friendlier in 0.16

#45

Post by skybrian »

tlarkworthy wrote: post #22
boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill…

It looks like you can always avoid needing signals of signals by declaring one signal for each type, not a signal for each instance.

All instances of the same message type can share a signal, as long as the messages contain a unique key to distinguish between objects, and the code that lives downstream filters events by key.

It's much like a database-backed app where you don't dynamically create tables while your app is running. Instead, instances are stored within a table and identified by their keys.

Re: Making Elm faster and friendlier in 0.16

#46

Post by tlarkworthy »

rtfeldman wrote: post #26
tlarkworthy wrote: post #22

Earlier quoted context omitted.

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill…

What do you mean by "dynamic GUI"? As opposed to what other kind of GUI?

A GUI with n buttons and a button to add and remove additional buttons

Re: Making Elm faster and friendlier in 0.16

#47

Post by tlarkworthy »

skybrian wrote: post #45
tlarkworthy wrote: post #22

Earlier quoted context omitted.

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill…

It looks like you can always avoid needing signals of signals by declaring one signal for each type , not a signal for each instance . All instances of the same message type can share a signal, as long as the messages contain a unique key to distinguish between objects, and the code that lives downstream filters events by key. It's much like a database-backed app where you don't dynamically create tables while your a…

No because you must might want a whole subgraph of dataflow associated with each instance. You are right you can perhaps do it with collection primitives as signals. Creating tables is appropriate for multi tenancy apps. Or apps that let you build apps, or analogously, a drawing program for graphics.

Re: Making Elm faster and friendlier in 0.16

#48

Post by Keats »

danneu wrote: post #16
methehack wrote: post #11

I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?

I personally like React + Immutable.js (for the store) + Redux ( https://github.com/rackt/redux ) which is more similar to Om and apparently Elm. It's actually the first Fluxlike implementation I willingly use.

Same here, just switched to TypeScript today and it's quite nice. Not as nice than Elm in terms of tooling (those errors are much more helpful than the TypeScript one and js of course). I guess it depends whether you want the React community or don't mind a smaller one and a functional language.

Re: Making Elm faster and friendlier in 0.16

#49

Post by ablesearcher »

vilterp wrote: post #39
ablesearcher wrote: post #32

Earlier quoted context omitted.

@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…

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

Re: Making Elm faster and friendlier in 0.16

#50

Post by lijnen »

nwienert wrote: post #36
rtfeldman wrote: post #23

Earlier quoted context omitted.

Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…

Actually, you do see a lot of questions and problems with the single state atom. In fact, I'd argue it's inherently a side step towards a future that has the best of both worlds: encapsulated state within components, but backed by some global state store invisibly. This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a…

https://github.com/tonsky/datascript
Post reply on HN