use Perl

• perlapp (Score:1)

  by gav (2710)

  I've not used it much for GUI stuff, but I think PerlApp [activestate.com] is great. I make simple installers with NSIS [nullsoft.com] and I've never had any problems. I've shipped apps to a dozen or so companies (many who depend on it for the day to day running of their business). Perl saves the day again!

  Something that is on my todo is to learn wxWindows, so I can write stuff that will work on Linux/OS X/Windows. I attempted to learn it once but found the lack of documentation frustrating. I don't really have much of a choice as I've h
  • Re:perlapp (Score:2)

    by Ovid (2709) on 2002.12.11 18:25 (#15352) Homepage Journal

    I have to confess that I also disagree with him from time to time. For example, in his latest article, he writes the following:

    Becoming proficient, really proficient, in just one programming world takes years. Sure, lots of bright teenagers learn Delphi one week and Python the next week and Perl the next week and think they are proficient.

    On the surface, I agree with that. I was certainly one of those cocksure "I can program anything" types and I faced my comeuppance once I started hanging out at Perlmonks and seeing real programmers in action. ("what's an adjacency list?", "what's this stuff about decoupling?"). However, he goes on to write (emphasis mine):

    Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff.

    That's where I take exception with him. Any time someone uses or implies superlative terms like "all", "never", "only", etc, then there's probably a flaw in the logic (and it sometimes paradoxically makes the person using it sound like an expert).

    Case in point: at my work, our Python programmer isn't terribly familiar with a Windows environment and he knew nothing about Python when he started working on his projects, but he picked up Python in a week. He's a good enough programmer that he knows how to design things well, how to refactor, and with a bit of prodding from me, he's even started testing. The payoff here is obvious. When he finds a problem that he's not familiar with, his overall programming background is strong enough that the problem is rarely a systemic one that turns everything into a ball of mud. Yes, it might take him a little longer to figure out what the problem is, but he's going to get it solved.

    In short, I'd be happy to take someone who's inexperienced with a given set of technologies so long as they can demonstrate that they know how to build things well. Few problems are insurmountable when you have the right technologies and the right mindset.

    Reply to This

    Parent

    • Re:perlapp (Score:1)

      by koschei (147)

      This argument is also known as the "university education" argument.
      
      The idea being that in university you pick up your theoretical knowledge, all the concepts and ideas, and have some practical applications of said knowledge (usually in some either ancient or obscure language).
      
      With that knowledge, you can pick up any language.
      
      You then have the joy of adjusting to management who give 'fun' specifications.
      
      Others seem to think that theory is bunk and you become a good programmer merely by doing lots of prog

      --
        ---ict / Spoon