A small dive into, and rejection of, Elm | Hacker News Reader

A small dive into, and rejection of, Elm

medium.com

101 pointsadamlett51 comments

> Again: no way to enumerate the options at compile or runtime so copy paste it is:

The author didn't find a built-in function to construct a list of option tags from a list of strings, so, instead of building their own... they copy pasted all the strings and manually built the option tags one by one. They could have collapsed that into a one-line `map` call.

Elm is young and has a long way to go: it is definitely missing many of the conveniences that a web framework will give you (such as functions for building forms from data). Personally, I miss typeclasses coming from Haskell. But it is a Haskell/ML-influenced language before it is a web framework, so for a while anybody using it should expect to be building more of their own plumbing.

Maybe I'm being presumptuous, but the author's approach seems like the kind of error fairly junior programmers make all the time: "if there's no function to do it for me, it can't be done, I'll copy-paste". That's a teachable moment. It's too bad if trying Elm when they didn't have the experience to build their own plumbing turned them off from that kind of approach: I liked Elm for a side project, and am hoping to try similar approaches like PureScript in the future. Getting the "if it compiles it probably works" experience on the front end is addictive.

How would you enumerate over a union type? as far as I know there is no way to do that in Elm.

Can you show your one line map call youre talking about

I think he means to make a list of all member of the type and then iterate over it. Then you have the options method that get a union type and can render the correct output

This is mentioned in the article. The author criticizes this because it means they have to keep the type and the list in sync.

I think this is a pretty pedantic reason to dismiss a language, personally.

Maybe to _dismiss_ a language. But it is a reasonable _criticism_ of the language. I hate those kinds of edge cases between strong and weak typing where the compiler knows something, but you have to express it again.

Granted, though, there aren't many languages that can handle that. As far as I can see, it requires compile-time code execution.

IMO that's a pretty good criticism of a language that's supposed to be type-safe, but forces you to break its type safety because its lack of a feature.

And it's not like any other language you can choose from for working in the browser is perfect.

Your small dive prompted me to create a simple version of what you were describing [1]. I didn't use my usual editor, and just used the cljsfiddle itself.

I really wanted to create a spec for the data in app-state, and check the value in the app-state atom each time I edited it (perhaps with an add-watch). That gets you many of the same advantages of static typing, but you only add the extra insurance when you think its worthwhile instead of always.

Instead of using strings for time-choices and page-choices (in the code at [1]), you can use maps like

    [{:title "Day" :time 24}, {:title "Hour" :time 1}...]

and expand when nessicary. It shouldn't be too difficult to keep them in sync this way.

You might want to check out clojurescript again sometime soon. Clojure.spec (and cljs.spec) are going to offer a huge jump in usability. Clojure.spec is a tool kit, and specs are basically definitions of data, that can be used for parsing, unparsing, and generating that very data. The beginning of this (interactive, cljs driven) blog post shows clojure.spec off a bit.

[1] - http://escherize.com/cljsfiddle/#gist=eea10854f99ef124f8dc15...

[2] - http://blog.klipse.tech/clojure/2016/10/10/defn-args.html

I don't know about anyone else, but for me in Chrome there was an empty white box where the code was supposed to be on your first link. When I clicked around in it a bit, the code magically appeared.

(I offer this as no criticism of anything, just in the hope it might save a single other soul the same confusion I had.)

Same for me. The editor window was blank until I clicked inside it.

Thanks guys I'll look into it.

I think it's fixed, if anyone has any issues let me know:

http://gitlab.com/escherize/cljsfiddle

Clojurescript with re-frame is great.

re-frame is absolutely fantastic! I've never enjoyed frontend web development as much as I have using ClojureScript with re-frame.

Absolutely agree. And the cool thing is you can use re-frame and friends on mobile with React Native. The most pleasant developer experiences I've had were with the Clojure and ClojureScript ecosystems.

https://github.com/drapanjanas/re-natal

Thanks for the link. I hadn't heard of re-natal, but it looks really great. Will have to try it now :)

Wouldn't dictionaries be a better option than union types? Union types seem to be for heterogeneous types, but Select boxes are homogeneous. Dictionaries are key/value stores with multiple named values per key, and they can be iterated. Sounds perfect for the usecase.

So two red flags. Author wanted to replace an existing tech with another buzzword tech he has never worked with. And the author immediately choose the wrong data type, likely because it was different.

I do agree though, if a web framework cannot easily do forms, its not very useful.

I think in this case it boils down to whether you ever need to do a pattern match over the select box type. If you do, then having the compiler check for exaustiveness makes the code more robust. If all you care is the string representation of the strings and how they convert to a numeric time then a dictionary will do the job just as well, while keeping things simpler.

The lack of introspection for union types during compile time has created some frustration for me as well. Not having some kind of compile time union list available sucks (it would probably be possible using some LISP-esque macro system), but I will gladly accept it, given the runtime safety.

I would like to encourage the author to revisit the 'timeRangeFromString' function and consider wrapping the result in a Maybe or Result, as this is exactly the type of function that is not guaranteed to deliver a result. With strongly typed languages like Elm it is best to use the type system to one's advantage, and not fight against it.

That is not to say that everyone should like Elm or similar languages, but they require you to shift the way you think about how you structure types.

Even without a full-blown macro system, it could be worthwhile to have a feature specifically for this. Haskell lets you write "deriving Enum" to (in effect) generate the list of values at the bottom of the blogpost automatically.

There is no reasonable or agreed upon way to do select boxes. You might at this point go “what?! isn’t that pretty basic stuff?” and I’d argue that you’d be right. The more I dug into this problem the more my conclusion solidified: Elm is: not ready for serious use

I've only briefly looked at Elm so far, so I'm not sure how much of an issue this is or isn't in real code. However, I'd like to point out that Javascript (without jquery or other frameworks) also doesn't have any selectbox support besides the built-in HTML ones (which aren't very flexible). I even wrote my own yesterday. Took about 100 lines of JS (no dependencies). I've written similar code in ClojureScript.

I know that the complaint is that the author had difficulties building a select/dropdown. Maybe its harder in Elm than in JS or ClojureScript for some reason, which is a shame if true, but it can't be thaaaat hard, can it?

Of course, Elm is still really young, so its possible it does, indeed, still need a bit more polish to make it truly useful.

The core of his point seems to be that Elm almost provides you with a strong type-safe way of building a select box. But it stops short by not allowing you to enumerate the values in your type definitions. Since you can't do this, you have to create a regular list with those values in it, which both breaks DRY principles and prevents the compiler from fully validating your code (which is basically the whole point of Elm).

Now, all that being said, i'm not familiar enough with Elm to know if he's actually right or if there is a better way to do what he wants. But that is what I think the crux of his point is.

Ah, I see. Thanks for the explanation.

There are two threads about Elm on reddit's /r/programming right now. This is one of them, the other one ís about "Elm is wrong" (http://reasonablypolymorphic.com/blog/elm-is-wrong)

Reddit: https://www.reddit.com/r/programming/comments/5bsanc/elm_is_...

I found it interesting because I have not myself looked into Elm yet but kept it in the back of my mind to do so some day, since thus far I only ever read extremely positive opinions.

People gotta stop fighting their tools.

The problems encountered in these two articles are similar to problems that used to plague me. I would want to get something in C++ that was like the way I thought it was done right in Modula-3. The C++ feature was almost but not quite enough like M3 to make it work. I would get frustrated and say that everyone was a moron and programming is doomed. Sometimes I'd even drop the project entirely. This sort of thinking made it impossible for me to use MFC.

At some point I just realized I needed to get along. Working in Java (1.1), I started doing things with heavy boilerplate if it was required. You simply can't use a tool against how it was designed. I guess Elm doesn't have the word "opinionated" in its documentation enough, because that's what saved Rails. People would be like "DB2 doesn't do those big column names" and Rails people would be like, "Yup. We're opinionated about databases too." Nevertheless, if you don't fight the basics of the system, you get stuff done quickly.

I personally welcome negative opinions on Elm. While that article is mostly complaining that it's not Haskell, the fact that Elm only gets praise somehow puts me off.

I get how the author feels, but, apart from the fact Elm does not _claim_ to be ready for production use, this seems to come down to "functional languages are different from non-functional languages and I can't wrap my head around it in a couple of hours". E.g.

> a language that seems to inherit not just nice types and largely ok or even nice syntax from Haskell but also a stubborn approach to prefer (imagined) purity over practicality [...]

Why "imagined"? I do think that prohibiting side-effects is a good thing. I'll be the first to admit that I'm not actually good at writing pure code that's easy to grasp, but I imagine that to be a lack of practice, just like w/ OOP.

Bottom line is that I don't get why people pick up a functional language, which also happens to be in development, and then bash it for being a functional language and not yet ready for production. This seems like pointless bashing.

The complaints don't see to be about a functional language so much, but that you need to cut+paste and have lots of boiler plate.

You'd have the same problem in C, without pre-processor abuse (which is how I've fixed this in the past), but I'd not want that problem in a modern language.

Haskell has support for reflection, using packages like Data.Data[1] (which is part of base). The type theory behind it is fairly advanced; I've never successfully used gfold on my own, but it's the kind of thing where one would put a library routine in that could generate a select box from a type that derives Data and Typeable.

I bring this up to suggest that this isn't necessarily a core limitation of ML languages like Elm, just a feature that Elm could borrow from Haskell in the future to address this problem without sacrificing typing.

[1]: https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-D...

To the author: try out Scala.js[1] if you want powerful FP features and a great type system in the browser.

[1]: https://www.scala-js.org

A really nice thing about it is that you have the same top-notch IDE support as JVM-based Scala. That is what I find lacking when I want to try other compile-to-JS functional languages (with the exception of ClojureScript, which also has excellent IDE support).

Good point. I also found it absolutely magical when my Scala code written for the JVM compiled flawlessly using Scala.js.

Select example: https://gist.github.com/jinjor/bf37f10713028a1d9ef547724bcf5... Different Select Example: https://gist.github.com/manuscrypt/0dac581c25101526e2398228c...

Searching elm-discuss for <2 minutes.

The first example has the duplication that the blogpost complains about. The second one doesn't use tagged union types, so you don't get the case statement coverage checking that the author wanted (if you want the tagged union, the task of converting it into a list is pushed to the client of the library).

The problem is that the case statement coverage isn't a valid assumption in this case and using a union type is putting a square peg in a round hole.

HTML selects do allow duplicate names. He'd be better off just using a dictionary or list of name/value pairs and forgoing the union type altogether.

https://gist.github.com/chalmagean/c0b2f874bcff728b3db047aa2...

The author should try React and Redux. I've used many different UI frameworks/libs over the years: jQuery, Backbone, Angular, etc

I don't claim that React is the end all be all, it has a few trade-offs.

The first thing that isn't ideal is that it has a fair amount of boiler plate that's kind of unavoidable: reducers, actions, mapStateToProps, mapDispatchToProps

Also, the size of React and React-Dom (which is required) is quite large, although with minification and gzipping it's not as bad.

It also has a pretty big learning curve when you're first getting started.

On the plus side, it's very performant, concerns are separated well and it scales well. Once you're up and running and familiar with how things work, it's a pretty nice environment to develop in.

I've replaced lodash with ramda and that has been a pleasure.

Also, JSX is really nice. It's nice to use a full-blown markup language that's pretty much HTML, and to use JavaScript. That beats trying to fit every abstraction you need into a template engine.

I haven't done much experience with Elm, it seems nice, especially since I've started to program more functionally. I would consider using it on my next project.

If you dig immutable, auto-curried, data-last methods there's also lodash/fp modules –

https://github.com/lodash/lodash/wiki/FP-Guide

I am currently using Elm on an app and had no difficulties creating a select list like the one in the article.

I use Elm more as a way to write components on a server rendered page and it works for great this way! The eco-system is too small to think about creating complex SPA at this point but I really like the language and hope it matures well.

So how did you approach it?

A title that will get to the front page, basically click bait.

Crap article with not much thought behind it. sigh...

Author is apparently unaware that elm doesn't claim to be ready for prime time yet. Batteries definitely not included.

I personally find elm pretty compelling, and look forward to using it in some distant future when I touch web frontends.

>Author is apparently unaware that elm doesn't claim to be ready for prime time yet.

You seem apparently unaware that nowhere in elm's website it says that, and in fact it totally implies the opposite "A delightful language for reliable webapps".

It also has links to companies using it live and advice on how to migrate codebases.

Definitely sounds like the Elm team think it's ready for prime time.

The version number is 0.17. This means breaking and backwards incompatible changes between releases.

If only we could depend on version numbering schemes to actually have meaning.

My understanding is that Elm enforces Semantic Versioning, which would imply that unless I'm not recalling the particulars correctly

I thought you needed 3 things for a semantic version.

Major.Minor.Patch

So 0.1.7 would be semantic, but 0.17 would not be.

0.17 === 0.17.0. The latest version of Elm is actually 0.17.3

Am I the only one that though this was about the mail reader? What on earth is Elm?

Hmm. Select boxes seem kind of important.

Reply on news.ycombinator.com