Re^2: Learning ***** as a second language

in reply to Re: Learning ***** as a second language
in thread Learning ***** as a second language

Funnily enough, it's just about at the point where perl collapses under its own weight that OO techniques become useful. This is also the point where a bit more design thought before you code starts to pay off.

Curiously enough I find languages like Ruby and Perl more effective at producing larger applications than Java. Seems I'm not alone in this.

Not that this is an argument against learning Java. Learning more languages is always a good thing.

Comment on Re^2: Learning ***** as a second language

Replies are listed 'Best First'.
Perl / Java in larger applications - was: Re^3: Learning ***** as a second language by Joost (Canon) on Aug 13, 2005 at 09:56 UTC
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 :-) "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]

Replies are listed 'Best First'.

Perl / Java in larger applications - was: Re^3: Learning ***** as a second language
by Joost (Canon) on Aug 13, 2005 at 09:56 UTC

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 :-)

"What should it profit a man, if he should win a flame war, yet lose his cool?"

[reply]

In Section Seekers of Perl Wisdom