On ever growing complexity in programming: on systems

Edsger W. Dijkstra gave a lecture, in 1972, that has since been come to be called “The Humble Programmer”. It’s a short piece that explains why software development, why programming, was growing more, not less complex over time, and some inspiration to be found in the dealing with it. There’s some choice quotes in here that I’m going to include, but read the whole thing.

On LISP:

With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

Lets call it TDD before TDD was coined:

Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.

On decomposing systems:

It has been suggested that there is some kind of law of nature telling us that the amount of intellectual effort needed grows with the square of program length. But, thank goodness, no one has been able to prove this law. And this is because it need not be true. We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called “abstraction”; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption —up till now not disproved by experience— that by suitable application of our powers of abstraction, the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length. But a by-product of these investigations may be of much greater practical significance, and is, in fact, the basis of my fourth argument. The by-product was the identification of a number of patterns of abstraction that play a vital role in the whole process of composing programs. Enough is now known about these patterns of abstraction that you could devote a lecture to about each of them.

On education:

As each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don’t expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today’s training and in those conservative groups of computer users that think their old programs so important that they don’t think it worth-while to rewrite and improve them. In this connection it is sad to observe that on many a university campus the choice of the central computing facility has too often been determined by the demands of a few established but expensive applications with a disregard of the question how many thousands of “small users” that are willing to write their own programs were going to suffer from this choice. Too often, for instance, high-energy physics seems to have blackmailed the scientific community with the price of its remaining experimental equipment. The easiest answer, of course, is a flat denial of the technical feasibility, but I am afraid that you need pretty strong arguments for that. No reassurance, alas, can be obtained from the remark that the intellectual ceiling of today’s average programmer will prevent the revolution from taking place: with others programming so much more effectively, he is liable to be edged out of the picture anyway.

There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.

On recognizing the difficulty, challenge, and opportunity:

Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10/10 or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

On Making and Working Towards Big Things: on innovation

Wondering why we’re living in an age of ever increasing decreased expectations? You are not alone. Author Neal Stephenson wrote a thought provoking must read for World Policy Institute titled, “Innovation Starvation”:

The imperative to develop new technologies and implement them on a heroic scale no longer seems like the childish preoccupation of a few nerds with slide rules. It’s the only way for the human race to escape from its current predicaments. Too bad we’ve forgotten how to do it.

The 99 Percent: a blog to follow

Tumblr and WordPress hosted blogs are home to an always ever growing source of inspiration. Check out “We are the 99 Percent”, hand written stories of struggle, fear, and hope.

Related:

Metafilter: “We are the 99 percent.”

Washington Post: “‘Occupy Wall Street’ only growing stronger”

New York Times: “Protests Stir Up Voices on the Web”

A Mathematician’s Lament: on education

Paul Lockhart wrote an accessible read on what is wrong with math education and the popular perception of math that is reinforced in culture that has been shared on the Web in quite a few corners. It deserves a wider read: “A Mathematician’s Lament”:

The art of proof has been replaced by a rigid step-by step pattern of uninspired formal deductions. The textbook presents a set of definitions, theorems, and proofs, the teacher copies them onto the blackboard, and the students copy them into their notebooks. They are then asked to mimic them in the exercises. Those that catch on to the pattern quickly are the “good” students.

The result is that the student becomes a passive participant in the creative act. Students are making statements to fit a preexisting proof-pattern, not because they mean them. They are being trained to ape arguments, not to intend them. So not only do they have no idea what their teacher is saying, they have no idea what they themselves are saying.

Even the traditional way in which definitions are presented is a lie. In an effort to create an illusion of “clarity” before embarking on the typical cascade of propositions and theorems, a set of definitions are provided so that statements and their proofs can be made as succinct as possible. On the surface this seems fairly innocuous; why not make some abbreviations so that things can be said more economically? The problem is that definitions matter. They come from aesthetic decisions about what distinctions you as an artist consider important. And they are problem-generated. To make a definition is to highlight and call attention to a feature or structural property. Historically this comes out of working on a problem, not as a prelude to it.

The point is you don’t start with definitions, you start with problems. Nobody ever had an idea of a number being “irrational” until Pythagoras attempted to measure the diagonal of a square and discovered that it could not be represented as a fraction. Definitions make sense when a point is reached in your argument which makes the distinction necessary. To make definitions without motivation is more likely to cause confusion.

Related:

Kevin Devlin: “Lockhart’s Lament – The Sequel”

Slashdot: “A Mathematician’s Lament — an Indictment of US Math Education”

G.H. Hardy:

A mathematician, like a painter or poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas.

Screaming Architecture: on systems

In “Screaming Architecture” Uncle Bob lays out one of the biggest wins by designing to the problem domain, instead of your weapon (ahem.. framework) of choice:

“If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.

Anemic Domain Model: on systems

Martin Fowler wrote a piece in 2003 that addresses a subtle anti-pattern – developing your domain model code devoid of behavior. It’s a short, interesting read, that is related to the development of fat controllers in MVCish applications: “AnemicDomainModel”:

“In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.”

Dear Emma

Dear Emma,

Hi Tinker. You’ve started Kindergarten, it is a big deal, even if you won’t remember it as such down the road, and I wanted to write you a letter, a message in a bottle. I hope you find this one day on an Internet like mine, one that empowered me to reach for my dreams.

In 1988, before I met Mommy, my younger brother and I were in trouble. It’s a long story, but importantly, both of us are blessed with a fantastic family now. We had to overcome much to get to where we are.

One of the tools to achieve that, for me, was a book of short stories that contained nuggets of wisdom. Wisdom that I saw few around me followed, but those that did seemed… happier… more at peace with themselves and the nature of the world. This didn’t result in complacency, but in an openness that enabled them to see the big picture, act upon it, and be true to themselves in their journey.

I learned about the book from an unlikely source, from a Rolling Stone article in 1990, on Steven Tyler, and Aerosmith, and its fight back from destruction.

It’s called, “All I Need to Know I Learned in Kindergarten”, by Robert Fulghum. Emma, my hope is you’re going to experience these lessons growing in your heart and mind (hopefully Mommy, me, all your grandparents, aunts and uncles, have demonstrated these things for you – I think we have).

The ideas in the book seem simple, but in practice, they aren’t. For example, ‘play fair’, when you will find, and it breaks my heart that this is so, that the world isn’t fair, and that some actually consider the idea of playing fair… weak. It’s not. Or take not hitting people. Always try and uphold it, however, there will be times you’ll be faced with a choice to defend yourself and others. And it will test your integrity and what you believe.

It is confusing and messy. But know this:

If you need to ask anything, ever, your entire family will try and answer it. There is no such thing as a dumb question. And if someone implies otherwise, have them see me (or your Grandpops, or uncles, or Grandmoms, or Mommy). We’ll set them straight.

Experience is a hard teacher, because she gives the test first, the lesson after. Ask!

Most important, you have an internal compass pointing at true North. Pointing at your heart, at truth and kindness. Listen to it. If you are feeling something is wrong – trust yourself – and think of the credo outlined at the beginning of this book.

It is a credo your Mommy and me believe in (she embodies this so much – she leads and teaches by example), and we hope you will too:

Each spring, for many years, I have set myself the task of writing a personal statement of belief: a Credo. When I was younger, the statement ran for many pages, trying to cover every base, with no loose ends. It sounded like a Supreme Court brief, as if words could resolve all conflicts about the meaning of existence.

The Credo has grown shorter in recent years – sometimes cynical, sometimes comical, and sometimes bland – but I keep working at it. Recently I set out to get the statement of personal belief down to one page in simple terms, fully understanding the naïve idealism that implied.

The inspiration for brevity came to me at a gasoline station. I managed to fill my old car’s tank with super deluxe high-octane go-juice. My old hoopy couldn’t handle it and got the willies – kept sputtering out at intersections and belching going downhill. I understood. My mind and my spirit get like that from time to time. Too much high-content information, and I get the existential willies. I keep sputtering out at intersections where life choices must be made and I either know too much or not enough. The examined life is no picnic.

I realized then that I already know most of what’s necessary to live a meaningful life – that it isn’t all that complicated. I know it. And have known it for a long, long time. Living it – well that’s another matter, yes? Here’s my Credo:

All I really need to know about how to live and what to do and how to be I learned in kindergarten. Wisdom was not at the top of the graduate-school mountain, but there in the sandpile at Sunday School. These are the things I learned:

Share everything.

Play fair.

Don’t hit people.

Put things back where you found them.

Clean up your own mess.

Don’t take things that aren’t yours.

Say you’re sorry when you hurt somebody.

Wash your hands before you eat.

Flush.

Warm cookies and cold milk are good for you.

Live a balanced life – learn some and think some and draw some and paint and sing and dance and play and work every day some.

Take a nap every afternoon.

When you go out into the world, watch out for traffic, hold hands, and stick together.

Be aware of wonder.

Remember the little seed in the Styrofoam cup: The roots go down and the plant goes up and nobody really knows how or why, but we are all like that.

Goldfish and hamsters and white mice and even the little seed in the Styrofoam cup – they all die. So do we.

And then remember the Dick-and-Jane books and the first word you learned – the biggest word of all – LOOK.

Everything you need to know is in there somewhere. The Golden Rule and love and basic sanitation. Ecology and politics and equality and sane living.

Take any one of those items and extrapolate it into sophisticated adult terms and apply it to your family life or your work or your government or your world and it holds true and clear and firm. Think what a better world it would be if we all – the whole world – had cookies and milk about three o’clock every afternoon and then lay down with our blankies for a nap. Or if all governments had as a basic policy to always put things back where they found them and to clean up their own mess.

And it is still true, no matter how old you are – when you go out into the world, it is best to hold hands and stick together.

We love you sweetheart,

Mommy and Daddy