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

171–180 of 218 posts

Re: Elm is Wrong

#171

Post by leshow »

Skinney wrote: post #148
leshow wrote: post #130

Earlier quoted context omitted.

You think Evan is just waiting around for the right abstraction to dawn on him? It's been years with not one bit of code written in the direction of adding a mechanism for abstraction in the language (whether that be typeclasses or something else)

"Code is the easy part" First you need to figure out what exactly the Elm community wants and needs. Once you have a pretty good idea of that, you can start prototyping things. Elm is still young, and the most pressing concerns for using Elm in production is not the lack of interfaces/protocols/typeclasses, but stuff like debuggers, which is what Evan is working on. I'm sure we'll see some tool for ad-hoc polymorphis…

Blind faith might be enough for you but I don't buy it. The original issue was 3 years ago.

Re: Elm is Wrong

#172

Post by walterstucco »

leshow wrote: post #125
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…

> He came to Elm expecting a Haskell for the web No, I don't think that's true. He came to Elm hoping there would be some useful ways to create abstractions in the language (that doesn't necessarily mean there has to be typeclasses. in fact, the whole article his him pursuing an alternate method of abstraction), and besides creating a function there really is none in Elm. You must resign yourself to write the same bo…

and who cares? fork the project and add the feature yourself. when I buy banana yogurts at the supermarket, I don't write to the yogurt company asking to change the flavour if I don't like it. I just buy a different brand of yogurt. Elm is even free as in free beer and free speech!

Re: Elm is Wrong

#173

Post by gshulegaard »

Noseshine wrote: post #168
gshulegaard wrote: post #160

Earlier quoted context omitted.

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…

Ah I see the disconnect, I think the underlying piece I glossed over was the fact that dict objects and set objects rely on the same hashable property of objects. This is in part due to the "one way and only one way" rule of thumb of Python's language design.

For me, talking about how dicts handle hashing keys and sets hashing members are equivalent in the context of the Python language.

Given that context I was saying changing the "hashable" nature of default objects would be counter-intuitive as the new behavior would be in contrast to the expected behavior of sets and/or immutable equal types in dict keys.

Re: Elm is Wrong

#174

Post by mfukar »

zzguy wrote: post #165
mfukar wrote: post #134

Earlier quoted context omitted.

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

> Is Elm open source? If so, couldn't the author implement the feature themselves?

Yeah!

Just create and maintain your own damn dialect of a language!

It's OPEN SOURCE, that means you automatically know and are an expert in anything it involves!

It's 2016, we can stop with that meme now.

Re: Elm is Wrong

#175

Post by maxiepoo »

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"?

The use of the term "witness" here comes from constructive logic, where proofs of propositions have actual computational content. There "witness" means the same thing as "proof" but is more evocative that the proof is data that can actually be manipulated.

You might like this article if you're interested to learn more: http://jozefg.bitbucket.org/posts/2015-01-09-constructivism....

Re: Elm is Wrong

#176

Post by leshow »

hkgumbs wrote: post #147

If anyone using elm runs into the same dictionary-comparable issue, please understand that it's a solved problem: http://package.elm-lang.org/packages/robertjlooby/elm-generi...

The problem is the compiler magic for what is 'comparable' is unavailable. This doesn't solve that problem. It creates an entirely new data structure that is mostly a copy paste of the stdlib Dict.

Re: Elm is Wrong

#177

Post by michaelmrose »

walterstucco wrote: post #172
leshow wrote: post #125

Earlier quoted context omitted.

> He came to Elm expecting a Haskell for the web No, I don't think that's true. He came to Elm hoping there would be some useful ways to create abstractions in the language (that doesn't necessarily mean there has to be typeclasses. in fact, the whole article his him pursuing an alternate method of abstraction), and besides creating a function there really is none in Elm. You must resign yourself to write the same bo…

and who cares? fork the project and add the feature yourself. when I buy banana yogurts at the supermarket, I don't write to the yogurt company asking to change the flavour if I don't like it. I just buy a different brand of yogurt. Elm is even free as in free beer and free speech!

There is a limited interaction between yogurt buyers and yogurt makers that solely consists of buying or not buying stuff. There is more interaction between programming language creators and programmers and indeed between programmers about their tools.

Analysis in depth is a useful thing for not only the creator who is likely to already understand the trade offs he has made but for other current and potential users of the language.

Re: Elm is Wrong

#178

Post by matt4077 »

mfukar wrote: post #101
ungzd wrote: post #91

Earlier quoted context omitted.

BTW, why lots of people think it's very wrong and immoral to criticize inanimate pieces of technology in rude and offensive language? Political correctness?

Yes. Generally, tone policing in HN gets stronger with the passage of time. Many comments in here complain about the tone without even touching on the point.

> Many comments in here complain about the tone without even touching on the point.

Then we'll either have to change all those commentators, or the original author – since one of the arguments against faul language is that it distracts.

Re: Elm is Wrong

#179

Post by sjrd »

boubiyeah wrote: post #145
wereHamster wrote: post #143

Earlier quoted context omitted.

> Meanwhile [...] typescript, [...] is [...] more than typesafe enough language. For someone who hasn't worked with a statically typed language yet, perhaps. But someone who knows and works with Haskell would disagree here.

Depends. I also work with scala. Yet somehow I don't need monads, functors, applicatives, etc on the frontend. TS with the right strictness flag enabled, is a good, practical middle ground for now even though I hope a good compile-to-js/assembly will be useable soon (I still have yet to try bucklescript/reason for real)

Since you work with Scala ... have you tried Scala.js?

Re: Elm is Wrong

#180

Post by maxthegeek1 »

chriswarbo wrote: post #123

I do have some sympathy for the author's desire to have record extension (re-)added, as that looks like a pure win, from my outside perspective. Maybe there are concerns which insiders may be better able to spot, like losing some reasoning ability. As for typeclasses, I think Elm's stance is perfectly reasonable. Typeclasses aren't a pure win, they have downsides too: - They couple the term level to the type level by…

Record extension was removed because it allowed Evan to improve error messages, and because he found that Elm's power users didn't use the feature.
Post reply on HN