Few and far between are the programming languages in which it is the least
bit difficult to write code which is hard to read, debug, understand, and
maintain. You should be judging the people writing the code, not the
language. You're shooting the messenger (the language) rather than the
message (the code as implemented).
As one trivial example, just because someone *can* write something like
that looks like an obfuscated C contest entry:
for(split(/:/,$ENV{'PATH'})){next if/^\.?$/;s![^/+]*$!man!&&-d&&
!$s{$_}++&&push(@mp,$_);}print join(":",@mp),"\n";
Or even as a more reasonably indented
for (split(/:/, $ENV{'PATH'})) {
next if /^\.?$/;
s![^/+]*$!man! && -d && !$seen{$_}++ && push(@manpath,$_);
}
print join(":", @manpath), "\n";
Or even a more reasonably structured:
for (split(/:/, $ENV{'PATH'})) {
if (/^\.?$/) { next; }
if (s![^/+]*$!man!) {
if (-d and !$seen{$_}++) { push(@manpath,$_); }
}
}
print join(":", @manpath), "\n";
Doesn't mean that it isn't considerably clearer to write it more like
this:
@bin_path = split /:/, $ENV{PATH};
@manpath = ();
foreach $path_component (@bin_path) {
if (substr($path_component, 0, 1) ne ".") {
$man_component = $path_component;
$man_component =~ s{ (?# replace basename with "man"... )
[^/+] (?# 1 char: neither plus nor slash )
* (?# 0 or more of these things )
$ (?# but only at the end )
}{man}x;
if (-d $man_component ) {
if ( $already_seen{$man_component} == 0 ) {
@manpath = ( @manpath, $man_component );
$already_seen{$man_component} = 1;
}
}
}
}
$colon_separated_version = join ":", @manpath;
print $colon_separated_version, "\n";
(The real code actually has regular comments in it as well.)
Those of you averse to $ and @ might think back to the many discussions of
using Hungarian notation for variable naming, that is c_blah for character
variables, i_blah for integer variables, s_blah for string variables,
etc. It turns out that that's what perl's type indicators are doing: $
and @ are just singular and plural semantic markers, things which help a
great deal in most languages. If you thing of letting $ mean "the" or
"a", and letting @ as saying "these" or "some", it might all make more
sense to you.
:My advice is this, they are all fairly
:simple to learn and use; find one you like, use it, if it becomes
:obsolete or something learn a new one.
Well, possibly. The danger is that you might have gotten yourself in too
deep. Languages can run out of steam. For example, appalled by the
primitive and restrictive nature of the bourne shell and seduced by the
built-in programming constructs in the korn shell, you write this 900-line
ksh program and then find that it just doesn't have the datatypes,
modularity, and control flow for what you really want to do. Or that the
27 little shell programs you called don't work when your program is fed
unexpected data (long, binary, etc). Or that you can't scale your data
set to two or three more orders of magnitude. This happens all the time
in shell programming, and occasionally using the other languages mentioned
here. It would appear to me that out-of-the-box python and perl have a
better chance of scaling well on significantly larger programs and data
sets than tcl does.
:If you are starting a project
:that is long term and fairly important, I think you might be better off
:with a compiler and some good ANSI C++ or Ada or something. If you are
:just doing simple/small stuff, then jsut use what you like.
Oh, I don't know about foisting C++ or Ada on someone that hastily. They
have a much greater entry cost (how much you have to know about the
language before you can use it effectively) than most attribute to them.
--tom
-- Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com"Make is like Pascal: everybody likes it, so they go in and change it. " --Dennis Ritchie