Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.)

    • 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