in reply to OT: Switching Sides
I have travelled more than one road (not through indecision but due to a mixture of platforms).
On the Windows side I've been using Activestate Perl, which has worked quite well. I keep the script open in an editor, and a command prompt session open for running it. I've found that MacPerl works well on the Mac OS (8.6), and I've found that the scripts I wrote on there ported with no changes except to the shebang line, when I moved them to the Linux box, or to Windows. I think this is a huge advantage to Perl -- it's quite portable. Naturally, there are the usual file-naming and line-ending issues.
<digression>
I have helped my spousal unit with his VB projects. I deeply dislike VB's built-in limitations, but that is another rant.
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). I think I once read rumors of such a thing and I hope it is coming (although I went for years debugging C at the command prompt. Have I gone soft?). And yes, I still type 'ls' in the Windows command prompt, and 'dir' on FreeBSD...
</digression>
I have searched for a gui front-end for Perl, and have worked a bit with Perl/Tk and with wxPerl. They have both worked well for me, but I didn't find a way to design things graphically like in VB (I'm not saying it doesn't exist, only that I didn't find it after a brief search).
Knowing the C programming language has helped me to learn Perl. (Although I still love C, I would probably learn Perl if I were just starting out today.)
I hope this helps a bit.
Re: OT: Switching Sides
by jonadab (Parson) on Nov 30, 2003 at 04:18 UTC
|
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$/
| [reply] [d/l] |
|
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] |
|
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$/
| [reply] [d/l] |
Re: Re: OT: Switching Sides
by demerphq (Chancellor) on Nov 30, 2003 at 22:01 UTC
|
using InStr instead of index,
Hmm. IME, most InStr work from VB can be replaced with regexes. I would almost go as far as to say that if you index() more than rarely you are probably missing out on better ways to do things.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] [d/l] |
Re: Re: OT: Switching Sides
by Anonymous Monk on Dec 01, 2003 at 22:59 UTC
|
Check 9out wxGlade. It will output wxPerl code as well wxPython, wxC++. It looks similar to Glade, hence the name.
http://wxglade.sourceforge.net/ | [reply] |
|
|