From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/03/15 Message-ID: <4ica32INN5hn@gambier.ugrad.cs.ubc.ca>#1/1 X-Deja-AN: 142839675 references: <00001a73+00002504@msn.com> <4i9ld6$m2v@rational.rational.com> <4iah20$p7k@saba.info.ucla.edu> organization: Computer Science, University of B.C., Vancouver, B.C., Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1996-03-15T00:00:00+00:00 List-Id: In article <4iah20$p7k@saba.info.ucla.edu>, Jay Martin 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. --