Scott Walters recently ranted on how Perl programmers tend not to perform OO analysis and design, at least when compared to Java programmers.
Setting aside issues of language design–though they’re important, I think there are other insights available–it does seem as if there’s much more literature available for developers who want to design large systems in Java than there is for developers who want to design large systems in Perl. (I operate from the assumption that the number of people who could write a program in Perl is probably the same as the number of people who could write a program in Java, if not greater, so I set aside questions of market size as well.)
Aristotle Pagaltzis suggested I repost my analysis here. In short, it’s all about the teachers.
Java ended up as the de facto teaching language because Pascal was the teaching language of the previous generation, C++ was too baroque, Smalltalk was too much unlike Pascal, and when “How to Use Excel” is a CS class, there’s no way you can think about teaching undergraduates Scheme.
Though there were still a few books written about Smalltalk or Lisp in this era, non-theoretical CS programs moved to Java in the late ’90s, hence Design Patterns mixed C++ and Java examples (and thus many of the more severe problems of that book). A lot of the great Smalltalk programmers I know moved to Java because it had momentum. You can go to OOPSLA (or more likely the POPL track) and hear about Haskell, ML, Ocaml, Smalltalk once in a while, and lately Ruby, but even a lot of academic research uses Java and the JVM. (.Net and the CLR have grown as you might expect in the past few years.)
I can’t entirely account for the fact that the dominant development environment of the dominant desktop platform was Visual C++, but I do think the academic adoption of Java has led to a focus among newly-minted Java programmers that There Is One Right Way To Do Things. It helps that the language design encourages One Right Way, though I remain unconvinced that that principle is useful.
Maybe calling this all one trend is conflation, but it seems a mixture of 1) deliberate design choices to funnel all code down certain paths 2) academic adoption and dogmatic teaching styles and 3) plenty of supporting literature.
Hey. Thanks for the write-up.
Another thread talked about how terrible OODA classes are. I haven't taken one, but I suspect that universities are as unable to teach OODA as they are secure programming practices. In my experience, Java (and C++ programmers before them) learned it from each other and from books written by peers, not from terrible text books or ill-prepared instructors.
I'm not sure (not that you suggested as much exactly) that it's that Java programmers learn OODA in school, such as that they went to school. If they went to school for it, it's probably a career for them -- something not necessarily fun they're doing to make money, and something that they have to feel that there is an educated way to do and an uneducated way. In other words, if they can't be snotty about the subtly and nuance of OO, what was all of that money and hard work for, and does it justify the fat salary they landed because of it?
Many (most?) Perl programmers are self-taught. We didn't get into Perl as a career, not originally. Our employers asked to do it, or it was the tool at hand, or we were programming for fun before people started paying us to do it. Perl programmers don't refuse to work on messed up code bases (though we do try to avoid it). We don't walk out the door if there isn't a formal enough design process. We usually accept verbal specifications without even thinking about it. When projects fail, we don't come back and say, "well, it wasn't our fault, we hired the best architects!". And, I think, that's why people like us: we're not snobs.
But, as with all things, the OODA snobs just happen to know something, even if they are snots about it. I think it would rule to know what they know but still be mellow >=)
-scott
Another thread went along the lines of (paraphrasing someone else), "I went to school
I was in the last year of students at the University of Newcastle (Australia) to learn C++ before Java became the language of choice for the CS department. I really thought going to Java from C++ was a downgrade.
After reading Mastering Algorithms with Perl (with the apt subtitle "Practical Programming through Computer Science") I was convinced that instead of moving to Java they should have moved to Perl.
Phil Crow's articles about Design Patterns on Perl.com and Mark Jason Dominus' What Design Patterns Aren't also drive home how practical Perl is with relation to OOAD -- Perl has a lot of the stuff you need already built in, and from what I can tell, Perl6 is going to have even more :)
I reckon when I finally finish my PhD (which involves OO design of games with Perl) then I might just go back and teach CS... with Perl!
Nice rant and nice article. I've read Scott's Perl Design Patterns wiki a lot - thanks for that!
In Java, every program must be OO so you can't leave the gate without knowing OO. Java got enough development poured into it to make it suitable for writing big applications because (a) Sun likes money, and (b) people saw Java as a kinder gentler C++ and were eager to jump off that ship. Perl 5's OO is a bit of a parlor trick - it's amazing how well it works - but when people write big applications (as in, many programmers working on them) the environments they're in (think, say, designing ships, traffic control systems, brokerage account balancing, MRI control interfaces, that sort of thing) they tend to want strict typing as a safety net.
Here's something that happens to me with depressing regularity these days: I learn of a book with a neat title (e.g. Feathers' book on legacy code) that's not language-specific; the synopsis says the book is language-agnostic, and so I get it, hoping for some cross-pollination kind of learning. And then 95% of the book turns out to be completely Java- or C#-specific with no applicability to Perl at all. Like most design patterns, which are designed to deal with problems caused by strict typing.
I really want to get some advanced teaching on OOAD that isn't almost completely wrapped around strict typing issues. Scott's wiki is good for that (http://www.perldesignpatterns.com/). UML hasn't been as useful to me as I'd hoped because of the same typing constraints. Periodically I go looking for OOAD classes in wherever ACM is getting its classe from and the only options turn out to be completely focussed on UML or Java. About 10 years ago I took a very good OOAD class from the Learning Tree that really was language-agnostic. Doesn't exist any more. Their closest equivalents are classes on UML or Java. Sigh.
"Why is there more OOAD in Java than in Perl?"
there is a simple answer: because in Perl you can get away with it. Not so in Java, if my limited experience help: if you screw the design, you'd better start from zero or resign yourself to a life of misery, pain and RSI.