Live data from Hacker News

Dijkstra on Haskell and Java (2001)

chrisdone.com

61–70 of 253 posts

Re: Dijkstra on Haskell and Java (2001)

#61
post #49
post #38

Earlier quoted context omitted.

Your first paragraph seems to be entirely nonsense. Almost everyone was first introduced to a high level language. This did not prevent anyone from understanding that those languages are themselves software, written by people. In fact, you generally have to take a whole course on compilers.

Knowing the single fact that a language is ultimately a piece of software is different from having an intrinsic understanding that each high level construct has to be somehow translated to what the computer can do. Everyone learns the fact "compilers provide programming languages" pretty quickly, but beginning programmers don't get early enough into the habit of thinking how what they write in a high level language t…

That is a lovely hypothesis, but I believe testing it would falsify it.

Re: Dijkstra on Haskell and Java (2001)

#62

Earlier quoted context omitted.

Just because you should not explain to students what "public static void main(String[] args)" is the first day does not mean that you can never teach them. Actually, if your students cannot understand what this line is after one full class of Java, then the problem is with the teacher, not the students.

> Actually, if your students cannot understand what this line is after one full class of Java, then the problem is with the teacher, not the students. I think you're dead wrong about that. Assuming somebody with no programming background at all, here is a (definitely not exhaustive!) list of things that must be learned in order to understand that line: Method visibility, what is a "method", what is a "function", what…

Plus, each of those concepts needs a motivation and a context in order for it to stick in their minds.

Re: Dijkstra on Haskell and Java (2001)

#63
post #42
post #33

To me there seems to be something wrong with using as the first language something that depends on a very, very complicated runtime and execution model to run on the hardware we currently are using. This way people end up viewing programming languages as some God-given black box and not just something another computer program written by another person provides for you. I think CS students should instead start by lear…

I disagree. The whole point of abstraction is that you don't have to care about the underlying mechanisms (although most non-trivial abstractions are leaky as Joel Spolsky has written about). For instance, someone who writes assembly should not have to know how a transistor works. A course in introductory programming similarly should not be about how a processor works.

It's trivially easy to write perfectly valid looking Haskell programs that are abysmally slow because of how they are actually executed, and since the reason for this can't be explained at a level of abstraction of such a course, people learn to treat the language as a closed black box, while you can't really competently use any language without understanding its execution model.

Abstractions are fine, but you have to be able to switch the abstractions level when necessary and understand the bits underneath, and I think it's natural to learn starting from low abstractions level and then building up. There are many basic low level issues that surface no matter how high level is the language you are using, I am not advocating teaching assembly to beginners, but a language like C and issues like:

- Direct addressing vs. indirect adressing, aka storing a value vs storing an address, aka pointers vs. values, aka call-by-value vs call-by-reference, ... Beginning programmers brought up on very high level languages are endlessly confused by the difference between copying the value and copying the reference.

- Understanding the stack and how procedure calls work. It might then be easier to understand why tail recursion in functional languages is cool but non-tail recursion not so much.

- Basic memory management. Why data structures are such a big deal.

...

All this shows why abstraction is necessary and useful in the first place, and what it's limitations are.

Re: Dijkstra on Haskell and Java (2001)

#64
post #9
post #3

A problem I've noticed in my degree is that for a certain percentage of students Java just doesn't stick. I'm in my fourth year now and there are plenty of people who just can't program, because they've only been taught Java, and they didn't get that. It's far too big a language to teach in a semester or two to a previous non-programmer. Even if it does sink in they rapidly find that the simplified Java being taught…

Java is definitely a terrible language for teaching and as a student's first introduction to arrays, memory handling and flow control it's pure terrible. However, Java is incredibly effective as a language for large teams. Since most of the companies coming to hire CS grads are big teams in need of extra hands on their software projects, they are looking for CS grads who know Java. So Java in universities is generall…

Up until about a decade ago, most CS graduates from MIT were never taught C or Java in any class. They still seemed to do pretty well in the job market. (Mostly it was assumed that if you really liked software development, you would go out and learn one of those languages outside of class, such as from a student-led seminar.)

Re: Dijkstra on Haskell and Java (2001)

#65
post #16

Dijkstra assumes that students will already have been exposed to imperative languages before joining university, and will appreciate the change. I think that this assumption might leave behind students that have not yet been exposed to any programming (that stuck). Over in the UK I certainly hadn't encountered anything more complicated than html before I hit university, and was very happy with sticking with Java for…

Please, don't get me wrong, but why would someone with no programming experience pick compsci?

It's not exactly a sexy career (for every übergeek in shorts with a Macbook Air there is an army of corporate drones with comporate-issue desktops using whatever tools corporate IT mandates, wearing corporate-standard neckties), it's difficult (to do it right) and financial return is far from assured.

Re: Dijkstra on Haskell and Java (2001)

#66

Around the same time, my alma mater was switching from Scheme to Java for their introductory courses. Last time I went back to homecoming, it seemed that most the professors were feeling pretty dissatisfied about the decision. One of the big reasons mentioned was that Java's just too big and hairy of a language. They end up spending all their time teaching API quirks and software engineering principles (such as prett…

Same here. There are two camps in my "alma mater". Those that think that students should learn programming with a simple and "clean" language, and those that think students should focus on widely used languages.

They too abandoned Scheme which means that student don't learn any functional language. I think it's a shame considering that functional paradigms are getting more and more commonplace. (However, I much prefer OCaml to Scheme).

Re: Dijkstra on Haskell and Java (2001)

#67
post #34
post #11

Earlier quoted context omitted.

> Java is definitely a terrible language for teaching and as a student's first introduction to arrays, memory handling and flow control it's pure terrible Sadly, teaching OS classes with Java is a thing: http://www.amazon.com/Operating-System-Concepts-Abraham-Silb...

That's not really a bad thing. First, no beginner is going to be learning about coding OSes so teaching the basics isn't a problem. Secondly, Java OSes are far more common than you'd think, although this was more true of 5 years ago when many phones/smartcards/etc used Java in their OS internals. A lot of the topics in OS concepts would probably be useful if you wanted to hack on OSS Android too. So I don't think the…

> It's a shame more classes don't actually just have all 100 students work together on a single code base - it would be incredibly beneficial

I up-voted your comment as a whole, but I really disagree with this statement. It's reality in many situations, but I think it's a shame that anyone has to work together with a team of 100 on anything, ever. You deal with it, and you solve the problems associated with it, but those are problems of management and process.

Re: Dijkstra on Haskell and Java (2001)

#69
I do most of my programming in Java and I'm convinced I want to learn functional programming, just to broaden my thinking. What are some considerations regarding starting with SICP book/Scheme vs. Scala vs. Closure vs. Haskell?

Re: Dijkstra on Haskell and Java (2001)

#70
post #51
post #39

Earlier quoted context omitted.

It may be turning around now, but applicants for compsci at Cambridge were apparently getting pretty dire by 2006, and this formed a significant part of the motivation for the Raspberry Pi ( http://www.raspberrypi.org/about ) > The idea behind a tiny and cheap computer for kids came in 2006, when Eben Upton, Rob Mullins, Jack Lang and Alan Mycroft, based at the University of Cambridge’s Computer Laboratory, became co…

Strangely I found myself struggling to pick up Standard ML despite having experience in C++ compared to my peers with no programming experience. It seems that they just treated it as math, while I had trouble changing my imperative programming mindset. Also Larry Paulson is a legend.

In case you're not learning from it, allow me to 'advertise' Coursera's proglang. A third of about sml (after racket and ruby) and it was pure joy, the language core and syntax is very tiny (unlike it's type error messages hehe).
Post reply on HN