Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Programming Quotes

The quote were compiled from several sources. The major were The Contempt Page which in turn mentions Jim Huggins (see his Short Quotes web site),  the Lambda the Ultimate web site, the quoteland.com web site, the Andy "Krazy" Glew's Favorite Quotes and Sayings web site, the Bumper-Sticker Computer Science web site, a Programming Quotations web site, the sysprog.net Quotations for Programmers web site, the Alan Perlis Epigrams in Programming web site, the Paul Graham's Quotes (mostly about Lisp) web site, the Quotations on simplicity in software design web site, Programming Quotations web site, Eugene Fink's web site, Glenn Vanderburg: Quotations on Software Design web site, Glenn Vanderburg: Quotations on Software Design web site, jbox.dk Quotations on simplicity in software design web site. Mathematical and Educational Quotation Server at Westfield State College Quotations Related to University Studies of Computer Science (some in Finnish)

Language, Design, Language Design

A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

- D. Adams

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice. Simplicity and straighforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

Frederick P. Brooks, Jr.: The Mythical Man-Month. Addison-Wesley, Reading MA, 1995 (anniversary ed.)

Greenspun's Tenth Rule of Programming: “Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.”

Philip Greenspun — but where?

Simplicity of the language is not what matters, but simplicity of use.

Richard A. O'Keefe in squeak-dev mailing list, April 2003

Software development methodologies evolved under this regime [figure it out, code it up, compile it, run it, throw it away] along with a mythical belief in master planning. Such beliefs were rooted in an elementary-school-level fiction that great masterpieces were planned, or arose as a by-product of physicists shovelling menial and rote coding tasks to their inferiors in the computing department. Master planning feeds off the desire for order, a desire born of our fear of failure, our fear of death.

Richard P. Gabriel and Ron Goldman: Mob Software: The Erotic Life of Code

To me, development consists of two processes that feed each other. First, you figure out what you want the computer to do. Then, you instruct the computer to do it. Trying to write those instructions inevitably changes what you want the computer to do and so it goes.

In this model, coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh domain of reality. It is where you learn what your computer can do. If you stop coding, you stop learning.

We aren't always good at guessing where responsibilities should go. Coding is where our design guesses are tested. Being prepared to be flexible about making design changes during coding results in programs that get better and better over time. Insisting that early design ideas be carried through is short sighted.

Kent Beck: Smalltalk Best Practice Patterns. Prentice Hall, NJ 1997

Planning is a necessary evil. It is a response to risk: the more dangerous an undertaking, the more important it is to plan ahead. Powerful tools decrease risk, and so decrease the need for planning. The design of your program can then benefit from what is probably the most useful source of information available: the experience of implementing it.

The spirit of Lisp hacking can be expressed in two sentences. Programming should be fun. Programs should be beautiful.

Paul Graham: ANSI Common Lisp

First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

Hal Abelson and Gerald Jay Sussman with Julie Sussman prefacing SICP

The most difficult work of programmers, and also the most rewarding, is not writing programs but rather designing abstractions.

Peter Van Roy and Seif Haridi: Concepts, Techniques, and Models of Computer Programming

A language that doesn't affect the way you think about programming, is not worth knowing.

A programming language is low level when its programs require attention to the irrelevant.

Alan J. Perlis: Epigrams in Programming

languages shape the way we think, or don't.

Erik Naggum in comp.lang.lisp, January 2000

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

Edsger W. Dijkstra: How do we tell truths that might hurt? (EWD 498)

 

Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion. And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg.

Paul Graham: Beating the Averages

languages are ecologies. Language features are not a priori good or bad. Rather, language features are good or bad in context, based on how well they interact with other language features.

What do I consider is most important for an abstract language to support efficiently? My time. Time is the only true, non-renewable commodity. I eschew languages like C because they often waste enormous amounts of my time trying to develop and debug programs, and justify it on the basis of micro-differences in speed that have just never ended up mattering to me. I regard C as appropriate for use as an assembly language, but it doesn't provide enough high-level services for me. When I'm old and grey and look back on my life, I want to have done a lot of interesting things, not just have done a few interesting things but “boy were they fast”.

I want my ideas to lead my technology and my tools, not to have my technology and tools leading my ideas.

Kent Pitman – Answers on Lisp and Much More, Slashdot 2002(?)

remember that language design and language implementation are different tasks. When you are designing a new language feature first think like a user and then validate it as an implementor.

Allen Wirfs-Brock in squeak-dev mailing list, January 2003

The computers are never large enough or fast enough. Each breakthrough in hardware technology leads to more massive programming enterprises, new organizational principles, and an enrichment of abstract models. Every reader should ask himself periodically “Toward what end, toward what end?” — but do not ask it too often lest you pass up the fun of programming for the constipation of bittersweet philosophy.

Alan J. Perlis forewording SICP

Mastering Complexity or Not

Computing's core challenge is how not to make a mess of it.

It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity.

Edsger W. Dijkstra: The next forty years (EWD 1051)

Software quality has almost nothing to do with algorithmic elegance, compactness, or speed — in fact, those attributes do more harm to quality than good.

The objective is to make things as clear as possible to the designer and to yourself, and excessive formality can destroy clarity just as easily as modest formality can enhance it.

.

[The Spec] Be literal in your interpretation and smile when the designer accuses you of semantic nit-picking.

In programming, it's often the buts in the specification that kill you.

Don't squeeze the code. Don't squeeze the code. DON'T SQUEEZE THE CODE.

Like so much in testing, the act of getting the information on which to base tests can be more effective at catching and exterminating bugs than the tests that result from that information. Insisting on getting transaction flows or the equivalent is sometimes a gentle way of convincing inept design groups that they don't know what they're doing. These are harsh words, but let's face it: superb code and unit testing will be useless if the overall design is poor. And how can there be a rational, effective design if no one on the design team can walk you through the more important transactions, step by step and alternative by alternative. I'm sure that mine is a biased sample, but every system I've ever seen that was in serious trouble had no transaction flows documented, nor had the designers provided anything that approximated that kind of functional representation; however, it's certainly possible to have a bad design even with transaction flows.

Boris Beizer: Software Testing Techniques 2E. Van Nostrand Reinhold, New York 1990

Paradox: by not considering the future of your code, you make your code much more likely to be adaptable in the future.

Kent Beck: Test-Driven Development. Addison-Wesley, Boston 2002

The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.

Frederick P. Brooks, Jr.: No Silver Bullet — Essence and Accident in Software Engineering. In: The Mythical Man-Month (anniversary ed.) Addison-Wesley, Reading MA, 1995

Object-Orientation

The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.

Edsger W. Dijkstra: How do we tell truths that might hurt? (EWD 498)

OO is like the Bible in that which scripture is to be interpreted metaphorically, and which is to be interpreted literally, is entirely a function of the religious agenda of the commentator. My own advice is to keep in mind that the stuff of computer programs is nothing but metaphor.

Thant Tessman in comp.object, August 2003

The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. This is not necessarily bad, but it is not entirely good either.

A lot of the code in the real worl is spaghetti code, and this is probably not going to change soon. For programs that would have ended up as spaghetti anyway, the object-oriented model is good: they will at least be structured spaghetti. But for programs that might otherwise have avoided this fate, object-oriented abstractions could be more dangerous than useful.

Paul Graham: ANSI Common Lisp

Bricks are just too limited, and the circumstances where they make sense are too constrained to serve as a model for building something as diverse and unpredictable as a city. And further, the city itself is not the end goal, because the city must also –in the best case– be a humane structure for human activity, which requires a second set of levels of complexity and concerns. Using this metaphor to talk about future computing systems, it's fair to say that OO addresses concerns at the level of bricks.

Despite the early clear understanding of the nature of software development by OO pioneers, the current caretakers of the ideas have reverted to the incumbent philosophy of perfect planning, grand design, and omniscience inherited from Babbage's theology.

Richard P. Gabriel: Objects have failed. OOPSLA 2002

C++

C++ is like teenage sex:

• It's on everyone's mind all the time.
• Everyone talks about it all the time.
• Everyone thinks everyone else is doing it.
• Almost no one is really doing it.
• The few who are doing it are
  • doing it poorly;
  • sure it will be better next time;
  • not practicing it safely.

allegedly a toilet graffito at the Technion CS department in Haifa, Israel, 1993-11-08 [ornate PS version]

When your hammer is C++, everything begins to look like a thumb.

Steve Haflich in alt.lang.design, December 1994

Being really good at C++ is like being really good at using rocks to sharpen sticks.

Thant Tessman in comp.lang.scheme, December 1996

(Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.)

Thant Tessman in comp.lang.scheme, April 1997

the effort that has gone into extending and 'refining' C++ (and to its creation in the first place) must be largely attributed to the unwillingness of its advocates to give up the effort they've already put into learning and using it (and C before it). Strangely, this is simultaneously despite and because of the fact that C++ is not one of the easier languages to learn.

Thant Tessman in comp.lang.c++.moderated, July 2000

As for C++ – well, it reminds me of the Soviet-era labor joke: “They pretend to pay us, and we pretend to work.” C++ pretends to provide an object-oriented data model, C++ programmers pretend to respect it, and everyone pretends that the code will work. The actual data model of C++ is exactly that of C, a single two-dimensional array of bits, eight by four billion, and all the syntactic sugar of C++ fundamentally cannot mask the gaping holes in its object model left by the cast operator and unconstrained address arithmetic.

Guy L. Steele: Objects have not failed. OOPSLA 2002

Unix and C

The C language (invented by Bell Labs — the people who were supposed to be building products with five 9's of reliability – 99.999%) then taught two entire generations of programmers to ignore buffer overflows, and nearly every other exceptional condition, as well. A famous paper in the Communications of the ACM found that nearly every Unix command (all written in C) could be made to fail (sometimes in spectacular ways) if given random characters (“line noise”) as input. And this after Unix became the de facto standard for workstations and had been in extensive commercial use for at least 10 years. The lauded “Microsoft programming tests” of the 1980's were designed to weed out anyone who was careful enough to check for buffer overflows, because they obviously didn't understand and appreciate the intricacies of the C language.

I'm sorry to be politically incorrect, but for the ACM to then laud “C” and its inventors as a major advance in computer science has to rank right up there with Chamberlain's appeasement of Hitler.

Henry Baker : “Buffer Overflow” security problems

Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%–80% of what you want from an operating system and programming language.

Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they?

Unix and C are the ultimate computer viruses.

Richard P. Gabriel: Lisp - Good News, Bad News, How to Win Big

The most irritating part of Unix IMHO is not the design of the kernel (yeah, yeah it's a monolithic spaghetti ball) or the functionality of system calls (yeah, yeah, no PCLSRing) or the unrecoverability of kernel panics, or whatever else is associated with the kernel and driver implementations. What's really irritating about the Unix design is all the institutionalized crufty software still floating around after thirty years of development, redesign, and redevelopment. Unix hackers have long spent time hacking on the hardware support, improving process scheduling, memory management, and the like, but they still live with an interface that feels just like 2.9BSD on a PDP-11/40, with some frills. It's disgusting. Everything from the init process on upwards is institutionalized, designed just like it was on the good old minicomputers.

(I'm not degrading the Unix (or UN*X as it were) of that era, nor the machines it ran on, many of which I'm enamored of and wish I could own. I'm criticizing the stubborness of an operating system that dates from that era and appears to be little changed from it.)

James A. Crippen in comp.lang.scheme, April 2000

“The wonderful thing about Unix standards is that there are so many to choose from.” You may be totally bewildered about the multitude of various standards that exist. Rest assured that nowhere in this manual will you encounter an attempt to spell it all out for you; you could not read and internalise such a twisted account without bleeding from the nose and ears.

Olin Shivers (supplementing Andrew S. Tanenbaum): Scsh Reference Manual

Yes, dear?
No, I wasn't complaining....
Yes, I understand unix is the waveofthefuture....
Yes, unix is the equivalent of a programmer/sysadmin Full Employment Act....
No, lusers will never understand unix, so I'll always have a job if I learn it....
Yes, unix is free (and worth every cent)....
No, no two unix installations are alike, so there's plenty of job security for everyone....
No, nothing ever gets fixed in unix so there's more job security....

Joe Bednorz: Gawd I miss VMS in e.mail to Richard Levitte, March 1996

Perl

Perl's gluing ability goes beyond computation, to people. To the poor and have-nots. It unites people in the computing field who are not endowed with fancy engaging brains. It is the sanctuary of dunces. The expressions of those thoughtless. The godsend for brainless coders. The means and banner of sys admins. The lingua franca of trial-and-error hackers. The song and dance of stultified engineers.

I'm also a Perler. Share a secret with me: When you are cornered by mathematicians or the like, who are about to speak lamba or something we don't understand, what do you do? Of course, flip out the little Swiss Army Knives in our pockets, and splutter #%$@ syntaxes that is equally abstruse, and we feel safe and secure. Fuck geniuses in this world. Leave Perlers along. Larry Wall for President. The three principal virtues of . . .

I think comrade glauber is incorrect. First of all, he got our mantra wrong. It is: The three characteristics of Perl programers: mundaneness, sloppiness, and fatuousness. Secondly, our language is not evolved to support no fucking real life no shit. Our language, is designed to be a fuckup from the very beginning. Designed, to fuck up those computer scientists. Fuck up their teachings. Fuck up their students. Fuck up their language. Fuck up their correctness. Fuck up their fucking theoretical theories. Remember, P is for Practical.

Xah Lee in comp.lang.lisp, December 2000

Perl did some things well: It transcended implementation differences by staring them in the eye and fighting it out, not by giving up, whining that something isn't standard and portable, etc. It gave the bad standards and their nonsensical implementation differences the finger and wrote its own standard. For the kinds of tasks Perl does well, it is downright impressively portable. You need the ever expanding Perl book, but not the tens or hundreds of shelf-feet of manuals that you used to have to deal with. Perl has created its own operating system interface precisely by being an incredibly ugly implementation, and I'll give Larry Wall this, but not much else: He did fully understand the value of uniform external behavior of a tool and he was willing to pay the price to get it. There is no excuse for the language he created in order to do this, however.

Erik Naggum in comp.lang.lisp, November 2000

the perl programmer who veers off the road into the forest will get out of his car and cut down each and every tree that blocks his progress, then drive a few meters and repeat the whole process. whether he gets where he wanted to go or not is immaterial — a perl programmer will happily keep moving forward and look busy.

it's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done,

Erik Naggum in comp.lang.lisp, March 2000

What really pisses me off with Perl is that people work so hard doing so terribly little while they think they have worked very little doing something really nifty. Fools!

Erik Naggum in comp.lang.lisp, October 2000

“IT” and “Software Engineering”

Software Engineering is Programming when you can't.

We must give industry not what it wants, but what it needs.

Edsger W. Dijkstra quoted in the program (10M .pdf) of his birthday symposium, Austin TX, 2000

Another series of [philosopher's] stones in the form of “programming tools” is produced under the banner of “software engineering”, which, as time went by, has sought to replace intellectual discipline by management discipline to the extent that it has now accepted as its charter “How to program if you cannot”.

Edsger W. Dijkstra: The threats to computer science (EWD 898)

In a cruel twist of history, however, American society has chosen precisely the 20th Century to become more and more a-mathematical (...), and we have reached the paradoxical state that, of all so-called developed nations, the USA is the most dependent on programmed computers and intellectually the worst equipped to be so. The suggestion that the programming problem could be amenable to mathematical treatment is, if heard at all, instantaneously rejected as being totally unrealistic. As a result, Program Design is prevented from becoming a subdiscipline of Computing Science. (...) And in the mean time, programming methodology –renamed “software engineering”– has become the happy hunting-ground for the gurus and the quacks.

Edsger W. Dijkstra: Why American Computing Science seems incurable (EWD 1165)

The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.

Edsger W. Dijkstra: How do we tell truths that might hurt? (EWD 498)

Robert and I both knew Lisp well, and we couldn't see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn't mean anything. If you chose technology that way, you'd be running Windows.

During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening — that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

Paul Graham: Beating the Averages

While we were doing Viaweb, we took a good deal of heat from pseudo-technical people like VCs and industry analysts for not using a database — and for using cheap Intel boxes as servers, running FreeBSD. But when we were getting bought by Yahoo, we found that they also just stored everything in files — and all their servers were also cheap Intel boxes running FreeBSD.

(During the Bubble, Oracle used to run ads saying that Yahoo used Oracle software. I found this hard to believe, so I asked around. It turned out the Yahoo accounting department used Oracle.)

Paul Graham on database-backed web applications

Technology is part of the answer, not part of the question. Don't make choices only to then try to figure out how to twist the problem in such a way so as to fit your choice. This will often result in your solution being more convoluted than my previous sentence.

Curtis Poe: Finding Technology Solutions, Perl Monks 2001-07-23

Those who use databases usually do so because they master no data structures of their own.

A few years from now, programming will have been revolutionized and lots and lots of work will be done by software that writes itself. This will requrie massive talent and intelligence and thinking outside the box and what have you, but for the time being, programming is a “consumer” job, “assembly line” coding is the norm, and what little exciting stuff is being performed is not going to make it compared to the mass-marketed crap sold by those who think they can surf on the previous half-century's worth of inventions forever. This will change, however, and those who know Common Lisp will be relieved of reinventing it, like the rest are doing, even in the “tools” world, badly.

Erik Naggum in comp.lang.lisp, June 2001

there is no aspect of database management that is not characterized by lack of foundation knowledge and riddled with confusion (...) As long as the industry neither requires, nor rewards knowledge of fundamentals, why should we expect anything else?

Fabian Pascal Responds, On Denormalization and Repeating Groups

Comparisons

VMS is like a Soviet railroad train. It's basically industrial-strength, but when you look at it closely, everything's a little more shabby than you might like. It gets the job done, but there's no grace to it.

The Mac operating system is like the monorail at Disney World. It's kind of spectacular and fun, but it doesn't go much of anywhere. Still, the kids like it.

Unix is like the maritime transit system in an impoverished country. The ferryboats are dangerous as hell, offer no protection from the weather and leak like sieves. Every monsoon season a couple of them capsize and drown all the passengers, but people still line up for them and crowd aboard.

MS-DOS is like the US rail system. It's there, but people just ignore it and find other ways of getting where they want to go.

Posted by Paul A. Vixie to rec.humor in March 1991

You're posting to a Scheme group. Around here, arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark.

Thant Tessman in comp.lang.scheme, June 2000

[On the recommendation to “initialize every variable as soon as it comes into scope”]
This is one of the totally mindless rules which in practice leads to bad code. I am sick of seeing C code which initialises variables to values that never get used; that is lying to the reader, and lying to the reader is never good idea. Variables should only ever be initialised when you have a value that you intend to use that you can initialise them with.

Richard A. O'Keefe in squeak-dev mailing list, September 2003

If someone didn't understand their code and its likely uses well enough to write brief useful comments, why should I imagine that they understood it well enough to write code that works?

Richard A. O'Keefe in squeak-dev mailing list, June 2003

Realistically, the practice of putting untested code into systems is common, and so are system failures. The excuse I've most often heard for putting in untested code is that there wasn't enough time or money left to do the testing. If there wasn't enough time and money to test the routine, then there wasn't enough time and money to create it in the first place. What you think is code, before it has been properly tested, is not code, but the mere promise of code — not a program, but a perverse parody of a program. If you put such junk into a system, its bugs will show, and because there hasn't been a rigorous unit test, you'll have a difficult time finding the bugs. As Hannah Cowley said, “Vanity, like murder, will out.” For it's vanity to think that untested code has no bugs, and murder to put such code in. It is better to leave out untested code altogether than to put it in. Code that doesn't exist can't corrupt good code. A function that hasn't been implemented is known not to work. An untested function may or may not work itself (probably not), but it can make other things fail that would otherwise work. In case I haven't made myself clear, leaving untested code in a system is stupid, shortsighted, and irresponsible.

GIGO (“Garbage-in equals garbage-out”) is no explanation for anything except our failure to test the system's tolerance for bad data. Garbage shouldn't get in — not in the first place or in the last place. Every system must contend with a bewildering array of internal and external garbage, and if you don't think the world is hostile, how do you plan to cope with alpha particles?

But to be really diabolical takes organization, structure, discipline, and method. Taking random potshots and waiting for inspiration with which to victimize the programmer won't do the job. Syntax testing is a primary tool of dirty testing, and method beats sadism every time.

A good threat is worth a thousand tests.

Boris Beizer: Software Testing Techniques 2E. Van Nostrand Reinhold, New York 1990

Tests are the Programmer's Stone, transmuting fear into boredom.

Kent Beck: Test-Driven Development. Addison-Wesley, Boston 2002

Finally, the idioms of a language are useful as a sociological exercise (“How do the natives of this linguistic terrain cook up a Web script?”), but it's dangerous to glean too much from them. Idioms are fundamentally human, therefore bearing all the perils of faulty, incomplete and sometimes even outlandish human understanding.

Shriram Krishnamurthi: Programming Languages: Application and Interpretation

Yes, as a name, xnor generalises well to the n-ary case: I'm confused completely independent of the number of arguments passed to the function.

Olin Shivers in the SRFI-33 discussion archive

The main idea here is that in the end the programmers want to program in a very high level language, and the machine should be as configurable as possible towards helping the best conceived environment run as fast as possible. A secondary idea is that it is hard to design when you have your optimization hat on, and thus, if you want to make progress with interactive language design, you want to be able to start using your latest and greatest ideas with as little special optimization as possible.

These are not goals that Intel and Motorola understood, anymore than they understood anything important about SW in general. The current caching schemes are rudimentary to say the least. The more interesting architectures today are the graphics accelerators — they don't do anything particularly new, but they at least have some notion of what they are supposed to do (and also what they don't have to do when Moore's Law makes it easy to have multiple processors).

Alan Kay in squeak-dev mailing list, March 2003

In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs. Where organization standards require flow charts, these are almost invariably done after the fact. Many shops proudly use machine programs to generate this “indispensable design tool” from the completed code. I think this universal experience is not an embarassing and deplorable departure from good practice, to be acknowledged only with a nervous laugh. Instead it is the application of good judgment, and it teaches us something about the utility of flow charts.

Frederick P. Brooks, Jr.: The Mythical Man-Month. Addison-Wesley, Reading MA, 1995 (anniversary ed.)

A favorite subject for Ph.D. dissertations in software engineering is graphical, or visual, programming, the application of computer graphics to software design. Sometimes the promise of such an approach is postulated from the analogy with VLSI chip design, where computer graphics plays so fruitful a role. Sometimes the approach is justified by considering flow charts as the ideal programming design medium, and providing powerful facilities for constructing them.

Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.

In the first place, as I have argued elsewhere, the flow chart is a very poor abstraction of software structure, Indeed, it is best viewed as Burkes, von Neumann, and Goldstine's attempt to provide a desperately needed high-level control language for their proposed computer. In the pitiful, multipage, connection-boxed form to which the flow chart has today been elaborated, it has proved to be essentially useless as a design tool — programmers draw flow charts after, not before, writing the programs they describe.

.

Whereas the difference between poor conceptual designs and great ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind, it cannot enflame or inspire the drudge.

Frederick P. Brooks, Jr.: No Silver Bullet — Essence and Accident in Software Engineering. In: The Mythical Man-Month (anniversary ed.) Addison-Wesley, Reading MA, 1995

Flowcharts have been falling out of favor for over a decade, and before another decade passes they'll be regarded as curious, archaic relics of a bygone programming era. Indeed, flowcharts are rarely used today; they're created mainly to satisfy obsolete documentation specifications.

I think that if you were to gather statistics over one big project or many small projects (that used the same paper), then the weight of the listings would correlate as well to the bug rate and test efforts as do lines of code. Yet, “lines of code” sounds reasonable and scientific, and “listing weight” seems to be an outrageous put-on. Who's putting whom on? The fact is, that it makes exactly as much sense (or nonsense) to say “This is a 230-gram program” as it does to say “This is a 500-line program.”

“Logic” is one of the most often used words in programmers' vocabularies but one of their least used techniques.

The barrier to reusable software has never been technical — it's been financial and managerial. Reusable software doesn't get built if no one is willing to pay the price. New languages and programming techniques won't do it — they never have. It takes bucks and guts.

Boris Beizer: Software Testing Techniques 2E. Van Nostrand Reinhold, New York 1990

I have been told that one of the reasons for the longevity of the Roman bridges is that their designers had to stand under them when they were first used. It may be time to put a similar discipline into the software field.

Henry Baker : “Buffer Overflow” security problems

We have gotten OK at building cathedrals — only we are building the same dozen or so over and over again.

The effect of ownership imperatives has caused there to be no body of software as literature. It is as if all writers had their own private companies and only people in the Melville company could read Moby-Dick and only those in Hemingway's could read The Sun Also Rises.

Richard P. Gabriel and Ron Goldman: Mob Software: The Erotic Life of Code

(I have found that the worst possible thing you could do wrong in this world is to give people something that is more powerful than they are prepared to understand. Back when I believed that SGML was a brilliant idea, I did not understand that the people who were the intended users were completely unable to understand it, and that only those who were stupid enough not to realize it in time, would continue to work with it, and so they sat there with their excellent document production system with a clever markup system and thought it had to be useful for something grander, and now we have XML, a non-solution to a non-problem so brilliant that m4 no longer seems like a prank. We really need Gary Larson- style cartoons on the history of computer science.)

Erik Naggum in comp.lang.lisp, January 2004

HTML represents the worst of two worlds. We could have taken a formatting language and added hypertext anchors so that users had beautifully designed documents on their desktops. We could have developed a powerful document structure language so that browsers could automatically do intelligent things with Web documents. What we have got with HTML is ugly documents without formatting or structural information.

Philip Greenspun : We Have Chosen Shame and Will Get War

Some of the patterns books I have read stress the language-independence of the patterns. This turns out to mean “hey, we need it for Java too!”

Richard A. O'Keefe in squeak-dev mailing list, November 2002

It's hard to make things fool-proof because fools are so ingenious. I remember someone telling me about a statistics package they had written which would only let you do meaningful regressions. Instead of being glad to have errors caught before it was too late, their users had discovered that they could save data to a file and load it back in as if it was completely new data, thereby tricking the program into accepting calculations which made no sense.

Richard A. O'Keefe in squeak-dev mailing list, December 2002

You are crazy, but that's not important. The only thing that matters is whether or not you do anything. Do anything, and you matter.

Olin Shivers in comp.lang.scheme, April 2000

If people are sane, if the world keeps moving forward, if we intellectuals keep fulfilling our duty of education, then good things will spread, and happiness will rain on earth.

Xah Lee in comp.lang.lisp, July 2000

Percy:  You know, they do say that the Infanta's eyes are more beautiful
        than the famous Stone of Galveston. 
Edmund: Mm! ... What?
Percy:  The famous Stone of Galveston, My Lord.
Edmund: And what's that, exactly?
Percy:  Well, it's a famous blue stone, and it comes ... from Galveston.
Edmund: I see. And what about it?
Percy:  Well, My Lord, the Infanta's eyes are bluer than it, for a start.
Edmund: I see. And have you ever seen this stone?
Percy:  (nods) No, not as such, My Lord, but I know a couple of people who
         have, and they say it's very very blue indeed. 
Edmund: And have these people seen the Infanta's eyes?
Percy:  No, I shouldn't think so, My Lord.
Edmund: And neither have you, presumably.
Percy:  No, My Lord.
Edmund: So, what you're telling me, Percy, is that something you have never
        seen is slightly less blue than something else you have never seen.
Percy:  (finally begins to grasp) Yes, My Lord.