Live data from Hacker News

Dijkstra on Haskell and Java (2001)

chrisdone.com

101–110 of 253 posts

Re: Dijkstra on Haskell and Java (2001)

#101

For serious students of the subject, kicking off with an unusual language can be helpful. As another noted: if the student hasn't even started programming prior to college, s/he is likely not of a succeeding mindset as the bulk of other students already grasp programming. Starting college, I'd already learned assembler, BASIC, and Pascal - all what Dijkstra was warning against over-ingraining; proceeding to C would h…

"if the student hasn't even started programming prior to college, s/he is likely not of a succeeding mindset"

Clearly it couldn't have anything to do with a lack of access to resources, or simply developing an interest in programming later in life than you.

Starting later may make them less likely to succeed, but saying that it is probably because they don't have a "succeeding mindset" is quite a privileged sounding generalization.

Re: Dijkstra on Haskell and Java (2001)

#102

Ugh, is this a guy who learned his CS from reading Proggit? There's no way you can say Haskell is "orders of magnitude better than Java"; maybe it's better, but it's not that much better.

It's a transcript from Dijsktra's letter.

Yeah, I know.

Dijstrka is pretty famous for picking the wrong side of fights about programming languages.

Re: Dijkstra on Haskell and Java (2001)

#103
I tend to think Java is a good first programming language, much like Basic and Pascal were the "first programming language" for so many of us back in our youths. Not every high-school offers programming, and of the ones that do there's no guarantee students have actually been properly introduced to programming.

And like all "first programming language"s, it should be discarded as you learn proper languages.

2001ish-era Java was a fine vehicle for introducing programming. Just not much else.

The second programming classes should move in both directions away from Java - to properly academic and expressive languages like Haskell, or getting their hands dirty with the nitty-gritty of C and assembly languages.

Re: Dijkstra on Haskell and Java (2001)

#104
post #98
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 think you are placing too much emphasis on the start of one's education. Pick a place in the stack. Start learning. Over time you should go up and down the stack, building understanding as you go. This can be done from many places in the stack.

That may be true, but it will not be until you descend the stack you start to code like someone who understands what they are doing. For instance I started off with PHP in high school and was using arrays with each entry as a string with a colin in it to split a key and value apart. So essentially I created the worlds worst hashmap and each lookup was O(N) - not to mention the actual string splitting I was doing on each element which would've most likely caused several memory copies.

Why not at least start with some basics at the bottom of the stack and ascend quickly? As Dijkstra mentions he believes a lot of people have had at least small exposure to programming prior to their tertiary education - hence they probably already started at some point in the stack anyhow.

Re: Dijkstra on Haskell and Java (2001)

#105
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…

Your idea about going from architecture to programming in the other way of traditional curricula, in my opinion, has a lot of merit. Other seem to agree.

An Israeli professor, Noam Nisan, created a course specifically for this purpose, now branded even more popularly as Nand2Tetris course and book.[0]

Why did he teach something obvious like this? From the site:

"Why Bother? Because many CS students don't understand how computers work; because fewer and fewer students take compilation courses; because many computer architecture courses are too detailed and too dry; because nothing beats the thrill of creating something from almost nothing; because Nand2Tetris engages students in implementing some of the coolest algorithms, data structures and techniques in applied computer science, and because the typical student feedback in Nand2Tetris courses is 'the best course I ever took'."

My first exposure to this was at a hackerspace in my area, where far more experienced programmers than I were wrestling with this "hardware and low-level OS layers were a black box" that ever more complex systems and programming environments have created.

I remember being the first time in a while, as an IT guy who plays with open source a lot, I got real enthusiastic even though it was rough for me (I never had a chance to finish). I encourage everyone to look into, because it was designed by Nisan specifically to address the deficiencies you had mentioned, and I watched a lot of skilled hackers fall in love with computers again because of it.

[0] http://www.nand2tetris.org/

Re: Dijkstra on Haskell and Java (2001)

#106
post #98
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 think you are placing too much emphasis on the start of one's education. Pick a place in the stack. Start learning. Over time you should go up and down the stack, building understanding as you go. This can be done from many places in the stack.

But many don't do this. Only true artisans due. I did not have this opportunity in college to be taught other way.

I stayed a language major. In hindsight, I would have changed majors, at least double-majored with this kind of curriculum and a few years later with my flirting with Linux. It would have shifted my curiosity in the right direction.

I can do basic Python and Perl programming (not to mention the terrible days of PHP and ColdFusion days in my student jobs), but even as an IT guy I routinely feel I never know enough.

And I am the only IT guy I know, not to program but just to understand, by the Sysinternals Windows Internals 900-pager to even try to get there. And that is just for Windows, which is not even worth it IMHO.

Re: Dijkstra on Haskell and Java (2001)

#107
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…

> CS students I think CS students should be taught computer science, not software engineering.

Well the C does stand for computer.

Re: Dijkstra on Haskell and Java (2001)

#108
post #67
post #34

Earlier quoted context omitted.

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

The students would learn a lot though. Most CS courses will give theory and practice for algorithms etc, but only give theory for software design. Trying to teach a student how and why it's important to encapsulate logic is generally a losing battle until you put them in a position where it makes sense. It's just a theoretical topic (that sounds like a religion) to not have global state until you dump the student in with 100 others all declaring global state. Same for namespaces and interfaces.

It would be a really interesting experiment even: divide up a big problem into 100 or so features and assign each feature to a random person. Give the students some time to work out who they need their code to communicate with and draw up some simple interfaces. Use github or similar with an account for every student. Make the TAs in charge of accepting pull requests. It could be the main focus of a software engineering course.

EDIT: The students wouldn't necessarily need to work with all 100 others - only the ones whose feature their feature interacts with. eg, 1 student could need to receive input from 5 inputs and calculate some statistics - he would only need to talk to the 5 students who would feed him data, and then talk to the 1 student he would feed data to.

Re: Dijkstra on Haskell and Java (2001)

#109
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…

Mostly speculation: Successful CS students are by nature inquisitive. They tend to ask the questions "how does this work." They aren't humanoid computers that need every concept spoon fed to them. Semester one doesn't need to teach the stack from high-level languages to quantum mechanics. It needs to get them thinking about basic concepts such as encapsulation, abstraction, and type safety.

Re: Dijkstra on Haskell and Java (2001)

#110
post #56
post #49

Earlier quoted context omitted.

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…

And you realize that machine code has to be translated to how electrons are routed right? Do you have a good understanding of how that works? Embrace abstraction folks.

Yes. Yes, I do. And it makes a tremendous difference.

Abstractions are an absolute necessity without which we could never have built a computer. And may be fine to stay at one level of abstraction for day to day stuff. Knowing the levels below and above however makes it possible to not only use the current one better but to also to navigate the hierarchy and use the best abstraction for a specific task. And design new ones if necessary.

Our CS courses provided exactly this: We looked at single transistors, programmed microchips, implemented a CPU on a FPGA, toyed with kernels and drivers, walked trough the OSI-layers, wrote a compiler, a static code analyzer, used monads and the lambda calculus, learned about turing machines and different computing architecures, abstractions, models and beyond.

It really helps to have the 'whole' picture.

Post reply on HN