Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday March 05, 2009
05:00 AM

Should We Do "Computer Science"?

[ #38596 ]

Universities are failing us.

From a paper entitled Parameterized Notions of Computation:

Examples of such are composable continuations, side-effects where the type of the state varies and input/output where the range of inputs and outputs varies. By also considering structured parameterisation, we extend the range of effects to cover separated side-effects and multiple independent streams of I/O. We also present two typed λ-calculi that soundly and completely model our categorical definitions — with and without symmetric monoidal parameterisation — and act as prototypical languages with parameterised effects.

Whoa! Pretty heavy reading. Now let's look at a description of Moose from the manual:

Moose is a complete object system for Perl 5. Consider any modern object-oriented language (which Perl 5 definitely isn't). It provides keywords for attribute declaration, object construction, inheritance, and maybe more. These keywords are part of the language, and you don't care how they are implemented.

Moose aims to do the same thing for Perl 5 OO. We can't actually create new keywords, but we do offer "sugar" that looks a lot like them. More importantly, with Moose, you define your class declaratively, without needing to know about blessed hashrefs, accessor methods, and so on.

Assuming you know Perl, that's pretty accessible. But looking at the first definition, what's "symmetric monoidal parameterisation"? I have no idea. The thing is, that's OK. I'm not the target audience.

I admit that I've been very annoyed at times with articles which present really cool ideas but do so in such tedious language that I can't follow it, but if it's not aimed at me, I can't blame the author. Other times we have works aimed at casual users, but the author fails to adequately address that.

So what I see a lot of is "comp-sci" people sneering at us for not using their elegant and beautiful tools and "I have stuff to do" people who sneer at those would don't understand the risks of implementing production code that you can't find developers for. This is unfortunate. To a certain extent, I see this as the divide between theoretical and experimental physicists. The first come up with grand ideas and the second cuts 'em off at the knees.

A better analogy, though, would be the difference between theoretical and applied physics. The former thinks about how things work. The second has to make things work. Neither can really function at peak efficiency if they don't have some grounding in what the other does.

In programming, I'm still struck by a comment that a really good programmer I know made about the Liskov Substitution Principle. He said "yeah, it's good in theory". In practice, we had some methods which had varying interfaces and we were using if/else statements to catch the differences. Admittedly, Liskov is sometimes problematic to apply because real-world conditions don't always map well to a class hierarchy, but like "using strict", you need to understand why it's important and, crucially, why you're not using it.

The problem here is ultimately the issue which Joel Spolsky has regarding "Java Schools". It's not Java per se which is the problem. It's the fact that people are learning to be McProgrammers and some programmers are turning out incomprehensibly complex frameworks that McProgrammers can't use, but are still aimed at them.

It's a serious divide in the software world. Many excellent "comp-sci" tools can make for simple, elegant code, but we're not teaching McProgrammers those tools. This appears to largely be a failing of our universities, but given that it's largely been easy to get programming jobs without a degree, I'm unsure of how we can solve this problem. We need the McProgrammers (and to be fair, there's nothing wrong with wanting to have a life outside of dense computer science papers), we need the computer scientists, but there's an awfully sparse array in the gulf between them and this group isn't able to do enough to bridge the gap.

We need universities to start addressing this. They need to start teaching:

  • Communication skills (there's a reason I listed this one first)
  • Automated testing
  • Source control
  • Working in teams on new code
  • Working in teams on existing code
  • Multiple language paradigms
  • Complexity management
  • Usability
  • More that hasn't occurred to me in this brief write-up ...

(I was tempted to add "manners" to that list)

Believe it or not, the best programming language instructors I had in college were two old COBOL programmers. They had real-world experience and they taught us things we were actually going to use. The worst instructors I had were my Java instructors. One was fresh out of university and had trouble explaining the difference between a class and instances of said class. One claimed real world experience but didn't understand MVC and had never done automated testing.

When I talk to new "university" programmers, they can write a heap sort from memory, they can explain complicated algorithms they've memorized, but they've often never programmed with anyone else and don't understand why deadlines are so important. (One was so steeped in his "one true way" that he mocked Perl programmers for not using linked lists regularly).

Business pressures mean that we'll always need the casual programmers who can churn out that log analysis tool because that's a real-world need and for the sorts of jobs that I work on, I often want them. Unfortunately, when I work on larger systems, I need to work with programmers who understand the importance of complexity management (watch the blank stares from many uni grads on that one), OO design and automated testing and deployment.

For those few times that (most) businesses need complexity, where do we find programmers who understand how to use adaptive resonance theory for recommendation systems? Where do we find the programmers who can take an ant algorithm and apply it to your delivery driver schedules? We need computer science and computer science needs implementers, but universities aren't churning out the graduates who can bridge this gap. Business suffers for it, no one really seems to care. We're limping along to where we need to go when we could at least walk, if not run.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • A good read. Should get a wider audience.

    Note you need to edit "explain explain" to just "explain".

  • I don't think the analogy with pure and applied physicists is correct. Working programmers aren't applied physicists: they're builders, or at most architects. Programming isn't a science, it's a trade, and I think what's missing here is some sort of degree (or other more vocational qualification depending on the educational system involved: I'm thinking of the sort of course that would once have been taught at English polytechnics) in Programming or Software Engineering, rather than Computer Science. Ideall
  • Nice article - just one observation. Assuming our Open Source ecology is working you don't need to many people to understand the intricate algorithms - you just need a few of them to capture the idea and encode it into a library :)
  • * Communication skills (there's a reason I listed this one first) * Automated testing * Source control * Working in teams on new code * Working in teams on existing code * Multiple language paradigms * Complexity management * Usability * More that hasn't occurred to me in this brief write-up ...

    Computer science is as much about computers as astronomy about telescopes, right?

    Everything you wrote up here is explainable within a couple of days. Most of it requires lot

    • Everything you wrote up here is explainable within a couple of days.

      I'd love to hire super geniuses like the ones you've taught, but unfortunately the rest of the world isn't nearly that capable. Some ten years in, and I'm still figuring out the nuances of automated testing.

      • Nuances are nuances. You do understand the principle points of it, eh? You're a bright fellow. Just like we all can do division, but the larger the numbers, the easier it is to screw up, and it takes time when someone does something screwy.
        • I can explain the principal points of functional programming to my five year old nephew in a few minutes, but even Abelson and Sussman spent more time on it at MIT.

  • A semi-serious question.

    Is it the job of universities to train people to do computing jobs?

    I completely agree that - by and large - a CS degree doesn't prepare folk for many aspects of the job of being a developer. But should it?

    Getting nostalgic for the old polytechnics...

    • I think it's the job of universities to teach their students the skills they need to succeed in their chosen field. If it's not computing jobs, that's fine, but if it is, they fail.

      • Universities have 3 basic missions:

        1. Advancing the state of knowledge.
        2. Exposing students to knowledge.
        3. Training students for future careers.

        These are listed in decreasing importance in the eyes of universities. From the point of view of most students, this should be in increasing order of priority. From the point of view of employers, this definitely should be increasing order of priority.

        Whenever a person or institution judges their performance by different criteria than outsiders judge them by, con

  • Applied Physics people explain how the idea might work in the real work with available materials.

    But in the end it's the engineers that actually make it work. :)

  • ...because people who set them give us paychecks. They are rarely important in the technical sense. Sometimes a project has to be finished before another which depends on it can start. More often, however, it's just a way for the boss(es) to assert their authority.
    • I've worked on deadlines which:

      • Which had severe legal consequences if we don't have it implemented
      • Which might save a client from bankruptcy if it was implemented in time (that one was not fun)
      • Holds up other projects if it's not implemented (many, if not most, of my deadlines now fall in this category)
      • Were simply part of a company struggle to stay alive

      Yes, I've worked on some projects which are simply management trying to assert authority, but that's been the minority. I'm sorry to hear you've had a dif

      • Well, of course my reply had a lot of tongue-in-cheek in it. However, the original post was talking about people not understanding the importance of deadlines, and this kind of talk is usually reserved to those of us who prefer to tell people what to do rather than do it.