Geek Logbook

Tech sea log book

Notes about: On the cruelty of really teaching computing science

Radical Novelty 1:

“The programmer is the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridge by a single technology he has be able to think in terms of conceptual hierarchies that are much deeper than single mind ever need to face before. Compared to that number of semantic levels the average mathematical theory is almost flat. By evoking the need for deep conceptual hierarchies, the automatic computer confronts us with a radically new intellectual challenge that has no precedent in our history”

Radical Novelty 2:

It is possible, and even tempting, to view a program as an abstract mechanism, as a device of some sort. To do so, however, is highly dangerous: the analogy is too shallow because a program is, as a mechanism, totally different from all the familiar analogue devices we grew with. (…) In the discrete world of computing, there is no meaningful metric in which “small” changes and “small” effects go hand in hand there never will be.

About Software Engineering:

A number of these phenomena have been bundled under the name “Software Engineering” as economics is known as “The Miserable Science”, software engineering should be known as “The Doomed Discipline”, doomed because it cannot even approach its goal since tis goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyze what its devotees actually do, you will discover that software engineering has accepted as its charter “How to program if you cannot”.

The notion of productivity by lines of codes:

The practice is pervaded by the treasuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring “programmer productivity” in terms of “numbers of lines of code produced per month”. This is a very costly measuring unit because it encourages the writing of insipid code (…) My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”.

About Bugs and Debugging:

It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrates their absence

Complete Text: On the cruelty of really teaching computing science


Leave a Reply

Your email address will not be published. Required fields are marked *.

You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>