Re: OT: Switching Sides

I think this is a huge advantage to Perl -- it's quite portable.

Absolutely. Provided you don't rely on external stuff (e.g., backtick out to system commands, use modules that are neither pure perl nor core, ...), Perl is very portable.

I do wish that I had a development environment like VB's for Perl, which would show me immediately when I commit my favorite stupid mistakes (e.g. dropping a semi-colon or using InStr instead of index, handicaps which come with using more than one system/language).

The closest thing I know to this is cperl-mode. It will, assuming you turn on syntax highlighting, show keywords like index in a special color, so you'll immediately notice if you typo them, because they won't change color like usual. It also matches grouping and quoting symbols for you; as soon as you type the closing one, the opening one flashes. (Actually, that's a feature of Emacs that works in pretty much all major modes; it is a feature Emacs *has* to have, because it's pretty hard to write good lisp without it; Emacs was developed by lisp programmers originally.) As far as dropping a semicolon, you'll notice when you go to the next line and it indents wrong. Configurable automatic indentation is cool. cperl-mode is in general cool. The only downside to it is that it runs in Emacs, which means you have to learn to use Emacs. Now, Emacs is wonderful in itself and well worth learning, but it's not exactly something you're going to pick up and start using in one afternoon. In fact, you can expect to spend just as much time learning Emacs as you spent learning Perl.

And yes, I still type 'ls' in the Windows command prompt, and 'dir' on FreeBSD...

You think you've got it bad... I keep getting mixed up between Ctrl-C (DOS, Windows, and *nix), Ctrl-Y (VMS), and C-g (Emacs). Then every once in a while I get stuck working with a pre-X Mac and have to try to remember what the keystroke is for Force Quit; I usually just end up holding down *all* the buckies and start hitting keys. Then there's copy and paste: on Windows it's Ctrl-C/Ctrl-V; under *nix, half the apps do it the Windows way and the other half do it the other way; on Mac it's clover-c and clover-v, and then there's Emacs, where I've got it bound to something yet different. (One of these days I'm going to get tired of messing around and totally transplant the entire Ctrl-C and Ctrl-X prefix keys in Emacs and their whole associated keymaps to different prefix keys, pervasively enforcing the transplant via hooks in all major modes so I can make copy and paste work the way I really want...)

(Although I still love C, I would probably learn Perl if I were just starting out today.)

I would recommend that newbies (here I mean newbies to programming in general, not just to Perl) learn higher-level languages such as Perl first, later getting into lower-level languages such as C only if they have the aptitude and desire for it. Perl is not the only suitably highlevel language, but it's a good choice. If you are worried that the C programmers will look down their nose at you for only knowing a "scripting language" (a quite silly thing to look down their nose at you for, but some people are indeed quite silly), then learn lisp or one of its derivitives; they're not on as high a level as Perl or Python, but they're *way* higher-level than C, support more paradigms better (doing functional programming in C is a fairly unnatural act), and (except for elisp) cannot be reasonably accused of being "a scripting language". (As an added bonus, if you learn common lisp, you get to patronise the C programmers, call them "whippersnappers", and tell them your language was being used for artificial intelligence research when their language's grandmother (BCL or whatever it was called) was in diapers. This doesn't make them happy, but it shuts them up.) But if you're not worried about the opinion of the C programmers, go ahead and delve right in to Perl. Previous experience in other languages does make learning Perl faster if you happen to have it, but not enough to justify going and learning the other languages first if you haven't already, particularly considering that it goes both ways: knowledge of Perl will make it easier to learn the other languages, too. IMO, Perl is a great choice for a first language.

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

Comment on Re: OT: Switching Sides Download Code

Replies are listed 'Best First'.
Re: Re: OT: Switching Sides by DrHyde (Prior) on Dec 01, 2003 at 09:21 UTC
I would recommend that newbies (here I mean newbies to programming in general, not just to Perl) learn higher-level languages such as Perl first, later getting into lower-level languages such as C only if they have the aptitude and desire for it I disagree, I don't recommend that anyone learn perl as their first language. It's better, in my opinion, to start with a low-level language, learn how computers work, and then when the apprentice has a thorough grounding in the basics the master can let him loose with high-level tools like perl and java. C makes an excellent first language for someone wanting to be a programmer. In my more old-gittish moments, I think that C is too high-level to get started with and that everyone should learn to program a simple processor like a Z80 or a 6502 in assembly language.	[reply]
Re: OT: Switching Sides by jonadab (Parson) on Dec 01, 2003 at 16:17 UTC
It's better, in my opinion, to start with a low-level language, learn how computers work I think it's adequate to have a chunked view of how computers work. I don't think it's necessary to know all the details of how each operation is carried out. Taken to extremes, this is really a tautology: Do you really want all beginning programmers to study microcode? Transistor gates? The relationship between power, current, voltage, and resistance? The behavior of individual electrons, the nature of metals, and the Bohr model? Quarks and quantum mechanics? In my more old-gittish moments, I think that C is too high-level to get started with and that everyone should learn to program a simple processor like a Z80 or a 6502 in assembly language. Assembly language is a far better first language than C. It's simpler. It's better documented. There are fewer really horrible examples out there, less really bad-quality code in assembly language than in C -- and the bad-quality assembly-language code they're less likely to find, because it's less likely to be in production use. C is a remarkably poor choice because it's just almost high-level enough that the programmer is likely to want to continue using it, rather than learning a more appropriate tool. Far too many potentially great programmers get mired in low-level thinking, forget how to work with layers of abstraction, and never recover from it. At least if you teach 'em line-number BASIC they'll want to move on. Then there's the other matter: there are too many C programmers already, a great surplus of them, so that many things are written in C that shouldn't be, things like entire applications that have absolutely no need for low-level fiddling and microoptimization, but they're written in C because it's the canonical ubiquitous language. This is a bad thing, as it leads to needless stupid preventable lowlevel bugs (segfaults, buffer overruns, coredumps, and the like). There would be a lot fewer computer crashes if C were only used where it's appropriate, for inherently lowlevel things (like kernels and virtual machines). `$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/` [download]	[reply] [d/l]


laziness, impatience, and hubris
	PerlMonks