Re: Any research putting c above ada?

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <3368A6FE.41C6@cca.rockwell.com>,
Roy Grimm  <ragrimm@cca.rockwell.com> wrote:
>Kaz Kylheku wrote:
>> >I was trained in the computer-science paradigm.  When I arrived at
>> >Rockwell and started working on engineering projects, I was astounded to
>> >see the difference between how I had done things before and how I had to
>> >do them here.  At my previous position, we cranked out code.  Here, we
>> >design and build software.  The focus here is on the design process and
>> >how we can build software to meet the design.  At my former employer, we
>> >were simply asked to crank out some code that did the job.  If it wasn't
>> >quite right, we'd throw some fixes into it and release it again, and
>> >again, and again until we either got it close enough or the buyer wanted
>> >something completely different.  That kind of slip shod programming
>> >doesn't fly very far here.
>> 
>> That is slip-shod, but it doesn't seem to relate to my own computer science
>> background and experiences.
>
>A common theme emerging from this tangent seems to be that every
>institution, and even every person does things differently.  We all have
>different experiences.  I had all theory in my classwork, but I did
>enough extra-curricular work (mostly in my job at the college computer
>center) that I was able to apply that theory to real world situations. 
>Even though I had a "less than stellar" academic record, I think I came
>out of that place with much more usable knowledge than most of the
>people in my class.

My experience was quite hands-on. In the compiler construction course, you had
to implement a compiler. (There was a prerequisite course on formal languages,
but I talked to the prof and skipped it). The assigments followed the various
stages of compiler design: lexical analysis, parsing, type checking,
intermediate code generation, etc. The lectures were very good too; you learned
about pattern matching automata, various parsing algorithms and the
construction of parser generators, etc. I still practice the construction of a
table for a shift reduce parser from an LR(1) grammar once in a while just to
stay sharp!

The OS courses had a heavy assignment load, involving real systems. In the
first course, you had to crank out multi-threaded programs. In the second one,
we used old Sun boxes for embedded programming using a small OS kernel.
Assignments ranged from implementing various OS features, to doing fun stuff
like packet sniffing.  I wrote a 68010 emulator to single-step through object
code off-line instead of waiting for the live thing. :) The final assignment
asked a lot of crap about things like the Berkeley FFS, System V
streams---totally unrelated to the assignment work, a lot of which I had no
clue about because I skipped most of the lectures to write the emulator.

In distributed systems, the first assigmnet was to write a scaled down name
service. The next one was to make it distributed, so that servers would talk to
other servers to find information. Then we had to make it multi-threaded, and
finally add public key cryptography. The exam was totally spaced out though,
about things like two-phase commit protocols, totally ordered atomic
multicasts, etc. You got to have _some_ rigor in the course load.  We used
C/UNIX for everything. 

In machine architectures, one assignment had us implementing software floating
point routines in assembly language. The day before the due date, the prof
imposed a much stricter maximum cycle count than the original spec, so the lab
was packed with people optimizing away like mad.  The advanced course was a
complete waste though; step by step analyses of what goes on inside the
pipelines of some model processor ad nauseum---probably because the prof came
from some ivy league university in the USA (great guy, don't get me wrong).

>> What was the focus of your computer science training? Was it largely
>> theoretical, or did it involve a lot of ``hands on'' work?
>
>Mostly theoretical.  I did take a directed study in Ada (it wasn't
>offered as a regular class at the time) which was my only collegiate
>experience with any kind of software engineering.  We spent all of our

Most topics in basic program design were covered by second year. OO wasn't
taught when I was there, just abstract data typing techniques, but was
introduced shortly afterward.  Even the local colleges offered decent
courses in data structures and program design; I took one in which Modula 2
was used as the language. I thought that in every decent school, the first
thing one would learn is how to decompose a program into abstractions
centered around abstract data types along with operations that work on
these data types.

In the third year, there was a mandatory one-semester course on software
engineering accompanied by a mandatory two-semester team project. This involved
developing a multi-user client-server application essentially from scratch,
with graphical interfaces on X terminals, ORACLE for storage. RPC stubs were
generated by a locally developed awk script. :)

I had a lot of fun in school. To this day I'm convinced that I got my money's
worth.

>I'm saying that the computer scientist and the electrical engineer both
>hack together some atrocious programs (i.e. a 16 page main function).  

That sort of coding indicates a serious failure to understand program design.
Functional or algorithmic decomposition is just the bare-bones basic technique
that dates back to the 50's.  It's not sufficient for large software projects,
but it's necessary for even small ones. I can't believe that someone can
come out of a computer science program and not be able to decompose a program
into subprograms. Even good highschools teach that to teenagers (some even
do abstract data types or, more recently, OO. One woman I know claims
to have learned about things like module cohesion and coupling in highschool.
The school was fortunate to have a good CS instructor).

I came to school from a childhood of hacking in assembly language in BASIC, 
and some Pascal.  Assembly taught me functional decomposition; it was far too
impractical to write long functions. Subroutines were your friend! When I
learned about abstract data types, I was bowled over.

>However, the computer scientist will do slightly better than the
>electrical engineer because the computer scientist has studied algorithm
>theory enough to figure out which algorithm works better.  It isn't
>until these people get into a disciplined development group that they
>actually learn how to design real software.  I hadn't even heard of a
>peer code review until I got to Rockwell.  The only peer reviewing I did

You are kidding! We had to do mandatory peer code inspections as part of the
aforementioned software engineering course and the project course.  Code
reviews allegedly catch something like 60% of defects (to pull some vague round
number out of a hat!) You have to read programs, not just write them.  We also
had to do mandatory lab work, which included hands-on experience with a CASE
tool known as Teamwork.  How can a computer science course not include at least
one course in SW engineering? 

Unfortunately, our course was a little too geared toward old traditions, like
structured analysis and design. I never understood the course properly until
some years later, when I realized that I had problems in the course because I
was thinking in an object-oriented manner centered around abstractions rather
than data flows or control flows. For instance, in some of the diagrams related
to structured analysis, I mistakenly tried to see abstractions or object-type
relationships. It was not until I read Booch that I became keenly aware of the
difference between the old and new schools. I could then see my educational
experience in its proper context.