http://qs321.pair.com?node_id=483392


in reply to Learning ***** as a second language

OK: Java! Java!. But here's why I think so.

Perl is just plain *wonderful* -- up to a point. It lets you do some pretty sizable jobs with incredible ease. But there comes a point where the job gets bigger than perl (or any other scripting language) can handle. For big jobs, where you'll probably find yourself collaborating with other developers, you need an industrial-strength 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.

(Sorry, much as I love perl, I don't consider its OO support one of its strong points).

Lots of languages inhabit the space that lies beyond above scripting languages, and I'm not familiar with most of them. But I like Java. IMHO, it has got OO just about right: not as kludgy as C++, but usable to do real stuff, unlike more academic offerings like Eiffel.

Java's not as facile to code in as perl (no surprises there). But that's where tools come in. To program in an IDE like Eclipse is a completely different experience. A lot of the heavy lifting is done for you.

Eventually, you may find design tools, such as one of the numerous UML packages, useful for doing really big jobs.

Go down this route and, as an earlier Anonymous poster suggested, you will "learn about the essentials of computer science which will make you a better programmer". In the process, you may find your way to a few things that are more enjoyable (and remunerative) than Sysadmin jobs.

But you'll still find that, for the small things that need doing every day, there's nothing like perl.

-- Dinosaur

  • Comment on Re: Learning ***** as a second language

Replies are listed 'Best First'.
Re^2: Learning ***** as a second language
by adrianh (Chancellor) on Aug 13, 2005 at 08:49 UTC
    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.

[reply]
      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