http://www.perlmonks.org?node_id=329078


in reply to Visual Basic .net and Perl

/me agrees with Corion. I will NEVER have any real use for Visual Basic and don't even own it, but I don't regret having learned it. Nor do I regret having learned Fortran or Cobol, though I'm unlikely to ever use either of those, either. The only language I regret wasting time learning is Lingo.

Perl is a very practical language, and I think you'll keep coming back to it, but don't let that stop you from learning others; I'm not letting it stop me. When I was a novice programmer, knowing only BASIC (the line-number variety -- GWBASIC if you're familiar with that), I took a high-school class in Pascal. It revolutionized the way I wrote BASIC. I went back to BASIC, incidentally, rather than continuing to use Pascal, but just knowing a second language, different from the one I was using, had changed the way I thought about certain things and greatly improved the quality of my code.

In college I took courses in Cobol and Fortran, studied Inform on my own (which I recommend, incidentally; the way it does objects is just really cool, and the Designer's Manual is top-notch), picked up courses in C++ and Pascal (again, but Borland Pascal 7 this time, more capable than what I'd used before), and started using QBasic instead of line number BASIC. By this time I was writing things in BASIC that are not normally written in BASIC. Because it was the only language I had an interpreter for on my PC, but I was thinking (and programming) like someone who knew multiple languages. If I dig out that QBasic code now it's moderately embarrasing (all the languages I'd studied were either procedural or object-oriented, and it shows, and the only OS I'd used was DOS, and that shows too), but it was still way better than you normally expect to see in BASIC.

Then I picked up elisp and subsequently Perl and have not looked back -- except, my knowledge of those other languages (especially BASIC, Pascal, Inform, and elisp) greatly influences the way I write Perl. I no longer think in BASIC or elisp and translate to Perl like I did at first; I think exclusively in Perl now; in fact, I don't think I remember QBasic well enough to think in it anymore, and when I work in elisp, I find myself slipping back and forth between thinking in elisp and thinking in Perl. But still, my style is influenced by my background.

After Perl, I learned enough Python to get a basic feel for its style and had a brief look at PHP. I came back to Perl, but I don't regret the time I spent learning those other languages. Now I'm in the process of learning scheme, which I'm pretty sure I won't ever use on a regular basis, but I want to understand some of its concepts (continuations, particularly) in order to expand the way I think about programming. I want to be comfortable with a programming Perl according to a multiparadigmatic approach (something Perl is particularly good at, BTW), and so understanding different paradigms is very useful to me. After scheme I want to learn Smalltalk, and I'm debating about Haskell, prolog, unlambda, and maybe Java -- none of which I expect to use on a regular basis, but all of which I think could teach me something, something that will be useful when I write Perl code.

In summary: Yes, learn a second language. VB is perhaps not the *most* useful choice, but who cares? It is *a* useful choice (useful in the sense of what learning it can teach you), and you can get around to the others afterwards. VB does have the virtue of being fairly easy to learn, and every extra language you learn makes it easier to learn others. Go for it.

Plus, if you're on Windows, VB is not just (not, IMO, even primarily) a programming language -- it's a macro toolkit for the OS (and a pretty good one, IMNSHO). You won't use it for network programming or serious text processing, but if you want to slap together a quick dialog box that asks the user a question and then changes a setting in the control panel, VB is fine for that. When I had access to it in college, I used it for that kind of stuff, more than for any real programming.

But more important than what you'll use it for is what it will teach you. Your second language is a significant step forward. Don't hesitate to take it.


;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Replies are listed 'Best First'.
Re^2: Visual Basic .net and Perl: learn the former; use the latter.
by Anonymous Monk on May 11, 2015 at 17:09 UTC
    I have to disagree about not sure what network programming you are referencing, but I use Visual Basic Express to do various task on different servers and PC's. I also used VB to import data to MS-Access, SQL, execute Queries, and even create queries. Don't get me wrong I am liking perl, but I like a GUI. I am working on a VB program to manage PERL scripts at the site I am assigned to. The perl programmers constantly are changing folder paths and numbers in perl scripts and copying them and creating a new bat file. With VB they no longer have to do that. So all languages have a purpose. It is like a Phillips vs flat head screw drivers. They both work, just with specific screws. Non really is better then the other. And sometimes you can use a flat head driver with a Phillips screw, but can't do that in reverse.

      Wow, thread necromancy.

      These days I'm working a lot in C (which I am learning by studying the NetHack codebase; yes, I realize this is a terrible terrible approach to learning C and will no doubt cause irreversible brain damage, but I am doing it anyway) and trying to get around to learning Ruby finally. I still think in Perl mostly, but I now occasionally catch myself trying to write "else if" in Perl instead of "elsif", due to the C.

      The perl programmers constantly are changing folder paths and numbers in perl scripts and copying them and creating a new bat file.

      They almost certainly should not be doing that. There are like fifty different ways to avoid hardcoding paths, and most of them are better than hardcoding paths. Using VB instead of Perl isn't really relevant to this, though: I can assure you that the tendency for programmers to hardcode paths, particularly when they are either A) not very good or more likely B) in a hurry, transcends language. PHP programmers do it. VB programmers certainly do it (and often in a way that breaks in various interesting ways if you try to run the code on a different version of Windows, because figuring out how to use the %BLAH% API really correctly is something of a dark art). Lisp programmers do it. Perl programmers do it. C programmers do it -- or do it in Makefiles, which is just as bad, unless you subject yourself to the agony that is maintaining good .ac and .am files, and then it's still not really good. Ruby programmers do it. Inform programmers don't hardcode paths, but that's because Inform programs don't directly do anything with files at all, so that exception really doesn't count.