|[2 earlier articles]|
|Re: Why context-free? firstname.lastname@example.org (2005-10-13)|
|Re: syntax extension, was Why context-free? email@example.com (toby) (2005-11-01)|
|Re: syntax extension, was Why context-free? firstname.lastname@example.org (2005-11-01)|
|Re: syntax extension, was Why context-free? email@example.com (Karsten Nyblad) (2005-11-01)|
|Re: syntax extension, was Why context-free? firstname.lastname@example.org (glen herrmannsfeldt) (2005-11-02)|
|Re: syntax extension, was Why context-free? email@example.com (2005-11-02)|
|Re: syntax extension, was Why context-free? firstname.lastname@example.org (toby) (2005-11-04)|
|Re: language design, syntax extension, was Why context-free? email@example.com (Oliver Wong) (2005-11-12)|
|Re: language design, syntax extension, was Why context-free? firstname.lastname@example.org (Ivan Boldyrev) (2005-11-15)|
|Re: syntax extension, was Why context-free? email@example.com (2005-11-26)|
|Re: syntax extension, was Why context-free? firstname.lastname@example.org (2005-11-27)|
|Re: syntax extension, was Why context-free? email@example.com (2005-12-08)|
|Re: syntax extension, was Why context-free? firstname.lastname@example.org (Robert Figura) (2005-12-15)|
|[2 later articles]|
|Date:||4 Nov 2005 14:01:45 -0500|
|References:||05-10-05305-10-068 05-10-075 05-11-006 05-11-013|
|Posted-Date:||04 Nov 2005 14:01:45 EST|
Nick Maclaren wrote:
> toby <email@example.com> 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
> 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
> 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
> 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.
Return to the
Search the comp.compilers archives again.