Re: Any research putting c above ada?

[Roy Grimm <ragrimm@cca.rockwell.com>]

Kaz Kylheku wrote:
> 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!

We didn't have any courses like that.  I took the class on formal
languages, where we touched on the various language types (iterative,
rule-based/logic, OO, etc.) but we never really got into compiler
building.  I started to take a graduate course in language priciples. 
The professor really was just walking us through how he built a lisp
based compiler.  I dropped it about halfway through since I had read to
the end of the book and absorbed all the material.  (I'm not interested
in pursuing a graduate degree right now, so I wasn't too concerned about
dropping the credits.)  I ended up picking up a book and I've started to
write my own Pascal compiler.  I probably won't ever write compilers for
a living, but it's an interesting subject that I don't know too much
about.

> 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.

Our OS course was all theory (and it was an elective to boot! <pun
intended>).  We had to write only one program in the entire class which
showed how we would structure a round-robin process scheduler.  We
didn't actually write the scheduler.  We only wrote a simulator which
would print out the order for processes based on an input file that
listed process entry time and duration.  I wanted to challenge myself so
I did it in Pascal with a circular linked list.

> 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.

We never had distributed systems of any kind, except as a brief side
note in our OS class.

> 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).

Machine architecture turned into an "intro to assembler" class with a
theoretical overview of basic logic circuts.  Wecovered up to showing a
16 bit adder built with various AND/OR/XOR/NOT gates.  We then jumped
right to "then you make all these pieces and put them together to make a
processor and it runs machine instructions".  The latter half of the
class was listening to lectures on how different machine instructions
work.

> 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.

The data structures/algorithm classes weren't recommended until the
junior year.  First year, intro to programming (two semesters to learn
Pascal).  Second year, architecture and assembler (many elected to take
the OS class too), Third year, data structures/algorithms and a possible
elective of programming language principles.  Then you were done.  You
could graduate with just that. (along with several math classes like
linear algebra and so forth...)  And many people did!  I took every
possible class I could to expand my experience.  However, there wasn't
much to take.  I had to take independent study classes to learn C, Unix
and Ada.

> 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. :)

Team projects?  The only team project we had was when we were all
sitting around in the lab helping each other find bugs.
 
> I had a lot of fun in school. To this day I'm convinced that I got my money's
> worth.

I wish I could say the same.  Too much money and no real practical
knowledge.  I'm really dissapointed with the Comp Sci program at my alma
mater.
 
> 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).

That sort of coding indicates a serious lack of basic training that
permiates some institutions.  We never once touched on debugging
techniques, team development, or any kind of software development
techniques.  The highschool I went to had one teacher for computers.  He
had his nephew (a graduate student in comp sci) come in to teach us all
Pascal (the teacher included!)
 
> 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.

Fortunately, my father is an engineer who taught me many things about
software development when I was in high school.  I had a full working
knowledge of software development before I got to college.  My professor
docked points on my homework because I was doing things in my
assignments that we hadn't covered yet.  Something as simple as "if
response not in ['y', 'Y', 'n', 'N']..." to test a response from the
user brought down the wrath of my prof.  "We won't do anything with sets
until second semester" was the response I got.

> 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?

"We're teaching Computer Science here.  If you want engineering, go to
an engineering school."  That's the prevailing attitude with many of the
CompSci programs at small liberal arts colleges.  They teach the
"science" of programming almost as a subfield of Mathematics.  The
professors usually don't have any knowledge or training in real world
software development.  You can get a PhD in Comp Sci with only writing a
handfull of large programs.  Even then, your programs really only need
to be directly related to your thesis.  With a PhD, you can become a
professor at almost any college.  Many of the professors that were
teaching in the colleges and universities I attended or was considering
attending had no real-world experience.  They went right through college
to graduate school and right into teaching.  IMNSHO, they are brilliant
theorists but poor software developers.  Granted, there are exceptions
to this very broad generalization, but not too many of them make
themselves widely known in the midwest.

> 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.

Personally, I was a cynic from the begining.  I have an engineer for a
father and an older sister who forged the path before me.  I knew enough
ahead of time to expect that most profs are more concerned with academic
theory than with teaching real-world practical knowledge.  I was
pleasantly suprised to find that there were several profs at my school
who thought differently.  My advisor in particular recognized that I was
more interested in learing how to work with computer systems and develop
software.  He supported me by suggesting I take independed and directed
study classes that let me learn what I really wanted and needed.

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com