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

161–170 of 190 posts

Re: Haskell for a New Decade [pdf]

#161

Post by Jeff_Brown »

SparklingCotton wrote: post #103
quickthrower2 wrote: post #48

Earlier quoted context omitted.

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…

I've used lens for years and years, but don't fully grok it. Who cares? Lens is also like category theory, you don't need to understand the details in order to use it.

More generally, trying to learn the whole language -- for almost any language -- is usually a waste of time.

Re: Haskell for a New Decade [pdf]

#162

Post by akho »

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.

What sort of hidden knowledge do you see in the flushing mechanism? It’s pretty straightforward.

(If you don’t want to go into how plastics are made, &c — but that stretches the metaphor way too far)

Re: Haskell for a New Decade [pdf]

#163

Post by platz »

yomly wrote: post #141
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…

Incidentally, I am learning Haskell right now. And fwiw don't have a CS degree. I think the difficulty of Haskell is overrated. It's just different. The crowd who complain about Haskell being hard despite x years experience are the same people who speak English and think Mandarin is hard. And yet 1.7+ billion people speak Mandarin, and most linguists agree that English is actually the harder language owing to its mor…

I agree, well stated!

Re: Haskell for a New Decade [pdf]

#164

Post by platz »

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.

Language extensions do not prose a problem for the best-in-class composability that OP is interested in, for practitioners of the language, that haskell offers.

Are you absolutely sure these language extensions are as bad as you think they are?

Lets look at what they asked for:

> But what I yearn for is computer languages that feel like the design elements all work together so that the whole is greater than the sum of the parts, instead of languages with a checklist of "good ideas" that thrown together create a whole that is lesser than the sums of their features.

- computer languages that feel like the design elements all work together so that the whole is greater than the sum of the parts

+ check

- instead of languages with a checklist of "good ideas" that thrown together create a whole that is lesser than the sums of their features

+ the key here is making sure that you have "a whole that is lesser than the sums of their features". Haskell's Language Extensions do not prevent composability that the language offers, so this is not as big a problem as you make out here

that said, I think it does require a bit of a 'paradigm shift' to learn haskell well, and if you're not up do it, clojure might be a better fit. But i don't think that would be motivated for the OP by the language extensions, but more from learning about laziness and lambda calculus.

Re: Haskell for a New Decade [pdf]

#165

Post by mlthoughts2018 »

mrkeen wrote: post #134
mlthoughts2018 wrote: post #17

When will Haskell get a different spokesperson? Stephen isn’t effective in this role. These posts have jumped the shark to the point when I see a big Haskell post on HN and see stephendiehl.com it’s just time to tune out. For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default. But Stephen does not help this, just preferring to inst…

> For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default. How far do you want to take the eager execution thing? Should we get rid of boolean short-circuiting? Should if-statements evaluate both the true and false paths before choosing one? Should compilers no longer remove dead code?

Many languages have already figured out good trade offs, why shouldn’t we expect a high standard of Haskell?

Re: Haskell for a New Decade [pdf]

#166

Post by jose_zap »

akho wrote: post #162
jose_zap wrote: post #113

Earlier quoted context omitted.

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.

What sort of hidden knowledge do you see in the flushing mechanism? It’s pretty straightforward. (If you don’t want to go into how plastics are made, &c — but that stretches the metaphor way too far)

I would personally have trouble naming all of the pieces in the flushing mechanism and being able to put y them together if I asked someone to buy them for me. That’s seems to be the same for many people I know.

Re: Haskell for a New Decade [pdf]

#167

Post by jose_zap »

tluyben2 wrote: post #151
jose_zap wrote: post #113

Earlier quoted context omitted.

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.

I agree, there is no point in trying to change their behavior, we can at best understand them and offer alternatives

Re: Haskell for a New Decade [pdf]

#168

Post by platz »

jeffdavis wrote: post #88

"Software is Terrible and Getting Worse" I wonder if increasing bloat is a permanent thing? Will software ever transition to a cycle of simplification? Has it ever gone through a simplification cycle in the past? Physical engineering has some limits that push back on complexity. You can only cram so many gears into a Swiss watch. An item can only have so many parts before manfacturing becomes a nightmare. What will p…

Prolog isn't going to save anyone - it's too hard to control the search strategy.

Re: Haskell for a New Decade [pdf]

#169

Post by marcosdumay »

tluyben2 wrote: post #112
evertedsphere wrote: post #110

Earlier quoted context omitted.

Anecdata point: I'm comfortable with lens at a very basic level, and if you have a good grasp of "normal" Haskell you can just compose lens operators and use combinators by playing the usual "type tetris" game of "what fits here?" and eventually you pick up a few idioms that are enough for most normal lens usage.

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…

Has he got any luck on that Quantum Mechanics and General Relativity harmonization or he simply avoids using a computer in a gravity wheel?
Post reply on HN