“It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire.”

The comment about Java’s adoption annoyed some Java aficionados, but in a recent interview, Robert Dewar adds that the problem goes far beyond the choice of Java as the first programming language. The real problem is that CS programs are being dumbed down, so that they become more accessible and popular. In result, they “are not rigorous enough and don’t promote in-depth thinking and problem solving”.

“A lot of it is, ‘Let’s make this all more fun.’ You know, ‘Math is not fun, let’s reduce math requirements. Algorithms are not fun, let’s get rid of them. Ewww – graphic libraries, they’re fun. Let’s have people mess with libraries. And [forget] all this business about ‘command line’ – we’ll have people use nice visual interfaces where they can point and click and do fancy graphic stuff and have fun.”

Although the paper is concerned with the American reality, I believe we have the same problem in Europe — at least, and as far as I know, in the UK and in Portugal. However, in my opinion, the problem starts before university. The maths’s programs in secondary schools are also being simplified (or dumbed down, if you prefer) and many important concepts, like logic and proofs, are being ignored.

In result, first-year students usually have a poor background on maths and problem solving. In fact, most of them have never seen a proof and don’t even understand the importance of mathematical reasoning. With poor reasoning abilities, they become intellectually less curious, accepting things as they are presented, and they have tremendous difficulties creating new algorithms, or convincing someone that their own algorithms are correct.

Moreover, once they are in the university, one of two things happens:

1. they are not taught explicitly how to solve problems or how to derive algorithms from their formal specifications (this is the most common case);
2. or they are taught the above skills but their poor background doesn’t allow them to fully appreciate these subjects.

What can be done?

Dewar and Schonberg suggest some skills to be taught:

“Students need to be exposed to the tools to construct large-scale reliable programs, as we discussed at the start of this article. Topics of relevance are studying formal specification methods and formal proof methodologies, as well as gaining an understanding of how high-reliability code is certified in the real world. When you step into a plane, you are putting your life in the hands of software which had better be totally reliable. As a computer scientist, you should have some knowledge of how this level of reliability is achieved. In this day and age, the fear of terrorist cyber attacks have given a new urgency to the building of software that is not only bug free, but is also immune from malicious attack. Such high-security software relies even more extensively on formal methodologies, and our students need to be prepared for this new world.”

I agree with every word in this paragraph! We really need professionals capable of creating certified software that works under all circumstances.

Joel Spolsky’s proposal

Joel Spolky’s wrote an interesting post where he suggests the following:

“I think the solution would be to create a programming-intensive BFA in Software Development–a Julliard for programmers. Such a program would consist of a practical studio requirement developing significant works of software on teams with very experienced teachers, with a sprinkling of liberal arts classes for balance. It would be a huge magnet to the talented high school kids who love programming, but can’t get excited about proving theorums.”

Obviously, this is a much more pragmatic and “hackish” approach than what Dewar and Schonberg suggest. He also writes:

“When I said BFA, Bachelor of Fine Arts, I meant it: software development is an art, and the existing Computer Science education, where you’re expected to learn a few things about NP completeness and Quicksort is singularly inadequate to training students how to develop software.”

I think I understand what Joel means when he writes that programming is an art. However, I prefer to call it a science. You see, art is subjective: it exists in your mind. We can both look to the same photograph or painting, and express different interpretations. A program, however, can’t be seen subjectively. Given a program, we have to be able to say objectively if it is correct (according to some specification) or if it is efficient. It is not a matter of aesthetic principles.

Other Comments

The author of Ekinoderm caught my attention when he wrote the following:

“When I got my B.S. (in 2003), I can remember students in my classes constantly grousing about how topics like Scheme or Finite State Automata were “useless” and we should spend our time doing “useful” things like learning how to use VB to make a database app or something. Or, God forbid, writing web apps in PHP.”

Interestingly, I had a very similar experience during my university degree. Many students in my classes didn’t like functional programming nor formal methods, because, according to them, these skills were useless to get a job; and they also didn’t like to encode the usual algorithms for trees or graphs in C, because their favourite language (usually Java or VB) already had libraries with the algorithms implemented.

On the contrary, I was interested in functional programming and formal methods. And I think I have benefited quite a lot from studying them. I also learned a lot implementing data structures and algorithms in C. Even so, and after several programming projects at the university, and a job programming Python for a company that offered Plone services, I didn’t feel ready for delivering certified programs (with proofs of correctness included). That was basically the reason why I have embarked in a PhD: I felt the need of programming by construction.

Final Notes

In 1975, Edsger Dijkstra wrote a famous note named “How do we tell truths that might hurt?“, where he enumerated some of the unpleasant truths about Computer Science. In the first paragraph, he basically explains why exposing truths (just like Dewar and Schonberg did) gives rise to so much discussion and discordance:

“Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. (Besides that, telling such truths is a sure way of making oneself unpopular in many circles, and, as such, it is an act that, in general, is not without personal risks. Vide Galileo Galilei…..)”

What is really amazing is that, 33 years later, some of the most unpleasant truths he enumerated are still true:

• Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
• The easiest machine applications are the technical/scientific computations.
• The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
• The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
• About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
• Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.
• Simplicity is prerequisite for reliability.
• By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.

To conclude the post, allow me to add one to the list:

As long as programming is considered a soft science and the formal derivation of algorithms is neglected, there will always be people enumerating unpleasant truths about Computer Science.

Related Articles:

• On Programming and Mathematical Methodology -- Part II
• On Programming and Mathematical Methodology