From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 26 Aug 1992 07:47:18 GMT

In article <1992Aug21.193337.16888@merlin.dev.cdx.mot.com> lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:
>In article <1992Aug21.005430.11003@news.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>|>>Are you seriously claiming that you go straight from a mental picture
>|>>of the final program to assembly without any intervening design steps?
>|>
>|>Are you saying it's *necessary* to go through committee meetings to write
>|>code?
>|>
>|>All programs are a collection of small steps, even hll ones.  In the case
>|>of assembler, it's often smaller still steps, sometimes it isn't, so what?
>|>
>|>You are proving my point, I blame academia for spreading this nonsense that
>|>panders to mediocrity.  If I understand the problem well enough, I write the
>|>code.  Maybe I write it on listing as I study it, maybe I write it on the
>|>back of an old listing to save paper, or maybe I just type it into my
>|>editor, but in any case, once past the *specification* of the problem (which
>|>is 99% of the effort IMO) I just write the code.
>|>
>|>Perhaps the widespread use of more inefficient methods of writing code goes
>|>hand in hand with the inefficiency of the code itself.
>|>
>|>I think there will be hll people here who will agree with me about most of
>|>this; code is code; you think of it; you write it; you test and debug it;
>|>you refine it; you repeat cycle 'til done.
>|>
>|>As explained in the Real Programmers story, the little toy that helps you
>|>write flow charts was left behind by the previous occupant of the desk; perhaps
>|>this is part of why he was previous, not present.
>
[Much flammage deleted]

The jist of this response is that the poster has worked on a supremely large
project involving so many people, that they need management just to keep
track of the programmers.


I won't comment on whether this project is managed correctly or not, but it's
this kind of thinking that would lead many to believe that the SDI may be
possible, while the SDI critics would point to this proof of why it will
never be pulled off.

My own point of view is that the posters point of view is so biased that he
can't conceive of the fact that there are individuals earning a living in
this business who turn out the equivalent of N of the people in his project.
This is not to say that his project could be done by current/N people, just
that for some smaller projects, it is totally normal.

His suggestion that I work only a week on any project is similarly skewed,
but I will admit that I never worked on any one project for more than 10
years :-).

cjl

>I am a graduate in Computer Science and I've worked in computing for eight
>years, all the time on large projects (the first was AT&T's 5ESS, rumoured
>to be the largest software project ever, with at least a couple of thousand
>developers at any time, and my current project has between 100 and 200
>developers).

>
>Your opinions lead me straight to the conclusion that the largest program
>you've ever written probably took you (on your own) no more than a week to
>write, and probably it takes you about half that time to write most of
>them.  I'm guessing here, but it seems reasonable that the vast majority
>of people who write code for a living write larger programs than that.  For
>those of us who do, high level languages are essential, as are requirements
>and design documentation and all the other aspects of software engineering
>that you denounce.
>
>On a personal note, I take offense at the implication that (a) because
>I use structured methods and a hll I write mediocre code, and (b) I write
>inefficient code using inefficient methods.
>
>Maybe the bottom line is that you should stay with your assembler and leave
>the high level languages to the professionals (though I must add that yes,
>there are professionals out there who use assembler).

Yes, I'll leave it to myself and the thousands of others who use assembler.

How many other people subscribe to the idea that productivity (as opposed to
salary) is a function of how many people can get in on a project?

cjl