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

71–80 of 124 posts

Re: Dijkstra on Haskell and Java (2001)

#71

Post by ufo »

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…

> What makes it fancy or scary?

Its an abstraction and abstractions are hard. In away, its similar to why beginners tend to have trouble with recursion (if you try to understand a recursive program by stepping through without using abstractions like preconditions and postconditions)

Re: Dijkstra on Haskell and Java (2001)

#72

Post by SilasX »

acallan wrote: post #66
SilasX wrote: post #48

Earlier quoted context omitted.

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.

But the one liner was the implementation, and doesn't do a QuickSort...

Re: Dijkstra on Haskell and Java (2001)

#73

Post by runT1ME »

dkersten wrote: post #49
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…

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…

> controlling how things are executed/computed.

No...see...you understand a monad. That is not the same thing as groking "Monads" in the abstract sense.

For instance, I don't think the State monad really has anything to do with how things are 'executed/computed'

Re: Dijkstra on Haskell and Java (2001)

#74

Post by acallan »

SilasX wrote: post #72
acallan wrote: post #66

Earlier quoted context omitted.

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.

But the one liner was the implementation, and doesn't do a QuickSort...

In tests and homework, we would implement the one-liner quicksort with paper and pencil, much like a math test. In a pencil implementation of that Haskell, it is n log(n). Each line on the paper represented one level of recursion.

Implementing it on silicon requires the trade-offs you mention. But silicon is just an implementation left to the reader...

EDIT: I guess where I'm coming from, Haskell was used in the context of the Theory of Computation, not real-world implementation details and the like.

Re: Dijkstra on Haskell and Java (2001)

#75

Post by Retra »

pjmlp wrote: post #56
alayne wrote: post #45

Earlier quoted context omitted.

You can do functional programming in Lisp, but even the wiki page for GOAL says "GOAL encourages an imperative programming style". Not to mention most Lisp data structures being mutable if we're talking purely functional.

I have a problem with modern notions of purely functional. My first functional programming language was Caml Light, back in 1996. Followed by Prolog and eventually Lisp. All alongside traditional lambda calculus and logic proofs, with ocasional references to a programming language called Mirada. So for me, Lisp is functional programming and I don't buy into this modern notion that only Haskell is the poster child of…

I looks like alayne is using 'purely functional' to mean Pure + Functional, but you are using it to mean Everything is an Expression / First-class functions, etc.. The functional paradigm.

Lisp is definitely a functional language. It's just not as pure as Haskell, which is the poster child for Maximally Pure FP, if not for the functional style.

Re: Dijkstra on Haskell and Java (2001)

#76

Post by Retra »

navait wrote: post #29

As much as I love Haskell, one problem with the intro to CS courses is that many of the students are not CS majors, but students from other disciplines that need to learn a little bit of programming. It makes sense here to teach Java and Python, as imperative languages are more useful to real world programming than functional languages. Perhaps it would be better to create a separate intro course for CS majors. On th…

I've always dreamed of building a programmable calculator that runs a lightweight Python (or Haskell) interpreter to replace all that obsolete TI crap that most schools use. I would have loved that kind of thing as a kid.

Re: Dijkstra on Haskell and Java (2001)

#77

Post by GeneralMayhem »

martin1975 wrote: post #61
aidos wrote: post #40

Earlier quoted context omitted.

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

I'm not the person you're addressing, but - yes, you're wrong. (And an asshole to boot, but that's another issue.)

"Getting a job" has absolutely nothing to do with "serving others," except maybe in the slavery sense of "serving," depending on your politics. The point is that universities are supposed to be dedicated to knowledge and understanding for their own sakes. It's not about "looking good," and I have absolutely no idea where you got that from. It's about learning, in whatever way best expands your understanding of the world, yourself, and the absract.

Re: Dijkstra on Haskell and Java (2001)

#78

Post by GeneralMayhem »

hnriot wrote: post #35
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…

I'm not sure pointer concepts are very difficult, pointers might confuse people that didn't grow up with assembly language, but they really aren't very hard to understand and they are also less and less relevant. Over the years the abstraction level increases, it's far better to teach people to continue computer science to the next 21st century level, not go over stuff from the 70's again that they will likely never…

You cannot write effective code in Java, Python, or C++ without understanding the difference between references and values. You can certainly stick to higher levels of abstractions - most functional languages do a good job of that, especially ones like Haskell that emphasize immutability and value-only semantics - but pointer concepts are absolutely relevant to the industry-standard languages.

Re: Dijkstra on Haskell and Java (2001)

#79

Post by TazeTSchnitzel »

cheepin wrote: post #39
brianchu wrote: post #34

FWIW, UC Berkeley's intro CS course sequence goes through the following languages in order: [Scratch (in an optional gentle-intro CS course)], Python (with an emphasis on using it for functional programming), a tiny bit of Scheme, a tiny bit of SQL (before they used a toy logic programming language), Java, C, MIPS assembly. I think this walks down the ladder of abstraction very nicely.

Odd to use Python as your intro to functional programming, since it lacks many functional programming features besides lambdas which the language creator doesn't even like ( http://www.artima.com/weblogs/viewpost.jsp?thread=98196 )

Python is more object-oriented than anything else. It's not terribly functional. Most tasks that can be accomplished with functional programming in Python aren't.

Re: Dijkstra on Haskell and Java (2001)

#80

Post by lostcolony »

dkersten wrote: post #49
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…

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…

For me the block for a long time for monads was understanding how they made IO possible.

That is, the basic ideas for things like a Maybe or similar were obvious and intuitive to me, and everyone software dev for long has done such things, even if they never think about what parts they could refactor out into something reusable.

But the leap from that to how it makes IO possible without side effects I just did not grok. It really only clicked reading something or other that described (admitting it was lying a little bit) the IO monad as something that threaded the state of the world through the program; that is, that world state becomes both an (invisible) input and output for functions, and so effects on it are fully encapsulated by the param(s) and return type of the function.

Post reply on HN