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

[jmartin@cs.ucla.edu (Jay Martin)]

sheldon@amc.com (Sheldon White) writes:

>In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:
>>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
>>

>(deletia)

>>
>>Alright dumbshits lesson time:
>>
>>  -- Tools and operating systems that only support one language are junk.
>>     Basic computer science, anyone who thinks otherwise is incompetent.
>>  

>That's probably true. Fortunately, UNIX is not such a system.

Then where have been the standard system interfaces for all the
other languages?  They don't exist.  UNIX only really supports
one language, C.  Which is why C didn't die like all the other
low level languages of its period.

>>  -- Stupidly go on and on about how an certain IO routine is not as fast
>>     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
>>     (2) Just shows the IO routine is broken.  Its trivia.
>>   

>I've worked on a lot of parsers, both using Yacc/Lex and using straight C
>code. Unless the syntax was completely trivial, using a tool like Yacc is
>vital for maintaining the code. Also, if your scanf version is too slow, what
>are you going to do? Rewrite scanf()?

We were talking about a trivial table, something easily accomplished
by standard IO routines in any language. That I mentioned "scanf" in a
retort was not inportant (scanf == simple IO routines).  (Scanf is
obsolete anyway use "iostream.h") If you are reading a 2K file at the
start of a 2 day computation should you care?  If scanf is so slow its
broken, like most of C.  Using Lex/Yacc to read in tables just for the
sake of performance is really silly.  Its just another example of the
rabid performance paranoia exhibited by C programmers.

>>  -- Go on and on how its great to over-engineer something simple.
>>     How great it is to be a "savant" at a criptic tool with little
>>     eye to the effects of using that tool to the maintainability
>>     of the software.  This is called "eat shit next guy" hacking.
>>

>Have you ever had to maintain a large parser, day in and day out, written in
>"just-crank-some-code" C? Talk about "eat shit next guy"...

Yes I would and have used a parser tool like Yacc for a real parser
(Though for a really good language compiler I hear its worth the pain
of a recursive decent parser), but I wasn't talking about a parser
or a real grammer we were talking about over engineering simple
IO code.

>Have you ever used a tool like Yacc?

Yes

>>Of course when you tell of maintainance headaches caused by abuse of
>>these tools do to they are ready availability and it is supposed to be
>>so cool to use them.  Then its the usual C/Unix hacker macho attitude
>>of "they are just lame programmers" the tools are great!  
>>

>There's nothing cool about Yacc. There's nothing cool about a sledgehammer.
>They are tools that can make life much, much easier.

If you are using them to do what they are supposed to do, then they
are cool.  This whole thread is using complex tools when they are not
necessary. One guy bragged about how cool it is to instead of just
inputting a number, you allow arbitrarily complex expressions to be
inputed. Extra complex tools causes maintance headaches because it
requires expertise when it is not necessary. 

Suppose I have programmer that works for me "FORTRAN-Bob".  Bob
doesn't have a CS degree and is learning C.

CS-Jay:  Well Bob your input file to your program should probably
         be done as a parser.  Its really cool and allows you to
         have "free format" input and stuff. 

FORTRAN-BOB:  You mean so it will be so easy to use as if it had a GUI or
              DB front end?

CS-Jay: Well no not really, it will still suck, but I think parsers
        are cool.  Well anyway you got to read some books, first
        you will need to read this automata/language theory book
        here, then half of this compilers text, after that you
        should read thes lex and yacc books.  And so you don't
        make any style mistakes read "Good style with Lex and
        Yacc".

FORTRAN-BOB: (Thoughts) I wish I could use FORTRAN READ.

Moral: Just because you are an expert at something doesn't mean
everyone else is.

>>The Unix philosophy is great for the quick hack, but for larger
>>software development the philosophy becomes counter productive.

>I'm sorry, but you sound like someone who hasn't had to maintain a large

Yes I have maintained large programs.  The Unix philosophy is
anti-software engineering (quick and dirty) if you ask me.

Jay