[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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  

> 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  

MfG Kai

Reply to: