From: | "toby" <toby@telegraphics.com.au> |
Newsgroups: | comp.compilers |
Date: | 4 Nov 2005 14:01:45 -0500 |
Organization: | http://groups.google.com |
References: | 05-10-05305-10-068 05-10-075 05-11-006 05-11-013 |
Keywords: | design, comment |
Posted-Date: | 04 Nov 2005 14:01:45 EST |
Nick Maclaren wrote:
> toby <toby@telegraphics.com.au> wrote:
> >But TeX (like METAFONT) is closely tailored to its domain, and within
> >that domain, is quite elegant. Of course it can be 'ghastly' for tasks
> >of a different character - Knuth himself gives several examples in The
> >TeXbook. Anything is *possible* but not necessarily easy.
>
> No, that wasn't my point. One of the "gotchas" is that spaces are
> syntactically significant, and you cannot introduce layout (ANY form
> of layout) for clarity without changing the meaning of the program.
> And, because TeX doesn't have a precise description (merely a guide on
> how to use it), it is very hard to analyse a program for why it
> doesn't do what you understand the TeX book to say that it should do.
I never found it particularly difficult. The TeXbook is superb
documentation, and for the truly desperate, there's the source. :-)
> >Similarly I find that many people who complain about Perl -
> >especially comparing it to languages such as Ruby or Python - have
> >missed the point. Perl has its sweet spot domains (as a child of sed,
> >C, sh, etc) and while it is a powerful general purpose programming
> >language, that was not its guiding principle. It was highly adapted
> >from birth.
>
> Again, you have missed the point. Perl is bad, even for the purposes
> that it was designed for and is most often used for - system scripts.
I disagree. At least you can admit it's no worse than bash.
> People who care about RAS really, really do NOT want a privileged
> script to do something unexpected. Humans make errors, but Perl is
> such that most errors make it do something unpredictable rather than
> issuing an error message.
I agree with that much.
> People may have heard before, but my first and last Perl program was
> 20 lines long, with every branch tested both for correctness of the
> condition and that each path was being correctly executed. It gave
> wrong answers the first time I used it.
Why should I accept your judgments of Perl then? Just asking. I would
not offer such criticisms of a language I'd only used once (and
incorrectly).
> I had misunderstood the manual, and typed completely broken syntax.
> This behaved as I expected during my tests and not on real data.
Why do you expect to get it right first time? One thing I have learned
about humans versus technology is that we are only truly proficient at
things we do every day; and that it takes 10 years to get good at
anything.
>
> Not really related to that, I also half converted it to MVS, ISO C
> and EBCDIC (don't ask), and so had to stufy its code. I have rarely
> seen anything so bad, and its quality made it very clear why it was
> likely to behave in that sort of way. I could go into details, but
> they are irrelevant. I have heard that newer versions are better,
> but my reaction is that they could scarcely fail to be.
It's clearly not for you. But there are plenty of wonderful languages
out there. Perl and TeX I consider to be domain specific, and therefore
perhaps prone to the learning-curve and fragility problems that you
encountered.
--Toby
>
> Regards,
> Nick Maclaren.
>
> [You keep mentioning your failure to write a correct perl program on
> the first try, but I can't figure out what conclusion we're supposed
> to draw. That someone who is a skilled programmer in some languages
> is still a novice in languages he doesn't know? That you aren't very
> good at learning languages from the manual? That preconceptions make
> it hard to learn new or different languages? I don't think my first
> perl program worked either, nor did my first Lisp, C, Basic, Algol 60,
> PL/I, Fortran, or Varian 620 assembler program, but I don't think it
> was the languages' fault. (Well, maybe for C.)
>
> Oh, by the way, I wrote a python program using my favorite text editor
> which has four character tab stops. It didn't work, so nobody should
> use python. -John]
Touché, John. At what point do your editorials become too long for
interjection and require participation as a civilian? :-)
[When they're longer than the original article, I guess.
This is veering away from compiler design into language design, so with
one more message in the queue I'm going to decree this thread to be over.
-John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.