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

201–210 of 218 posts

Re: Elm is Wrong

#201

Post by caconym_ »

Skinney wrote: post #106
caconym_ wrote: post #10

It really seems like Elm should implement typeclasses. I don't know Elm, but I can't really imagine writing serious Haskell programs without them, and I've seen multiple Elm-related complaints today that were either directly lamenting their absence or lamenting difficulties that they would have solved, trivially.

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 development, rather than a statement that its creators consider it to be finished and complete as it is at this time.

I've jumped ship on things for far less than a "need", just because there was something better. I expect that a lot of people use Elm despite any perceived deficiencies because they think it's still better than the alternatives for their application(s).

Re: Elm is Wrong

#202

Post by lasfter »

adamlett wrote: post #107
lasfter wrote: post #102

Earlier quoted context omitted.

That doesn't seem like a useful exercise because political correctness does not always equate to behaving respectfully, even if there is overlap (i.e. most respectful behaviour is politically correct and vice versa). I could just as well suggest you mentally substitute the phrase helping the needy with kicking puppies whenever you encounter it.

political correctness does not always equate to behaving respectfully Could you provide an example of when it doesn't?

For example, mocking masculinity/men, white people, Conservative people, etc is all "politically correct". I would not call it respectful to call Trump voters deplorables or to belittle issues that men face, but it's certainly not politically incorrect.

Re: Elm is Wrong

#203

Post by ccapndave »

masklinn wrote: post #150
ccapndave wrote: post #48

Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever). I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I co…

> Yes, things could be better, and I'm sure they eventually will be. That's unlikely, it is not the direction Evan wants to take, and so far the language has gone the opposite direction on purpose and by design. > And hey, when these kinds of abstractions do arrive Which they probably won't. Realise that the Elm platform is written in Haskell, Evan knows about these features, he could have used them and he very speci…

I disagree - I think that firstly Evan wants to implement the right abstraction (which he doesn't think is traditional Haskell type classes), and secondly its simply not a priority.

Re: Elm is Wrong

#204

Post by riffraff »

b123400 wrote: post #61

I have some similar thoughts when trying out Elm. Every function that a language support/does not support shapes the ecosystem, and that is arguably as important as the language itself. With Elm, decision making is done by a small group of people and they can be quite opinionated. I started when 0.15 is out, amazed by how beautiful FRP can be, then it is gone now. I cannot add / remove fields from dictionary, I canno…

could you explain what you found better between the old FRP style and the new subscriptions style?

I am not an elm user, but I follow from time to time, and they seem substantially equivalent looking at the migration guide[0]

[0] https://github.com/elm-lang/elm-platform/blob/master/upgrade...

Re: Elm is Wrong

#205

Post by Moezalez »

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…

> PhD thesis It was his Bachelor thesis

Re: Elm is Wrong

#206

Post by dkersten »

orf wrote: post #167
dkersten wrote: post #120

Earlier quoted context omitted.

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

That's really not true[1]. You can only use hashable types, which excludes dicts, lists and sets.

For example (tested on both python 2.7 and 3.4):

    >>> {{'a': 1}: 2}
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unhashable type: 'dict'
    >>> {[1,2,3]: 4}
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unhashable type: 'list'
    >>> {{1,2,3}: 4}
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unhashable type: 'set'
Objects inheriting from object are hashable by default, but the hash is based on the objects instance such that each instance will return a unique value for that instance:

    >>> class A(object):
    ...     def __init__(self):
    ...         self.x = 1
    ...
    >>> a = A()
    >>> b = A()
    >>> d = {a: 1, b: 2}
    >>> a.x = 10
    >>> b.x = 10
    >>> d[a]
    1
    >>> d[b]
    2
While this makes sense for the instance stored in the dict (because mutability would otherwise mean that they key changes values), I don't think this is particularly useful. I rarely look up dicts by instance, but rather by value. That is, I would construct another object with the same attributes and look up by that.

You can, of course, implement your own __hash__ to make it work, but you have to do it manually for any object you want it and most third-party objects won't have implemented it so you'd have to monkey patch them.

Contrast that with Clojure, where all built-in data structures (maps, sets, lists, dicts etc) work as keys out of the box.

[1] I guess its true in the sense that you can implement __hash__ to make it work. But its not particularly easy or idiomatic.

Re: Elm is Wrong

#207

Post by adamlett »

lasfter wrote: post #202
adamlett wrote: post #107

Earlier quoted context omitted.

political correctness does not always equate to behaving respectfully Could you provide an example of when it doesn't?

For example, mocking masculinity/men, white people, Conservative people, etc is all "politically correct". I would not call it respectful to call Trump voters deplorables or to belittle issues that men face, but it's certainly not politically incorrect.

I think I see what you mean, but in my experience, this is not how most people understand or use that term. Wikipedia backs me up on this:

The term political correctness (…) in modern usage, is used to describe language, policies, or measures that are intended primarily not to offend or disadvantage any particular group of people in society.

Re: Elm is Wrong

#208

Post by phaedrus »

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

I agree; to me it says equally as much about the expectations of the author of the article. In C++ you can define operator On the other hand C++ is only just about to get its first version of Concepts. (Haskell programmers in this thread: imagine if you waited 10+ years to get typeclasses.)

My point being that most languages are going to be missing something you wish they had.

Re: Elm is Wrong

#209

Post by phaedrus »

hathawsh wrote: post #153
Noseshine wrote: post #135

Earlier quoted context omitted.

> What would you expect to happen if the object is modified after being inserted into the dictionary? I would expect it to continue to use the object . Why would it matter if it was mutated or not? You can try it right in your browser with Javascript and the Map() object type. You can mutate the object all you want, as long as it's the same object(-reference) you access the same value in the Map object. Just as I wou…

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?

Re: Elm is Wrong

#210

Post by elbear »

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…

As I said in my post, I understand OP's frustration. I understand that he expected more consideration for his efforts to learn the language and his suggestions for improvement.

The deficiency was only in his eyes though. Evan and the Elm community are fully aware of the type classes thing, because it's been mentioned by many people. He just doesn't see it as something that requires an immediate solution.

To summarize: I understand OP's frustration. At the same time, Elm (just like any other open source project) doesn't owe him anything. If you open a pull request or an issue you are not guaranteed a resolution in your favor. Ranting will help you vent but that's it.

Post reply on HN