HN Theater @HNTheaterMonth

Elm creator Evan Czaplicki can, in an elegant and pedagogical way that would feel familiar to at least developers coming from JS:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

Haskell/FP/Math purists would probably balk at the oversimplification. But introducing intimidating concepts by way of such oversimplification (without entirely missing the target) is precisely the point! Beginners just need a very rough and coarse grained overview, so they are able to gain some basic familiarity with the concept. That gives them some already-familiar conceptual knobs to hang further details on, reduces fear, and inspires curiosity to investigate further.

Not necessarily. See this short clip where Elm creator Evan Czaplicki illustrates my point by way of the Monad:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

Thank you for the feedback. Maybe this short video clip can help.

Elm creator Evan Czaplicki illustrates it by way of the Monad:

https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39.

I've also updated that section of the article, to provide some justification for my wish there, including a few more illustrative backing sources.

A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard.

[1] https://www.youtube.com/watch?v=oYk8CKH7OhE

> It would appear that you misunderstood what I said.

Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailable, then you use a lower-level alternative). If that was what you meant, then I agree...and I don't think I needed to have read SICP to know that. ;)

> This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them.

I would describe this particular issue as having been "patiently explored to death." Here are several links demonstrating this:

[0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_...

[1] https://www.youtube.com/watch?v=oYk8CKH7OhE

[2] https://github.com/elm-lang/elm-compiler/issues/1039

[3] http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorph...

> Elm not facilitating the use of sufficient level of abstractions [...] I had never got the impression that the Elm community was going to fix those problems any time soon. [...] Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that.

This quote characterizes Elm as not having "sufficient level of abstractions" and that these are "problems" that are not being "fixed." My reference to the "abstraction wall" is also a direct quote from a previous comment. [4]

All of these quotes frame personal preference as objective fact.

It's like saying Java is "broken" because it does not support manual memory management, which no one seems "interested in fixing" by adding `malloc()` and `free()` to the language. Plenty of people would (rightly!) be upset if Java introduced `malloc()` and `free()`, thus breaking the invariant that everything is garbage collected.

Likewise, there are many happy Elm users, myself included, who think Elm would be substantially worse if it moved toward the abstractions that PureScript embraces. The fact that Elm doesn't is a benefit from our perspective, even if it's a drawback from yours.

Neither of us have "wrong" preferences. There's no universally correct answer here. We can both go about building Web applications in our languages of choice.

This distinction may not matter to you, but to someone wondering whether Elm is worth looking into, there's a big difference between "I am inevitably going to hit a wall" (which is not true) and "not everyone agrees with Elm's design decisions" (which is of course true).

[4] https://news.ycombinator.com/item?id=14877406

⬐ sridca

The level of abstraction a programming language provides is a verifiable fact. At what minimum level a programmer is comfortable working with is a personal preference. If Elm’s type system is not sufficient to provide that level of abstraction it is certainly a problem to me that has not been resolved in the language. For all we know, other people may have different preferences; some may be content working with vanilla JavaScript and some even with assembly instructions. I don’t think anyone denies this, and you seem to be defending something that was never challenged.

As for Elm’s approach to dealing with discussions of this nature, out of the four links you had provided the last three were unilateral messages (the Github issue in particular is locked to collaborators with only a message from Evan). As for the Google Group thread it perfectly demonstrates the feeling I have had with the Elm community. Paul Chiusano (who had the same problem as me) in that thread finally got frustrated due to lack of patience and exploration among the participants; it is quite odd you would use this as a demonstration of the Elm community patiently exploring something. His exact words:

  What I find frustrating about this is that when 
  conversations get ugly, the actual issues are not 
  given sufficient attention and people just end up 
  responding to the general unpleasantness and the 
  labels being tossed around. I still feel like we 
  have not really gotten to the bottom of things, 
  but I don't have much hope that this thread will 
  get us there and would rather just drop it for 
  now like Joey suggests.

⬐ rtfeldman

  At what minimum level a programmer is
  comfortable working with is a personal
  preference. [...] I don’t think anyone denies 
  this, and you seem to be defending something
  that was never challenged.

Since it sounds like we're in agreement on this being a matter of personal preference, I'm happy to move on. :)

  Paul Chiusano (who had the same problem as me)
  in that thread finally got frustrated
  due to lack of patience and exploration among
  the participants; it is quite odd you would
  use this as a demonstration of the Elm
  community patiently exploring something.

Paul wasn't frustrated due to a "lack of patience and exploration among the participants," he was frustrated that "let's be patient and explore this further" was the outcome of the discussion--instead of the outcome he wanted, which was getting his feature requests being prioritized higher. I'll break it down.

First, here is a quote from Evan's first response in that thread: [0]

  Since very very early on, type classes have been
  requested by Haskell programmers. My opinion is
  that these features create serious accessibility
  problems in Haskell, even for people such as
  myself who came to Haskell already knowing
  Scheme, Standard ML, and OCaml. I was three
  years in to Haskell before Monad Transformers
  were clear to me.
  
  So I have always looked at these things not just
  as features to be implemented, but unsolved
  design problems. How do we present these ideas
  in a way that is super simple?
  How do we grow our community in a smart way?
  
  A question to think about for type classes is,
  what is the best way to reuse variable
  names? Type classes, implicit arguments, and
  module functors all answer this question,
  but each comes with some unfortunate tradeoffs.
  My view here is that there is no need
  to rush. When our community collectively needs
  this kind of feature, we will be in
  a much better position to evaluate the
  trade-offs between these approaches for the
  problems we are facing in practice.

Some things to note:

1) He asks specific questions to invite exploration. "What is the best way to reuse variable names? How do we present these ideas in a way that is super simple? How do we grow our community in a smart way?"

2) He explicitly calls for being patient with that exploration: "My view here is that there is no need to rush."

Following this are a bunch of posts which include a mix of discussion about these questions and a debate about prioritization.

Paul then posted: [1]

  This is turning into an interesting discussion
  and I'm very tempted to wade in,
  but honestly, I'd just like an answer to my
  earlier question about timeline for
  the non-controversial features.

He's being incredibly clear about this: he found the exploration interesting, but was more interested in knowing Evan's timeline than participating. Fair enough.

At this point we can rule out the conclusion that Paul "finally got frustrated due to lack of patience and exploration among the participants" - because he stated, in no uncertain terms, that despite being tempted by an interesting discussion, that's not what he wants. What he wants is an answer about the prioritization of his feature request.

Evan responded, and Paul responded back: [2]

  Okay, thanks for the reply. And I appreciate
  all the hard work you are putting into Elm!
  [ ... ] Here's something to consider when
  prioritizing work [ ... ] Features like HKP +
  rank-N types / typeclasses are like an
  investment in the whole community, and they
  can have huge leverage.

So he's not interested in participating in the discussion, or in directly answering the questions Evan posed at the start of the thread, but he still wants Evan to accept his feature request. I get that, but I'm not sure how the person who is essentially saying "I do not want to participate in a patient exploration with the community, I think these features should be added as soon as possible" can be held up as supporting evidence for the notion that the Elm community is closed to patient exploration.

Later, about 50 posts deep in this thread, an Elm community member named Sean finally got frustrated with how someone else named Jonathan was advocating for his (and Paul's) point. Sean quoted Jonathan's comment that "I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas" and responded by saying "And this is exactly the sort of condescending stuff that puts people off the Haskell community. As soon as someone doesn’t agree with you, you question their ability. Lovely." [3] Jonathan responded "So I think we have our answer-- no, you don't even understand what you are rejecting. Brilliant."

This obviously heated exchange was what led Paul to write what you quoted, which I'll re-quote with additional context of Paul's comment: [4]

  Jonathan, I share some of your frustrations
  but I think you should be much more careful
  in how you say things. [ ... ] Sean, whether
  or not you think your characterizations of
  Jonathan are accurate, I think some of your
  comments were unhelpful and uncharitable
  toward Jonathan.
  
  [ ... ]
  
  What I find frustrating about this is that
  when conversations get ugly, the actual
  issues are not given sufficient attention
  and people just end up responding to the
  general unpleasantness and the labels
  being tossed around.

So he's frustrated that this heated exchange got in the way. The rest of what you quoted was:

  I still feel like we have not really gotten
  to the bottom of things, but I don't have
  much hope that this thread will get us there
  and would rather just drop it for now like 
  Joey suggests.

As Paul made extremely clear in the quote from earlier, what he's talking about here is that he wants Evan to accept his feature request. He's not saying he felt there was insufficient exploration; in fact, he thought that exploration was "an interesting discussion and I'm very tempted to wade in" - his objection is that the discussion's outcome - "be patient; this is an unsolved design problem and we need to gather more real-world data points before we can solve it" - was not the outcome he wanted.

To recap:

1) Evan calls for patient exploration

2) Some patient exploration happens

3) Paul comments that the exploration has been interesting, but it's not what he wants. Really what he wants is a timeline for when the features will be prioritized.

4) Much later in the thread, two commenters get upset at one another.

5) Paul expresses frustration that their getting upset is distracting the thread from what he wants, which is to get his feature request accepted.

Hopefully this clears things up. :)

[0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_...

[1] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvw...

[2] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9...

[3] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-o...

[4] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG...

⬐ hellofunk

Wow, now that's what I call a decompilation.

Lets be mainstream by Evan Czaplicky

Designer of Elm language talks about principles he used to create language as approachable as JavaScript but as type-safe as haskell.

https://www.youtube.com/watch?v=oYk8CKH7OhE

I like how mpj explains it. Monad - FunFunFunction #21 https://www.youtube.com/watch?v=9QveBbn7t_c

Furthermore, the creator of Elm has a fun explanation too. Evan Czaplicki - Let's be mainstream! User focused design in Elm - Curry On https://youtu.be/oYk8CKH7OhE?t=1454

More serious computer scientist explains monads in the following. Erik Meijer: Functional Programming https://www.youtube.com/watch?v=z0N1aZ6SnBk&feature=youtu.be... and here too https://www.infoq.com/interviews/meijer-monads

> Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential.

I'd recommend watching this talk: [0]. Evan talks a lot about the decisions that went into the language, such as not having type classes or other advanced features. He makes a strong case for Elm not as a language-to-rule-them-all, but as a tool for the average programmer, who is more interested in building things than in learning about theory. The myriad language features in Haskell, OCaml, etc. are wonderful to those who understand them, but have not proven to be particularly effective at attracting those who aren't already interested in the languages. In that talk, he really made a strong case as to why Elm is valuable and relevant, even for someone such as myself, a functional programming nerd who loves learning about type theory, abstract algebra, and similar things.

Also, I really don't think it's fair to say "The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years)." OCaml has been around for almost 20 years now, and F# for more than 10. Both have the backing of very large development teams.

[0]: https://www.youtube.com/watch?v=oYk8CKH7OhE

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.

⬐ PeCaN

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

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

I'm pretty keen to play with Elm, but it gives me some pause that an app like this (or the demo at https://github.com/evancz/start-app) results in... 11k lines of Javascript. Nevertheless, these talks got me bulled up on Elm: https://www.youtube.com/watch?v=FV0DXNB94NE (Richard Feldman, collegially, on React -> Elm)</a> / https://www.youtube.com/watch?v=oYk8CKH7OhE (Evan Czaplicki on the motivation for Elm)

⬐ michaelsbradley

That's because the Elm compiler doesn't yet do much in the way of "dead code elimination" (DCE).

However, that will change in a future release of Elm, once Joey Eremondi's work has been fully integrated. My understanding is that integration is not slated for the 0.16 release (imminent) but will likely be part of the 0.17 release.

See: https://groups.google.com/forum/#!searchin/elm-dev/dead$20co...

⬐ hellofunk

Are they planning to leverage the Google Closure compiler the way Clojurescript does? Un-optimized Clojurescript is also huge until it runs through Closure compilation.

⬐ hellofunk

I should have read that thread first; it appears the answer to my question is "yes".

⬐ michaelsbradley

No, I believe the DCE implementation (still in the works) is specific to the Elm compiler, as opposed to an implementation which organizes the source in such a way as to leverage Google's Closure compiler.

Yeah the Haskell part is mostly tongue and cheek :P I wouldn't use it for any old project but I could see how the benefits of Haskell could outweigh its difficulties in some scenarios. Personally, I like functional programming, but I'm not sure it's suitable for the masses (perhaps some day? https://www.youtube.com/watch?v=oYk8CKH7OhE).