Elm is Wrong • Hacker News Board

Re: Elm is Wrong

#211

Post by elbear » Thu, Nov 10, 2016, 3:41 PM UTC

logicallee wrote: post #127

elbear wrote: post #122

Earlier quoted context omitted.

Actually, that's the thing: Elm is designed for people who don't know Haskell. It's designed for JavaScript developers who are attracted by the "no runtime exceptions" claim. If you're coming from Haskell, you'll see Elm as a dumbed down, stripped version of Haskell, which will trigger in you the feelings it triggered in the OP.

Thanks. The chances we'll hear the perspective from a javascript dev with no haskell exp are slim though.

Join the Slack elm channel. You'll find them there.

Re: Elm is Wrong

#212

Post by Skinney » Thu, Nov 10, 2016, 4:19 PM UTC

caconym_ wrote: post #201

Skinney wrote: post #106

Earlier quoted context omitted.

Keep in mind that Evan works at a company that has 55k lines of Elm in production. Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now.

> Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now. Need is not the word I'd use. IIRC (from some Github issue I saw recently) Evan has said they are adopting a "wait and see approach" on typeclasses and/or other type system extensions. Given how young Elm is, I see this as a careful and considered approach to its continued develop…

Read the two last words of that sentence. I agree with you, I use Elm every day.

Re: Elm is Wrong

#213

Post by JBiserkov » Thu, Nov 10, 2016, 4:45 PM UTC

sametmax wrote: post #22

I'm not particularly interested in Elm, but basically this post is about one problem in the language. One. This doesn't make the language a pile of garbage as the author seems to let you think. I'm a Python programmer. I fully expect dict keys to be able to be arbitrary objects. But after coding a lot in JS, I realized I could live without it. It's nice, but it's not a show stopper if I don't have it. Same goes here.…

>There is no "map" function, but there are "List.map", "Dict.map", "Array.map" among others, and none of them are related to one another. This is not only annoying, but also breaks the abstract data-type guarantee: our call-sites are now tightly coupled to our implementation details. If I decide to change from a "List a" to an "Array a" for efficiency reasons, my whole codebase needs to know about it.

I can accept this in old languages. I can accept this in embedded languages. I cannot accept this in a language that is supposed to be about programmer productivity.

Basically this patient has one bullet hole in their heart. One. This doesn't make the patient dead as the author seems to let you think.

Re: Elm is Wrong

#214

Post by caconym_ » Thu, Nov 10, 2016, 5:13 PM UTC

Skinney wrote: post #212

caconym_ wrote: post #201

Earlier quoted context omitted.

> Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now. Need is not the word I'd use. IIRC (from some Github issue I saw recently) Evan has said they are adopting a "wait and see approach" on typeclasses and/or other type system extensions. Given how young Elm is, I see this as a careful and considered approach to its continued develop…

Read the two last words of that sentence. I agree with you, I use Elm every day.

I'm not sure what point you think I'm trying to make. A language can be better than its competitors/alternatives while still having room to improve.

I'm not saying "Elm is bad", or whatever.

Re: Elm is Wrong

#215

Post by Skinney » Thu, Nov 10, 2016, 6:55 PM UTC

caconym_ wrote: post #214

Skinney wrote: post #212

Earlier quoted context omitted.

Read the two last words of that sentence. I agree with you, I use Elm every day.

I'm not sure what point you think I'm trying to make. A language can be better than its competitors/alternatives while still having room to improve. I'm not saying "Elm is bad", or whatever.

Here's how I view our conversation thus far. I said "Evan doesn't feel the need to add typeclasses right now." You said "He is thinking about maybe adding it in the future." Then I said "I know, that's why I ended my sentence with -- right now --" and then you said "what are you talking about? I'm not saying Elm is bad!"

> A language can be better than its competitors/alternatives while still having room to improve.

I agree with you is all I'm saying. I never tried to imply otherwise. All I said is that there is no reason to think that Elm has to have typeclasses right now to be useful, as some others seem to suggest.

Re: Elm is Wrong

#216

Post by 3rwww1 » Tue, Nov 15, 2016, 1:39 PM UTC

mikekchar wrote: post #41

bbcbasic wrote: post #26

Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Sandy should take into account that Elm is created by one person pretty much (‎Evan Czaplicki) who created it in his PhD thesis and has been maintaining it since. So it's someones baby still, and they might be offended. It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky lan…

Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…

I agree with most of this, but I beg to differ with the last bit :

> [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole

We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code.

Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language.

However the real question here is not "is this language worthless because of that", but rather "can I overcome that limitation for my specific use case ?".

My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.

Re: Elm is Wrong

#217

Post by 3rwww1 » Tue, Nov 15, 2016, 1:39 PM UTC

mikekchar wrote: post #41

bbcbasic wrote: post #26

Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Sandy should take into account that Elm is created by one person pretty much (‎Evan Czaplicki) who created it in his PhD thesis and has been maintaining it since. So it's someones baby still, and they might be offended. It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky lan…

Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…

I agree with most of this, but I beg to differ with the last bit :

> [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole

We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code.

Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language.

However the real question here is not "is this language worthless because of this or that", but rather "can I overcome that limitation for my specific use case ?".

My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.

Re: Elm is Wrong

#218

Post by hathawsh » Thu, Nov 17, 2016, 9:00 PM UTC

phaedrus wrote: post #209

hathawsh wrote: post #153

Earlier quoted context omitted.

This is where Pythonistas rely on the idea that "we're all consenting adults here". It's very useful to let objects assert that they have an arbitrary, immutable hash value. I've used that ability in Python and it solved problems that would have been very challenging otherwise. Of course, that ability also leads to undocumented behavior if hash values change. Python coders expect dicts to behave in undocumented ways…

I'm genuinely curious how/why this is a problem for Python yet I've never heard of it being a problem for C#. In C# you can override Object.GetHashCode(), and there's no way in C# to even express the constraint/desire "the result of GetHashCode doesn't change (especially after insertion into a container)". Yet I've never heard of anyone in C# having a problem using mutable objects in sets or dictionaries?

To be honest, most Python coders probably never get deep enough in the language to start overriding hash values, and those who do probably understand the implications before they get that deep.