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

131–140 of 218 posts

Re: Elm is Wrong

#131

Post by leshow »

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.

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.

Re: Elm is Wrong

#132

Post by b123400 »

mrkgnao wrote: post #87
b123400 wrote: post #70

Earlier quoted context omitted.

I tried Halogen for a while and found it too complicated. I need to create a type with 6 type params (something like `ParentComponentSpec s s' f f' g p`) for embedding a child component! Also, most of the operations are wrapped in monad, which ultimately bring me back to the procedural way of thinking.

Pux is great!

Wow, I never heard of that! Thanks, will check it out :)

Re: Elm is Wrong

#133

Post by shoover »

ungzd wrote: post #88

Does the same criticism apply to OCaml and F#? Anyone who used these languages for long time, how do you solve lack of higher-kinded types (or OCaml has them?) and do polymorphism?

In F# you can always bail on the strict parts of the F# type system and use .NET classes and interfaces for polymorphism.

Re: Elm is Wrong

#134

Post by mfukar »

elbear wrote: post #117
mfukar wrote: post #101

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

> 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 dismissive answer. That's the context. We can't apply Evan's* rationale behind the reply here, because the OP never had the chance to have it revealed to him to the extent of his interaction.

I'm surprised I have to point this stuff out. However understanding we may be, surely we can see why anybody is frustrated with being dismissed like this?

* Apologies, but I don't actually know Elm's author's last name.

Re: Elm is Wrong

#135

Post by Noseshine »

Erwin wrote: post #105
Singletoned wrote: post #54

Earlier 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?
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 would expect. "Mutable" doesn't change which object you have, only what it looks like inside.

Re: Elm is Wrong

#136

Post by lukeasrodgers »

ungzd wrote: post #91
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…

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?

I can't speak for it being immoral, but basically, using rude and offensive language tends to undermine rational discourse. If your purpose is get at the truth, then it is prudent to avoid such language.

However, a lot of writing (academic, journalistic, what have you) has "getting at the truth" as only one of its goals among many, including "expressing my feelings," "attacking someone else," "playing with poetic language," "sounding smart," etc.

Re: Elm is Wrong

#137

Post by gbersac »

inglor wrote: post #79
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.…

JavaScript maps can have object keys, you're just using objects as dictionaries. Objects in python don't typically have non-string keys. ```js var m = new Map(); var o = {}; // some object m.set(o, 5); m.get(o); // 5 ```

> ```js var m = new Map(); var o = {}; // some object m.set(o, 5); m.get(o); // 5 ```

That guy who thought markdown was supported by hacker news. LOL ! I've been through that too...

Re: Elm is Wrong

#138

Post by crb002 »

Evan needs an EXT set of libraries for stuff not in core just like Matz did. My pain point is forms. Make form generation and client side validation easy and everything else will follow.

Re: Elm is Wrong

#139

Post by NumberCruncher »

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…

>> trying to emulate type classes, build abstractions, do things like I would in other languages

I am pretty sure I read somewhere on the project homepage that you should not do this but do things on the elm way.

Re: Elm is Wrong

#140

Post by [deleted] »

the_duke wrote: post #7
sitkack wrote: post #2

>I have complaints about Elm after using it during a quick hack session.

The post is opinionated and a bit aggresively worded. But his(/her?) major complaint is valid: lack of type classes, which completely kills essential composability and generic properties of Haskell. And the module system doesn't offer MLs features to make up for it (signatures). This means that Elm requires boilerplate for things that are elegantly handled by type classes. You may also look at Purescript [1], a more…

[deleted]
Post reply on HN