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

181–190 of 190 posts

Re: Haskell for a New Decade [pdf]

#181

Post by mwcampbell »

lmm wrote: post #180
mwcampbell wrote: post #148

Earlier quoted context omitted.

For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to…

> The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. Recent JVM libraries have (rightly) moved away from null. Using e.g. JDK8 streams from Kotlin is very cumbersome (noticeably more cumbersome than using them from Scala). The special treatment of interop also cr…

> People who care about zero overhead wouldn't be using Kotlin in the first place.

Depends on the target platform. When developing for Android, one can't entirely escape the JVM (or rather, ART), and developing entirely in a JVM language eliminates JNI overhead. And I'm guessing ART doesn't have all the advanced optimizations of HotSpot.

Re: Haskell for a New Decade [pdf]

#182

Post by jiyinyiyong »

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…

> Haskell is what happens when you go full lambda calculus, and the dedication to referential transparency really forces you down some interesting paths/abstractions. It's also worth noting that other functional languages like OCaml and lisp do not force purity so the idioms are not as extreme.

Clojure does, in some degree.

Re: Haskell for a New Decade [pdf]

#183

Post by yomly »

jiyinyiyong wrote: post #182
yomly wrote: post #141

Earlier quoted context omitted.

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…

> Haskell is what happens when you go full lambda calculus, and the dedication to referential transparency really forces you down some interesting paths/abstractions. It's also worth noting that other functional languages like OCaml and lisp do not force purity so the idioms are not as extreme. Clojure does, in some degree.

Clojure encourages functional style code through its immutable data structures and a set of (mostly) referentially transparent functions that operate on them.

But clojure is very strictly imperative. Atoms are easily accessible in the stdlib and side effects can be called inline and hidden within functions. This masks IO from a perceived return type.

Haskell differs here because it forces you down the path of "everything explicit" and "everything referentially transparent". Essentially monads emerge as a result of this, but their use definitely feels unergonomic in clojure

Re: Haskell for a New Decade [pdf]

#184

Post by nvarsj »

platz wrote: post #164
nvarsj wrote: post #146

Earlier quoted context omitted.

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

Don't get me wrong - I really do love Haskell. And I don't think the language extensions are bad.

I just mean that Haskell doesn't feel like a coherent, commercial language to me. It is basically a bunch of PhD thesis's strung together on top of a research language - with some of these being very interesting and incredibly useful. This is perfectly fine for what it is - but it also means the overall language and standard library have not been designed with a "batteries included" mentality that let people get going easily and quickly in a commercial setting.

I suggested CL/Clojure because those are both interesting, lambda-calculus based languages similar to Haskell (without the typing, unfortunately), with great, mature libraries for building any commercial project possible.

Re: Haskell for a New Decade [pdf]

#185

Post by platz »

nvarsj wrote: post #184
platz wrote: post #164

Earlier quoted context omitted.

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

Don't get me wrong - I really do love Haskell. And I don't think the language extensions are bad. I just mean that Haskell doesn't feel like a coherent, commercial language to me. It is basically a bunch of PhD thesis's strung together on top of a research language - with some of these being very interesting and incredibly useful. This is perfectly fine for what it is - but it also means the overall language and stan…

No, I agree Haskell is not a "batteries included" language.

That said, a lot new of languages tend to opt for a minimal base footprint e.g. rust, so that has also been the trend lately.

Re: Haskell for a New Decade [pdf]

#186

Post by lptk »

JoelMcCracken wrote: post #40
chrisseaton wrote: post #36

Earlier quoted context omitted.

But those were popular and common before Haskell. Why would we say that lambdas spun off from Haskell to Java, rather than they were spun off from ML, or Miranda, or from Lisp?

I can’t say really, but my recollection is that the last decade of higher interest in FP has had Haskell as a fixture, and was significantly sparked by the need to program in a multi core world, and parallelization is made significantly simpler in the context of pure FP and controlled side effects. I hear you though. I was mostly a lisp person and only really got into Haskell in the last couple of years. Even still I…

I think it's safe to say that the inspiration for Java lambda almost certainly did not come from the "FP zeitgeist" you're describing, but simply from other JVM languages like Scala and Clojure, which showed how useful they were and how they could be done nicely on the JVM.

Re: Haskell for a New Decade [pdf]

#187

Post by somethingsome »

jose_zap wrote: post #166
akho wrote: post #162

Earlier quoted context omitted.

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.

It is not because you cannot name something that you don't understand something, even in profound levels.. the knowledge of the name is only conventional against the underlaying mechanism. It suffice to repair one wc, one time to have a pretty good idea on how it work without much effort

Re: Haskell for a New Decade [pdf]

#188

Post by somethingsome »

giantDinosaur wrote: post #145
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…

So they're essentially non-functional with today's technology stack? I think it's safe to declare the entire thing essentially incomprehensible to a single person. Sure - you can understand all the basics, and achieve expertise in a lot of it, but modern software and computing is essentially fractal in its complexity. Even when you think you understand, it often ends up being an abstraction which is re-written by som…

Why would they be non-functional with today's technology stack? The whole stack is complex, but everything depends in general on very basic principles (eg: basic information knowledge about parallelism, how a compilation works, etc.. and hardware knowledge : how parallelism is handled, why do we need asynchronous jobs and how they work, etc..). Any complex piece of software can be decomposed into basic principles and very often without a lot of work. The only softwares that require more time to understand are the ones that solve some physical or mathematical problems IMO, as you need to understand the math underlying them. But again, this is not an impossible task

Re: Haskell for a New Decade [pdf]

#189

Post by JoelMcCracken »

lptk wrote: post #186
JoelMcCracken wrote: post #40

Earlier quoted context omitted.

I can’t say really, but my recollection is that the last decade of higher interest in FP has had Haskell as a fixture, and was significantly sparked by the need to program in a multi core world, and parallelization is made significantly simpler in the context of pure FP and controlled side effects. I hear you though. I was mostly a lisp person and only really got into Haskell in the last couple of years. Even still I…

I think it's safe to say that the inspiration for Java lambda almost certainly did not come from the "FP zeitgeist" you're describing, but simply from other JVM languages like Scala and Clojure, which showed how useful they were and how they could be done nicely on the JVM.

I believe both of those languages have motivational roots in the parallel computation drive/what I am describing as the FP zeitgeist.

For example, this ya the earliest reference to clojure I could find on hn. Notice the text of the announcement and how it focuses on parallelism https://groups.google.com/forum/m/#!topic/comp.lang.lisp/xvK...

Re: Haskell for a New Decade [pdf]

#190

Post by akho »

jose_zap wrote: post #166
akho wrote: post #162

Earlier quoted context omitted.

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.

It’s easy to do. You should get at least some more handy friends — or become one yourself: it will broaden your understanding of your environment, most things are very easy to fix and change.
Post reply on HN