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

101–110 of 124 posts

Re: Dijkstra on Haskell and Java (2001)

#101

Post by aidos »

GeneralMayhem wrote: post #77
martin1975 wrote: post #61

Earlier quoted context omitted.

"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 absolut…

That's exactly the spirit in which I was meaning it and there's not much more to add really.

Re: Dijkstra on Haskell and Java (2001)

#102

Post by cdelahousse »

jagger27 wrote: post #43
johnloeber wrote: post #21

Earlier quoted context omitted.

They actually do this at the University of Chicago. That's exactly the introductory sequence. The first class in the major is in Racket (Standard) or Haskell (Honors). The second class in the major is in C, and also covers basic UNIX tools. The third class is in x86 assembly and C, focused on understanding low-level systems.

I wish I was there. My curriculum at Carleton University is 1. Intro to CS in Python ending with a taste of Java 2. Java 3. C (intro to UNIX) 4. C++ (design first, implement after, waterfall, etc.) Along with 3 there is data structures taught in Java [0] and with 4 there is web dev taught in Node.js. 0: Following this text: http://opendatastructures.org/ Taught by its author, Dr. Pat Morin.

Actually, the first class is now Java and C++. Morin isn't teaching Python any more.

"Functional" programming is taught in third year (COMP 3007), but you don't get too deep into it.

My issue with the listed classes isn't the chosen languages. A commenter mentioned that you can learn a lot of functional (and other) concepts in a procedural or object oriented language. My issue is that I basically learned the same concepts over and over again, just using different programming languages. You learn to iterate over a multidimensional array in Java, and then you do so again with C, but you have to deallocate and reallocate, and then you do it in C++, but you create an object for the array. It's all the same stuff.

Re: Dijkstra on Haskell and Java (2001)

#103

Post by acallan »

SilasX wrote: post #81
acallan wrote: post #74

Earlier quoted context omitted.

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

I'm not disputing the scaling properties of the Haskell one-liner, but it doesn't give you the benefits of the true QuickSort as your comment suggests, e.g. it doesn't guarantee in-place sorting or efficient use of when access be locked. The point is, I find it questionable to praise Haskell for how you can implement a one-line QuickSort that isn't really a QuickSort.

Each list comprehension is O(n). O(n)+O(n)=O(n). Each iteration will roughly bisect the list, resulting in roughly log(n) iterations. Thus the one-liner is O(n*log(n)).

Haskell says nothing about how lists are implemented, so with respect to "true"ness (I'm not really sure what this means), we can cannot generalize. A sufficiently optimized Haskell compiler implemented in silicon would have the liberty of using the memory in-place.

Re: Dijkstra on Haskell and Java (2001)

#104

Post by SilasX »

acallan wrote: post #103
SilasX wrote: post #81

Earlier quoted context omitted.

I'm not disputing the scaling properties of the Haskell one-liner, but it doesn't give you the benefits of the true QuickSort as your comment suggests, e.g. it doesn't guarantee in-place sorting or efficient use of when access be locked. The point is, I find it questionable to praise Haskell for how you can implement a one-line QuickSort that isn't really a QuickSort.

Each list comprehension is O(n). O(n)+O(n)=O(n). Each iteration will roughly bisect the list, resulting in roughly log(n) iterations. Thus the one-liner is O(n*log(n)). Haskell says nothing about how lists are implemented, so with respect to "true"ness (I'm not really sure what this means), we can cannot generalize. A sufficiently optimized Haskell compiler implemented in silicon would have the liberty of using the m…

>Each list comprehension is O(n). O(n)+O(n)=O(n). Each iteration will roughly bisect the list, resulting in roughly log(n) iterations. Thus the one-liner is O(n*log(n)).

"I'm not disputing the scaling properties of that sort" = this proof does not convince me of anything I didn't already agree with. Was I unclear about what I was objecting to?

> Haskell says nothing about how lists are implemented, so with respect to "true"ness (I'm not really sure what this means), we can cannot generalize. A sufficiently optimized Haskell compiler implemented in silicon would have the liberty of using the memory in-place.

"Trueness" means "doing the real QuickSort". The one you posted doesn't. You can get the real QuickSort, but not with one line. A better compiler might identify useful invariants; you were not using such a compiler.

But if you had such a compiler, you wouldn't need to write I that way; you could just specify what conditions the final sort would obey, and that would be enough. You wouldn't need to tell it to filter explicitly.

Re: Dijkstra on Haskell and Java (2001)

#105

Post by [deleted] »

nbouscal wrote: post #87
jfaucett wrote: post #63

Earlier quoted context omitted.

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…

You're demonstrating that you don't know what monads are. "Type wrapper function" could mean any number of things (lack of specificity is a bad trait in naming), but it couldn't mean a monad: monads consist of three things, whereas "type wrapper function" implies one thing. Names don't need to be metaphorical. The purpose of a name is not to teach you what the thing is. For that, you should have a proper explanation…

[deleted]

Re: Dijkstra on Haskell and Java (2001)

#106

Post by dkersten »

runT1ME wrote: post #73
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…

> 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'

Sure it does - you execute code in the context of a monad. In the case of the State monad, your code executes in the context of a stateful environment.

Re: Dijkstra on Haskell and Java (2001)

#107

Post by dkersten »

ddellacosta wrote: post #90
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 don't know if I can agree with this. I've invested a significant amount of time in learning about monads (and functors, applicatives, monoids, and more from the bestiary of commonly used category theoretic structures in Haskell) and I find them quite challenging to grasp in their full generality. While specific use-cases are readily understood, getting to the heart of what a monad "is" has taken me time, and I hone…

Absolutely there's a spectrum and I certainly don't fully understand the full set of category theoretic structures (I'm slowly trying to learn, but.. its slow going). I just think that monads as programming constructs are quite simple. I don't doubt that in a full mathematical context there is a hell of a lot more to them and the mathematical reasoning behind how they work is surely beyond my understanding, but from a how they work, how to use them, how they interact with the language and what they enable you to do point of view, they aren't difficult at all.

Re: Dijkstra on Haskell and Java (2001)

#108

Post by dkersten »

lostcolony wrote: post #80
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…

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

That's a fair observation and I admit I didn't consider that when I wrote my comment. It is pretty difficult to visualise and leads to a lot of "but you still interact with the outside world so how can it be pure" kinds of confusion. Its very hard to visaulise how the program essentially gets wound up and then at runtime as IO occurs gets unwound. Some of the other monads are definitely simpler to understand!

Re: Dijkstra on Haskell and Java (2001)

#109

Post by dkersten »

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.

I was kinda thinking of F#'s Computation Expressions when I posted my comment.

Re: Dijkstra on Haskell and Java (2001)

#110

Post by dkersten »

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…

We should call things what they are.

Sure - I wasn't seriously suggesting we rename them, just that in my personal experience, newcomers get scared off seemingly by the name alone before ever actually finding anything out about them. A friendlier name may avoid this for newcomers. It definitely wouldn't be worth it for more advanced practitioners where referring to them exactly and in the context of their category theory roots is much more useful than friendliness.

Post reply on HN