Sandy is wrong.
Elm is Wrong
111–120 of 218 posts
Re: Elm is Wrong
#112I'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.…
One problem that makes it sound like a nightmare to work with.
Re: Elm is Wrong
#113Earlier quoted context omitted.
You seem to miss the point. Elm is particularly easy to pick up for people coming from Haskell. Maybe not in 15 seconds, but 15 minutes is a totally reasonable estimate. The author can without doubt write a large project in Elm. His complaints were about missing the conveniences of abstraction Haskell-like languages provide, and he is more than qualified to talk about it. Decomposing records into tuples of comparable…
>15 minutes is a totally reasonable estimate [coming from Haskell]. The author can without doubt write a large project in Elm. Well, all right. In general I would say that is not true even for languages that are close, but there are exceptions and I suppose I can take your word for it.
It's only because Elm is basic Haskell minus a lot of stuff. So basically if you know Haskell you already know Elm (so you need the 15 minutes to get up to speed wrt ports and subscriptions or whatever), but at the same time miss the stuff that has been left out that you take for granted, hence the failed attempt of the author to get some of that back.
Re: Elm is Wrong
#114Earlier quoted context omitted.
So my point was actually about the specifics of picking up a language to do a new project , and then complaining about it. (Hence my example of writing a serious book in a language you don't know.) I think you really go into superlatives here. It's not fair for you to say "15 seconds", for example. 15 seconds is how long you've been reading this comment. (I just timed myself, okay maybe 10-13 seconds.) I also think t…
I find that there are times where I get into a "Someone is wrong on the internet" situation, but still think it's worth commenting. This is one of those times. My goal is not to win the argument, but rather I hope I can show you a different way to look at the situation. To be fair, the only reason I wrote my original reply to you was because you asked why people would down vote you. Clearly 15 seconds is unreasonable…
So is it fair to say that it is possible for me to conclude "xyz is broken" based on a single paragraph? For example, if I read the Wikipedia article on Perl 6, the second paragraph says "While historically several interpreter and compiler implementations were being written, today only the Rakudo Perl implementation is in active development."
So let me skip the part where I spend 2 weeks picking up a language!
Let's go straight to: "if an ostensibly open language only has one single implementation, it is fundamentally broken and underspecified and should not be used by anyone, period."
Is the part I quoted enough for me to conclucde that it's a broken language not fit for any use by anyone? Because the article that we're talking about has the title "Elm is wrong."
Can I say, "Perl 6 is wrong" without even bothering with coding in it for a few months?
Re: Elm is Wrong
#115In cases where we're "acting on" some value, like a dictionary, surely we should be able to store the comparison function in the value? I don't know Elm, but something like the following Haskell:
data Dict k v = D (k -> k -> Bool) [(k, v)]
empty :: (k -> k -> Bool) -> Dict k v
empty f = D f []
-- and so on
We could do the same for things like Set too.
As far as I can see, the only 'problem' would be operations like `merge`, where we might have two different functions. The simplest thing would be to bias in favour of one, e.g. turning `merge d1 d2` into something like `extendWith d1 d2`.
I'm not saying this can replace typeclasses or modules in general, but in these sorts of cases we're already passing around a datastructure, so why bother passing around the required functions separately?
There's probably some irony here, considering the fact that GHC implements typeclasses using dictionary passing!
Re: Elm is Wrong
#116Earlier 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?
"safe spaces" in Universities.
Re: Elm is Wrong
#117Earlier 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.
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 open source project) doesn't owe him anything. That's why many people take an issue with his tone.
In summary, Elm's target audience are JavaScript developers. It's developers who want their apps to be more robust and easier to refactor than in plain JavaScript. Sure, type classes are useful but they also increase complexity. Evan wants to see if there's a better solution and the Elm community generally accepts that.
Re: Elm is Wrong
#118Earlier quoted context omitted.
>15 minutes is a totally reasonable estimate [coming from Haskell]. The author can without doubt write a large project in Elm. Well, all right. In general I would say that is not true even for languages that are close, but there are exceptions and I suppose I can take your word for it.
It's only because Elm is basic Haskell minus a lot of stuff. So basically if you know Haskell you already know Elm (so you need the 15 minutes to get up to speed wrt ports and subscriptions or whatever), but at the same time miss the stuff that has been left out that you take for granted, hence the failed attempt of the author to get some of that back.
That could have been presented much more clearly in the article.
It would be interesting to compare with the opinion/experience of someone who didn't know Haskell, well, right? (Though in that case perhaps the learning curve is too steep, maybe Elm isn't meant for that.)
Re: Elm is Wrong
#119Earlier quoted context omitted.
I think it's valid criticism. There's a (excruciating) description of a use case, (valid) attempts to build a solution, and reaching the point where someone tells you "No, you can't have that because I don't want to" - whoever that may be - is understandably frustrating. Especially when the facility in question solves a real PITA of a problem. Now, the author was obviously venting, he even admits it. Nonetheless, the…
I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: https://github.com/elm-lang/elm-compiler/issues/985 Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means t…
It has a dictator for life, but given the article doesn't seem like the B is earned yet :P
Re: Elm is Wrong
#120Earlier quoted context omitted.
> I'm a Python programmer. I fully expect dict keys to be able to be arbitrary objects. I'm a Python programmer too, and I also fully expect dict keys to be able to be arbitary objects, and I get really frustrated with the fact that they can't be arbitary objects. They have to be hashable objects, and the hash function refuses to hash certain objects that it has decided aren't allowed.
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.