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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,267eec8ad557a7d0 X-Google-Attributes: gid103376,public From: zink@panix.com (David Zink) Subject: Re: ARIANE-5 Failure (DC-X works) Date: 1996/06/17 Message-ID: <4q4tbv$b6b@panix3.panix.com>#1/1 X-Deja-AN: 160721540 references: <4plpqn$ko5@Starbase.NeoSoft.COM> organization: Panix Public Access Internet & Unix, NYC newsgroups: comp.lang.ada Date: 1996-06-17T00:00:00+00:00 List-Id: In article dewar@cs.nyu.edu (Robert Dewar) writes: >Samuel said > >"Your definition misses a subtle distinction. I can't define it >formally. I think most of us view programmers as people who tell a >system HOW to do something. The MatrixX user identifies WHAT to >compute, but not HOW." > >The reason you cannot define this discinction formally is that it is >a meaningless one. That was the whole point of Lambert's point about >VHLANOS. One person's program is another persons abstract specification. I agree that only micro-code or assembly language programmers tell the machine HOW to compute instead of just WHAT. However I have been wrestling with the question of how to distinguish between Pascal Programmers and Data-Entry operators. You see, the Data-Entry operator enters a bunch of symbols (programs the database) so that it will print out a specific set of values (behave in a certain way). I compare them to Pascal programmers because of your phrase 'executable specification'. Pascal compilers produce not executable code but data (P-code) which the pascal database engine massages to generate the reports I've requested. I next thought, "Ah, but the Pascal Programmers manipulates the data he enters in order to produce more desirable output." Having worked in the financial industry for some time, I quickly remembered that this was no different than Data-Entry. However it does qualify the Pascal Data-Entry crew as 'engineers', so if we label them 'Software Engineers' instead of programmers, at least we have believable nomenclature. But it still leaves me wondering what a 'Programmer' is. Obviously those mathematicians using Matrix-X are not, as anyone can see (formal distinctions being a bit of a joke when they cannot distinguish things people can easily distinguish). Your points about whether the code is delivered in ADA seem equally meaningless. Either ADA is a language in which a team of fools cannot create a dysfunctional program, or it is not. It hardly matters to me or any thinking person whether the team of fools is biological or cybernetic. The only value to programming in ADA or any other high-level language is that it allows competent programmers to significantly reduce their accidental error rate. Its value is not that it forces a wise choice of algorithms, or that it forces the program specification to bear a meaningful relation to the actual problem to be solved, though it =can= help the program specification bear a meaningful relationship to the program behavior. These last issues are the proper domain of programmers. The first is the proper domain of tools. If the mathematicians entered equations into a database and the runtime code retrieved those equations and evaluated them using validated ADA code/methods, would they be programmers or (as I suspect) data-entry operators? If, the (equation) data being constant for individual runs of the program, the data was extracted from the database and transformed into executable/compilable code, does that transform the mathematicians into programmers? In which case I've transformed an awful lot of data-entry operators into programmers over the years. I should tell them they're underpaid. Perhaps you see why I'm confused. --David PS (a few passing thoughts): If I were accepting machine generated code for a project of mine, I would want awfully iron-clad proof that the code-generator's output implemented the input. Until we eliminate documentation and specification altogether, until the program *is* its documentation and specification, I doubt that we'll have reliable programs. The main advantage of assembly language programming is that it kept incompetent programmers from ever completing a project. Unfortunately the cost was that even competent programmers were hard put to avoid subtle errors. What I'd like is a language with no subtle errors.