I think the primary reason is that Perl is too individualizable, by far. Yes, I said too individualizable. That strength of Perl - TMTOWTDI - is its biggest weakness when it comes to working in groups.
When it comes to programming applications, the key feature of a good workflow is managing change. Every application will have change come down the pike. A new feature, an overeager salesman, a bug found, or an idiotic CTO - these all bring about changes. A good workflow will build an application that manages these changes without compromising the application's ability to manage subsequent changes. A team of decent Perl developers will easily be able to build an application that does this. But, how long is the ramp-up for a new developer? What happens when one of the initial developers leaves?
Java, on the other hand, does not give you all that freedom in how you build your application. There is no TMTOWTDI Ave. in Java City. This inability to express yourself is a strength when it comes to managing turnover. Every Java application in existence looks a lot like every other Java application.
Furthermore, Java offers a set of guarantees that Perl simply cannot do because of the design tradeoffs inherent in the language. For example, there is absolutely no way to declare something invariant in Perl. In Java, invariants are a normal part of the language. Perl also has no way of guaranteeing the type of a given variable. Java and Haskell both have this feature. You cannot turn off monkey-patching or any of the other runtime poking that is one of Perl's greatest strengths, not even lexically.
And, to top it all off, there's such a huge variety in feature strengths that a Perl novice simply cannot comprehend a Perl master's code, let alone a guru's. Every Java developer can read every other Java developer's code.
Given that some programming teams turn over a developer every week, which language should they choose?
I think this is where Task::Kensho and the like really have milage - providing a standard, but still with options.
ReplyDeleteI agree this is a problem, particularly as I spend more and more time acting in the manager role. I do think that slowly the community is starting to create a reasonably wide set of agreements regarding best practices and how to solve common problems such as deployment, etc.
ReplyDeleteBut yeah, most perl shops are so individualized as to make it hard for newcomers, while the core, original programmer group spends more and more time in knowledge transfer and in keeping all the plates in the air.
Maybe I worked with "exceptional" programmers at previous jobs, but I must say that Java has plenty of avenues to confuse and deceive a new project member. The syntax may be consistent and simple, but the waterbed theory of complexity strikes again--there are a maze of twisty little files, all alike.
ReplyDeleteJava _does_ have many ways to do it; it's just less apparent.
ReplyDeleteOn the surface, all you see are objects and method calls, so it looks clean an coherent. It also looks "readable", because the source code is mostly composed from english words. But if you want to really understand that code, you must jump through dozens of classes to get a grasp of the global design ... and that global design can be done in many, many different ways.
Designing a proper OO hierarchy is quite hard, especially if the language forces you to use the OO paradigm in situations where other paradigms would be more appropriate. This is why Java programmers are so deeply in need of "patterns" to help them shape things properly. But even with patterns, there are several degrees of freedom; this is where programmers "express themselves", which can lead sometimes to beautiful designs or sometimes to to horrible lasagna code (the OO version of spaghetti code).
Does that mean you disagree with your own blog post? =)
ReplyDeleteI think there's an important distinction between someone new to a language and someone new to a project. For a new developer in a new project, the difference between perl and java is significant. But for an experienced developer in a new project, the difference between perl and java is not significant.
I have not too much to say, because I don't know java.
ReplyDeleteAnyway, this get me some point of view:
http://www.java.com/en/about/
http://www.perl.org/about.html
http://www.cpan.org/ports/
I think the language is not the main issue, in teams/projects management.
In Perl, there is more than 1 way to do it, and usually, that's what gives you the option to make it pretty. It's like creative writing.
ReplyDeleteIn Java, you're stuck with the way that the language designers prefer, and it may not be that great for the particular code you're writing.
But your development team has to get it. The goal is easy to maintain code. You can't stop on the first iteration of code that meets the requirement. You're not done yet if it's still ugly.
I spend a lot of time squashing bugs on a 10 year old code set. On the first pass, my average solution is 20-30 lines of code. I usually check in 5-10 lines by the time I'm done. That's less risk of change to the system, and 1/2 to 1/3 as much code to support in the future. And it's pretty.