[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 02.08.96 in <32024846.7671EB98@verisim.com>:

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

> This wasn't about style.  It's about "cryptic".  Good and bad style is
> 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.

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

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.

> > I still have trouble
> > figuring out how to write _readable_ programs in Perl.
> Funny, I don't.

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.

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

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

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.

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

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

MfG Kai

Reply to: