Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Kinyon
    ... I didn t say problem domain . I said project specifications . There s a big difference. Also, not to be confused with project requirements . An example
    Message 1 of 58 , Apr 7, 2005
    • 0 Attachment
      > I wondered if anyone was going to go that route, and you have. So you
      > agree that choice of language is relevant, given a problem domain.
      > This belies Nagler's insistence upon hammering in screws (witness his
      > attempt to find theorem proving software written in Perl) and his
      > constant question "what can X do that Perl can't?"

      I didn't say "problem domain". I said "project specifications".
      There's a big difference. Also, not to be confused with "project

      An example specification would be "Must be completed in 4 man-weeks."
      The choice of tools (of which programming language(s) is merely one
      item) has an impact on whether that specification is met or not.

      Another specification might be "Must be able to run on the
      aforementioned 324928 different platforms seamlessly." Programming
      language, obviously, has an impact on whether that spec is met or not.

      Obviously, problem domain has an impact on choice of programming
      language. However, the impact isn't what you think. Let's say that we
      have an application that, among other features, will provide a
      theorem-solving capability. Maybe, as is often the case in Perl, we
      call out to a Haskell/Lisp/Prolog/whatever module. Now, this is most
      often done going out to C through XS, but Inline makes it simple to go
      to any language you want. Parrot will make this even more ubiquitous
      with Perl6 / Ponie. So, maybe we delegate the handling of the
      nuts'n'bolts of that specific feature to another language and code the
      glue in Perl.

      Or, maybe Perl is the right language to provide a theorem-solving
      capability ... IN THIS PROJECT. Maybe you need to provide
      theorem-solving capabilities across 200 different OSes from the Palm
      to *nix to Win32 to Mac to an AS400, all from within the same codebase
      that will only have 3 developers on it under massive time constraints
      for development. All of a sudden, a PurePerl solution starts to sound
      a lot more appealing, doesn't it?

      Now, I will grant you that this is a contrived example. But, it's no
      more contrived than the project I work on currently. It's a web
      application, half in Perl and half in Javascript, but the supported
      browsers go back to NS4/IE4, supported OSes back to Win95 and OS9, and
      it must support Japanese characters on all of them. No specs, tests,
      test-team, original developers, etc. It runs on a custom-built
      webserver written in C (no original developers) running under Sun's
      iPlanet, using custom-built session-management based on IPC, written
      in C, with (you guessed it!) no original developers. Bugs in the
      custom components cannot be fixed because that would entail manual
      ad-hoc testing of 5 separate applications, so they must all be worked
      around separately in each application. And, this application was
      officially retired 3 years ago, but had new income of over a million
      dollars last year alone. I couldn't make this up if I tried.

    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
      • 0 Attachment
        Greg C wrote:

        > Consider: projects A and B have identical goals. In project A, you
        > have free
        > rein in your choice of software and hardware tools. However, the
        > manager sets
        > arbitrary deadlines, likes to stand behind people and criticize their
        > code as
        > they type,

        Wait. That sounds like Rob ....
        ;c) (kidding)

        > On project B, the choice of langauge and hardware are made for you and
        > there's
        > only one computer per two programmers. On the other hand, the manager
        > sees his
        > people as people, negotiates requirements and schedules on a realistic
        > basis,
        > trusts his people, follows a set of best practices (be it XP or some
        > other) and
        > chases everyone out of the office at 5:30.

        Wait. That *also* sounds like Rob ...


        (not kidding!)
      Your message has been successfully submitted and would be delivered to recipients shortly.