Ask HN: How would you evolve modern computer science curriculum?
10 comments
You recommend teaching Javascript or Ruby in an undergraduate Computer Science Data Structures course. Are you aware of the fact that Computer Science, as a major, is not "Learn programming"? It is learning the theory and science behind Computers, computing and programming. What you suggest is more applicable for CNIT or Computers, Networking, and Information Technology; A major where one would learn more how to apply the theories and concepts of programming. But even then, you're suggesting SCRIPTING languages for PROGRAMMING. The only thing a scripting language is good for in the education system is conveying concepts such as abstraction ( because that's practically all they are ). Java is a way better language for that.
I think instead of attempting to revamp the CS curriculum, we should work harder to portray CS for what it is, which is not "Study this and be a programmer for the rest of your life". People who come out of CS go on to do a wide array of things, programming is just a basic and necessary skill for learning and understanding computing that one picks it up. And knowing the theories and concepts really well makes good programmers, same as how knowing the fundamentals of Mathematics would produce someone who could be a good accountant or something similar.
I think instead of attempting to revamp the CS curriculum, we should work harder to portray CS for what it is, which is not "Study this and be a programmer for the rest of your life". People who come out of CS go on to do a wide array of things, programming is just a basic and necessary skill for learning and understanding computing that one picks it up. And knowing the theories and concepts really well makes good programmers, same as how knowing the fundamentals of Mathematics would produce someone who could be a good accountant or something similar.
Yes, very aware. What I suggest was just an off the cuff idea to help spark ideas. CS is still too new to not have some evolution left in the curriculum. This really isn't controversial.
You are like the guy back in 1975 saying "...We don't need no stinking change from Assembly to C, this isn't a 'Learn How To Program Degree' don't you know..."
Assembly is fine, it's just not relevant anymore to a CS major. C and Java are still good but they are becoming less relevant was time marches on. Blah blah blah. Is thing on?
In fact, if waited and just said the same thing in 7-14 years or so, everybody would be saying "..<insert newer language here> for Data Strucutres?...no sh*#t, who programs in C or Java anymore?!?..."
You are like the guy back in 1975 saying "...We don't need no stinking change from Assembly to C, this isn't a 'Learn How To Program Degree' don't you know..."
Assembly is fine, it's just not relevant anymore to a CS major. C and Java are still good but they are becoming less relevant was time marches on. Blah blah blah. Is thing on?
In fact, if waited and just said the same thing in 7-14 years or so, everybody would be saying "..<insert newer language here> for Data Strucutres?...no sh*#t, who programs in C or Java anymore?!?..."
I think you guys are not actually reading what I wrote - I'm all for the rigor, I'm all for the theory. There is just no reason to not make things more relevant and practical since you have to pick a language/focus/domain for any given class anyway - no matter how theoretically focused it is.
For the Data Structures comment, please see the second sentence that begins with "The concepts are what matter in DS...". What I am saying is, how about a new language? It would be super cool to have to rectify Data Structures theory with the real world issues of something like Javascript.
For the other comment about keeping things static, you know there was a time all these course were taught in Assembly. So are you arguing we should have never even evolved past that?
Anyway, I was hoping more for fun/brainstorming/idea generation. How might I have worded it differently to get that instead of shallow objections?
For the Data Structures comment, please see the second sentence that begins with "The concepts are what matter in DS...". What I am saying is, how about a new language? It would be super cool to have to rectify Data Structures theory with the real world issues of something like Javascript.
For the other comment about keeping things static, you know there was a time all these course were taught in Assembly. So are you arguing we should have never even evolved past that?
Anyway, I was hoping more for fun/brainstorming/idea generation. How might I have worded it differently to get that instead of shallow objections?
The problem is that web programming is a very abstracted and high level concept. When you take a data structures course, you learn in languages where memory usage can be easily measured or guaranteed, such as Java or C, and the runtime can be more concretely measured. This is important because the fundamental importance of data structures is their memory vs time trade off.
Javascript is just not the language for this. Neither is Ruby, Python, Haskell, Perl, <insert trendy scripting/functional language here>.
I understand that you're trying to push for teaching a language that might have more modern, real world applications, but CS is not ( at least in the undergraduate world ) about learning the modern or bleeding edge. Leave that to post-graduation, in your free time, or during a graduate program.
The best you can do is extending the CS curriculum to teach "Introduction to Web Programming" or the like utilizing Python and/or Javascript, or offering it as an elective. The closest thing to replacing Java in CS undergraduate curriculum is Go or Rust or some similar, newer language, but the jury is still out on how useful as educational tools they are.
I understand that you're trying to push for teaching a language that might have more modern, real world applications, but CS is not ( at least in the undergraduate world ) about learning the modern or bleeding edge. Leave that to post-graduation, in your free time, or during a graduate program.
The best you can do is extending the CS curriculum to teach "Introduction to Web Programming" or the like utilizing Python and/or Javascript, or offering it as an elective. The closest thing to replacing Java in CS undergraduate curriculum is Go or Rust or some similar, newer language, but the jury is still out on how useful as educational tools they are.
I absolutely beg to differ on your first point. You don't use actual performance measurements in Data Structures courses, no matter what language you use. You aren't instrumenting your code or counting bytes or anything. You measure the concepts by analyzing with Big-O notation. If you really wanted to, you could teach a Data Structures course using just paper, pencil, and pseudo-code.
Pretty much any language will work fine for teaching data structures.
Pretty much any language will work fine for teaching data structures.
Pretty much any language will work for teaching data structures badly.
If your instructor is showing you a cool animation of a list with less than 30 elements being sorted by X algorithm, he's doing it badly. Or at least if that's all he's doing. There are by the way many schools that do just that, under the rationalization that the point of the class is to have the student practice what he learned at Programming 101. I attended such course in the day, and then went to teach the same course some years later, but I don't think the results were any good.
IF he have you run your algorithm against input taken from /dev/random, first 100KB, then 1MB, then 10MB, then 100MB he's a little less bad. IF he makes you do the whole sequence a dozen times an plot each resulting data points in a graphic with logarithmic scale, he is not bad at all.
Then you can start to discuss Big-O notation, but for the resulting graph to make any sense you need that the program written by the student to have a relatively strong correlation with what the computer is actually doing. It will not do, by example, if the runtime environment decides to implement you list as a dictionary object instead of a raw array. Also, having a relatively precise clock like Java's currentTimeMillis will reduce the possibility that you embarrass yourself if the practice do not seem to match the theory.
If the course is being taught at graduate level, you may want to run a second experiment, this time with input sizes of 1KB, 256B, 64B, 16B. At this point you will be able to discuss stuff like the Little-O notation, the constants involved in both notations, and how those are derived from Limits of the time function.
For this you will absolutely need the best clock available in your hardware, so C because a must. It will also help if you can run cc -s on your code and see what assembly is behind your code. I know it is overly ambitions, but that's how I would like to have learn about this stuff.
If your instructor is showing you a cool animation of a list with less than 30 elements being sorted by X algorithm, he's doing it badly. Or at least if that's all he's doing. There are by the way many schools that do just that, under the rationalization that the point of the class is to have the student practice what he learned at Programming 101. I attended such course in the day, and then went to teach the same course some years later, but I don't think the results were any good.
IF he have you run your algorithm against input taken from /dev/random, first 100KB, then 1MB, then 10MB, then 100MB he's a little less bad. IF he makes you do the whole sequence a dozen times an plot each resulting data points in a graphic with logarithmic scale, he is not bad at all.
Then you can start to discuss Big-O notation, but for the resulting graph to make any sense you need that the program written by the student to have a relatively strong correlation with what the computer is actually doing. It will not do, by example, if the runtime environment decides to implement you list as a dictionary object instead of a raw array. Also, having a relatively precise clock like Java's currentTimeMillis will reduce the possibility that you embarrass yourself if the practice do not seem to match the theory.
If the course is being taught at graduate level, you may want to run a second experiment, this time with input sizes of 1KB, 256B, 64B, 16B. At this point you will be able to discuss stuff like the Little-O notation, the constants involved in both notations, and how those are derived from Limits of the time function.
For this you will absolutely need the best clock available in your hardware, so C because a must. It will also help if you can run cc -s on your code and see what assembly is behind your code. I know it is overly ambitions, but that's how I would like to have learn about this stuff.
[deleted]
I would say that it is a good thing that the core courses are static in time. It means the field is mature enough to support an undergraduate program at all. Physics and Chemistry majors spend most of their time at school catching up to the historic state of the art up to early 20th century. If they want to know the most up to date advances they have to either pursue a self directed continued education, or enroll in a graduate level program.
As a matter of fact, a rapidly changing curriculum would be at least a yellow flag. In the worst case, it's the pseudo sciences that go up and down, chasing the passing fade du-jour. This is more like a smell test than an objective indicator. The correlation is there, but it is not well understood. Not necessarily every rapidly changing curriculum is a pseudo-science, but a closer look is probably due.
That was probably the state of the art of Computer Sciences ~65 years ago. The Foundations were already known, but the field was still too much of a virgin land to be settled by undergraduates. It was rather a diverse group of mathematicians, scientists and (mechanical and electric) engineers who were just exploring the territory. It eventually coalesced into what we have today, so it is a good thing that the pace has slowed down by now.
As a matter of fact, a rapidly changing curriculum would be at least a yellow flag. In the worst case, it's the pseudo sciences that go up and down, chasing the passing fade du-jour. This is more like a smell test than an objective indicator. The correlation is there, but it is not well understood. Not necessarily every rapidly changing curriculum is a pseudo-science, but a closer look is probably due.
That was probably the state of the art of Computer Sciences ~65 years ago. The Foundations were already known, but the field was still too much of a virgin land to be settled by undergraduates. It was rather a diverse group of mathematicians, scientists and (mechanical and electric) engineers who were just exploring the territory. It eventually coalesced into what we have today, so it is a good thing that the pace has slowed down by now.
From http://www.meetup.com/Oslo-pm/events/172566472/
"Perl 6: A Programming Language for Computer Scientists (And Other Crazy People)
A good Computer Science syllabus will cover everything from bit manipulation to set theory, from Boolean algebra to concurrency, from parsing grammars to graph traversal, from two's-complement arithmetic to higher-order functions, from sorting algorithms to multiple dispatch, from macros to closures. ...
To teach all these concepts and techniques it is usually necessary to resort to a wide range of different programming languages ... Lisp and Fortran ... Forth ... Smalltalk, C, Scheme ... C++, Perl, Occam ... Haskell, Java, JavaScript ... C#, Scala, Clojure.
This diversity ... encourages an unfortunate ... internal compartmentalization of concepts and approaches.
Perl 6 ... aims to provide all of the major features of all of the major languages from all three dominant paradigms.
... we stole the best features from 20 different languages, and then spent a decade working out how to put them together in a way that is clean, efficient, powerful, and still usable by actual human beings. And Perl 6 was the result."
"Perl 6: A Programming Language for Computer Scientists (And Other Crazy People)
A good Computer Science syllabus will cover everything from bit manipulation to set theory, from Boolean algebra to concurrency, from parsing grammars to graph traversal, from two's-complement arithmetic to higher-order functions, from sorting algorithms to multiple dispatch, from macros to closures. ...
To teach all these concepts and techniques it is usually necessary to resort to a wide range of different programming languages ... Lisp and Fortran ... Forth ... Smalltalk, C, Scheme ... C++, Perl, Occam ... Haskell, Java, JavaScript ... C#, Scala, Clojure.
This diversity ... encourages an unfortunate ... internal compartmentalization of concepts and approaches.
Perl 6 ... aims to provide all of the major features of all of the major languages from all three dominant paradigms.
... we stole the best features from 20 different languages, and then spent a decade working out how to put them together in a way that is clean, efficient, powerful, and still usable by actual human beings. And Perl 6 was the result."
It sounds like all your changes would be more appropriate for a vocational school software engineering program.
For instance your data structures remark. A data structures course would be fairly odd to teach in something like python where you have no pointers or low level control of memory like C or C++. If all you care about is high level structures then that's not really in the spirit of a CS degree data structures course in my opinion.
For instance your data structures remark. A data structures course would be fairly odd to teach in something like python where you have no pointers or low level control of memory like C or C++. If all you care about is high level structures then that's not really in the spirit of a CS degree data structures course in my opinion.
I definitely think the rigor and theoretical basis should still be maintained; definitely NOT saying CS programs should make themselves more vocational though I do see plenty of room for more practical interdisciplinary degrees to spring up.
Not sure about the assertion that Data Structures can only be taught properly in a low level language. Any rigorous course would be pretty much orthogonal to the language's peculiarities. You could implement RED-Black trees in Javascript as easy as any language. The cool thing, for any language you pick, as a side effect you'll get to dive deeper in that language's particular features and idioms while also learning the Data Structures theory. So why not Javascript or Python or Haskell or...? I could imagine some cool projects coming out of this one, like implementing your own efficient Shadow DOMs using the various tree structures that get covered.
Not sure about the assertion that Data Structures can only be taught properly in a low level language. Any rigorous course would be pretty much orthogonal to the language's peculiarities. You could implement RED-Black trees in Javascript as easy as any language. The cool thing, for any language you pick, as a side effect you'll get to dive deeper in that language's particular features and idioms while also learning the Data Structures theory. So why not Javascript or Python or Haskell or...? I could imagine some cool projects coming out of this one, like implementing your own efficient Shadow DOMs using the various tree structures that get covered.
It seems to me that you are making the same general argument that Steve McConnell (of Code Complete fame) made in his 2003 book "Professional Software Development", namely that CS programs serve a different purpose and clientele than a Software Development or Software Engineering program would serve. So, rather than evolving a CS curriculum, another option would be to introduce parallel software engineering programs. Honestly though, for a professional developer who sees this as a career, I'd argue you are better off doing CS at the undergrad level, then pursuing something like a Masters in Software Engineering. CS at the undergrad level gives everyone the foundation they need, regardless of what the pursue professionally after that.
I'd love to get y'all's feedback on a related question: did you receive any training in your CS degrees that had anything to do with testing, dev-ops, continuous deployment, and the like? I teach in an MIS department and have started to include some of these concepts in the capstone course, which was originally more of a project management course.
From talking to the employers who hire our students (and the CS department's students), I got the impression that CS students are taking four years of programming classes but are never taught how to write tests or even to use version control. Is that the way it is? Is that the way it should be?
From talking to the employers who hire our students (and the CS department's students), I got the impression that CS students are taking four years of programming classes but are never taught how to write tests or even to use version control. Is that the way it is? Is that the way it should be?
I went through Georgia Tech, and there is never any formal introduction to version control. If you're exposed to it, it's from a job or a friend (who in turn got it from a friend or their job). If you don't know it exists, you'll never seek out and learn it.
Testing was used in some courses. We had a software development class that involved UML, TDD, and everything "proper". Testing is also provided as a way of pre-checking your homework by some TAs. They might give you a basic set of tests for your linked list homework (adding, removing, etc), but then their grading script will check off by 1s, etc. It's not necessarily taught how to write said tests in those classes.
Continuous deployment is never touched. If you co-op/intern you might be exposed to it.
No one that I knew of learned anything related to "ops", unless they happened to take an interest in it.
Testing was used in some courses. We had a software development class that involved UML, TDD, and everything "proper". Testing is also provided as a way of pre-checking your homework by some TAs. They might give you a basic set of tests for your linked list homework (adding, removing, etc), but then their grading script will check off by 1s, etc. It's not necessarily taught how to write said tests in those classes.
Continuous deployment is never touched. If you co-op/intern you might be exposed to it.
No one that I knew of learned anything related to "ops", unless they happened to take an interest in it.
No chemical engineer I know learn how to go to the assembly line and take samples for quality control, either. And arguably this is a good thing. You pay to go to school in order to learn stuff that is useful across the board in many different situations, not to have the local big employer save a few bucks per new hire during the induction training.
This is a fair point, but begs the question: should a CS degree include, or not include, learning about software project management and software development processes? I teach in the business school (an MIS department) so it's not controversial that we'd teach about project management and operations management here. I don't know what the prevailing opinion is in engineering schools.
I think we have reached to point where we should admit that a career in software development needs much more learning than what can possibly be achieved at school (regardless of level).
The current state of affairs holds the belief that no CS graduate worth their salt should be ignorant of software engineering methodologies (agile, waterfall, etc), nor specific development processes & tools (source control, peer reviews, unit testing, etc). At the same time it holds the more or less contradictory belief that CS curriculum should be concerned mostly with Computer Science and not mention much of the practical side of software development.
The ideal is that a good program will present the student with multiple opportunities to pick up practical skills on the go. No formal class and no grades, but exposure through lab work. The reality is that this requires everyone involved (students, instructors and various other support roles) to work longer and harder to achieve this tacit expectations.
The current state of affairs holds the belief that no CS graduate worth their salt should be ignorant of software engineering methodologies (agile, waterfall, etc), nor specific development processes & tools (source control, peer reviews, unit testing, etc). At the same time it holds the more or less contradictory belief that CS curriculum should be concerned mostly with Computer Science and not mention much of the practical side of software development.
The ideal is that a good program will present the student with multiple opportunities to pick up practical skills on the go. No formal class and no grades, but exposure through lab work. The reality is that this requires everyone involved (students, instructors and various other support roles) to work longer and harder to achieve this tacit expectations.
If people's comments here are any indication, yes, SADLY, that is kind of the way it is.
Does it have to be? Definitely not.
There are tons of ways to inject practical skill building moments into an otherwise rigorous and principled CS degree.
For example, Professors could force students to turn in their coding assignments by Git Pushing to a repo. Since they have to do that anyway, they might as well version their assignments as they work on them. Boom! Some exposure to version control.
Or Professors could provide students with a suite of unit tests that their assignments will have to eventually pass. Now the students are coding to test cases from the very start of an assignment and probably picking up some practical knowledge about testing platforms.
Both of these tactics could be injected into just about any course, from Compilers to Data Structures.
Does it have to be? Definitely not.
There are tons of ways to inject practical skill building moments into an otherwise rigorous and principled CS degree.
For example, Professors could force students to turn in their coding assignments by Git Pushing to a repo. Since they have to do that anyway, they might as well version their assignments as they work on them. Boom! Some exposure to version control.
Or Professors could provide students with a suite of unit tests that their assignments will have to eventually pass. Now the students are coding to test cases from the very start of an assignment and probably picking up some practical knowledge about testing platforms.
Both of these tactics could be injected into just about any course, from Compilers to Data Structures.
This is an orthogonal issue from the one you brought in originally, and in this case I am 100% with you.
In Programming 101, you require all assignments to be turned in by pushing to <insert your favorite control version here> repository.
In Data Structures, you require each assignment to turn at least 5 versions which show the evolution of your work (not just 4 empty skeletons and one final push with the completed assignment at the end). Then was you asses the quality of versions you introduce this other soft technology called "peer review".
In later courses, like Compilers, you can have the whole group work on a single code base, each branching and merging back their own part of the work. You teach how to work in teams.
etc, etc...
What the choking point is here is that instructors themselves are, more often than not, not familiar with this kind of techniques and technologies. And they are unlikely to learn if there is not some serious institutional support for this. Of course the odd extraordinary professor will be a regular contributor to open source projects and the like, but all the others will not know what to do.
I think if you are interested to pursue this beyond a simple online discussion, you should start from here. Try to talk your local head of CS department into this kind of stuff, see where can you get from there.
In Programming 101, you require all assignments to be turned in by pushing to <insert your favorite control version here> repository.
In Data Structures, you require each assignment to turn at least 5 versions which show the evolution of your work (not just 4 empty skeletons and one final push with the completed assignment at the end). Then was you asses the quality of versions you introduce this other soft technology called "peer review".
In later courses, like Compilers, you can have the whole group work on a single code base, each branching and merging back their own part of the work. You teach how to work in teams.
etc, etc...
What the choking point is here is that instructors themselves are, more often than not, not familiar with this kind of techniques and technologies. And they are unlikely to learn if there is not some serious institutional support for this. Of course the odd extraordinary professor will be a regular contributor to open source projects and the like, but all the others will not know what to do.
I think if you are interested to pursue this beyond a simple online discussion, you should start from here. Try to talk your local head of CS department into this kind of stuff, see where can you get from there.
Testing and Version Control: Yes. Far more than we needed to.
Dev-ops and continuous delivery is much harder to learn in a college setting because you, IMO, only start to see the benefits on large long term projects or quick moving undocumented/poorly documented ones.
Dev-ops and continuous delivery is much harder to learn in a college setting because you, IMO, only start to see the benefits on large long term projects or quick moving undocumented/poorly documented ones.
I would suggest more bridges to other programs. One could argue this exists ad-hoc with double majors, and minors, and similar, but it could be done better with more proactive thought and combined classes.
Some areas that could be combined: CS & Linguistics, CS & Physics, CS & Math, CS & Biology, CS & Chemistry, CS & Philosophy, CS & Psychology, CS & Business, CS & Geography...
These are done a little here and there, but I would like CS to cross the disciplinary divide more. Technology is eating everything, so why not teach it that way?
Some areas that could be combined: CS & Linguistics, CS & Physics, CS & Math, CS & Biology, CS & Chemistry, CS & Philosophy, CS & Psychology, CS & Business, CS & Geography...
These are done a little here and there, but I would like CS to cross the disciplinary divide more. Technology is eating everything, so why not teach it that way?
The main disagreement I have is the assertion that the majority of jobs (at a nationwide level) is for web based languages. While it is trending in that direction from what I see the majority of jobs are still Java and C++ with a bit of C thrown in. And while there may come a time when Javascript overtakes Java and C++, I don't think we are there yet, at least not nationally.
From my own personal experience as a Computer Science graduate, I feel that an ideal Computer Science curriculum would be as theoretical as possible, but would promote outside work in industry for those looking to work in industry.
I interned quite heavily during my uni days, and I learned more about programming in the months I spent working than I did in an entire year on my course.
I interned quite heavily during my uni days, and I learned more about programming in the months I spent working than I did in an entire year on my course.
From the answers to that question, you can see that the core computer science curriculum has barely changed in 30 years. As for programming languages used, Java has been the mainstream for over 10 years now and C/C++ is still hanging tough after breaking into higher education 20+ years ago.
In '96-'99, the core courses I took (Data Structures, OS, Compilers, Computer Arch, etc.) served me well and I was glad to get a mix of Java and C/C++ at the time. If I was starting my undergrad today however, I'd be a little disappointed to know not much had changed since then. I'd argue a good bit of the curriculum is nearing its shelf life or, to carry on the spoiling food metaphor, at least needs to be put in the freezer for preservation.
Got me thinking about how things could evolve. Some examples:
Data Structures => Javascript or some other web-able Ruby that 70% of folks will actually get a job in. The concepts are what matter in DS, but while we are at it how about a more relevant language choice? Points to those school already using Python for this!
Operating Systems => Teach it in C still, keep it hardcore low level, and probably make it an elective for the minority of folks who want to do performance OS work.
"Browser/Internet as the OS" => Replace the traditional core OS class; class project would basically be this: http://runtimejs.org/
Databases => Replace with a new core course for "Data Science"; make Databases an elective.
So, how would you evolve modern computer science curriculum if you could?