Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell for a New Decade [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

151–160 of 190 posts

Re: Haskell for a New Decade [pdf]

#151

Post by tluyben2 »

jose_zap wrote: post #113
tluyben2 wrote: post #112

Earlier quoted context omitted.

There are many people (at least that from the developers I know) who need to understand things fully before they 'can' use them. One of my friends is mentally stuck for 30 years on a platform because he cannot use what he does not fully understand. He tried Haskell (a few years ago) but instead of going through exercises or just trying to implement something, he read a book and noticed he did not understand basic (mo…

Ask him to explain in full detail how the flushing mechanism of a WC works. Then ask him if he uses any alternative solution he understands better. I think it is quite common, even for people who want to understand things at a fundamental level, to just use stuff without said understanding.

It is not so consistent; I guess when they think about it consciously, they want to understand it. For all the rest (more low level, a WC etc) they, inconsistently, do not care. It is not really for me to change their behaviour, I just know that some of them are really crippled by this.

Re: Haskell for a New Decade [pdf]

#153

Post by xamuel »

Smaug123 wrote: post #107
nine_k wrote: post #77

Earlier quoted context omitted.

None of the languages that let you achieve certain top qualities (top performance, proven correctness, concurrency, compactness, etc) are trivial or "feel natural". Haskell, Rust, APL / K / Q, Erlang, hell, even C++ and Scala (though these two are unnecessarily bloated). You got to study and internalize concepts that underlie them, change your way of thinking. This is because reality is not intuitive, too. Take natur…

I'd definitely argue that no language ever will "feel natural" unless it fundamentally changes the metaphors of computation. Humans just don't think in sufficiently "hard-boundary" terms for programming as currently phrased to come naturally. Granted, culture has made up for a lot of that - in the UK, children are expected to be able to perform arithmetic, which presumably helps a lot in instilling the appropriate st…

When we tell a person to do something, we always give them some freedom in how to do it. When we tell a computer to do something, we don't. If one were to instruct a human being to go to the grocery store in absolutely full micromanaged detail, it would look equally unnatural ("Lift your right knee. Swing your right foot forward. Put down your right foot...") Sort of like that videogame QWOP.

Re: Haskell for a New Decade [pdf]

#154

Post by dundarious »

axilmar wrote: post #149

As a seasoned C++ programmer, that occasionally plays with Haskell, here is a question? Has finally Haskell the problem of how to do destructive updates or not? If it cannot do destructive updates, I am not interested. The kind of software I am called to build always requires destructive updates for performance reasons and secondly I am so used to assignment and all the design patterns around it that I don't think I…

If that means you're not a fan of ST or the State monad, maybe the newly added linear types support will eventually provide what you're looking for.

Re: Haskell for a New Decade [pdf]

#156

Post by piercebot »

nvarsj wrote: post #146
travisgriggs wrote: post #95

Earlier quoted context omitted.

I'll respect your opinion but sign up for the "not what other people want" crowd. I started learning Haskell last week. I have a small rest service I need to write and I want to try something new. Why Haskell? Because I miss seeing excellence/purity in computer languages. Nearly 10 years ago I jumped out of the Smalltalk balloon. It was one of the only languages where Object Oriented felt like a paradigm shift (CLOS…

Haskell is probably the exact opposite of what you are looking for. It's basically a pile of every academic's pet language feature. I would suggest you try Common Lisp or Clojure, which will probably be closer to what you are looking for.

Going to throw my weight behind the Clojure recommendation.

For more information about the language, there was a great PDF published about the history of the language recently: https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

Re: Haskell for a New Decade [pdf]

#157

Post by lallysingh »

quickthrower2 wrote: post #48
nh2 wrote: post #37

Earlier quoted context omitted.

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…

Thanks for that. Everything you said is from the perspective on being not only in a Haskell job but in a Haskell team. Your 3 months is 5 years for someone trying to learn on their own in their spare time. And then they need this to get a Haskell job due to the competition for such job and the queue of super smart people lining up for a Haskell job. And the pay cuts are brutal. Now you are an outlier, working on a Ha…

Generally I easily found C++ as difficult to learn as Haskell. Mastering C++ takes a half-dozen books -- although that number's starting to reduce as the language is getting a bit cleaner. Haskell takes 2-3. The last is just the optics book, if you want to learn lenses, which are worth it.

Re: Haskell for a New Decade [pdf]

#158

Post by agentultra »

axilmar wrote: post #149

As a seasoned C++ programmer, that occasionally plays with Haskell, here is a question? Has finally Haskell the problem of how to do destructive updates or not? If it cannot do destructive updates, I am not interested. The kind of software I am called to build always requires destructive updates for performance reasons and secondly I am so used to assignment and all the design patterns around it that I don't think I…

It can and direct you to do it safely and is about to get better.

Looking forward to GHC 8.12 and linear types.

Re: Haskell for a New Decade [pdf]

#159

Post by runeks »

axilmar wrote: post #149

As a seasoned C++ programmer, that occasionally plays with Haskell, here is a question? Has finally Haskell the problem of how to do destructive updates or not? If it cannot do destructive updates, I am not interested. The kind of software I am called to build always requires destructive updates for performance reasons and secondly I am so used to assignment and all the design patterns around it that I don't think I…

Haskell can do destructive (in-place) updates via various forms of mutable variables (e.g. IORef).

Re: Haskell for a New Decade [pdf]

#160

Post by tome »

axilmar wrote: post #149

As a seasoned C++ programmer, that occasionally plays with Haskell, here is a question? Has finally Haskell the problem of how to do destructive updates or not? If it cannot do destructive updates, I am not interested. The kind of software I am called to build always requires destructive updates for performance reasons and secondly I am so used to assignment and all the design patterns around it that I don't think I…

> Has finally Haskell the problem of how to do destructive updates or not?

No "finally" about it. Haskell must have had destructive updates for at least a couple of decades.

Post reply on HN