[Edu-sig] re: College CS courses

[Matthias Felleisen]

Alan Gould writes: 

>  Certainly CS courses used to cover all of those areas.
>  Now they appear to have become merely programming courses, 
>  and even there only within very narrow boundaries 
>  - Java and VB!

> It seems likely that we will now stop recruiting CS grads and hire job
> changers or ... 

> Thanks for your comments, they do seem to reflect the current CS trends.



Alan,

you shouldn't conclude from a single response, which comes from the .net
 world and not from the .edu world, that colleges ignore what's happening
 in the real world. Indeed, the trend to teach just Java and VB **IS** a
 reflection of this trend to accommodate the "real world". The problem is
 that it reflects the perception of fashion-prone colleges not
 history-sensitive reality.

I am a professor of Computer Science and I believe that Computer Science is
 about the construction of software. This includes many things: 

 - programming and design of programs, cross-language programming
 - specifying functions, modules, systems 
 - requirements engineering
 - integration of software packages 
 - generation of programs from specs
 - maintenance, including run-time checking of all forms 
 - software analysis (`a la soft typing in Erlang, since you're in telecom)
 - testing and debugging, test suites
 - integration with an existing OS and machine 
 - stress testing and performance debugging 

 This is a random ordering and covers the essentials. There are other things
 that they need to know, but they are best taught in a business school
 setting. 

I also believe that a CS program should dedicate the first three years of
 an education (the US assumes a four-year program) to the _principles_ of
 software construction and the last year to buzz words. Currently, it's
 almost the opposite at many places.

I have seen Berkeley's approach, and it's probably close to what you want.
 (I know about Stanford and I don't think the post from Berkeley described
 the situation properly.) I know Rice's curriculum, and I find we do many
 of the above but lack people who do a lot of software package
 integration. I know that Indiana teaches an approach like the one I
 described. 

In general though, universities and colleges have three problems with
 teaching "software construction" rather than some "stuff in JAVA:"

First, they believe that they must cater to their students. Whatever
 students want is taught. Of course, an 18-year old doesn't have a clue
 about the long-term needs of a CS career or software company. An 18-old
 knows what he did for his latest internship and that's about it. For these
 internships they use JAVA and VB, so this must be industry
 relevant. Right?

Second, professors are really paid for the research they conduct. Like
 software products, research is **feature driven**; studying the process of
 software construction (I don't mean management). Trying to figure out how
 to produce software that is by an order of magnitude more maintainable
 than today's "stuff" is just barely ever rewarded. It's too long-term
 oriented. As a result, researchers focus on data structures, algorithms,
 and small programs/libraries. Few of us direct large teams of programmers
 in a software project. (My PLT SCHEME project consists of some 12 people,
 distributed over three universities. That includes one staff programmer,
 two assistant professors, and eight students. That's not a small project
 for a university, if you count software integration as a necessary
 property. I bet it's tiny compared to what you know.)

Third, we don't have the resources to teach all these topics. We cannot
 truly emulate the industrial context that (large) companies assume. We
 don't do it. We don't have the software basis. We don't have the staff to
 grade such things. How should we know how to teach it?  

For years, I have given course in which students build a product over the
 semester, exchange products among teams, get down-graded when they want to
 "purchase" an intermediate solution. When I finally got to teach it, my
 average enrollment went down from way above the average of a Rice
 sophomore course to just below. Those people who make it thru love
 it. They call it "software bootcamp" and say "it's worth its price." For
 years, I have pushed that other professors adopt a similar model and teach
 the contents and the software process at the same time. (My course is
 *NOT* our SE course.) You may guess how many did.

This summer I am moving to NORTHEASTERN UNIVERSITY in Boston. This is a
 "co-op" university where students spend one year in industry (in addition
 to their summers) and then come back to study more. This is like the
 programs of "Technische Universitaeten" in Germany, and I know that it
 taught me a lot about the real world. (It even induced a switch in career
 plans.)  I suspect that these kids know more about the requirements of a
 true job, but I am afraid that they too will confuse the use of JAVA or VB
 for their latest co-op period with the use of insight into software
 construction.

What we need is that people like you come to universities and speak
 out. You must tell professors and students, time and again, that focusing
 on JAVA and half-baked OOP isn't going to be it. Tell them to start with
 Scheme or Python. Tell them to bring Java in when students know how to
 program. 

They won't believe this if they hear it from the few colleagues who care
 about the process (not management). They may just believe it if industry
 representatives like you say so again and again.

-- Matthias

Matthias Felleisen
Professor of Computer Science
Rice University

For a new way to look at the world of high school computing, see 

 http://www.teach-scheme.org/
 http://www.htdp.org/

"Computer Science is no more about computers than astronomy is 
 about telescopes."	
                                             -- E. W. Dijkstra