Re: C/C++ knocks the crap out of Ada

[c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)]

In article <4iah20$p7k@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
 >rlk@rational.com (Bob Kitzberger) writes:
 >
 >>:   make is a _general_purpose_ utility.  It _can_ be used to manage C 
 >>: projects, or it can be used for a whole host of other things.  How is 
 >>: this hard to understand?  Does ADA provide its own OS, its own editor and 
 >>: its own hardware so that you never need to use anything else?
 >
 >>I don't think that anyone is having difficulty understanding your point.
 >>Make is indeed general purpose, but its roots are in the C/Unix
 >>culture, and those roots show.
 >
 >Right, make is mostly used to support development in C and other
 >primitive languages.  I have seen this piece of crap utility used for
 >all sort of braindead misuses.  Unix-ites seem to love to dp goofy
 >things with their utilities.  Heh, I have seen people using Lex and
 >Yacc to build parsers to read in simple tables.  Like swatting a bug

I use Lex and Yacc for scanning simple configuration files and what not? What
is your problem? According to what you are saying, the features of Ada are also
overkill---why not just use hand-coded assembly language? C++ classes? Why
bother, just use static tables for everything!

Lex and Yacc are proven utilities that work. 

The input file to Lex is far easier to debug and maintain than a hand-written
lexical analyzer.

Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
keyboard.

It's a lot easier to change the grammar and have yacc regenerate new code than
to fiddle with a hand coded recursive-descent or shift-reduce parser.


 >with a sledge hammer (they ever heard of "scanf"?), but they probably

A lex generated scanner is far more robust and _faster_ than scanf(), you twit,
especially if you use GNU flex -f to generate the scanner.

I have written a test program in which I compared a flex scanner against
scanf(). The task was to read an eight megabyte file containing eight or nine
digit integers. One program did a loop in which scanf("%d") was invoked.
Another used a lexical analyzer to match the tokens and atoi() to do the
integer conversion. The flex-generated code was almost twice as fast.

I have created about half a dozen lexers/parsers in the last year alone, each
of which took the lesser part of an afternoon of fiddling. Some were for
retrieving data out of HTML, others for parsing logs, configuration files and
the like.

I replaced one use of scanf() for parsing the entries of a log with a lex
scanner, and improved the CPU efficiency of the program twenty fold!

Programs that use yacc are a godsend too! Easy to understand and modify. I can
read the yacc grammar and understand the input language. It's self-documenting.

Believe me, these tools have been a wallet-enhancing productivity items. Some of
us have a life.

 >felt so Computer Scientific doing it! (The journey is the reward) By the

That is completely false. What journey are you talking about? Five minutes of
punching in a simple grammar specification instead of hours of debugging some
silly code only to have it run no faster than an automatically generated
program?

The self-indulgent programmer will insist on hand-coding everything. I would
find it a lot more gratifying to write out a grammar on hand, compute the LR(1)
state machine construction and code my own parsing table, and then whip it up
into raw code. That would be my idea of ``journey is the reward''.

 >way after 10+ years of using Unix I am having trouble thinking of a
 >standard Unix utility that is not a total misdesigned piece of crap!
 >Maybe someone can help me.

A professional counsellor, perhaps.
--