in reply to Perl versus VB

The only reason i can think of to use Visual Basic is if you are developing the application for a client that already has all of the necessary licenses or you are working for a certified Microsoft "dev shop" who provides all of the necessary code and documentation for you. That's not a good enough reason for me ...

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 should also mention, however, that the only GUI i use these days is a web browser. Programming in Tk reminds me too much of Java and web browsers have served my needs quite satisfactorily. There is Python of course, and if i couldn't use Perl/Tk to get the job done, i would most certainly use Python before i even thought about using ... what was that language again? ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^2: Perl versus VB
by diotalevi (Canon) on Jan 18, 2003 at 17:02 UTC

    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.

[reply]
[d/l]
[select]
      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.

[reply]

        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

[reply]
[d/l]

In Section Seekers of Perl Wisdom