Er du enig? 20 gyldne citater fra kendte programmører

Historien har budt på adskillige store skikkelser inden for programmeringens verden. Her får du en stribe af de bedste citater fra dem.

»Hvis debugging er der, hvor man fjerner softwarebugs, må programmering være der, hvor man tilføjer dem.«

Citatet stammer fra den kendte hollandske datalog Edsger Dijkstra, der nok er mest berømt for sin algoritme til at finde korteste veje fra et knudepunkt til alle andre knudepunkter i en graf.

Sammen med 19 andre berømtheder inden fra programmeringens verden pryder han en liste over 20 geniale, sjove og tankevækkende citater på hjemmesiden Java Code Geeks.

På listen suppleres han blandt andet af den danske opfinder af det objektorienterede programmeringssprog C++, Bjarne Stroustrup, som angiveligt har udtalt:

»C gør det let for dig at skyde dig selv i foden; C++ gør det sværere, men når du endelig gør det, skyder du hele benet af.«

En udtalelse, som kendere af de to maskinnære sprog nok vil nikke genkendende til. Eller om ikke andet så grine ad.

Hvad angår antallet af linjer i et program, anser Microsoft-stifter Bill Gates det for at rigtigt dårligt udtryk for programmets trivsel og vækst:

»At måle et programs fremdrift i antal kodelinjer svarer til at måle fremdriften af et flys konstruktion ud fra vægten«.

En voldelig psykopat

I samme boldgade optræder Ken Thompson, UNIX-godfather, med citatet:

»En af mine mest produktive dage var, da jeg smed 1.000 linjer kode ud.«

Også et par af koryfæerne inden for fri og open source-software kommer på banen. En af dem er Erik S. Raymond, forfatter til klassikeren 'The Cathedral and the Bazaar'.

Han afsender følgende svada til dem, der går højt op i universitetsstudier:

»Uddannelse inden for datalogi gør ingen til en dygtig programmør, ligesom det heller ikke gør nogen til en dygtig maler at studere pensler og farver.«

Sidste citat i denne omgang bliver fra Martin Golding, der kommer med et godt råd omkring kodens læsbarhed og dokumentation.

»Skriv altid din kode, som om ham, der ender med at vedligeholde den, er en voldelig psykopat, der ved, hvor du bor.«

Du kan læse flere citater hos Java Code Geeks og er velkommen til at bidrage med flere af dine favoritter i debatten herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (33)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

"Afprøvning kan ikke vise, at et program er fejlfrit, kun at der er fejl i det".

Og et andet (med ukendt kilde): "Hvis man på et tidspunkt bygger en computer, der kan programmeres på engelsk, vil man finde ud af at programmører ikke kan skrive engelsk".

  • 15
  • 0
tue kyndal

@Jeppe Schmidt: Tak for gode joke ... jeg var lige ved at falde ned af stolen.

@Sune Marcher: Du høre vist til den halvdel der ikke forstod joken...så lad mig lige gentage den i hele bytes...måske ti-øren så flader ;O)

Der findes 00000010 forskellige typer af mennesker i denne verden. Dem der forstår det binære talsystem og dem der ikke gør... God torsdag til alle!

Griner stadigvæk..og det er efterhånden sjælden efter et besøg på version2.

Keep them coming ;O)

  • 4
  • 9
Sune Marcher
  • 7
  • 0
Allan Ebdrup Blogger

Her er et jeg har opfundet selv, efter at have set mange forskellige systemer gennem årene:

Der er intet der er så simpelt, at det ikke kan gøres komplekst.

Det har jeg desværre måtte sige lidt for ofte.

Så hellere noget KISS og YAGNI

  • 10
  • 0
Per Dalgas Jakobsen

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

  • 12
  • 0
Casper Bang

Min favorit er ikke er omtalt nogen steder. David Wheeler udtalte engang "All problems in computer science can be solved by another level of indirection", hvortil Kevlin Henney svarede "...except for the problem of too many layers of indirection."

Dét må klinge rigtig mange steder, i en verden der til stadighed kompliceres af abstraktioner, lag, patterns mv.

  • 7
  • 0
Mark Gjøl

Premature optimization is the root of all evil (or at least most of it).


Folk forstår det desværre stadigvæk ikke helt... For nyligt spurgte Linus Torvalds ud om nogen kunne optimere et stykke kode der allerede kørte på meget få instruktioner (https://plus.google.com/102150693225130002912/posts/7bKRjV92snH)... Og en kastede det citat ud. Man kunne påstå, at optimering af Linux-kernen i dag ikke vil være premature. :)

  • 0
  • 0
Sune Marcher

Det er trivielt: Programmet

%&![#${Ȥ¨^!#(

er på en linje, og indeholder een fejl: Det kan ikke oversættes.

Det er da blot et spørgsmål om at lave en Brainfuck v2 ;-)

Premature optimization is the root of all evil (or at least most of it).

Det citat bruger jeg nærmest hver dag til at prioritere efter.

Desværre skriver nogle af de folk, der bruger det citat, kode man skulle tro gik efter devisen "premature pessimization"... hvilket kan ende med at spilde endnu mere tid end en smule gold-plating.

  • 0
  • 1
Robert Larsen

"[The BLINK tag in HTML] was a joke, okay? If we thought it
would actually be used, we wouldn’t have written it!" -- Mark Andreessen

"On two occasions I have been asked [by members of Parlia-
ment!]: ‘Pray, Mr. Babbage, if you put into the machine wrong
figures, will the right answers come out?’ I am not able rightly
to apprehend the kind of confusion of ideas that could provoke
such a question." -- Charles Babbage

"The first 90% of the code accounts for the first 90% of the
development time ... The remaining 10% of the code accounts
for the other 90% of the development time." -- Tom Cargill

"The Internet is a great way to get on the net." -- Bob Dole

"To err is human, but to really foul things up you need a com-
puter." -- Paul Ehrlich

"One of the main causes of the fall of the Roman Empire
was that, lacking zero, they had no way to indicate successful
termination of their C programs." -- Robert Firth

"I sit looking at this damn computer screen all day long, day in
and day out, week after week, and think: Man, if I could just
find the ‘on’ switch ..." -- Zachary Good

"A computer program does what you tell it to do, not what you
want it to do." -- Greer's Third Law

"One machine can do the work of fifty ordinary men. No machine
can do the work of one extraordinary man." -- Elbert Hubbard

God weekend

  • 4
  • 0
Jacob Christian Munch-Andersen

Premature optimization is the root of all evil (or at least most of it).


Et citat hvis misbrug kan måle sig med selv bibelske tekster.

Skal vi lige tage bare en bid mere af sammenhængen:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Og så i øvrigt notere at citatet primært omhandler optimeringer på et lavt abstraktionsniveau, så som at rulle loops ud, skrive udtryk om for at spare et par operationer og lignende.

Jeg er rimelig sikker på at Knuths intentioner ikke var at give folk en undskyldning for at undlade at tænke performance ind i deres design.

Nu om dage vil jeg mene at mangel på optimering generelt er et langt større problem end den optimering/obfuskering som Knuth omtaler.

  • 4
  • 0
Michael Zedeler

Og så i øvrigt notere at citatet primært omhandler optimeringer på et lavt abstraktionsniveau, så som at rulle loops ud, skrive udtryk om for at spare et par operationer og lignende.

Til en start vil jeg lige pointere at jeg læser "optimization" som performanceoptimering. Ikke andet. Men ellers synes jeg skam det i høj grad er relevant uanset hvilket niveau man arbejder på. Det er ikke "premature" hvis man på arkitektniveau træffer nogle valg af hensyn til performance - tvært i mod (jeg har f. eks. for ikke lang tid siden frarådet en stor, pan-nordisk virksomhed fra at bruge SugarCRM til deres 2000+ sælgere og 500.000+ kunder - nu kan læserne så diskutere om det er "premature optimization" eller ej).

Det er fuldstændig rigtigt at der er et bjerg af elendige systemer hvor dovenskaben har været den drivende faktor bag de fleste beslutninger. Det kan man bare ikke sidestille med Donald Knuths citat.

Det som jeg synes at jeg oplever, er at rigtig mange performanceoptimeringsvalg bliver truffet i blinde, eller med utilstrækkelige data som grundlag. Dermed ender man med at forbedre performance på steder der ikke er på en kritisk sti i systemet og samtidig bliver det efterfølgende vedligehold tilsvarende kompliceret.

  • 0
  • 0
Dennis Decker Jensen

For en ordens skyld så vil jeg gengive hele afsnittet omkring citationen af Donald Knuth. Det er fra "Structured Programming with go to Statements", Computing Surveys, Vol. 6, No. 4, December 1974 - Copyright ACM, gengivet med deres tilladelse. Artiklen kommer omkring meget mere end blot low-level-optimering, selv om det er det centrale emne. Er stadig aktuel, og kan anbefales at genlæse med nogen få års mellemrum.

”The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise-and-pound-foolish programmers, who can’t debug or maintain their ”optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. After working with such tools for seven years, I’ve become convinced that all compilers written from now on should be designed to provide all programmers with feedback indicating what parts of their programs are costing the most; indeed, this feedback should be supplied automatically unless it has been specifically turned off.”

Det sidste venter vi så stadig på for de fleste oversætterprogrammer. Jeg ved, at fx SBCL (Common Lisp oversætter) som standard giver hints om mulige optimeringer i programkode.

Dovenskab kan være lige så skidt (hvis ikke mere) end den overreaktion, som Knuth omtaler, så det er stadig værd at tage diskussionen om de 12% - for et kvalitetsprogram, som ikke er nærmere defineret.

  • 1
  • 0
Dennis Decker Jensen

It is to be noted that neither algebra will handle problems such as: “If a boy aged twenty can gather ten pounds of blackberries in a day and a girl aged eighteen can gather nine pounds, how many will they gather together?” The answer is, of course, that it all depends, but probably not very many. If the reader feels himself to be affronted by the absurdity of such a problem, let us remark quite firmly that it is at least as representative as either of the other two examples of the questions which arise in everyday life.
- Lord Baron Bertram Vivian Bowden, "Faster than Thought" (1953), p.37

  • 0
  • 0
Dennis Decker Jensen

The Novice has been the focus of an alarming amount of attention in the computer field. It is not just that the preferred user is unskilled, it is that the whole field in its application rewards novices and punishes experts. What you learn today will be useless a few years hence, so why bother to study and know /anything/ well? I think this is the main reason for the IT winter we are now experiencing.
- Erik Naggum

  • 1
  • 0
Dennis Decker Jensen

Der findes jo tusinder af gode citationer. Stopper med Dijkstra og noget dansk.

"The programmer is in the unique position that his is the only profession in which such a gigantic ratio [10^9], which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before. ... [A program] has, unavoidably, the uncomfortable property that the smallest possible perturbations -- i.e., changes of a single bit - can have the most drastic consequences."
- Edsger W. Dijkstra, 1989

"Conceptually FORTRAN remained on familiar grounds in the sense that its purpose was to aid the mechanization of computational processes we used to do with pen and paper (and mechanical desk calculators if you could afford them). This was in strong contrast to LISP whose purpose was to enable the execution of processes that no one would dream of performing with pen and paper."
- Edsger W. Dijkstra

Divus Madsen: "Hvordan vil du få folk te å tro på din
sandhed, når du sæller ud a den?!"
Fan Gok: "Lissom konsulentfirmaerne: Jeg sætter prisen op."

  • 0
  • 0
Log ind eller Opret konto for at kommentere