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

Elm is Wrong

reasonablypolymorphic.com

Post reply on HN
Print view View original

161–170 of 218 posts

Re: Elm is Wrong

#161

Post by [deleted] »

Noseshine wrote: post #155
gshulegaard wrote: post #146

Earlier quoted context omitted.

This fundamentally reduces the usefulness of hash representations though. Instead of thinking of dict keys, think sets. It's also worth pointing out that user-defined objects operate the way you seem to desire (e.g. default to using the id() property of the object to derive the hash). So in my mind, this strikes the perfect balance? StdLib types that are immutable bake in more comparative hash properties while making…

> This fundamentally reduces the usefulness of hash representations though. If you want something immutable just put something immutable in? > Instead of thinking of dict keys, think sets. It's the same that I already wrote for sets, and also the same I just wrote: If you want something immutable just put something immutable in. By the way, I'm not talking about any particular implementation.

[deleted]

Re: Elm is Wrong

#162

Post by shiro »

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

Not all problems are equal. Most problems can be compensated in some way or another, using abstractions. Problems that limits abstraction are grave, for it puts a glass ceiling that can't be got around.

A language designer may limit the power of abstraction intentionally; maybe the abstraction taxes performance too much; or maybe too much power scares the target users. That's a plausible choice, but that also turns some users away.

Re: Elm is Wrong

#163

Post by wyager »

A few months ago, I spent a few evenings trying both Elm and Purescript. Elm was easier to get started with, but felt much more cramped and difficult to scale up to large programs. Purescript was more complicated to figure out (I had to read about F-algebras to understand Halogen's UI query algebras), but it's substantially more powerful and flexible. It's very similar to Haskell, with the addition of built-in record types.

Re: Elm is Wrong

#164

Post by VyseofArcadia »

> Ord a is a witness that type a is well-ordered, which is to say that for any two as, one is definitely less than or equal to another.

What the author described here is a linear order, not a well ordering, despite linking to the correct Wikipedia page.

Re: Elm is Wrong

#165

Post by zzguy »

mfukar wrote: post #134
elbear wrote: post #117

Earlier quoted context omitted.

Here's how I see his point. He came to Elm expecting a Haskell for the web. Elm has the completely opposite philosophy of keeping things simple, even if it means extra boilerplate. I can understand OP's frustration, but if he watched a few of Evan's talks (like this one https://www.youtube.com/watch?v=DSjbTC-hvqQ ), he would realise his expectations about Elm are wrong. Also, he forgot that Elm (just like any other o…

> Also, he forgot that Elm (just like any other open source project) doesn't owe him anything. That's why many people take an issue with his tone. We can't take issue with his tone by appropriating information about Elm's direction in an ex post facto manner. The guy - whatever guy - is a newcomer to Elm, picks it up, see an obvious deficiency, asks (quite politely, I might add) about a feature addition, gets a dismi…

Is Elm open source? If so, couldn't the author implement the feature themselves? If the maintainer doesn't want it, then idk, fuck off? Nobody said he had to use it. When did open source turn into "Do whatever random people tell you to do, for free"? Talk about entitlement....

Re: Elm is Wrong

#166

Post by charlieflowers »

charlieflowers wrote: post #149

What is the thought process behind him using the term "witness"? I can tell it is backed by an interesting perspective and I'd like to learn more about that perspective. At one point, he said this witness "proved" something ... so is this coming from "propositions as types"?

Ah, I found it: https://wiki.haskell.org/Type_witness

In my own words, a "type witness" is a Haskell idiom (maybe broader?) that allows you to perform dynamic casts.

Here's the first example from that link:

A simple witness type might be defined over the Int, Bool and Char types like so:

data Witness a where IntWitness :: Witness Int BoolWitness :: Witness Bool CharWitness :: Witness Char

dynamicCast IntWitness IntWitness pa = Just pa

dynamicCast BoolWitness BoolWitness pa = Just pa

dynamicCast CharWitness CharWitness pa = Just pa

dynamicCast _ _ _ = Nothing

Re: Elm is Wrong

#167

Post by orf »

dkersten wrote: post #120
sametmax wrote: post #75

Earlier quoted context omitted.

Come on, how many time in your entire life did you need this ? For set, it's a bit more annoying. But for dicts. twice in 10 years maybe ?

After a few years of Clojure(Script), where immutability means you can use almost anything as keys, I have found many cases where my python code would have been simpler and easier if I could use arbitrary objects (and therefore data structures) as keys. I mean, its not a huge deal, but it adds up.

> I have found many cases where my python code would have been simpler and easier if I could use arbitrary objects as keys

You can use pretty much anything as a dictionary key

Re: Elm is Wrong

#168

Post by Noseshine »

gshulegaard wrote: post #160
Noseshine wrote: post #155

Earlier quoted context omitted.

> This fundamentally reduces the usefulness of hash representations though. If you want something immutable just put something immutable in? > Instead of thinking of dict keys, think sets. It's the same that I already wrote for sets, and also the same I just wrote: If you want something immutable just put something immutable in. By the way, I'm not talking about any particular implementation.

I think there is a disconnect here, I showed you how you could place a mutable object as a dict key in Python. One which uses the object itself (id() property) for the hash. > If you want something immutable just put something immutable in. My point is what do you expect if you do this: >>> x = (1, 2) >>> y = (1, 2) >>> set([x, y]) I would argue that you would expect: >>> set([(1,2)]) Since x is equal to y. But if yo…

We were originally talking about a dictionary key, and the purpose of an object as key in a dictionary is AFAICS to associate a value with that concrete object. Whenever I use those structures I have to solve an engineering problem, not a math problem. I would claim that's the majority of use cases, a claim that seems to be supported by how it is commonly implemented (see Java below and Javascript for two of the most common languages).

Anyway, it's configurable for example in Java (http://stackoverflow.com/questions/9440380/using-an-instance...) - default is to use the reference but you can override object methods to change that. Similarly for C#(http://stackoverflow.com/questions/634826/using-an-object-as... or http://stackoverflow.com/questions/8952003/how-does-hashset-...).

Re: Elm is Wrong

#169

Post by leshow »

rtfeldman wrote: post #158
leshow wrote: post #131

Earlier quoted context omitted.

This is unconvincing to me. Just because Evan and his friends are happy to write boilerplate and copy-paste the same stuff over and over doesn't mean it's the right thing to do.

Hi! I work at NoRedInk, the aforementioned company with 55,000 lines of Elm in production. We don't "copy-paste the same stuff over and over." That would suck. Why would we be excited about a language that made us do that? Our Elm code is about as DRY as our JS code was before, except the Elm code is way easier to maintain.

How do you compose update functions without writing the boilerplate let ... in for every Msg? How do you stop your main update function from growing endlessly as you add new Msgs?

You need only look in the standard library for examples of boilerplate and not-DRY code. The map function is implemented separately for Lists, Arrays, etc.

I really want to love Elm. But the more I wrote it the more I realised that the only answer to those questions is that you solve them with boilerplate and brute force. When I ask the community what the solution is I'm largely ignored or told it's not a "real" problem.

Re: Elm is Wrong

#170

Post by leshow »

Skinney wrote: post #152
leshow wrote: post #131

Earlier quoted context omitted.

This is unconvincing to me. Just because Evan and his friends are happy to write boilerplate and copy-paste the same stuff over and over doesn't mean it's the right thing to do.

What is "the right thing to do"? Depends doesn't it? Just because other languages have support for something like typeclasses, doesn't mean that it's the right thing for Elm to have. The fact that NoRedInk are perfectly happy without typeclasses (or something similar) could be an indication that it really isn't as important that people would make you believe. After all, there are several languages out there with supp…

Perhaps not, but it seemed like an issue even in small sized apps that I wrote.

I think that Evan and Richard are personally invested in the language and can't see it's shortcomings.

Post reply on HN