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

IBM releases Elm-powered app

discourse.elm-lang.org

Post reply on HN
Print view View original

171–180 of 199 posts

Re: IBM releases Elm-powered app

#171

Post by rs86 »

hellofunk wrote: post #99

Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of…

Elm has managed effects and purity, and I had immense satisfaction in using it... Managed effects means that doing http requests and working with DOM events are managed from a runtime and from the point of view of the programmer they are just returning values that describe the effectful actions they want to perform, and any changes to programming state from those actions are apparently as function arguments...

The language has its warts, but I would use it if it were not for the poor project management and support.

Re: IBM releases Elm-powered app

#172

Post by rs86 »

hardwaresofton wrote: post #42
haskman wrote: post #36

Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming t…

I've always thought that Elm was like Purescript in the way that it was just another way to bring the good parts of Haskell (a good type system) into JS. I didn't consider elm's architecture as the main value proposition -- if you squint it looks just like every other data management model for component-based approaches these days -- flux, redux, etc all work in a similar way, +/- immutability. Hopefully people aren'…

Elm is quite different from purescript or Haskell... It shares syntax and the purity semantics but its type system is much less expressive (no type classes); no do notation; no monads...

Re: IBM releases Elm-powered app

#173

Post by rs86 »

Athas wrote: post #33
cttet wrote: post #28

Earlier quoted context omitted.

"one of the few languages that have parametric polymorphism but no ad-hoc polymorphism" I wonder what others are? Would like to try them.

OCaml and Standard ML are two others, and I'd say OCaml is established enough that Elm is not really breaching new ground here. The main difference is that OCaml has other features you tend to use instead, particularly the module system.

Can't the module system be used for ad hoc polymorphism?

Re: IBM releases Elm-powered app

#174

Post by cttet »

hellofunk wrote: post #63
cttet wrote: post #30

Earlier quoted context omitted.

This was also the thing that attracted me to Elm years ago. But at that time Elm doesn't have a CSS module yet. Now with Elm-UI, it is like my dream HTML/CSS replacement. However that was all for static UI though. Writing Elm app is still a pain if you are not a Javascript expert. Elm's implementation of the web API is minimal and the progress is extremely slow. In addition, most function that's in libraries in Javas…

Elm-UI is in a questionable state. Their github page originally said it was no longer maintained. Now they acknowledge that they are struggling to update to the latest version of Elm which caused many syntax breakages.

As nhanb mentioned I meant https://github.com/mdgriffith/elm-ui. There is a great talk about it: https://www.youtube.com/watch?v=Ie-gqwSHQr0

Re: IBM releases Elm-powered app

#175

Post by cttet »

yakshaving_jgt wrote: post #40

> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous." Like, what's the alternative? More JavaScript?

The alternative is less Javascript logic written by the app developer (and instead use packages and APIs directly).

Elm disguised as a beginner friendly language for web front-end, which is not true with the case of ports. Where you need to be fairly familiar with Javascript.

The Elm community also advertise a lot on the advantage of development happiness of Elm over Javascript, and mention the Javascript fatigue a lot. But the truth for a beginner is that you can't escape the Javascript ecosystem when using Elm, and sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided.

If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.

Re: IBM releases Elm-powered app

#176

Post by razze »

leshow wrote: post #129
hardwaresofton wrote: post #42

Earlier quoted context omitted.

I've always thought that Elm was like Purescript in the way that it was just another way to bring the good parts of Haskell (a good type system) into JS. I didn't consider elm's architecture as the main value proposition -- if you squint it looks just like every other data management model for component-based approaches these days -- flux, redux, etc all work in a similar way, +/- immutability. Hopefully people aren'…

Elm isn't a general purpose programming language. You can only write web-apps with it you can only use TEA (the elm architecture). In that way, the TEA really is it's main value proposition.

there are some niche apps like games that use Elm without TEA afaik

Re: IBM releases Elm-powered app

#177

Post by a-saleh »

yogthos wrote: post #163
yakshaving_jgt wrote: post #150

Earlier quoted context omitted.

This argument is essentially “the tool doesn’t protect me from everything, therefore it’s better to have no protection at all.” And I don’t agree with it. I’m aware Elm doesn’t have dependent types.

There is a cost associated with eliminating this class of errors using static typing. The cost is that you're restricted to a set of statements that the type checker can verify to be correct. Writing code for the benefit of the type checker is often at odds with writing it in a way that conveys the meaning best to the human reader. This is necessarily less expressive than the dynamic approach. Code written in dynamic…

In my opinion you get more than just "eliminating a class of bugs", in my (arguably limited) forays into functional programming languages I really liked the type-guided programming.

One aspect is "I refactored the code, fixed all the type-errors and everything works", another is "I don't know, what should I write here, compiler, tell me!" with typed-holes, along-side some nice search, such as hoogle (or elm's fancy search [1]) In simmilar fashion, I remember Elm was enforcing a version bump, if you break package public api.

On the other hand, you definitely are replacing one set of problems for a different set, and it is up to you to decide what kind of problems you like solving better.

For me, access to fast immutable data-structures seem to have the best return-on-investment, and easiest to introduce (i.e. even Javascript or Python have somewhat decent libraries for these).

[1] https://klaftertief.github.io/elm-search/

Re: IBM releases Elm-powered app

#178

Post by a-saleh »

adgasf wrote: post #122
hellofunk wrote: post #99

Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of…

I would take F# + Fable over Reason since Reason doesn't have computation expressions or do-notation

I think you could replicate some of these with ocaml_ppx system (looks like macros over ast?)

I.e. https://github.com/janestreet/ppx_let kinda looks like let! bindings in F#

Re: IBM releases Elm-powered app

#179

Post by yogthos »

a-saleh wrote: post #177
yogthos wrote: post #163

Earlier quoted context omitted.

There is a cost associated with eliminating this class of errors using static typing. The cost is that you're restricted to a set of statements that the type checker can verify to be correct. Writing code for the benefit of the type checker is often at odds with writing it in a way that conveys the meaning best to the human reader. This is necessarily less expressive than the dynamic approach. Code written in dynamic…

In my opinion you get more than just "eliminating a class of bugs", in my (arguably limited) forays into functional programming languages I really liked the type-guided programming. One aspect is "I refactored the code, fixed all the type-errors and everything works", another is "I don't know, what should I write here, compiler, tell me!" with typed-holes, along-side some nice search, such as hoogle (or elm's fancy s…

With Clojure the approach is to use REPL driven development. It's tightly integrated with the editor, and any time you write a function you run it to see that it's doing what you intended. Because you're evaluating code as you're writing it, there's generally no confusion regarding what the code is doing. [1]

Meanwhile, immutability as the default makes it natural to structure applications using independent components. This helps with the problem of tracking types in large applications as well. You don't need to track types across your entire application, and you're able to do local reasoning within the scope of each component. You make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components.

Spec [2] is a contract system that's often used to define API boundaries in Clojure. I find it provides an advantage over static typing because it directly focuses on semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they're in order. This is difficult to express using most type systems out there, while trivial to do using Spec.

Spec also facilitates stuff like hoogle [3].

[1] https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.... [2] https://clojure.org/guides/spec [3] https://re-find.it/

Re: IBM releases Elm-powered app

#180

Post by yogthos »

willtim wrote: post #162
yogthos wrote: post #135

Earlier quoted context omitted.

In this comparison of a minimal "real world" app comparison, Elm version has around 3 times as much code as ClojureScript. https://medium.freecodecamp.org/a-real-world-comparison-of-f...

An apples and oranges comparison. Any difference would surely be made up by all the tests one would have to write to be sure the clojure code was free of basic errors.

That's a completely baseless assumption. I have not found the need to write any more tests in Clojure than I have in statically typed languages. The only tests my team ends up writing tend to be end-to-end specification tests, and you would want to have those in any serious project regardless of type discipline.
Post reply on HN