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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Any research putting c above ada? Date: 1997/05/01 Message-ID: <5kaqd4$m9b@bcrkh13.bnr.ca> X-Deja-AN: 238768712 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <33674E4C.446B@cca.rockwell.com> <5k88b3$340@bcrkh13.bnr.ca> <3368A6FE.41C6@cca.rockwell.com> Organization: Prism Systems Inc. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-01T00:00:00+00:00 List-Id: In article <3368A6FE.41C6@cca.rockwell.com>, Roy Grimm 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.