Earlier quoted context omitted.
political correctness does not always equate to behaving respectfully Could you provide an example of when it doesn't?
"safe spaces" in Universities.
I see no use of the term political correctness.
Elm is Wrong
121–130 of 218 posts
Re: Elm is Wrong
#122Earlier quoted context omitted.
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.)
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.
Re: Elm is Wrong
#123I 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 allowing values to depend on types. This makes it impossible to compile or interpret a program without first checking/inferring its types. Static types without typeclasses don't have this problem; as far as I can tell this even includes dependent types (which do their coupling the other way), as long as you don't allow some form of typecase.
- Global uniqueness of instances doesn't compose. If I have a perfectly correct module A, and a perfectly correct module B, a module C might break by importing both, due to overlapping instances. This has to be mitigated by convention, e.g. not writing orphan instances.
- Local reasoning can require knowledge of global properties. This is especially true for things like code generation. For example, if I plumb together two expressions, say `nub :: Eq a => [a] -> [a]` and `xs :: [b]`, I can generate new requirements like `Eq b`. However, I can't just go ahead and implement those requirements (e.g. generating an `Eq` instance for `b`), since that will break if there's already an implementation, floating somewhere in the sea of imported modules. Packages like `ifcxt` can help, by allowing lookups and fallbacks, but they're not a complete solution.
- If more than one instance of a typeclass might makes sense for some type, it's pretty much inevitable that APIs using the typeclass (e.g. `foo :: Bar a => a -> ...`) will gain extra functions for bypassing the typeclass (e.g. `fooBy :: (a -> ...) -> a -> ...`)
There are probably more issues in the literature, but these are ones I've been banging my head against recently.
Typeclasses are a great idea and a useful addition to the PLT toolbox, but including them in a language isn't an automatic improvement: it's more of a design choice to steer the language down a particular path, when other languages may prefer other paths. Similar to using strict/non-strict evaluation, or exceptions, or macros.
Re: Elm is Wrong
#124Earlier 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.
Well, you cannot use a mutable object as a key without some help. What would you expect to happen if the object is modified after being inserted into the dictionary? If you have a list or dictionary you want to use a key, you can convert it into a tuple which would make it immutable. If you don't care about performance for larger collections you could just use a list instead of a dictionary, which does not require ha…
> What would you expect to happen if the object is modified after being inserted into the dictionary?
This question is sometimes not important: When the mutable object is not mutated.
Re: Elm is Wrong
#125Earlier quoted context omitted.
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 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 boilerplate over and over. It is impossible to keep any large Elm project DRY.
Re: Elm is Wrong
#126Earlier quoted context omitted.
Well, you cannot use a mutable object as a key without some help. What would you expect to happen if the object is modified after being inserted into the dictionary? If you have a list or dictionary you want to use a key, you can convert it into a tuple which would make it immutable. If you don't care about performance for larger collections you could just use a list instead of a dictionary, which does not require ha…
> What would you expect to happen if the object is modified after being inserted into the dictionary? This question is sometimes not important: When the mutable object is not mutated.
> This question is sometimes not important: When the mutable object is not mutated.
Which you can't guarantee when the object is mutable, so for consistency's sake it's left out.
Though you can always build your own Dict subclass and implement __hash__ on it and be angry with yourself when it fails. :)
Re: Elm is Wrong
#127Earlier quoted context omitted.
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.)
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.
Re: Elm is Wrong
#128I don't believe in Elm one bit. it's been 4 years guys. I follow its developement (it's not a hard thing to do after all, it's a snail pace) because its creator is intelligent and there are a few nice things in it. But as a practical platform to build real apps? No way. I mean you can build apps with any tech, so of course people will try and succeed with it; but it's just a bad choice. Elm is impratical because you…
Rejecting a programming language feature because you find it constraining is just ignoring history. Arguments similar to yours have been used to dismiss Garbage Collection, type systems, and even the use of high-level languages, all of which were very successful precisely because they constrain the set of programs you can write. Also, why all the hate? As you said, neither you or the TypeScript community have any rea…
what is the feature you're talking about? I don't see any innovation in elm on the order of a GC or a type system. Perhaps you're referring to Elm's "feature" of removing the ability to create abstractions away from the programmer so that everything must be done by copy-paste and brute force.
Re: Elm is Wrong
#129As someone who's written a language, the need to have a personal approval from a founder before being published to the site stuck out to me more than the typeclasses. I'd argue in favor of it, so long as the review is done in a timely process. I can understand wanting a smaller number of high-quality, reviewed libraries that are tested and shouldn't break.
The restriction only applies to native modules (modules that ship with Javascript): https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9...
If you want to write anything non-trivial in Elm you need to use native modules though because the language doesn't give you access to any of it's "magic"
Re: Elm is Wrong
#130Earlier quoted context omitted.
> The line from Evan, Elm's creator, has always been along the lines of "show me a concrete actual use-case that you can't do without typeclasses", this article fails to clear that fairly low bar. Translation: "I will never add typeclasses." There is no concrete actual use-case that is impossible to implement without typeclasses. What typeclasses make possible is an abstraction over concrete actual use-cases. That is…
Evan has several times said that he's open for typeclasses. Problem is that they have a profound effect on the language, and so they have to be done right. He doesn't know what the right implementation of that might be at the moment, so he's waiting until he comes up with what the right thing to add for Elm would be.
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)