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

The Flub Paradox

steved-imaginaryreal.blogspot.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: The Flub Paradox

#71

Post by codygman »

marcosdumay wrote: post #63
_dps wrote: post #60

Earlier quoted context omitted.

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications. Haskell is powerful, but won't solve all the problems on the world.

> Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized)

To give a rebuttal to Haskell not being good for "numerical work", you might be interested in this pre-alpha numerics library:

https://github.com/wellposed/numerical#performance-faq

I'm tempted to agree with you re: low latency, then I run across stuff like this:

https://github.com/tomahawkins/atom

I believe it (or a similar library) are used in quite a few of a certain companies (or multiples) flagship applications, though I can't recall the details.

Re: The Flub Paradox

#72

Post by codygman »

tempodox wrote: post #12

Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…

> In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL.

Can you give some examples of concepts that are a cumbersome burden and cause impractical cognitive load in Haskell? Perhaps some example code?

Re: The Flub Paradox

#73

Post by tempodox »

wz1000 wrote: post #29
tempodox wrote: post #12

Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…

> Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. Why do you say this? Sure, Haskell is radically different from most programming languages out there, even ones that claim to be 'functional'. But that does not mean it is 'overdone'…

> You start again from scratch.

You describe my situation with Haskell quite exactly, and I agree you have good points. The non-monad parts of Haskell are, after all, the most beautiful PL I've ever seen, and that puts me between a rock and a hard place.

My difficulty with monads comes from the very reason why they're so powerful: You can do anything with them, but at the cost of the monadic form taking center stage and the original problem's form getting almost lost, scattered across the functions implementing the monad laws. Maybe that's not so bad, but I haven't adjusted my thought process to that yet.

Re: The Flub Paradox

#74

Post by tempodox »

codygman wrote: post #72
tempodox wrote: post #12

Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…

> In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. Can you give some examples of concepts that are a cumbersome burden and cause impractical cognitive load in Haskell? Perhaps some example code?

Partially, I can explain by quoting myself from another answer:

My difficulty with monads comes from the very reason why they're so powerful: You can do anything with them, but at the cost of the monadic form taking center stage and the original problem's form getting almost lost, scattered across the functions implementing the monad laws. Maybe that's not so bad, but I haven't adjusted my thought process to that yet.

Or try to temporarily throw some debug logging into a deeply nested function that doesn't have the IO monad in its return type. Maybe that's the wrong type of thinking for this language, but there doesn't seem to be a “howto” on what to do instead...

Re: The Flub Paradox

#75

Post by tempodox »

michaelochurch wrote: post #62
_dps wrote: post #60

Earlier quoted context omitted.

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice. I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful lik…

Haskell took me a while, because there weren't many great resources on how to write many kinds of "real" code in Haskell. The quality of material is getting steadily better. I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack. If you're coming from Java, you're more productive than you were at 1 month in Haskell (you still know very little Haskell, but yo…

I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack.

Though merely anecdotal, that data point eases my mind a bit. I come from Assembler, Lisp, C, OCaml, so maybe my difficulties are par for the course.

Re: The Flub Paradox

#76

Post by marcosdumay »

_dps wrote: post #66
marcosdumay wrote: post #63

Earlier quoted context omitted.

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications. Haskell is powerful, but won't solve all the problems on the world.

This is an excellent point and maybe you gave me a good compact summary of the situation. Perhaps you can tell me if you agree. The kind of work I do tends to involve a small number of low-variability data types, and the ROI on complex logic (w.r.t. computational performance) has to be very high for it to be accepted into a project. We don't shy away from complex logic, but we do have a high hurdle for it to cross be…

That's what I was trying to say (and much more precise).

Yet, I'd look at codygman's answer. It's a library that tries to improve memory locality by using more complex logic, and hides everything under Haskell abstractions so it's easy to use.

I'm not currently working on this area, so I can't really tell what it's good for.

Re: The Flub Paradox

#77

Post by wz1000 »

tempodox wrote: post #73
wz1000 wrote: post #29

Earlier quoted context omitted.

> Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. Why do you say this? Sure, Haskell is radically different from most programming languages out there, even ones that claim to be 'functional'. But that does not mean it is 'overdone'…

> You start again from scratch. You describe my situation with Haskell quite exactly, and I agree you have good points. The non-monad parts of Haskell are, after all, the most beautiful PL I've ever seen, and that puts me between a rock and a hard place. My difficulty with monads comes from the very reason why they're so powerful: You can do anything with them, but at the cost of the monadic form taking center stage…

For me, monads are just as beautiful as any other part of the language. Like almost everything new, you just have to work with them for some time, until you build intuition for the underlying mathematical object and everything just "clicks".
Post reply on HN