in reply to (jeffa) Re: Perl versus VB
in thread Perl versus VB

Having been there, done that with Visual Basic (i literally converted from it to Perl back in February of 2001), i can say that i no longer desire to build applications with Visual Basic (same with .NET). I really liked MZSanford's "lacks heavy lifting features" con for VB, it really says a lot about why Perl is a favorite tool for those programmers who like to get stuff done (and still have some teeth and/or hair left at the end of the day).
I'd really like to add onto this. A few days ago I started in on a project at work. From the specs I could probably write a ten to twenty line perl program, have the problem solved and get back to my other more important projects. But no, I get to do the work in LotusScript (it's Visual Basic for Lotus products. It's 95% identical to Microsoft Visual Basic). Ugh! All in all the things I've found myself needing are a SQL GROUP BY/SUM/COUNT aggregator (except without SQL), hashes, arrays, regular expressions and the spiritual equivalent of anonymous code references.

VB does have hash (called "List") and array support but it's extremely poor. I had to spend a good portion of my time writing some Hash and Array classes so I'd get all the things we take for granted here in perl (untyped variables, push, pop). I substituted VB's Like operator for a regular expression and got my anonymous code references through Execute which is somewhat like eval STRING except that all communication has to be done via globals. All in all I had to work a lot harder to get to (somewhat) the same place as the perl code could have gotten me.

I still don't have a fully functional Array class but I didn't need things like shift, unshift so they didn't get put in. The Hash class works well enough I guess. The Like operator cannot be compared to regular expressions because you lose so much functionality. The code I wrote is inflexible in it's pattern matching support so if I ever need real regex then I can ask the client to go pay $200 for a license to VB Regexpr.

The last bit though - code references I'm somewhat afraid it's not maintainable since I don't think my team has spent much time thinking about eval "". I'm sure they could pick it up but still... it's significantly scarier code than it would have to be if I were writing perl.

I think the net effect is that VB can get you to the same (mostly) place as perl. You just have to work much, much harder and be more creative. Oh and it takes longer as well.

Replies are listed 'Best First'.
Re^3: Perl versus VB
by Aristotle (Chancellor) on Jan 18, 2003 at 18:10 UTC
    I think the net effect is that VB can get you to the same (mostly) place as perl. You just have to work much, much harder
    That's a non-statement. Perl is implemented in C, which is compiled to machine code, so by definition both C as well as machine code can get you to the same place as Perl. The same applies for most any non-crippled language. I'm not sure anyone would be insane enough to try machine code for most of their tasks, though.. :) (And that's not to say I even hate machine code - written in assembly, anyway. When I do need it, I love it - getting another 400% speed-up after you did all your algorithm homework is great. I've done a bit of low-level graphics in my time and enjoyed that a lot.)

    Makeshifts last the longest.

      I think the net effect is that VB can get you to the same (mostly) place as perl. You just have to work much, much harder
      That's a non-statement. Perl is implemented in C, which is compiled to machine code, so by definition both C as well as machine code can get you to the same place as Perl.
      What are you on? I'm comparing VB to perl as practical languages for real work (as in what I spent most of yesterday doing for pay). You're saying that they are both of equal power because at root, they can do the same things. I'm saying that perl has more shortcuts than VB does and as such it's more effective (in that sense) as a business programming language. Of course, I didn't use perl because my database doesn't support it and neither does my development team (of which I am a member). That isn't a a quction about what is possible, it's a question of what is possible given other constraints.


      Fun Fun Fun in the Fluffy Chair

        I said any complete language can do the job any other can, somehow. Nowhere did I imply that this means all languages are created equal (in fact, very much not so), and nowhere was I disagreeing with you or making any statement about your (non-)choice of VB or anything else. You mentioned that VB gets you places at a much slower pace than Perl - I was pointing out that in fact, the pace is the only criterion when considering a language in the abstract (outside other factors you mention like team compatibility, PHB mandates etc).

        Makeshifts last the longest.