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.
In reply to Re: Visual Basic .net and Perl: learn the former; use the latter.
by jonadab
in thread Visual Basic .net and Perl
by juo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |