Subject: Re: Perl vs Python vs ....

From: Dan Stromberg <[email-masked]>
Date: Thu, 01 Aug 1996 14:03:02 -0700

Ian Jackson wrote:
> 
> We only have room for one `extra' scripting language, besides the
> usual sh, awk, sed, &c, on the base disks.
> 
> Perl is widely known.  It can solve most problems.  There are problems
> for which it is difficult to get it to work, but these don't often
> occur at installation time.
> 
> sh is not suitable for many of the things Perl gets used for -
> consider update-inetd, update-info &c.

Actually, a /bin/sh script to add inetd.conf entries, and another to
remove entries keyed off the service field, was unmentionably simple to
code, and has proved quite reliable in (lots of) practice.

> 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.

> There is no point having a religious war over this; this decision was
> taken a long time ago and can't be changed now, even if we wanted to.

This is rhetoric.  It could be changed and you know it.  What I mean to
say is, I really dislike "can't" when what's meant is "won't".

I daresay that a linux distribution (or the Hurd, or *BSD, or...) that
doesn't fall into the perl trap, should have a brighter future.

> Ian.

---

From: "Brian C. White" <[email-masked]>
Date: Thu, 01 Aug 1996 19:34:49 -0400

> 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)

> say is, I really dislike "can't" when what's meant is "won't".

Of course it can be changed.  Anything can be changed!  What he was saying,
and this is obvious to anyone not specifically trying to play with words,
was that it was NOT WORTH THE TROUBLE to change even if we wanted to.

> doesn't fall into the perl trap, should have a brighter future.

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.

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!)

                                        Brian
                               ( [email-masked] )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

---

From: [email-masked] (Erick Branderhorst)
Date: Fri, 2 Aug 1996 09:54:11 +0100

> that require munging large numbers of files in complex regexpish ways.
> I've found that if you use "-w", "use strict", and "use English", perl
> makes/allows you to write pretty reasonable code.  Certainly code that
> is far better (and usually faster) than sh.

If "-w", "use strict" and "use English" makes perl code more reasonable 
why don't we require that in the guidelines right now and put some effort
in a perl2guile translator (everybody will benefit).

Erick

---

From: Rob Browning <[email-masked]>
Date: 01 Aug 1996 23:45:41 -0500

Dan Stromberg <[email-masked]> writes:

> One way to do that, is to hang onto /bin/sh until something like guile
> is ready.

> Another way to do that, is to move beyond perl to something like python
> or ML (metalanguage) - right now.  It wouldn't take much at all.

Guile (or something like it) could be very good.  I use RScheme
(somewhat similar) pretty often now, but I still use perl for jobs
that require munging large numbers of files in complex regexpish ways.
I've found that if you use "-w", "use strict", and "use English", perl
makes/allows you to write pretty reasonable code.  Certainly code that
is far better (and usually faster) than sh.

I did look in to python at one point.  I actually read essentially the
entire manual (it's long).  In general I was fairly impressed, but
there were several things that (IMO) just weren't right that prevented
me from being willing/able to use it.  One of those was indention for
syntax.  In my *opinion* this is just wrong.  I did have a practical
reason, though.  It makes it quite hard to automatically generate code
in an indentation based language because you can't, for example, just
spit out the code for a loop, you have to know how deep that loop is
in the rest of the program to get the indentation right.  This is not
a problem in programs using braces or parens or whatever.  It's not
impossible to overcome the problem, just more difficult than
necessary.  There are other reasons I don't like indentation as
syntax, but that was the clincher.

If you really want to know the other reasons I didn't like python
(assuming there were any, I can't remember since I made that decision
a long time ago), I'll get the manual and try to recall; I don't think
it's really fair to say "I hated that, it was bad" without being
willing to back it up.

So I use perl now, but if Guile gets to where it can do the same kind
of text processing better, or nearly as well, with better syntax, I'll
be happy to switch.

(This thread is in great danger of turning in to another language holy
war.  I'm really not trying to add any fuel.  I hope I didn't.)

--
Rob

---

From: [email-masked] (Kai Henningsen)
Date: 02 Aug 1996 09:23:00 +0200

> (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.

> nice clean code.  It's also very easy to garbage code, but that isn't

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.

> to the amount of software available for it.  (Don't believe me?  Look

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

---

From: "Brian C. White" <[email-masked]>
Date: Fri, 02 Aug 1996 01:48:39 -0400

> And how much further would the industry be, if C had been typesafe (or
> if some other, typesafe language had been used)?  The expertise in
> language design existed at the time, but C didn't have it.

There were typesafe languages in the time of C:  Pascal, Modula, etc.

Where did they go?  They didn't go anywhere because they aren't useful
in real applications.  Have you ever tried to write a dynamic skip-list
in pascal?

> And yet, C was adopted as a major standard - because the people who knew
> better, didn't bother to speak up.

No.  It became a major standard because it does the job.  C++ is the same
way, and so is Perl.  They're not the prettiest, but they do the job in
an easy and efficient way.

> That's not to say that a lot hasn't been accomplished in C - obviously.
> But we could have done a lot more, if such a simple thing hadn't been
> put off until ANSI.  Also, the code I maintained on my first job,
> probably would've been a LOT cleaner - many of you are probably in the
> same boat.  I really hated roaming around fixing somebody else's stray
> pointer references.

True, but it's more likely that much of the existing code would not have
been written at all or would not be as functional.  Maintaing poorly
structured code is hard, but not as hard as maintaining code that was
kludged to get around limitations in the language.

> Yes, yes, yes, and No, no, no.
> 
> A language's success is typically 95% who backs it, and 5% how good it
> is.  With the masses, that is.

I disagree here, and MS-Dos is a great example.  It's not who backs it,
but what.  Dos was backed by tonnes of software.  That's why it's still
here.  Dos does the job; or did until fairly recently.

> However, for a group that knows what it's doing, it should be 5% who
> backs it, and 95% how good it is.  So it -should- be for debian.  The
> debian project is in a more than adequate position, to set a
> more-positive direction for the unix industry.

Yes!  Now define "good".  Good is how useful it is, not how how nicely
it's designed.  Perl _is_ useful.  Sure, there are other things, even
better things, in many ways.  But perl is a standard and following a
standard is also "good" in many ways.  I provides for a lot, even if it
lacks in others.

Don't get me wrong here, I abhor doing things because "that's the way
they've always been done"!  Right now, the pros of perl (good user base,
almost standard on all unicies, powerful) outweighs the pros of a
better language that fewer people know and isn't as common.  The cost
of changing must also be weighed and affects the decision even if it
alone is not sufficient reason.

> One way to do that, is to hang onto /bin/sh until something like guile

Guile is a neat idea, I'll admit.  It's almost like a high-level I-code
interpreter, except the I-code is scheme.  Done correctly, it could make
for a fairly painless conversion and still allow people to write in the
language of their choice, changing to better ones at their own pace.  It's
a while out, though.

Still, "good, now" is better than "perfect, later".

> or ML (metalanguage) - right now.  It wouldn't take much at all.

But what is the cost of that move?  How many people have to be retrained?
What are the advantages?  Do the advantages outweigh the costs?

> Once the inertia's there, it's hard to change it.  In fact, many people
> will become angry with you if you do.  But it's often very worthwhile to
> take a step back, and look at the long-term ramifications of a decision.

People, in general, hate change.  I personally have nothing against
changing the supported base language if I thought it would gain something
significant.  Convince me of that and I'll argue your side without
hesitation.

                                        Brian
                               ( [email-masked] )

---

From: Dan Stromberg <[email-masked]>
Date: Thu, 01 Aug 1996 18:25:18 -0700

In fact, I'm pretty sure I recall either K or R, saying that lint should
have been just another pass of cc, instead of a separate program.
That's a very small design-decision, but it's had a _H_U_G_E impact, for
more people than a wanna think about.  The choice of a languages is a
rather larger decision.

> to write nice clean code with.  It's just not _enforced_ that you write

assembler is powerful, and quite easy to write nice clean code with.  It
was hot stuff at its inception.

sendmail is powerful, and quite easy to write nice clean header munging
and mail routing with.  It was hot stuff at its inception.

perl is powerful, and quite easy to write nice clean small-scale scripts
with.  It was pretty old-news, at its inception.

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Fri, 2 Aug 1996 13:18:32 +0200 (MET DST)

> code, and has proved quite reliable in (lots of) practice.

Come on. update-rc.d is a sh script, and on my Pentium133 it takes 10 (ten!)
seconds to run. That's unacceptable. I rewrote it in perl, line-by-line so
without optimizing it and it now runs in 0.1 secs or so.

_Speed_ is also important.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Rob Browning <[email-masked]>
Date: 02 Aug 1996 11:32:59 -0500

> in a perl2guile translator (everybody will benefit).

Interesting idea.  I always use these options, but I'd be reluctant to
force others to do the same.  BTW I also like "use FileHandle"...

--
Rob

---

From: "Brian C. White" <[email-masked]>
Date: Fri, 02 Aug 1996 14:26:14 -0400

> anything general about it.

No it's not.  Assembler is low-level crunching.  It's unstructured, typeless,
and unportable.  If you want portable asm, go to C.

This wasn't about style.  It's about "cryptic".  Good and bad style is
possible in any language.

> of the quirks that parsing, say, FORTRAN or -surprise!- Perl has.

Perl's syntax is quite straightforward for a human.  It is, however, a
language of side-effects.  This is what can make it difficult to follow.
It's also what gives it part of its power.

> I still have trouble

Funny, I don't.

> that aspect it's a lot more like assembler than like any high-level

There are very, very few places you _must_ use $_.  Writing clean code
is no more difficult than in any other language.  It's just easy in
perl to write things poorly.  I put this blame on the programmer, though,
not the language.

> assembler. (Somehow, this didn't make them small and fast.)

This point totally escapes me.  Dos, like C and Perl is/was successful
because of the amount of software available for it.  It doesn't matter
what the software was written in.

> shouldn't have either, based on any technical merits.)

I wouldn't call it avertising, but I think I know what you're saying.  These
languages were "advertised" by other users because they worked.  They did
the job better than the other choices.

                                        Brian
                               ( [email-masked] )

---

From: [email-masked] (Kai Henningsen)
Date: 02 Aug 1996 18:44:00 +0200

[email-masked] (Brian C. White)  wrote on 02.08.96 in <[email-masked]>:

> > > advanced the computer industry would be if neither of those had ever
> > > been invented.
> >

Where did they go? They went and got some of the most popular  
implementations, ever.

Ever heard of Turbo Pascal/Borland Pascal/Delphi? (The names change, but  
it's essentially the same language.) When I have to program in the DOS  
world, I'm using that almost exclusively (both at home, and in a  
commercial environment). It's great for nearly everything you can do with  
C, only it's a lot easier to get right. (And yes, I have tried C in the  
same environment.)

There are even clones around - I know of at least four other compilers  
that claim some sort of compatibility with Borland's dialect. I'd love to  
have one for Linux.

The latest version can even implement a type-safe variant of printf.

Also, sometime, have a look at Modula-3. There's a free implementation  
made mostly by Dec (uses gcc as backend on most architectures).

> kludged to get around limitations in the language.

I know of no language limitations in a decent, modern Pascal-style  
language - such as the Borland dialects or Modula-3 - that you'd need to  
kludge around, that are not also present in C.

People who say somehing like that usually think of the original Pascal  
version. Pascal-style languages have come a long, long way since then.  
Modern such languages include stuff like modularization, objects and  
exceptions, without having the syntactic and semantic mess of C++.

> here.  Dos does the job; or did until fairly recently.

I don't see any important difference between these two paragraphs. The  
main point is that technical excellence is only a very small part in  
success.

> it's designed.

Here's a major diagreement: nice design is an *important* part of  
usefulness.

It shows in such things as training costs, and ongoing development costs  
(for example, once you know the language, not only can you find errors far  
faster in a Pascal-style language than in C, there are whole classes of  
errors that the compiler catches that in C you'd need a debug session to  
find).

> What are the advantages?  Do the advantages outweigh the costs?

Currently, probably not, in the case of Perl in Debian.

Let's keep an open mind, however, so that if this should change, we don't  
sleep through it.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 03 Aug 1996 11:06:00 +0200

[email-masked] (Brian C. White)  wrote on 02.08.96 in <[email-masked]>:

> No it's not.  Assembler is low-level crunching.  It's unstructured,
> typeless, and unportable.  If you want portable asm, go to C.

I'll give you the "unportable". Even part of the "low-level".

However, I have seen examples of typed and structured assembler languages  
- even object support.

> possible in any language.

And you can write very non-cryptic programs in most assembler languages.  
It isn't even hard.

Of course, you can write cryptic programs in any language at all.

> language of side-effects.  This is what can make it difficult to follow.

That's a problem, but it's not the problem I meant. For difficult to  
parse, well, compare these two lines:

   a =~ s/some/thing...
   b = c/d

Very bad syntax design, that.

> It's also what gives it part of its power.

That is just plain wrong. Heavy dependence on side effect does not power  
give - if anything, it diminishes the power, because you have to work  
harder to build reusable code.

> > figuring out how to write _readable_ programs in Perl.

Either you're trying to do different things, or you have a different idea  
of readable. Maybe both.

Note that I have no such problems with, say, assemblers, C, Pascal, REXX,  
Lisp ... to name a few.

> There are very, very few places you _must_ use $_.  Writing clean code

There are few places you must access it explicitely. There are, however,  
any number of things that _will_ use it (and thus you need to make sure  
they don't conflict with each other). Bad language design.

> what the software was written in.

Well, DOS certainly never had any advantage at all over other OSs in "how  
easy it is to write useful programs with" it.

It's success did not depend on technical merits. Ever.

> the job better than the other choices.

Nope. "Because they worked", or "did the job better", never entered the  
picture.

MfG Kai

---

From: Michael Alan Dorman <[email-masked]>
Date: Sat, 03 Aug 1996 15:23:46 -0400

>Very bad syntax design, that.

There's always s,some,thing, or s|some|thing| or whatever.

>Note that I have no such problems with, say, assemblers, C, Pascal, REXX,  

I've written programs in Perl (often making heavy use of regexps and
string handling) and gone for months without looking at the code, and
then had no problems figuring out what I needed to do when I went back
to modify the code.

Of course, this only proves that I am suspicious of the supposed
self-documenting capabilities of _any_ language, and thus comment and
document religiously.

>It's success did not depend on technical merits. Ever.

I'd disagree with that.  At the introduction of the IBM PC, you had
DOS, the p-system and, later CP/M.  I'd take DOS over the p-system any
day.  And by the time DRI got their act together, DOS had directories.

So, in that context, it did.  Remember, it wasn't bundled.

That it was not quickly enough eclipsed so that installed base was not
a problem competition-wise is hardly MS's fault.

Of course, I have to wonder how I ended up defending DOS and
Microsoft...

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."

---

From: "James A. Robinson" <[email-masked]>
Date: Sat, 03 Aug 1996 22:26:01 -0400

Much of this discussion (talking about MS-DOS, assembler code, etc.)
has no real place for debian developers.  I've asked Bruce to say
something, and he told me to ask you all to please move this
discussion off the list.  Please take it to private e-mail or
something for now.

Jim

---

From: [email-masked] (Kai Henningsen)
Date: 04 Aug 1996 12:48:00 +0200

I think we should wrap this up. It's becoming much too long.

>From the "clean syntax" poin of view, that's anything but an improvement.  
Maybe you need to spend some time with lex and yacc (sorry, flex and  
bison) to really understand what I'm upset about here.

> day.  And by the time DRI got their act together, DOS had directories.

Actually, the technical merits of those seem pretty close to me.

> So, in that context, it did.  Remember, it wasn't bundled.

Back then, *my* computer was an Apple ][, with either Apple DOS, Prodos,  
the p-system, or CP/M. My first Intel machine was an AT compatible from  
Acer (back then, they were named Multitech; changed because of a name  
clash.) DOS was bundled in a way - you usually "got it". I needed some  
talking to get them to *sell* me one (3.1, I believe); I wanted the  
manuals.

Back then, I did most of my programming in Pascal - p-system or Turbo  
Pascal for CP/M. I'd *loved* to have a p-system for the AT; unfortunately,  
I've never even *seen* one. Nor CP/M for the beast, either.

Then again, when I first heard of the Intel chip (remember, I used a 64 K  
machine at the time), my reaction was "1 MB address space? Are those guys  
stupid? Why not do at least the 16 MB of the 68000?"

> a problem competition-wise is hardly MS's fault.

The real problem is probably that OS/2 1.0 (aka "project black hole") took  
several years too long. Otherwise, we'd still have a mediocre system  
instead of an abominable one. Maybe even better, but somehow I doubt OS/2  
would have been as good as today.

Oh well, we should go back to Linux.

> Of course, I have to wonder how I ended up defending DOS and

I know the feeling.

MfG Kai