Re: Perl vs Python vs ....
bcwhite@verisim.com (Brian C. White) wrote on 01.08.96 in <[🔎] 32013F18.1E7283F3@verisim.com>:
> Dan Stromberg wrote:
> > > For this reason we decided that Perl would be on our base disks, and
> > > that packages could use it (well, the subset that's on the base disks)
> > > in their preinst/postrm. Packages which want something else must
> > > Depend on it and may only use it in their postinst/prerm.
> >
> > There's clearly a place for a stronger scripting language, despite the
> > argument posed above. It's just very sad that it should be perl. perl
> > really fits into many people's stereotypes of "unix as inherently
> > cryptic monster", very neatly.
>
> I'm sure C and Assembler fit "cryptic" too. Just think how much further
> advanced the computer industry would be if neither of those had ever been
> invented.
>
> (that's sarcasm, by the way)
And it's misplaced.
As to assembler, there are lots of _very_ different styles of writing it;
there is no one "Assembler" language. It's quite impossible to say
anything general about it.
As to C, while the language does miss some very crucial features and does
make it relatively easy to write cryptic programs, the language itself is
quite clean and orthogonal. Parsing C code, for example, does not have any
of the quirks that parsing, say, FORTRAN or -surprise!- Perl has.
As to Perl, it has some very ugly parts in its syntax, and its semantic
isn't too fine either - lots and lots of global variable dependencies.
There can be no doubt that Perl is very _effective_ - but it has a very,
very long way to go before it can be a nice language. I still have trouble
figuring out how to write _readable_ programs in Perl.
And, incidentally, as to bourne shell syntax - well, let's give it the
benefit of doubt and use POSIX.2 or bash - well, its main problem, and
that is a very serious problem, has always been quoting. This makes for
very cryptic code, and it also makes some problems nearly impossible to
solve - I had a case where input might contain all sorts of cryptic chars
that I *never* got right. Also, shell libraries (other executables, that
is) have a _very_ slow interface.
> Oh, give it up! Perl is a fine language. Its powerful and is quite easy
> to write nice clean code with. It's just not _enforced_ that you write
> nice clean code. It's also very easy to garbage code, but that isn't
> enforced, either.
Sorry, but I disagree very much. Perl is an powerful and effective
language. It is neither fine nor even clean; it is _very_ ugly. And while
some variants of code are indeed easy to write in a clean way, lots of
others aren't. You can't get rid of dependencies on $_, for example. In
that aspect it's a lot more like assembler than like any high-level
language.
> As for the truth of your comment... Language syntax and symantics have
> little to do with a language's success; it's how easy it is to write
> useful programs with. An operating system's success is due primarily
> to the amount of software available for it. (Don't believe me? Look
> at MS-Dos!)
It doesn't depend on the "easy" factor, either. Look at MS-DOS, indeed -
for a very long time, all the utilities were completely written in
assembler. (Somehow, this didn't make them small and fast.)
Like anything else, success of languages is mainly an advertizing thing.
And there can be no doubt that Perl has won that one. (So has C++, which
shouldn't have either, based on any technical merits.)
*However*, after all that is said, I still think we should stick with Perl
as first choice for a language that's better than shell - either that, or
C, and string manipulation is awfully hard in C.
It's not because I like it. It's because very many people know how to use
it.
MfG Kai
Reply to: