Re: Computer languages

Re: Computer languages

[crispen]

Sorry for the heresy that follows, but every time there's any text
to process, it's C for me.  I've got a couple of C programs I wrote
for the last Ada program I was on that generated Ada text -- the idea
was to find the sizes of a bunch of interface data objects, so good
old Ada's 'SIZE attribute is wonderful.  But extracting the declarations
from various packages, putting them together to make compilable Ada
code (lots of file I/O, lots of text manipulation) -- that's a job
for C.

I even pragma Interface to printf for error/status messages.  There
is an advantage to that in our environment; you can pragma
Interface_Name it to logMsg in VxWorks so that you can print
even at interrupt level -- something that Text_IO can't do.

Of course, I didn't have to deliver these utilities.

A buddy of mine just did a big interactive text and file thing using
Ada and it took him 3 days.  I'm certain he could have done it in C
in half a morning.

Oh, yeah, heavy operating system interfaces.  I always do a quick
hack in C for things like sockets, rpcs and so on so that I know
I understand it.  Then I write some Ada bindings and redevelop in Ada.

Even on the most anally controlled programs there's going to be a
need for some quick, nasty hacks to get an unexpected job done
right away.  F-22 seems to doubt this.  Boy are they going to be
surprised.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |           Co-workers don't           |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Computer languages

[J. Giles]

In article <9211121331.AA21974@efftoo.boeing.com>, crispen@efftoo.boeing.com (c
rispen) writes:
|> Sorry for the heresy that follows, but every time there's any text
|> to process, it's C for me.  [...]

Why?  C has *NO* language features supporting text *at all*.  It has
callable functions which are inconvenient and can be efficiently
written for *any* other language as well.  Even Fortran has better,
more convenient text handling features than C.  All the C text
handling functions can be written, tested, and debugged in Fortran
in about an hour (I know: I did it once on a bet).  But Fortran
has string assignment, substring selection, and concatenation
*built-in*!

To be sure, there are text handling *languages* which are better
than any of the general purpose Fortran, Ada, or Pascal style
languagtes for text.  But C is by far worse than any of these.

I can never understand why C is so often recommended for the 
things it's *poorest* at.

-- 
J. Giles

Re: Computer languages

[Michael Feldman]

In article <9211121331.AA21974@efftoo.boeing.com> crispen@efftoo.boeing.com (cr
ispen) writes:
>
[stuff deleted]

>A buddy of mine just did a big interactive text and file thing using
>Ada and it took him 3 days.  I'm certain he could have done it in C
>in half a morning.
>
And for 1-shot text stuff, I use Snobol4. Really.
(There's a great freely-distributed version for PC's, and some
nice industrial strength ones as well).

Mike
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Computer languages

[crispen]

cochiti.lanl.gov!jlg@lanl.gov  (J. Giles) says:

>C has *NO* language features supporting text *at all*.

Sorry.  I should have said "C and Unix".  Take one example: strtok().
I use this all the time to parse command lines or other free-form
inputs.  Then there are the macros islower and toupper, and on and on.

I fear I have trod on religious ground again.  Look, Ada has a model
of a string as an array, one of whose attributes is length.  I do
believe that there's power in "array (Positive range <>) of Character".
It's marvelously abstract, and you get the size of the string for free
without having to resort to strlen(), for example.

But I also think that there's power in C's model: a null-terminated
array of char.  Let's take an example: you have two processes which
intercommunicate outside Ada's context (how many non-proprietary
multi-CPU Adas do *you* know about?).  So the Ada process either looks
at some region of shared memory or it reads from a stream.

So the writing process has to jot down both the string itself and
the length of the string.  Minimal problem: you have to write two
things instead of one (though we certainly sacrifice some abstraction
by having to peek under the hood to pass an attribute).  The reading
process, on the other hand, is worse off.  It has to use NEW (and a
copy) to get ahold of that string and do anything with it.  Come to
think of it, I've had to use NEW for strings in subprograms *within*
the Ada context because of some bitchy string "feature" or other.

A C process, on the other hand, simply assumes that the string is
terminated by a null and can deal with the string in situ.

I am aware of the Verdix C_Strings and A_Strings packages as well as
the stuff that sommar@enea.se was kind enough to email me.  These
utilities generally permit you (require you?) to convert from Ada's
built-in string type to some other string type.  But that makes
my point again, doesn't it?:  For some purposes, Ada's model of strings
is less useful than other models.

If you have a program whose chief activity is to manipulate C strings or
which takes advantage of all the Unix/C library string manipulation
functions, then I believe that writing such a program in Ada, converting
from Ada strings to C strings and back again, is an exercise in silliness.
If, on the other hand, you have to convert between strings and enumerations,
or if the string manipulation is only a small part of the functionality
of the program, then there's no place like Ada.

>From time to time we're required to be silly; other times we're silly
through inadvertence; let's not be silly deliberately!

>Fortran has string assignment, substring selection, and concatenation
>*built-in*!

Well, your experience must certainly be different from mine.  I had a
set of text manipulation programs to write in Fortran several years
ago and found the (Gould) Fortran string manipulation operations so
slow and so buggy that I ended up EQUIVALENCEing a bunch of arrays of
INTEGER*1, INTEGER*2, INTEGER*4 and INTEGER*8s and dealing with all my
strings as integers.  Scarcely an advantage for this particular Fortran!
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+