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 learning basics of computer architecture at a high level and programming on a level close to the computer architecture that so far has turned out to be practical, the Von Neumann machine. This way they can understand the whole field better, if you never face the challenges of organizing computations in a computer without many existing layers of abstractions designed by other people, you will never understand the development of the field and how the disciplines of algorithms, operating systems, computer architecture, etc came to be the way they are, too many things are taken for granted by people who have only seen very high level languages.
People should know what the stack is, how function calls works, what is an assembler, what linked lists, binary trees, hash maps, ... are and why those had to be invented etc. I think something at the level of Go or C is best for that. Then I think a good moment comes for a course like SICP where people can learn how to take those pieces and build abstraction layers out of them.
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.
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.
I'm an advocate of assembly language on microcontrollers being an introduction to programming. PICs are great because they are cheap, basic tooling is cheap, and the instruction set is small.
It gives a student a period of getting familiar with computers as machines, rather than brands or software stacks. Plenty of time in the rest of your life for that.
>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.
Computer Science is more than just programming. There is a lot of formal theory underpinning this area that has nothing to do with circuits, transistors and microprocessors. CS departments shouldn't just be concerned with training programmers, but also scientists.
My experience of teaching is that a little knowledge of assembler is a dangerous thing when it comes to modern programming. Writing good code for a modern amd64 processor with deep pipelines and vector instructions has almost nothing to do with teaching simple assembler. Students often get the Idea they should do things like limit the number of local variables they use, not realising c or c++ compiles will turn their code in Single Static Assignment almost straight away.
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.
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 pretty much the entire subject of OOP), leaving little time to focus on much more important basic skills such as breaking a problem into smaller pieces and attacking a problem in an organized manner. Or even simple stuff, like the difference between a value and a variable. They also lamented the loss of a REPL, which is an invaluable tool for enabling (and encouraging) students to experiment and get a better understanding of how a programming language actually works.
For my own part, I wonder if the current cultural unfashionability of OOP isn't somehow a result of the vogue for switching CS programs over to Java around the turn of the century. I find myself thinking that what a lot of newcomers to FP seem to think of as problems inherent to object-oriented programming are really just problems inherent to not having worked your way through SICP during your formative years.
I had my formative education based on SICP and I can confidently say it made me a better (Java and other) programmer. I work with Java every day and I am very productive with it, but teaching it as a first language is foolish imho.
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).
I went to the University of Texas right before they made this change and I will say that my Programming Language course using Haskell was one of the toughest classes I took there.
I was barely a novice at an imperative language, and all of a sudden I had the comfortable struts of local mutable state ripped out from under me. Having to solve most problems via recursion was incredibly challenging at that stage and I'd be lying if I said I left that class feeling like I understood Haskell.
That course did have the desired effect that Dijkstra was hoping for though. I never programmed functionally in my coursework after that, but it stuck with me and the feeling that "there is something different out there" in the programming language world has forced me to never be satisfied with one language or one approach to solving a problem in my professional life since then.
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 at first year undergraduate level is far below the standard required for real world Java programming.
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 generally the ivory tower being forced by business constraints to adapt to outside business interests.
My university down here taught in Scheme for the introduction and theory classes, and in Java for algorithms and networking. Seemed to work well as a balance, although I'm not sure if they still do that.
I think there are 2 ways of teaching programming at the beginning, although I'm not sure which is best.
1. Teach structure and organisation of programming. - Python is a good for this as it's object oriented, but has very little boilerplate and syntax getting in the way of learning. A few universities have done well using Haskell for this instead, and I think that's quite a good option, particular as it introduces types.
2. Teach from the perspective of how a computer works - C is probably the best one for this as it helps students understand how computers work at a more basic level, being closer to assembly and machine code. It also allows for memory to be thought of as a much more basic resource of the machine that users must manage.
Java would be good for teaching data structures and algorithms, but I don't think that should come until after an introductory class using one of the above methods.
That's a problem regardless of the specific language taught first and I say that having personally witnessed the struggles of students who learned in pseudocode (my first semester), Java, Python, and Scheme. Programming requires you to structure your thinking a particular way. It's natural for some people, it's unnatural for others. I tutored a couple dozen people of varying aptitudes through the courses as an undergrad and was suprised at how little a difference Java vs Python made.
I do think that there are better ways and worse ways to teach programming. Brett Victor put out an overview [1] of the topic last year and while that essay in itself isn't the answer, it's at least a better start than anything I ran into as an undergrad.
I already had math research experience with C when I finally took my schools introduction to CS course, and had wrapped my head around pointers and recursion. Java just felt like memorizing a bunch of strings and exceptions.
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 the entirety of first year. I had been exposed to C++, ADA(!), Prolog and had an in depth look at Erlang by the time my course finished...
I think that this assumption might leave behind students that have not yet been exposed to any programming (that stuck).
Let me provide some anecdotal counter-evidence: during my last year of high school, I was in a university class where they taught us programming using Haskell (this was in 2000). I observed a fairly consistent pattern - those who had prior experience with imperative programming (me included), had far more difficulty picking up Haskell than those who hadn't.
The girl I worked with (who had no prior experience) was surprised, since "it's just like maths" :).
Despite the fact that I learned imperative style first (as most have) -- I think that functional programming is also a valid start point. I don't know that you necessarily benefited from starting in Java/some other procedural language.
I actually graduated from UT's Comp Sci school and I know many of the "elements" courses (super introductory, even for non-majors) are taught in python. That, I think is a good introduction, but for people in the major, I don't think learning Haskell/functional programming is a stretch at all.
If one can wrap their minds around functional programming (which introduced correctly is actually relatively easy to grasp) -- it will be MUCH easier to learn imperative programming. In the end, any good imperative programming seeks to be modular (s/procedures|methods|subroutines/functions/g), and will liken itself to something you would write in functional programming (loosely couple functions that do a specific task well). Yes there are places this gets hairy (side effects, I/O based operations), but computer science is not about writing procedural code, it's really more about algorithms, which is why 4 year universities are NOT trade schools, but do prepare you for the real world (in that you're not COMPLETELY useless). Program syntax is easy to learn (a skilled faker can just repeat it verbatim), efficiency/correctness/proper data-structure usage is difficult.
I spent my first few undergrad years as a CS major at UT before this change happened, and had no prior experience with programming (I started in '97).
The INTRO-intro CS class at the time actually used Pascal, and was endlessly confusing to me as a cold beginner.
My next course, however, was taught in Scheme, and immediately I felt more at home. And for the first time, I felt like I might have some actual aptitude for programming.
Without that peek into the elegant heart of computer science, I doubt I'd have stuck with it as long as I did.
My old university has a big partnership with MIT, and the first programming course is, I believe, similar to MIT's.
I learned programming with Scheme, in that course, in 2004. I used, without noticing, many techniques I would later have relearn due to a "prolongued exposure to imperative programming". In my semester I used closures, functions as first class objects and lots of recursion.
The following three semesters I forgot all that, for I had to use C, C++ and Java. When, in the fourth semester, I had my AI course in Lisp, I used "let"s and loops for everything. In the middle of the semester, I remembered recursion, and how it made everything better (in Lisp). Later, by myself, I relearned closures, functions as first-class-objects and other stuff.
Having Scheme as an introductory language is good because it put students that came from a IT-technical high-school education equal to general high-school education students (that have never seen programming before). With the "real world" so drowned in imperative programming languages, there are few courses that can justify using a functional programming language. The things I know about FP, I know because I thought myself.
I'm not saying FP is better than imperative programming, is just that both should be (well) taught. (As some other paradigms too, I believe).
Some years ago my old uni, like MIT, changed from Scheme to Python. Python is my favourite programming language. But I'm still not happy with the decision.
As much as I enjoy Dijkstra's wit in general (and I agree with the argument for learning functional languages early), I imagine taking a shot at "Texas's solid conservatism" didn't help his case all that much. For "enlightened" individuals, most left thinking and academic people are really no better at mitigating tribalism, prejudice, and ignorance of other points of view than the far fringes of the right. Perhaps it would have been more effective to appeal to the self interest of the council.
I can't help but notice that the vast majority of commenters are missing the fundamental reason for all this handwringing. The reason isn't language schism (that too, but I'd attach a much smaller weight to it) so much as the schism between corporatism & academia.
Corporate America wants languages that are dumb, easy for corporate drones to assimilate, hard to mess up with, verbose ( verbosity is misinterpreted as documentation in the enterprise) and Java fits the bill from the get-go.
So Java became that. Rather than go down the R&D route, the pipeline became more corporate America oriented.
Haskell has always had very deep roots in academia - the focus on enabling the corporate American drone with Haskell is minimal, close to zero. So what do you expect ? The focus will be on debating types & building theorem provers, not on "how to show big bank's fourth quarter report in 3 colors with 7 columns and subtotals in single widget while data-binding seamlessly occurs in middle tier using enterprise beans built from beanfactoryfactory" - this sort of shit that is commonplace in the Java EE world I inhabited post Sun, would be considered positively gauche in Haskell.
Totally! Djikstra was very aware of this influence and pokes only somewhat subtly at it here. Djikstra believed very strongly in inventing the next group of well-armed intelligent computer scientists—scientists tackling the hardest problems humans have yet discovered by his view. His goals are vastly maligned with what corporate America wants and the choice of language is a tool in the war between those interests.
Exactly. Tooling is extremely political. Do you want to use tools with a low skill ceiling? Are you a control freak who worries about the all of the potential catastrophes that unskilled coworkers could rain down on you?
Perfectly put. I'm having to take a VB.net course to advance to the next level of my high school's CS curriculum, if you could even call it that.
It's painful as hell, and like you said, makes me feel like a corporate monkey who's writing some ugly code for use in some specific pants-on-head retarded enterprise "app."
The worst thing I have observed is colleges choosing Java (and C#) "because that's what the market demand".
When I was in college (1986, engineering, not compsci) students started with 8-bit BASIC and FORTRAN (I mostly skipped classes on BASIC because I had learned to program on my Apple II). One year later, they switched from BASIC to Pascal. Later on, one of the teachers decided to teach APL. It was a wonderful experience because it was a different take on my previous paradigms.
I am not sure what is the best way to teach someone how to program. When I was a kid, you turned your computer on and immediately got to a REPL (one Dijkstra would strongly disapprove, but still a programming environment). IMHO any programming language that demands an IDE or a build system more complex than make (even if hidden behind a shiny GUI) should not be used as an introduction. Paraphrasing Dijkstra, it could damage the young minds beyond repair.
If my Apple II booted into Eclipse, I'd have gone into cinematography.
One of my favorite things about heaving to learn Scheme in my intro CS course was that it put most students on an even footing with regards to already (not) knowing the language. It's awesome to see Dijkstra alluding to that, "it drives home the message there is more to programming than they thought."
I'm having a ball learning Clojure now, and it would be much much harder if I'd never used Scheme. (I've done some functional programming in C++ and Ruby, but I wouldn't have done that if I hadn't done it in Scheme earlier.)
My personal opinion - the best languages for learning are script-able, dynamically typed languages like Ruby or Python. You can build very basic programs in a procedural or functional style, and then get introduced very softly into the world of OO.
Haskell is great in some ways, terrible in others. Like the fact that you can't apply a normal function to a monad, and monads are hidden with do <- syntax, so you need to use monadic functions, and then there's type classes and shit... In Haskell it seems the complexity goes up exponentially and building anything beyond trivial is a huge hassle - no wonder 'design' patterns like FRP seem to be all the rage (while the entire computing landscape is being built on languages like C++ and Java).
Lisp/Scheme are conceptually very simple and easy to learn, but the syntax is hard to follow, and some of the keywords make no sense to someone who's never done any programming.
I personally think Ruby -> Java/C++ would be a great progression, with maybe some SML/OCaml on the side somewhere along the way. I spent way too much time dabbling in various 'trendy' languages like Clojure, Haskell, various Lisps and other FPLs, Ruby and JS/Node, etc... Now I'm at the point where I just want to build things, so I'm using a very practical, OOP, statically-typed, compiled language that many people have already shipped many practical apps with.... Probably not going back to 'trendy' languages.
I agree that Haskell can be difficult coming from an imperative mindset (it is for me too!), and that it takes time to grok monads, but what exactly is difficult about type classes?
And what do you mean "design patterns like FRP"? I'm sure you know there are tons of design patterns that are "all the rage" for C++ and Java (a lot of them dealing with the complexity of doing OOP). Why are you giving those languages a pass?
The first programming language we learned at university was ML. It was a very simple language for teaching functional programming, it has a minimal syntax that makes some sort of sense and it was likely that everyone was starting off at the same point with it.
Like Dijkstra said, getting these high-level concepts in there early is very important.
I'm a wee bit confused by this. I graduated from UTCS in 1990 (the first time) and was a graduate student and employee of the CS department from about 1992 until 2004-ish.
At no time were the introductory classes in Haskell, to my knowledge.
According to the wayback machine[1], the introductory courses (CS307 at the time) in 2001 were in Scheme, while subsequent courses were in C++. I recall the introductory classes experimented with Miranda briefly.
On the other hand, the typed letter[2] is from the EWD archives. Weird.
I love Haskell and Java. From a high level they are my favorite languages for their respective paradigms, so I think most programmers should at least try to write a simple program in both.
That said, I think people are overreacting to Java as a CS 100-level language because of enterprise experiences.
I have written enterprise Java and I hate it, but I still love Java. Java EE is all beans and POJOs and XML and Swing and cruft and I want to burn it in a fire. But that's not Java, those are libraries.
Java is an excellent language to introduce someone to programming, because there is very little magic. Everything is explicit, due to the static typing and imperative nature. The computer (or JVM in this case) doesn't do anything that you don't tell it to do. That's easy for someone to grasp.
Additionally, Java makes it very easy to write readable, organized, and extensible programs even if they are verbose. Using classes, objects, methods, types, and all of that OOP stuff makes it easy to write modular programs where each piece of code does exactly one thing. In functional programming the intricacies of passing state and higher-level functions lead to a lot more spaghetti code for someone who has never programmed before.
Do I think that we should only teach Java? No, of course not. Do I think that it's still a great first language? Absolutely.
If I had control of a curriculum, I'd teach Java for half a semester and then Haskell for half of the semester. I think it's important to not introduce "more productive" dynamic languages like Ruby or Python until students have had to deal with concepts like types so that they can appreciate what Python and other dynamic languages are leaving out.
At Penn, where I go to school, the intro to CS class teaches OCaml in the first half and Java in the second. Unfortunately I think that so many people are struggling with writing code as a concept that they're too frustrated to appreciate the beauty of OCaml at first. Teaching it after something a little easier would make the advantages clearer.
We did half C/C++ and half Mathematica in parallel. For the project you needed to build a prototype in Mathematica and then implement it fully in C++ using a cross platform gui toolkit (Glockenspiel - this was quite some time ago). It seemed to work - for a functional language Mathematica was also fairly practical.
It's just my experience, but the people I know for whom Java was a genuinely first language seem to have a harder time than anyone else grokking pointers.
> It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.
I would guess Haskell would be perfect if the goal is to produce academics. But if most of your students are destined for industry, Haskell is in my opinion the absolute worst language.
- You'll probably get a high drop out rate because of the complexity (recursion, pure / first class functions etc).
- You rely that your students already have experience at high school with imperative languages
- The industry by far still don't use functional languages.
But then again Java is an equally bad choice, for the reasons mentioned, but also you jump immediately into OOP, again expecting the student to have former experience.
What is wrong with laying a solid foundation with the introductory class in C or Python, and then moving on to the more advanced OOP or functional worlds?
Here's a positive report on teaching "back to basics" first-semester programming with Java. They only teach procedural concepts and no OO at all. The point is, while Java itself is non-ideal for this and slants towards OO, you can just ignore that part and teach with it anyway.
Lots of people here have raised concerns that the way Java forces class and static declarations is confusing for beginners. Interestingly, the instructors were concerned about that too, but found that students don't seem to mind.
The second major concern being discussed here, that functional programming isn't possible in Java, I think is a non-issue for a true introductory first-semester class, which needs to focus on more basic issues of procedural programming and abstraction. The SICP approach is beautiful and great for already advanced and highly motivated students, but that's honestly a small minority.
(You can find many more examples of reports like this if you search for "CS1", which is the shorthand for intro-to-CS that's used in the CS education literature.)
Ah, I encountered this coming up when various friends were enrolling in computer science courses at Universities. Curriculum either followed an 'engineering' format, a more EE to CS bottom-up methodology, or they followed a top-down thought process.
The reasoning for bottom-up is that there are fundamental aspects of the bottom up approach that truly teach the fundamentals that are necessary to become a great computer scientist/engineer/developer that I don't think any other method provides.
But the top-down approach is appealing for one reason it seems: It's friendly. I would not be surprised if the retention rate for top-down was greater than the bottom-up. Using something like Python, Java, or whatever other conventional blackbox language is easy, comfortable, and immediately demonstrates to a student the power of programming. The practicality of what they learn is evident. Ideally, interest in this would continue down the line. 'This is really cool, but how does Python actually work?'.
Unfortunately, it seems that most people, when presented with a working blackbox, don't care to see how it actually ticks. It takes a certain special someone to open up a watch, disassemble and reassemble it. So who knows how well the top-down carries over into learning the fundamentals.
The bottom-up has the drawback of intimidating the meek. I certainly was one. I would have benefited from a top-down approach, as I am one of the types who like to see how something ’ticks’.
So therein lies a trade off, would you sacrifice the known quality of your curriculum for better retention? Having someone learn something, is better than nothing, but that’s up to people like Prof. Dijkstra to decide.
I think judging programming languages by their features is the same as judging people by their talent and not by their deeds.
Take Java for example. Most people (Dijkstra included) hate it. But look how much Java has accomplished. It's not a coincidence that Hadoop is written in Java. It's not a coincidence that Java is the primary language on Android.
To quote a great man: "Java works. Java captures the essence of the evolutionary spirit"
Same thing applies to PHP, Javascript, and whatever everyone hates.
Couple of years ago I thought that Java was the Devil's invention and the most awful programming language ever. Then I started using Java with Hadoop. And for the first week Java was the most awful programming language ever. Two/three weeks in I was absolutely okay with Java. It worked. And for me that's the only thing that counts.
[+] [-] stiff|12 years ago|reply
I think CS students should instead start by learning basics of computer architecture at a high level and programming on a level close to the computer architecture that so far has turned out to be practical, the Von Neumann machine. This way they can understand the whole field better, if you never face the challenges of organizing computations in a computer without many existing layers of abstractions designed by other people, you will never understand the development of the field and how the disciplines of algorithms, operating systems, computer architecture, etc came to be the way they are, too many things are taken for granted by people who have only seen very high level languages.
People should know what the stack is, how function calls works, what is an assembler, what linked lists, binary trees, hash maps, ... are and why those had to be invented etc. I think something at the level of Go or C is best for that. Then I think a good moment comes for a course like SICP where people can learn how to take those pieces and build abstraction layers out of them.
[+] [-] 616c|12 years ago|reply
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/
[+] [-] scott_s|12 years ago|reply
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.
[+] [-] btian|12 years ago|reply
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.
[+] [-] jimktrains2|12 years ago|reply
I think CS students should be taught computer science, not software engineering.
[+] [-] pessimizer|12 years ago|reply
It gives a student a period of getting familiar with computers as machines, rather than brands or software stacks. Plenty of time in the rest of your life for that.
[+] [-] macspoofing|12 years ago|reply
Computer Science is more than just programming. There is a lot of formal theory underpinning this area that has nothing to do with circuits, transistors and microprocessors. CS departments shouldn't just be concerned with training programmers, but also scientists.
[+] [-] CJefferson|12 years ago|reply
My experience of teaching is that a little knowledge of assembler is a dangerous thing when it comes to modern programming. Writing good code for a modern amd64 processor with deep pipelines and vector instructions has almost nothing to do with teaching simple assembler. Students often get the Idea they should do things like limit the number of local variables they use, not realising c or c++ compiles will turn their code in Single Static Assignment almost straight away.
[+] [-] cies|12 years ago|reply
I heard this idea before, sound interesting. Are you aware of any CS course starting with assembly as intro language?
[+] [-] asdasf|12 years ago|reply
[+] [-] bunderbunder|12 years ago|reply
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 pretty much the entire subject of OOP), leaving little time to focus on much more important basic skills such as breaking a problem into smaller pieces and attacking a problem in an organized manner. Or even simple stuff, like the difference between a value and a variable. They also lamented the loss of a REPL, which is an invaluable tool for enabling (and encouraging) students to experiment and get a better understanding of how a programming language actually works.
For my own part, I wonder if the current cultural unfashionability of OOP isn't somehow a result of the vogue for switching CS programs over to Java around the turn of the century. I find myself thinking that what a lot of newcomers to FP seem to think of as problems inherent to object-oriented programming are really just problems inherent to not having worked your way through SICP during your formative years.
[+] [-] wlievens|12 years ago|reply
[+] [-] yodsanklai|12 years ago|reply
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).
[+] [-] sebastianconcpt|12 years ago|reply
Or this one that runs on your browser: http://amber-lang.net/
[+] [-] hesdeadjim|12 years ago|reply
I was barely a novice at an imperative language, and all of a sudden I had the comfortable struts of local mutable state ripped out from under me. Having to solve most problems via recursion was incredibly challenging at that stage and I'd be lying if I said I left that class feeling like I understood Haskell.
That course did have the desired effect that Dijkstra was hoping for though. I never programmed functionally in my coursework after that, but it stuck with me and the feeling that "there is something different out there" in the programming language world has forced me to never be satisfied with one language or one approach to solving a problem in my professional life since then.
[+] [-] ElliotH|12 years ago|reply
Even if it does sink in they rapidly find that the simplified Java being taught at first year undergraduate level is far below the standard required for real world Java programming.
[+] [-] RyanZAG|12 years ago|reply
My university down here taught in Scheme for the introduction and theory classes, and in Java for algorithms and networking. Seemed to work well as a balance, although I'm not sure if they still do that.
[+] [-] danpalmer|12 years ago|reply
1. Teach structure and organisation of programming. - Python is a good for this as it's object oriented, but has very little boilerplate and syntax getting in the way of learning. A few universities have done well using Haskell for this instead, and I think that's quite a good option, particular as it introduces types.
2. Teach from the perspective of how a computer works - C is probably the best one for this as it helps students understand how computers work at a more basic level, being closer to assembly and machine code. It also allows for memory to be thought of as a much more basic resource of the machine that users must manage.
Java would be good for teaching data structures and algorithms, but I don't think that should come until after an introductory class using one of the above methods.
[+] [-] grayrest|12 years ago|reply
I do think that there are better ways and worse ways to teach programming. Brett Victor put out an overview [1] of the topic last year and while that essay in itself isn't the answer, it's at least a better start than anything I ran into as an undergrad.
[1] http://worrydream.com/LearnableProgramming/
[+] [-] mathToCS|12 years ago|reply
[+] [-] timje1|12 years ago|reply
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 the entirety of first year. I had been exposed to C++, ADA(!), Prolog and had an in depth look at Erlang by the time my course finished...
[+] [-] microtonal|12 years ago|reply
Let me provide some anecdotal counter-evidence: during my last year of high school, I was in a university class where they taught us programming using Haskell (this was in 2000). I observed a fairly consistent pattern - those who had prior experience with imperative programming (me included), had far more difficulty picking up Haskell than those who hadn't.
The girl I worked with (who had no prior experience) was surprised, since "it's just like maths" :).
[+] [-] hardwaresofton|12 years ago|reply
I actually graduated from UT's Comp Sci school and I know many of the "elements" courses (super introductory, even for non-majors) are taught in python. That, I think is a good introduction, but for people in the major, I don't think learning Haskell/functional programming is a stretch at all.
If one can wrap their minds around functional programming (which introduced correctly is actually relatively easy to grasp) -- it will be MUCH easier to learn imperative programming. In the end, any good imperative programming seeks to be modular (s/procedures|methods|subroutines/functions/g), and will liken itself to something you would write in functional programming (loosely couple functions that do a specific task well). Yes there are places this gets hairy (side effects, I/O based operations), but computer science is not about writing procedural code, it's really more about algorithms, which is why 4 year universities are NOT trade schools, but do prepare you for the real world (in that you're not COMPLETELY useless). Program syntax is easy to learn (a skilled faker can just repeat it verbatim), efficiency/correctness/proper data-structure usage is difficult.
[+] [-] adamesque|12 years ago|reply
The INTRO-intro CS class at the time actually used Pascal, and was endlessly confusing to me as a cold beginner.
My next course, however, was taught in Scheme, and immediately I felt more at home. And for the first time, I felt like I might have some actual aptitude for programming.
Without that peek into the elegant heart of computer science, I doubt I'd have stuck with it as long as I did.
[+] [-] Vaskivo|12 years ago|reply
I learned programming with Scheme, in that course, in 2004. I used, without noticing, many techniques I would later have relearn due to a "prolongued exposure to imperative programming". In my semester I used closures, functions as first class objects and lots of recursion.
The following three semesters I forgot all that, for I had to use C, C++ and Java. When, in the fourth semester, I had my AI course in Lisp, I used "let"s and loops for everything. In the middle of the semester, I remembered recursion, and how it made everything better (in Lisp). Later, by myself, I relearned closures, functions as first-class-objects and other stuff.
Having Scheme as an introductory language is good because it put students that came from a IT-technical high-school education equal to general high-school education students (that have never seen programming before). With the "real world" so drowned in imperative programming languages, there are few courses that can justify using a functional programming language. The things I know about FP, I know because I thought myself.
I'm not saying FP is better than imperative programming, is just that both should be (well) taught. (As some other paradigms too, I believe).
Some years ago my old uni, like MIT, changed from Scheme to Python. Python is my favourite programming language. But I'm still not happy with the decision.
[+] [-] christiansmith|12 years ago|reply
[+] [-] dxbydt|12 years ago|reply
Corporate America wants languages that are dumb, easy for corporate drones to assimilate, hard to mess up with, verbose ( verbosity is misinterpreted as documentation in the enterprise) and Java fits the bill from the get-go.
Now, that doesn't mean you can't do non-dumb things in Java - at Sun Microsystems, we worked on all sorts of very cool R&D-type shit like JavaOS(http://en.wikipedia.org/wiki/JavaOS), Hotjava ( http://en.wikipedia.org/wiki/HotJava), JavaSpaces (http://en.wikipedia.org/wiki/JavaSpaces#JavaSpaces ), JavaCC( http://en.wikipedia.org/wiki/JavaCC ), Jini (http://en.wikipedia.org/wiki/Jini ), ...a very long list of R&D stuff. Sun Research was fucking elite, & staff engineers were considered outright geniuses. None of that cool R&D shit got any traction.
So what got traction ? Whatever yucky shit corporate America wanted - JavaBeans( http://en.wikipedia.org/wiki/Java_Beans ), EJB (http://en.wikipedia.org/wiki/EJB ), Swing (http://en.wikipedia.org/wiki/Swing_(Java) ), various sorts of form-builders, table widgets, reporting shit, IDEs, classfile obfuscators,...
So Java became that. Rather than go down the R&D route, the pipeline became more corporate America oriented.
Haskell has always had very deep roots in academia - the focus on enabling the corporate American drone with Haskell is minimal, close to zero. So what do you expect ? The focus will be on debating types & building theorem provers, not on "how to show big bank's fourth quarter report in 3 colors with 7 columns and subtotals in single widget while data-binding seamlessly occurs in middle tier using enterprise beans built from beanfactoryfactory" - this sort of shit that is commonplace in the Java EE world I inhabited post Sun, would be considered positively gauche in Haskell.
[+] [-] tel|12 years ago|reply
[+] [-] mattgreenrocks|12 years ago|reply
[+] [-] kunai|12 years ago|reply
It's painful as hell, and like you said, makes me feel like a corporate monkey who's writing some ugly code for use in some specific pants-on-head retarded enterprise "app."
[+] [-] btian|12 years ago|reply
[+] [-] rbanffy|12 years ago|reply
When I was in college (1986, engineering, not compsci) students started with 8-bit BASIC and FORTRAN (I mostly skipped classes on BASIC because I had learned to program on my Apple II). One year later, they switched from BASIC to Pascal. Later on, one of the teachers decided to teach APL. It was a wonderful experience because it was a different take on my previous paradigms.
I am not sure what is the best way to teach someone how to program. When I was a kid, you turned your computer on and immediately got to a REPL (one Dijkstra would strongly disapprove, but still a programming environment). IMHO any programming language that demands an IDE or a build system more complex than make (even if hidden behind a shiny GUI) should not be used as an introduction. Paraphrasing Dijkstra, it could damage the young minds beyond repair.
If my Apple II booted into Eclipse, I'd have gone into cinematography.
[+] [-] annasaru|12 years ago|reply
That's an awesome punchline.
[+] [-] danielweber|12 years ago|reply
I'm having a ball learning Clojure now, and it would be much much harder if I'd never used Scheme. (I've done some functional programming in C++ and Ruby, but I wouldn't have done that if I hadn't done it in Scheme earlier.)
[+] [-] Mikeb85|12 years ago|reply
Haskell is great in some ways, terrible in others. Like the fact that you can't apply a normal function to a monad, and monads are hidden with do <- syntax, so you need to use monadic functions, and then there's type classes and shit... In Haskell it seems the complexity goes up exponentially and building anything beyond trivial is a huge hassle - no wonder 'design' patterns like FRP seem to be all the rage (while the entire computing landscape is being built on languages like C++ and Java).
Lisp/Scheme are conceptually very simple and easy to learn, but the syntax is hard to follow, and some of the keywords make no sense to someone who's never done any programming.
I personally think Ruby -> Java/C++ would be a great progression, with maybe some SML/OCaml on the side somewhere along the way. I spent way too much time dabbling in various 'trendy' languages like Clojure, Haskell, various Lisps and other FPLs, Ruby and JS/Node, etc... Now I'm at the point where I just want to build things, so I'm using a very practical, OOP, statically-typed, compiled language that many people have already shipped many practical apps with.... Probably not going back to 'trendy' languages.
[+] [-] the_af|12 years ago|reply
And what do you mean "design patterns like FRP"? I'm sure you know there are tons of design patterns that are "all the rage" for C++ and Java (a lot of them dealing with the complexity of doing OOP). Why are you giving those languages a pass?
[+] [-] rollo|12 years ago|reply
[+] [-] gerjomarty|12 years ago|reply
Like Dijkstra said, getting these high-level concepts in there early is very important.
[+] [-] mcguire|12 years ago|reply
At no time were the introductory classes in Haskell, to my knowledge.
According to the wayback machine[1], the introductory courses (CS307 at the time) in 2001 were in Scheme, while subsequent courses were in C++. I recall the introductory classes experimented with Miranda briefly.
On the other hand, the typed letter[2] is from the EWD archives. Weird.
[1] https://web.archive.org/web/20010429024151/http://www.cs.ute...
[2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...
[+] [-] habosa|12 years ago|reply
That said, I think people are overreacting to Java as a CS 100-level language because of enterprise experiences.
I have written enterprise Java and I hate it, but I still love Java. Java EE is all beans and POJOs and XML and Swing and cruft and I want to burn it in a fire. But that's not Java, those are libraries.
Java is an excellent language to introduce someone to programming, because there is very little magic. Everything is explicit, due to the static typing and imperative nature. The computer (or JVM in this case) doesn't do anything that you don't tell it to do. That's easy for someone to grasp.
Additionally, Java makes it very easy to write readable, organized, and extensible programs even if they are verbose. Using classes, objects, methods, types, and all of that OOP stuff makes it easy to write modular programs where each piece of code does exactly one thing. In functional programming the intricacies of passing state and higher-level functions lead to a lot more spaghetti code for someone who has never programmed before.
Do I think that we should only teach Java? No, of course not. Do I think that it's still a great first language? Absolutely.
If I had control of a curriculum, I'd teach Java for half a semester and then Haskell for half of the semester. I think it's important to not introduce "more productive" dynamic languages like Ruby or Python until students have had to deal with concepts like types so that they can appreciate what Python and other dynamic languages are leaving out.
At Penn, where I go to school, the intro to CS class teaches OCaml in the first half and Java in the second. Unfortunately I think that so many people are struggling with writing code as a concept that they're too frustrated to appreciate the beauty of OCaml at first. Teaching it after something a little easier would make the advantages clearer.
[+] [-] discreteevent|12 years ago|reply
[+] [-] dllthomas|12 years ago|reply
[+] [-] mattdeboard|12 years ago|reply
> It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.
[+] [-] kabouseng|12 years ago|reply
- You'll probably get a high drop out rate because of the complexity (recursion, pure / first class functions etc).
- You rely that your students already have experience at high school with imperative languages
- The industry by far still don't use functional languages.
But then again Java is an equally bad choice, for the reasons mentioned, but also you jump immediately into OOP, again expecting the student to have former experience.
What is wrong with laying a solid foundation with the introductory class in C or Python, and then moving on to the more advanced OOP or functional worlds?
[+] [-] brendano|12 years ago|reply
Lots of people here have raised concerns that the way Java forces class and static declarations is confusing for beginners. Interestingly, the instructors were concerned about that too, but found that students don't seem to mind.
http://homes.cs.washington.edu/~reges/sigcse/basics.pdf
http://homes.cs.washington.edu/~reges/sigcse/basics.ppt
The second major concern being discussed here, that functional programming isn't possible in Java, I think is a non-issue for a true introductory first-semester class, which needs to focus on more basic issues of procedural programming and abstraction. The SICP approach is beautiful and great for already advanced and highly motivated students, but that's honestly a small minority.
(You can find many more examples of reports like this if you search for "CS1", which is the shorthand for intro-to-CS that's used in the CS education literature.)
[+] [-] joyeuse6701|12 years ago|reply
The reasoning for bottom-up is that there are fundamental aspects of the bottom up approach that truly teach the fundamentals that are necessary to become a great computer scientist/engineer/developer that I don't think any other method provides.
But the top-down approach is appealing for one reason it seems: It's friendly. I would not be surprised if the retention rate for top-down was greater than the bottom-up. Using something like Python, Java, or whatever other conventional blackbox language is easy, comfortable, and immediately demonstrates to a student the power of programming. The practicality of what they learn is evident. Ideally, interest in this would continue down the line. 'This is really cool, but how does Python actually work?'.
Unfortunately, it seems that most people, when presented with a working blackbox, don't care to see how it actually ticks. It takes a certain special someone to open up a watch, disassemble and reassemble it. So who knows how well the top-down carries over into learning the fundamentals.
The bottom-up has the drawback of intimidating the meek. I certainly was one. I would have benefited from a top-down approach, as I am one of the types who like to see how something ’ticks’.
So therein lies a trade off, would you sacrifice the known quality of your curriculum for better retention? Having someone learn something, is better than nothing, but that’s up to people like Prof. Dijkstra to decide.
EDIT: spelling/coherency
[+] [-] parenthesis|12 years ago|reply
[+] [-] mschlafli1|12 years ago|reply
[+] [-] warmfuzzykitten|12 years ago|reply
[+] [-] NigelTufnel|12 years ago|reply
Take Java for example. Most people (Dijkstra included) hate it. But look how much Java has accomplished. It's not a coincidence that Hadoop is written in Java. It's not a coincidence that Java is the primary language on Android.
To quote a great man: "Java works. Java captures the essence of the evolutionary spirit" Same thing applies to PHP, Javascript, and whatever everyone hates.
Couple of years ago I thought that Java was the Devil's invention and the most awful programming language ever. Then I started using Java with Hadoop. And for the first week Java was the most awful programming language ever. Two/three weeks in I was absolutely okay with Java. It worked. And for me that's the only thing that counts.