
A small dive into, and rejection of, Elm - adamlett
https://medium.com/@boxed/a-small-dive-into-and-rejection-of-elm-8217fd5da235#.kkt82zm3y
======
wfleming
> 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.

~~~
leshow
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

~~~
eskimobloood
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

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

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

------
escherize
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...](http://escherize.com/cljsfiddle/#gist=eea10854f99ef124f8dc152af1ff306d)

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

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

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

~~~
escherize
Thanks guys I'll look into it.

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

[http://gitlab.com/escherize/cljsfiddle](http://gitlab.com/escherize/cljsfiddle)

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

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

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

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

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

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

~~~
dkersten
Ah, I see. Thanks for the explanation.

------
Noseshine
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](http://reasonablypolymorphic.com/blog/elm-is-wrong))

Reddit:
[https://www.reddit.com/r/programming/comments/5bsanc/elm_is_...](https://www.reddit.com/r/programming/comments/5bsanc/elm_is_wrong_reasonably_polymorphic/)

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.

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

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

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

------
fusiongyro
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...](https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-
Data.html)

------
Cyph0n
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](https://www.scala-js.org)

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

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

------
zalmoxes
Select example:
[https://gist.github.com/jinjor/bf37f10713028a1d9ef547724bcf5...](https://gist.github.com/jinjor/bf37f10713028a1d9ef547724bcf5532)
Different Select Example:
[https://gist.github.com/manuscrypt/0dac581c25101526e2398228c...](https://gist.github.com/manuscrypt/0dac581c25101526e2398228c241b61c)

Searching elm-discuss for <2 minutes.

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

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

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

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

[https://github.com/lodash/lodash/wiki/FP-
Guide](https://github.com/lodash/lodash/wiki/FP-Guide)

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

~~~
shoover
So how did you approach it?

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

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

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

~~~
coldtea
> _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".

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

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

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

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

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

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

------
draw_down
Hmm. Select boxes seem kind of important.

