|Think about Loose Coupling|
Perl / Java in larger applications - was: Re^3: Learning ***** as a second languageby Joost (Canon)
|on Aug 13, 2005 at 09:56 UTC||Need Help??|
Curiously enough I find languages like Ruby and Perl more effective at producing larger applications than Java.
I find that large(ish) applications in Perl tend to be a lot smaller / simpler than more-or-less equivalent applications in Java (measured in lines of code / number of objects/classes involved etc). Which in turn makes the program easier to understand and maintainable (and quite often faster) than the Java equivalent.
Partly this is because of the usefulness of perl's built-ins; arrays and hashes, which means you hardly ever deal with hand-coded "Value-Objects" (i.e. structs, listsOfMyObjects etc), the extremely compact and useful text-processing functions and simple conversion of numbers and strings (which help a *lot* when you're dealing with a large user-interface and is a royal pain in Java).
I'm sure another part is due to differences in programmer experience / skill and because the Java projects tend to have more programmers working at them than the perl projects. A project with many programmers of different skill-levels makes for more overhead, more explicit (and complicated) interface specs and many, many more class diagrams :-) (see mythical man-month; basically I'm claiming that not only does a project take more MM if you add programmers, the design also tends to be much more complex than necessary if you don't keep it under tight control). This has probably has little to do with the languages themselves, it's just the specific projects I've worked on, but see below.
One of the much-touted advantages of Java is that it enables explicit interfaces, class-contracts and large object-oriented design. Unfortunately (IMO) it also *encourages* large multi-layered designs and complex class-contracts / interfaces where they're inappropriate or even counter-productive.
In this respect, Perl is the anti-Java: it encourages compact, implicit code and has *no* explicit class-contracts by default. This can result in programs that basically have "no" design and are completely unmaintainable, but it also means an experienced programmer has a lot more choice on what parts of the pogram are "worth" spending a lot of design time on (which, I think, is why many CPAN libraries have much simpler APIs than their Java counterparts).
Basically, in Perl you design because you need to manage complexity, in Java you design *everything* because you just "have to". Personally, I know which of the two approaches I like best :-)