Sometimes the Perl community is pathetic.
Here's one way in that it's pathetic: not reading Object Oriented Design & Analysis books.
I hear a lot of arguments for not doing so. Many of them, given in all seriousness, aren't even on topic.
"I don't need to study Object Oriented Design because OO means strong typing and you don't need strong typing to do OO". What the FUCKING HELL!? Apparently Perl is the language for crack babies.
"Plan to throw one away". Yes, this is an ideal, and ideals are good. Assuming that the ideal scenario will play out is foolish. It's foolish to assume that you'll be willing to demand it even as you begin to have doubts about your job security if you demanded it and whether it's really in line with the clients interests. Over and over again I see development teams who are going to "do it right" setting out but then reality sets in and kicks their ass. So be smart, not idealistic, or else have really good job security and the authority to actually make the ideal happen, as well as the confidence to follow through.
"Design is of limited use". This one I strongly agree with -- "planning is NP complete", as I say. But I didn't say anything about planning the whole thing from the onset. That's a presumption inserted by the aruger to excuse themselves from studying OO design. If they don't need it up front, they can do it later, but they won't do it later either, because they don't know how because they won't frickin' read the classic texts on it!
Then there are an infinite number of arguments that take the form of "Java is known for that being serious about OO stuff, and Perl is better than Java, therefore Perl doesnt need it". Unlike the first example which was merely self contradictory, this one is actually circular, which you'd know if you studied formal logic, makes it invalid.
It's these blatent attempts at weaseling out of the less than fun parts of our *jobs* (read: paid to do them) that turned the industry off to Perl programmers. And I hate you for being lazy and causing the industry to go cold on Perl. Ignorance is false laziness. Don't do it. Go read _Object Oriented Design Heuristics_ today! It's language agnostic, it's classic (before this trendy dumbed down "OO is easy!" movement), it doesn't pull punches, it admits when things are hard, doesn't cock up silver bullets for you to try to lean on (and fail), and it'll make you a lot better programmer.
Point of clarification: the hatred doesn't apply to the parts of the Perl community that are actually working to bring (optional) strong typing to Perl, or otherwise steal from Java rather than hide from it and pretend it doesn't exist.
For nearly any programmer, there are some things that you just plain need, regardless of what language you're working in:
* Relational database design theory and the five normal forms
* Security -- validation, race conditions, in-band versus out-of-band signaling, other things
* Algorithms theory -- otherwise every program you make will be a mash up
* OO Design -- (or alternatively, the sort of meta-programming and software engineering taught in the wizard book) -- or else your program will start to seriously suck beyond a surprisingly low level of complexity
I know most of you guys didn't get a CS degree, and you used to be the sysadmin, or the typesetter, or the janitor... but if you're going to adopt this field, at least dig enough into the topics on which its founded to understand *why* they're needed. Honestly, it's easier than constantly arguing (first to yourself, then your boss, then to interviewers, then to the unemployement officer) why *you* don't need to know them.
-scott
Do you think there are language features which encourage more respect for OOAD in Java versus Perl? Do you think the way that people approach and learn both languages lead to different types of programming?
(I ask because I suspect that there's one strong trend involved, but I'd like to hear your thoughts here, if the questions are at all interesting to you.)
Re:Why?
scrottie on 2007-07-28T06:21:20
Hi chromatic,
I was thinking of emailing you to suggest plugging perlsurvey.org.
"Do you think there are language features which encourage more respect for OOAD in Java versus Perl?"
In some regards. The language, by design, treats it as important, so it encourages respect. And you'd have to have some respect for it to use the language, or be willing to learn respect for it, or else be willing to put up with a lot of pointless fuss for no good reason. The language itself doesn't help you with OODA, but the refactoring browsers in the IDEs people generally use when programming in it certainly help though obviously they can't do the work for you. An attempt to *help* the programmer with OODA would be comically disasterous, which gives me ideas for Acme:: modules...
Abolishing a global namespace; requiring a package declaration; disallowing multiple inheritance; defaulting to a "protected" visibility to require more permissive access to be explicitly declared. None of those foster OODA per se but they treat it like it's important. The programmer takes a cue from all of that fuss. Once they accept that they're making classes and deciding which interfaces are public, they'll be tempted to try to do a good job of it.
Of course, in each of those cases, the "feature" implemented was easier to implement than the alternative (multiple inheritance, etc). Except strong typing, which also sends a strong message to programmers about thinking through their class designs. In fact, strong typing forcing programmrers to think about subclass types seems to push them to subclass rather than compose.
Making contraversal decisions to take abilities away is a great way to communicate to your users that there are dangerous out there and constant viligance against them is needed. Python seems to have learned that trick well.
"Do you think the way that people approach and learn both languages lead to different types of programming?"
Absolutely. Before considering the backgrounds of the people starting out in either language, the environment they're currently in (size of the shop, detail of the specs), consider that you have to create interfaces and use interfaces to do anything non-trivial with the Java standard API. So a book teaching Java, such as, oh, _Java in a Nutshell_ (mine is pretty old and ratty) quickly takes you through the package, class, object, and method syntaxes before even showing you an example program (paint). Java programmers learn that to take user input, you have to implement the listener API. Going with the flow of the language will make most problems feel like matters of implementing APIs. As far as how people approach Java, I think they approach it a lot closer to how people approach Cisco, Oracle, or SAP -- as a career, one that might be fun but whose work isn't inherently so, and one that pays well thanks to the high level of professionalism maintained and protrayed with the help of the sponsor company.
It seems like Perl programmers are more likely to leave a job when human factors are neglected (as they would in a Java shop) and Java programmers are more likely to leave a job when technical matters (architecture, unit tests, etc) are neglected. Java programmers need the upper hand of, if not doing a good job, at least doing it _right_. Perl programmers just want to be your friend. Or so it seems.
Anyway.
Cheers,
-scott
Re:Why?
scrottie on 2007-07-28T06:24:59
"(I ask because I suspect that there's one strong trend involved, but I'd like to hear your thoughts here, if the questions are at all interesting to you.)"
I'm curious. What trend do you suspect?
-scottRe:Why?
chromatic on 2007-07-28T07:29:56
What trend do you suspect?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 fuunnel all code down certain paths 2) academic adoption and dogmatic teaching styles and 3) plenty of supporting literature.
Re:Why?
Aristotle on 2007-07-28T08:36:58
Whoa.
I think this deserves a post on your O’Reilly weblog. Seriously, that’s an excellent bit of insight that deserves to get some wider attention than a comment somewhere on use Perl.
Look, I tried to learn Object-Oriented design. I really did. I knew software engineering was absolutely the most important area in my studies. I shelled out thousands of dollars for a bachelor's degree and most of a master's degree. I took software engineering as an undergrad and got a jerk of a professor who didn't teach a thing. He was the only unsatisfactory professor I had. At the end of the course I seriously considered going to the dean's office and demanding my money back and credit for the course revoked. And in all seriousness, today I wish I had.
So then I took two software engineering courses as a graduate. They were helpful, at least, and the professor was much better. But somehow OO design still seems to be unteachable.
And so I tried to learn it from the three software engineering textbooks I'd accumulated. And guess what? They suck. I've seen UML designs for elevators, zoos, animals, and all kinds of crap. For some insane reason, they can't show me how to produce an object oriented design for an actual program. I have no idea why these books think I can learn to design a program when they only teach me to design things that aren't programs. I have no idea why the teachers thought so, either.
Actually this wasn't just true of the OO design. The design methodology taught without OO suffered from the same problem. In the middle of the second course I found myself wanting to beg the professor, "Look, can you just teach us how to use this notation to design a program that accepts two numbers as input, provides a menu of the four basic arithmetic operations, and then performs that calculation and gives the output?" Another thing I wish I'd done rather than just thinking about.
By now I should be an expert at this, but so far I haven't learned a thing about formal object oriented design. They told me it was astoundingly important, they told me the notation was the best invention in the world, but they still couldn't figure out how to use it to program.
Contrariwise, I actually learned a lot about OO design from Perl programmers and Perl documentation, and in every design experience with peers (work and formerly school) I'm told that my designs are usually highly admired. But I'm missing whatever I was supposed to get out of learning formal object oriented design, and it's because textbooks think they can teach it by showing you how to design an Aardvark.
Re:The texts sucked
chromatic on 2007-07-28T16:54:36
I've read (okay, skimmed) a lot of software design or OO design texts, and I've found similar things. Most of them suck, a lot. (Even our books have occasional howlers.) If I'm right and the design of Java can mitigate some of the damage of bad use of OO, then this doesn't matter so much for Java users; their programs will tend to converge on the local maxima which happens to be only slightly better than the global minima.
For programmers in languages which lack the "Everybody buckle up" philosophy by default, you can perpetuate some truly awful hacks without knowing it.
J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers. Most of the other million or so Perl programmers don't have that advantage. They don't get taught Perl in school, the Really Great Books All Programmers Should Read almost never include Perl, and the belief that "Hey, it's a scripting language and not all that serious, you can just whipuptitude something quickly in an afternoon" way in which many of them first encounter the language doesn't exactly lead itself to high disciplined programming right from the start. It takes a decent Perl programmer to read Design Patterns and see how to apply those ideas to his or her code (or, better, how many of them aren't necessary if you use Perl effectively). A Java programmer can just cut and paste the examples.
I'm not sure either way is more optimal than the other, and I'm not saying that bad Java is any less bad than bad Perl. However, it is my experience that most bad Java code is bad in similar ways, thanks in part to the language design.
Re:The texts sucked
jdavidb on 2007-07-29T11:16:10
J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.I think I'm going to put that on my resume.
:) Re:The texts sucked
jdavidb on 2007-07-30T13:56:58
Anyone know if O'Reilly's Head First Object-Oriented Analysis and Design is any good or not?
Re:The texts sucked
scrottie on 2007-08-01T06:03:18
Yeah. I hear ya. I don't think universities can teach computer security either. Sometimes, in some fields, the text books rock. I adored anthropology. The algorithms book I walked away from CSci with was... well, it was technically correct, but within the confines of that, it was as utterly unhelpful as it possibly could be. Java programmers, being interested in a career, go through Csci, but it's in the field, and from books off amazon.com, that they learn this stuff, just like the C++ programers before them who got out in the field, learned that design is really hard, slowly mastered it, and wrote books for their peers. I suggest _Object Oriented Design Heuristics_. I assure you, it does not suck;)
By the way, even having a Csci education makes you a minority among Perl programmers, I think...
So, basically, I agree with your comments, and I admire the position you're able to speak from.
-scottRe:The texts sucked
jdavidb on 2007-08-01T13:05:38
Thank you!
