Partager via


What Should Change in Comp Sci Education

I believe I received as good of a computer science education as exists.  This essay is not targeted at my education, nor any other particular school, faculty, nor individual, but rather how computer science is generally taught across the board.  In fact I know of no college or university that teaches it the way that I'll suggest.

 

Joel (from Joel on Software) recently wrote an essay on JavaSchools that is largely on-mark (except for the MapReduce comment, but I can explain why he's wrong about that later :-)).  He captures part of the problem, but he misses what I think the real problem is...  I agree that Java is an inadequate language for teaching CS, but so is C++ and Scheme.  What's missing in computer science education is that we don't teach students how to be fluent in multiple languages (or rather multiple paradigms) -- we don't give them multiple tools to use, and furthermore we don't teach them how to determine what language abstractions are the right ones for a given task.

 

You're probably saying to yourself, "But I took a semester of programming languages and we studied 24 different paradigms of programming -- and while I've forgotten all of them, it was cool while I took it."   Learning programming languages in one semester and then promptly never using the concepts again is only slightly better than never being introduced to the concepts at all.  We have to do better than that.  And simply letting students pick any language they prefer is not sufficient.  There is enough difference in ability between the 25/75th percentile of students that good students could do all their assignments in assembly language and still pass their courses. 

 

What a C.S. curriculum should be is four years of using different languages/paradigms to solve different types of problems.   Part of a computer science education should be an understanding of what language constructs would be useful to solve a given a problem, and how to solve a given problem given the constraints of a given paradigm.  This does a few things: (1) It puts a wide range of programming languages at the disposal to a computer programmer, but more importantly (2) does not limit the thought process of the programmer to what any single language contains.  (3) Lastly, it teaches students that there is more than one way to skin a cat (although it's always been unclear to me why we even need to skin cats). 

 

Here's a fun exercise, find a friend who essentially only writes in a conventional OO language and ask them to implement some graph algorithms in a functional language.  Almost everything they know about OO/imperative languages works against them in this exercise.  Often times the functional solutions are scary elegant, but 9 times out of 10 they won't figure them out on their own given their taint.

 

Joel's article also mentions that people are using Java to solve interview programming problems,.  One thing I notice in interviews is that when I ask people what language they'd like to program in they answer "language X", even before I've told them the problem. This is disappointing in that they may have just picked a language which is not appropriate for the problem.  Never have I heard someone say, "Let me hear the problem and then I'll pick the language that I'll use to implement the solution". 

 

One reason for the current situation is that most people know only one language well and they use that language for all their work (it's the "everything looks like a nail syndrome").  Language specific frameworks are one reason why this occurs, and it's unfortunate that there's been relatively little work to make languages work well together (the CLR is one of the few mainstream attempts at this).  The result of this is that people develop expertise in only one language, or tend to follow the flavor of the year (apparently this was Ruby for 2005).  Unfortunately, even when people language-hop (from Java to Python to Ruby, for example) they tend to stick with Algol-style languages almost exclusively.

 

I must say that if such a curriculum does exist, I'd love to know about it -- it would be a great place to recruit from.

Comments

  • Anonymous
    December 29, 2005
    The comment has been removed
  • Anonymous
    December 30, 2005
    I agree with your basic thesis - that software engineers should be fluent with various languages - but I don't think the problem is as extreme as you state. Most programming problems - say 80% - can be addressed efficiently with "conventional" OO programming, and realistically, any one of the top languages will do - C++, Java, C#, and VB. Let's call that the "80% solution." In these cases, either the individual developer is free to choose the language they are most proficient at, or if they are part of a work group, they will typically accept the language choice already made by the group. This is what you call the "everything looks like a nail syndrome." I think this is actually very practical.

    The balance of programming jobs are more interesting - maybe a scripting language like Perl or Phython is needed. Maybe the "code" will run in an FPGA, so VHDL is needed. Maybe assembly. Maybe SQL or XQuery. These are the cases where a software engineer proficient at picking up and using different languages, and being able to wrap their minds around different paradigms will be able to get the job done.

    In the CS degree, I agree that the job there is to provide the basic foundation for teaching the compartive differences between different paradigms - for example, what the difference is between C++ and XQuery - not at a syntax level, but a higher level. I also thing that specialized classes should force students to learn a new language - for example, a database class should teach and the students should work in SQL, and not Java. But for learning basic "traditional" OO programming, I don't think it makes any difference if students learn Java, C++, C#, or VB.
  • Anonymous
    December 30, 2005
    Hi tazagotta, I'm afraid I wasn't clear enough. I agree that if you're doing OO programming simply knowing one or two OO languages is sufficient. I was really trying to say that leaving college being proficient at OO only is not sufficient. You really should be proficient at multiple paradigms, and fluent at various languages that can express these various paradigms. Furthermore, you'll be able to examine different types of problems through that lens.

    Using objects for every problem only makes sense when working through a textbook on object-oriented programming. Unfortunately, most people use object-oriented programming for every task, when often a better solution may be more appropriate. A good read is from Paul Graham here http://www.paulgraham.com/noop.html.

    If more people were proficient in more paradigms I think we'd see more solutions where we use more than just standard Algol languages, and the decisions on which paradigm to use would make sense because they thought through them.

    But I do agree that if you're doing OO programming then using C++, C#, and VB.NET are your best bets. But ask yourself -- why am I using objects? Is this the best way to express the problem I'm trying to solve? I think a lot of people would see they're cramming their problem space into a class hierarchy where they don't need one.
  • Anonymous
    January 04, 2006
    Kang,

    In your opinion, would you not think that C++ is a multi-paradigm programming language.

    For example, in C++ you can use the Procedural programming paradigm, you can use the Object Oriented Paradigm, and more recently you can now use the Generic programming paradigm all with in one language.

    Obviously, the problem space determines which paradigm is to be used.

    One last thing: sometimes it is not commercially viable to use a different programming language. As an example, I haven't heard of any commercial software systems being implemented with the Eiffel programming language. Although I may be completely wrong about this.

    Harish
  • Anonymous
    January 04, 2006
    Hi Harish, I do consider C++ multiparadigm, although doesn't cover everything.

    There are software systems built with Eiffel. Not many that I know of, but there are some.
  • Anonymous
    January 05, 2006
    UBC used to be such a school -
    year 1: scheme and C++
    year 2: C++, perl and Java
    year 3: scheme, C, C++, Java...

    had to program in at least 3 different langauges in any given semester after year 1. I found it very hard as there was not enough time to master either language.

    I don't fully agree with you though - it takes a lot of time and effort to learn one language well, and at least for me, it is pretty much impossible to master more than one. I used to be a pretty good Java programmer but had to switch to C++ 1.5 years ago. When I went back to write a small Java program 2 months ago, I found out, much to my dispair, that now I code Java using C++ idioms.

    Programming is tough and for an average guy siwtching from one language to another to implement a medium to large industrial strength application is not realistic. In fact my employer now has a policy of using just one language for all the development, something I disagree with, but understand the practical motives behind it.
  • Anonymous
    January 07, 2006
    Good post, Kang Su. I talk about this a bit too in my post. I'm waiting to hear what you have to say about MapReduce.

    Cheers,
    Robert
  • Anonymous
    June 19, 2009
    PingBack from http://debtsolutionsnow.info/story.php?id=13481