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:
(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.
A good read. Should get a wider audience.
Note you need to edit "explain explain" to just "explain".
Re:Liked this.
Ovid on 2009-03-05T11:02:44
Thanks. And I fixed the "explain explain"
:)
The McProgrammers you mention are the equivalent of ordinary builders who know how to build a wall, or maybe a whole house, but don't have the higher-level knowledge of physics and (more importantly) engineering to design a large and complicated structure. There would be little point such a person trying to read a paper written by a physicist (pure or applied) and apply it to their day job: the research needs to be filtered through several layers of 'Engineer' before it can be useful to them.
I suspect the root of the problem here is simply that CS as a discipline is so very young. Most of the physics used in (say) construction is several hundred years old, so we've had time to find out which bits are useful and how they apply to practical problems. In CS we keep trying to take pure research done approximately last week and use it in working programs right now.
* 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 lots of practice. Being disagreeable while being agreeable is a skill you learn elsewhere, just like manners.
Most colleges teach using the pop language today, which to the fairness of the 3 schools I attended (looking at the course requirements), made up 6 credits out of 128, 8 credits out of 128 and lastly, 0 out of 64 credits required.
It sounds like most of your point is not knowing their terminology. In the non-scholarly world, most of what we build or interact with is fairly common stuff. A forum has posts and replies. A letter has a thread of correspondence. It out lay it out on a table, you have multiple threads.
When you talk about the theoretical complexity and classification, you have to use new terms. Describing them every time gets old, fast. The barrier to entry is knowledge. In your BS degree, you learn about the book. In your MS, you learn to read and enjoy the book. In your PhD, you learn to write the book.
We've all done the business concepts to death. The next progressions are a) stagnate and branch out into other goals, like making lots of money or other fields like biology and applying it there or b) LEARN MORE.'
I'll reiterate the list and demonstrate how silly these things are in comparison to real problems.
* Communication skills (there's a reason I listed this one first)
This is a tech writing and/or language of your choice Thing. We mostly learn this anyhow.
* Automated testing
There are 4 or 5 types of tests. These can be described within minutes. A day of practice, and you're done. This isn't a science problem, but a process problem that's being solved. You write stuff, you test it. You ensure you always make sure it works, even after changes to the target.
* Source control
File goes in, file comes out. Changes are tracked and copies are made.
* Working in teams (snip)
This isn't a computer science agenda. This is a life lesson.
* Multiple language paradigms
Turing complete. Any mess can be made in any language. Any masterpiece as well.
* Complexity management
Alogirthms teaches big-o notation and fundamentals. Anything much more beyond that usually requires a masters.
* Usability
UI usability? That's environmental psych. I don't usually rant like this, but c'mmon - a request to dumbing ourselves down?
Re:No!
chromatic on 2009-03-05T19:41:53
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.
Re:No!
exussum0 on 2009-03-06T12:31:27
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.Re:No!
chromatic on 2009-03-06T20:15:03
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...
Re:"We need universities to start addressing this"
Ovid on 2009-03-05T19:32:44
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.
Re:"We need universities to start addressing this"
btilly on 2009-03-06T08:55:10
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, conflict is inevitable. However do you really want universities to prioritize on career development? The ones that do, tend to be the ones whose CS programs are glorified Java schools.
That said, every field has a core that everyone is expected to know. My opinion is that the core for CS should include a good dose of software engineering. Which would include many of your topics. However I don't argue that just on its utility on the job, but because software engineering helps you reliably write the kinds of programs that CS research requires you to write.
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.
Re:Deadlines are only important
Ovid on 2009-03-06T07:04:54
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 different experience. That doesn't sound fun.
Re:Deadlines are only important
SimonHawkin on 2009-03-06T18:29:51
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.
