Hacker News Reader

Comment by wredue | Hacker News Reader

> But there are other cases where safety and performance _are_ in contention, and we must choose one or the other. Anyone who has been forced to satisfy the borrow checker by using a .clone(), using Rc, or refactoring objects into a hash map and referred to them by an ID (that must be hashed to exchange with a reference), has felt this contention.

Yes. You literally did assume that the borrow checker is an authority, as seen here.

To be frank with you, given that zig is 95% of the way there, I feel that you are “diving off the deep end” when stating things like “Haskell doesn’t go far enough”. Haskell typing system is a nice experiment, but I don’t believe to be good in any capacity, let alone “not going far enough”.

Haskell, in my opinion, a great case of “solving a problem before even asking what the problem really is”.

View on HN

They obviously meant safety in the sense of "knowing the operation is safe because it is checked". You can tell that was the intention because they say "forced to satisfy" which indicates the stated operation is unnecessary, but needed to appease a overly cautious checker. In addition, in the previous sentence they say "allows us to guarantee safety with minimal friction" to indicate they are talking about automatic safety guarantees, not the abstract concept of safety.

So what problem do you think Haskell thinks it's solving?

I haven’t the foggiest clue what problem Haskell is solving, because as far as I can tell, it doesn’t solve any problem particularly well. Hence “solving the problem before even asking what their problem actually is”.

"Designed for teaching, research, and industrial applications" - from wikipedia (2nd sentence)

Seems to have done pretty damn well IMO. Not that I've used it for 25 years, but I liked it and it introduced me to FP which totally changed how I thought of programming. I guess we have to differ on this.

Yes. It changed how you thought about programming *for the worse*.

Whereas I believe that concepts are tools for programmers to reach for when appropriate, functional programmers believe concepts are rules and reaching for them should be mandatory, no matter how much bullshit they force you to add for no reason other than you accepted from the get go that, for example, immutability should be mandatory.

This is a massive fundamental problem with Haskell and all language that take hardline stances on things that are better left to the users. In this regard, I’d say it’s a complete failure. It’s horrible for teaching. You need to know more than you need to know for Java just to use it. It’s horrible for research. It has hardline fundamental stances that rejects exploration, and therefor is research averse. It is horrible for industrial applications as there are massive ranges of industry that simply cannot give to the whims of Haskell for one reason or another, but probably multiple reasons cause Haskell is terrible.

I'm pretty sure you don't have a clue or any significant experience, and too much arrogance to stop and question your own assumptions which you've just imposed on others including me, but carry on anyway.

> functional programmers believe concepts are rules

Based on what? It’s almost like “functional programmer” is not a single entity controlled by Big Haskell - you are just spewing bullshit about a made up boogeyman.

> I believe that concepts are tools for programmers to reach for when appropriate, functional programmers believe concepts are rules and reaching for them should be mandatory

Could you give some examples of such concepts? It's rather hard to understand what you mean in the abstract.

> "This is a massive fundamental problem with Haskell and all language that take hardline stances on things that are better left to the users".

Thank you. This is completely and utterly true.

Reply on news.ycombinator.com