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.
  • The situation with Java comes down to one thing. Protection before execution.

    Java has a simple structure, it's easy to parse. So the editors and toolchain can be made SO much more rich for Java than for Perl.

    Then do extra checks at compile time, that we can't do.

    They have the equivalent of strict and warnings on by default.

    All of these checks are aimed at weeding out evil as early as possible, and managing it when it happens (exceptions).

    Of course you can write evil at the level above where the toolchain ca
    • The situation with Java comes down to one thing. Protection before execution.

      Don't forget lackluster abstraction possibilities, a huge standard library, the mad rush to standardize on One Giant API To Do Things, and programming, configuration, and deployment mechanisms that emphasize Lots of Little Fiddly Bits .

      The amount of damage you can do has some correlation to the amount of productivity you can achieve.

      (There's probably a more profound point related to the idea that there are very few system

      • Don't forget lackluster abstraction possibilities, a huge standard library, the mad rush to standardize on One Giant API To Do Things, and programming, configuration, and deployment mechanisms that emphasize Lots of Little Fiddly Bits.

        The key isn't to live in what Brian Eno would call the "small here" or the "short now". Computing is an evolving story, and what we've seen so far is just the opening chapters.

        If you look back 20 years, microcomputers were a stifling platform, because of their anemic resources, and the need to program everything in either BASIC or Assembly. BASIC was good enough for the small little fiddly bits, but anything real required tricksy uses of Assembly. Things only started to take off once Pascal became widely available.

        But Pascal was a cruddy language for large scale programming. And soon enough, we had C and C programmers. The good thing about C was that it was close enough to the metal that you could get acceptable performance and build things as complicated as Windows 3.1 that ran quickly enough and almost reliably enough to do something useful with these little boxes.

        Yet C is a crappy language for the majority of people writing software. As Joel Spolsky points out, there are entire classes of programmers who can't really deal with pointers, manual memory management, buffer overflows and the like. When it comes down to it, you shouldn't have to worry about pointers or memory management when your task is writing an accounting system or a group calendar.

        If you take the long view, all of these languages were just shims to let us get something done while we waited for the hardware and software tools to catch up to where we need to be. If Java has a poor abstraction capabilities, a hugely complex standard library, it's because as an industry this is what we needed for a large class of problems. It also helps to put a nail into the coffin of second systems and gratuitous complexity. Everything that follows Java will need to be a third system (or greater), and benefit from an analysis of where Java went wrong.

        Another way to look at it is that Java is solving a problem of managers who would rather reduce risk at the expense of increased power and productivity. Until the tools, education, and computing power improve, we will still need rooms full of programmers doing uninteresting work using tools with blunt edges. Small teams that are skilled enough to run with scissors will still be able to use Perl, Lisp, Haskell, Smalltalk and other such "esoteric" languages to get more done with less.

        • > Another way to look at it is that Java is solving a problem
          > of managers who would rather reduce risk at the expense of
          > increased power and productivity.

          That's a very negative way of looking at the problem.

          One thing managers are used working with that we aren't so much is the element of Trust as a malleable entity.

          When you work alone, or in small teams, you can learn a lot about people, and trust isn't a big issue.

          When you have big teams of people, or work with dozens of outsources, then you sim
          • That's a very negative way of looking at the problem.

            Not at all. It's the engineer's lament that the best solution frequently doesn't win. This is just a case where superior technology (e.g. Perl) is loses out to an inferior technology (e.g. Java).

            Trust is a significant part of the social issue here, and it's not something that open source can generally solve on its own. Linux and MySQL are thriving in large part because of the corporate umbrella provided by RedHat (et. al.) and MySQL AB that ma