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

Dijkstra on Haskell and Java (2001)

chrisdone.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Dijkstra on Haskell and Java (2001)

#61

Post by martin1975 »

aidos wrote: post #40
Arwill wrote: post #18

Earlier quoted context omitted.

The problem is, people finish their CS study, and do not have such level of knowledge that they could start working right away. So Haskell might be nice, but is hardly a sought for skill. Sure if students would learn different stuff by themselves, they could learn useful skills too, but most of the students are lazy, and only learn what they have to.

The pursuit of knowledge shouldn't be dampened by silly things like getting a job. It's computer science after all. Aside from that, learning Haskell at university has eventually made me a better programmer. It gives you a whole other world outlook and that's useful once you finally start figuring out how to build reasonable software.

"The pursuit of knowledge shouldn't be dampened by silly things like getting a job."

Here's how I just read this: "The pursuit of what makes me look good shouldn't be dampened by silly things like serving people other than myself".

And than just to dampen that statement, you added "Haskell made me a better programmer", which clearly implies you got a job, serving the needs of others.

Would it be fair to say you are more concerned with looking good than serving others, based solely off what you said? Correct me if I'm wrong please.

Re: Dijkstra on Haskell and Java (2001)

#62

Post by sbov »

Arwill wrote: post #18
jfaucett wrote: post #8

I don't see why they don't just teach C, x86, and Haskell everywhere. If you know the concepts behind these, you can quickly grok any other programming language. Also I never got the whole hype behind OOP. IMHO its self explanatory, nothing you need an entire course on to be effective and understand OOP programs. Memory layout and management, advanced pointer concepts and monads are a slightly different matter. If I…

The problem is, people finish their CS study, and do not have such level of knowledge that they could start working right away. So Haskell might be nice, but is hardly a sought for skill. Sure if students would learn different stuff by themselves, they could learn useful skills too, but most of the students are lazy, and only learn what they have to.

So, what would you cut out of CS so they can learn things that makes them employable right away, by a wide variety of companies, and not just yours?

Keep in mind it should be stuff that will have staying power, and not the latest fad, because you tend to go to school for at least 4 years.

Re: Dijkstra on Haskell and Java (2001)

#63

Post by jfaucett »

nbouscal wrote: post #59
dkersten wrote: post #49

Earlier quoted context omitted.

and monads I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realis…

I really don't understand why people think monad is a "fancy scary term". It's a five-letter easily-pronounceable word. What makes it fancy or scary? I think people assume that they're scary, and then confirmation bias themselves into making them hard to learn, despite them being a reasonably simple concept overall. As for calling them strategies… if we called them that it would make learning and understanding the in…

hmm, if we called them what they are we'd call them "type wrapper functions" and talk about "type wrapper function chains", monads carries zero metaphorical/associative meaning. I think thats the problem with the name and a large reason people find them so unapproachable, most other terms in computer science carry significant associative meaning that helps in learning them, pointers have to do with pointing at things, functions carry the mathematical meaning of a set of inputs mapping to a set of outputs, etc.

Re: Dijkstra on Haskell and Java (2001)

#64

Post by amelius »

nbouscal wrote: post #59
dkersten wrote: post #49

Earlier quoted context omitted.

and monads I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realis…

I really don't understand why people think monad is a "fancy scary term". It's a five-letter easily-pronounceable word. What makes it fancy or scary? I think people assume that they're scary, and then confirmation bias themselves into making them hard to learn, despite them being a reasonably simple concept overall. As for calling them strategies… if we called them that it would make learning and understanding the in…

> I really don't understand why people think monad is a "fancy scary term".

The reason could be that the term "monad" comes from category theory, and that is a topic not everybody is too familiar with...

Re: Dijkstra on Haskell and Java (2001)

#65

Post by codygman »

CJefferson wrote: post #15
mathetic wrote: post #10

Earlier quoted context omitted.

I am looking forward to the day the notion that functional languages are not suitable for developing software will die. It is not only that functional languages are more succinct, easier to reason about and are more readable, they also often come with significantly better type systems. Some have type systems sophisticated enough to specify nearly all the legal states and guarantee these are the only states the progra…

That day will come, for many of us, when a large AAA game, web browser, or usable OS is written in a FP language. And I realise that is an unfair target, but there is very little user facing FP software. The only one I can think of I have used is xmonad, which is both hard to use and fairly buggy

Xmonad is buggy? I've been using it for 4 years and never had a problem. I actually also use it on multiple displays.

Re: Dijkstra on Haskell and Java (2001)

#66

Post by acallan »

SilasX wrote: post #48
acallan wrote: post #22

Indeed, my first CS class in 1999 at UT was in Haskell. Wow! What a change it was from high school AP Computer Science in Texas, which was (in those days) C++. Seeing QuickSort in just one line was what hit it home. I remember thinking at the time that this was really incredible, but that Haskell had no future. This was at the time of Hugs 98, although I remember hearing about GHC. I'm glad to be wrong about this.

Hold on: does Haskell allow "the" QuickSort on one line, or just a sort? Because from what I've read, if you want to make Haskell do all the efficient stuff in a QS, you have to tell it a lot more, bloating the program. Edit: this is what I had in mind: http://augustss.blogspot.com/2007/08/quicksort-in-haskell-qu... Btw, I took AP Compsci with C++ in Austin around that time, so we might know each other.

Like a lot of UT Computer Science, the implementation is a detail left for the reader. The semantics of the language make the one-liner n*log(n)--that's the takeaway.

Re: Dijkstra on Haskell and Java (2001)

#67

Post by conistonwater »

SilasX wrote: post #48
acallan wrote: post #22

Indeed, my first CS class in 1999 at UT was in Haskell. Wow! What a change it was from high school AP Computer Science in Texas, which was (in those days) C++. Seeing QuickSort in just one line was what hit it home. I remember thinking at the time that this was really incredible, but that Haskell had no future. This was at the time of Hugs 98, although I remember hearing about GHC. I'm glad to be wrong about this.

Hold on: does Haskell allow "the" QuickSort on one line, or just a sort? Because from what I've read, if you want to make Haskell do all the efficient stuff in a QS, you have to tell it a lot more, bloating the program. Edit: this is what I had in mind: http://augustss.blogspot.com/2007/08/quicksort-in-haskell-qu... Btw, I took AP Compsci with C++ in Austin around that time, so we might know each other.

If you think quicksort is bloated, wait till you see a full implementation of depth-first search (I mean full: with all the back/cross/forward-edges and everything). It's a good exercise, but not very pretty.

Most of the bloat comes from the fact that when you implement it in Haskell, the resulting program doesn't really depend on being executed in the IO monad, and can be easily modified to run in many other monads too (like ST, or some transformed monad). The result is that the Haskell imperative version is far more general than a similar C implementation.

Re: Dijkstra on Haskell and Java (2001)

#68

Post by [deleted] »

sbov wrote: post #62
Arwill wrote: post #18

Earlier quoted context omitted.

The problem is, people finish their CS study, and do not have such level of knowledge that they could start working right away. So Haskell might be nice, but is hardly a sought for skill. Sure if students would learn different stuff by themselves, they could learn useful skills too, but most of the students are lazy, and only learn what they have to.

So, what would you cut out of CS so they can learn things that makes them employable right away, by a wide variety of companies, and not just yours? Keep in mind it should be stuff that will have staying power, and not the latest fad, because you tend to go to school for at least 4 years.

[deleted]

Re: Dijkstra on Haskell and Java (2001)

#69

Post by hornd »

nbouscal wrote: post #59
dkersten wrote: post #49

Earlier quoted context omitted.

and monads I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realis…

I really don't understand why people think monad is a "fancy scary term". It's a five-letter easily-pronounceable word. What makes it fancy or scary? I think people assume that they're scary, and then confirmation bias themselves into making them hard to learn, despite them being a reasonably simple concept overall. As for calling them strategies… if we called them that it would make learning and understanding the in…

Why would calling them anything different have any effect on learning other concepts?

Re: Dijkstra on Haskell and Java (2001)

#70

Post by louthy »

arjie wrote: post #53
dkersten wrote: post #49

Earlier quoted context omitted.

and monads I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realis…

How about F#'s Computation Expressions? Not exactly the same, I'm told, but they're close, if so.

They're called computation expressions in F# and not monads because they're not exclusively used to implement monads. The term is more generalised to capture the much larger scope of the feature.

Here's a breakdown of the difference:

http://tomasp.net/blog/2013/computation-zoo-padl/index.html

Post reply on HN