The programmers of tomorrow

A recent article written by Dr. Robert B.K. Dewar and Dr. Edmond Schonberg (both from AdaCore Inc.) is generating some discussion on the state of Computer Science (CS) education in the United States. In “Computer Science Education: Where Are the Software Engineers of Tomorrow?“, Dewar and Schonberg claim that U.S. universities are training unqualified and easily replaceable programmers.

“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 Posts:

14 thoughts on “The programmers of tomorrow

  1. Completely agree with you on all you have mentioned… But I do believe languages like Java have an important place in computer science. You could do the same functional programming in Java… but its really hard to keep a new programming away from using the libraries.

    Also from what I have seen… most people believe that having a good mathematical aptitude means you can be good at programming. I disagree to this view and instead suggest that you require more analytical skills than mathematical skills to be good at programming…

  2. Dear Saptarshi,

    thanks for your comment. Java has a place in CS education, but I agree with Dewar and Schonberg when they say that Java is not suitable as the first programming language.

    In my degree, for instance, I have been taught Java to learn OOP. But first, I’ve learnt the functional paradigm (Haskell), the imperative paradigm (C), and data structures and algorithms.

  3. Pingback: Binary Code » Follow-up Reading on “Computer Science”

  4. god damn this is the most intelligent BLOG article on the internet today…I totally concur

    Most CS people I know who call themselves programmers TODAY should be hit on the side of the head with a lead pipe

  5. Add the Netherlands to your list. Recent investigation here showed that over half of the students here lack basic skills on math and language.
    Schools focussed too much on getting the ones that fell behind back on the boat, that it missed out supporting and stimulating the ones with talent.
    Schools are also being paid for getting students through their exams, but not so much on doing so with quality of these exams.
    Also managers have taken over the schools. Teachers are not free to do their profession but have to commit to measurable, but not meaningfull, criteria.
    Students even protested that they wanted more math!
    Good thing though is that things are finally going to change. Hopefully these changes will get funds so they won’t fail.

  6. The industry and society needs some people skilled in math and willing to develop great algorithms, or great graphics libraries, etc. The greatest need is for people to understand the major concerns of software: software design, performance, security, etc. Exposure to data structures and multiple types of languages are essential, but I’ve never had to use any of the “mathy” classes I’ve used in school. Yes, if you want to write software for financial quants, you’ll need it, but let the students who want to study those subject take advantage of them. For most developers, they’ll be useless. I’m with Joel – there’s more of an art to good software.

  7. Dear The_Tzar,

    Thanks for your comment.

    I suspect the problem is general all over Europe (with some exceptions, of course). We’re also trying to change things in Portugal. In fact, I’m participating in an experience for testing some “new” methods on Portuguese secondary schools. Basically, the idea is to contrast a calculational and goal-directed approach with the traditional way of teaching mathematics.


  8. Dear Michael,

    thank you for your comment.

    You say that you have “never had to use any of the “mathy” classes [you’ve] used in school”.

    Have you ever been taught how to derive an algorithm? How to prove its correctness? If your answer is yes, then I wonder why you don’t want to be sure about the programs you write.

    Anyway, I understand your point of view and let me tell you that I don’t construct or prove all the code I write. But I don’t write code that will run in critical systems, either :)

    All the best,

  9. Pingback: Los programadores del mañana

  10. I totally agree with everyone here. But I have a question that can give me a straight answer. Maybe you can help me out. I programmed in VB and SQL Server, for a couple of years. Im now going back after 6 years of no programming expirience and would like to know should I learn C. Using Windows or Linux, I want to be marketable, what route should I take?

  11. Dear Miguel,

    I think it really depends on what you like to do. What I recommend is that, besides learning new technologies, you learn good theoretical foundations.

    I think it also helps to read books like “The Pragmatic Programmer: From Journeyman to Master” or “Code Complete” to get some practical tips.

    Other than that, remember that programming is about solving problems. And the more you solve, the better you get!

  12. I graduated 1972, EE. I observed that the best mathematicians made the worst programmers. (Tools were a lot less sophistocate then.) Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code. Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try. I seem to be able to break anything. Perhaps that is related to being new to a lot of things that I try, and supply the “stupid inputs” to things.
    Recent graduates, even into the 1980s, have little skill in isolating performance issues. I attribute this to no comprehension of what the code is asking the machine to do. An assembler, for assembly language on an IBM 360, exposed me to cycle counting for each machine instruction. Later, reading decompilations of high level code in FORTRAN, COBOL, and C, provided further insights to what we ask the machine to do. A CS curriculum should include at least one assembler-level course.
    Then, a course in approaches to performance profiling could also expose CS students to the inner workings of code. Even Order constant, n log n, n squared, algorithms can have significantly different performance profiles due to implementation. My continuing series “Travels with Mark” on IBM’s DeveloperWorks web site demonstrates one implementation of black box performance testing. The first one introduces a tool for profiling a database environment and some statistics behind the techniques. Subsequent articles explore the performance of different aspects of the database and application design decisions in coding techniques.
    This is all a level of implementation that most folk do not get an opportunity to explore in the working world. I have enjoyed doing it, and having the opportunity to write about and share it.
    Thinking styles: There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing.
    It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades. Very little changes except the facade. Bottlenecks move around through various hardware and system limitations. It is always fun to watch faces when you express an idea, “That is not going to work unless you can solve problem X.”
    I cheated, however. I later acquired an MBA with a strong technical component, which included several courses in statistics taught by a PhD statistician with a number of practical years of experience in industry. I took courses in undergrad statistics, but did not get a feeling for statistics until graduate school. I sense that the graduate TA, Teaching Assistants, really did not have a fundamental understanding of the statistics – simply an ability to apply the equations and tables. In the 1990s, after explaining the concept of degrees of freedom to my son taking a statistics course supports that suspicion. “Oh, that makes sense. Why didn’t he just say that!”

  13. Dear Mark,

    thanks for your comment. I have some comments and questions, too.

    “I graduated 1972, EE. I observed that the best mathematicians made the worst programmers. Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code.”

    I believe that the standard proof skills are not the most convenient for programmers. In fact, my PhD thesis is on proof skills for computer scientists; I’m working in principles and foundations of (calculational) algorithmic problem solving. My work is essentially a contribution for what Tony Hoare started and Edsger Dijkstra (and others) continued: exploring the mathematical aspect of programming and deriving programs from their formal specification.

    “Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try.”

    Unless you test all the possible inputs against all possible outputs, you can’t ensure that the algorithm meets its specification. Remember that testing can prove the presence of bugs, but never their absence!

    “Thinking styles: There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing.”

    Tools and languages change the way you think about problems. That is why some people prefer first-year students that never had any contact with programming.

    “It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades.”

    With computers going minuscule and ubiquitous, I don’t believe that distributed designs will go back to centralized!


  14. Pingback: formal proofs

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>