Reads: E.W. Dijkstra: “The Humble Programmer”

Posted on June 10, 2010 by Karl

E.W. Dijkstra ACM Turing Lecture 1972: “The Humble Programmer”:

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 1010 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 creating change

Posted on May 30, 2010 by Karl

Kimberly Blessing shares “What You Can Learn From Jamie Oliver About Creating Change”.

Open Source news and knowledge aggregation projects that have caught my eye recently

Posted on May 30, 2010 by Karl

Managing News

Ushahidi

ThinkTank

The Fifty State Project

Media Cloud

A little further down the stack:

Jim Henson, 20 Years Later

Posted on May 18, 2010 by Karl

Wired: “20 Years Later, Remembering Jim Henson”.

There can never be enough journalists like Bill Moyers

Posted on May 5, 2010 by Karl

Recently my friend and coworker Arpit Mathur passed along a critique of journalism’s sorry state using the leaked iPhone story as evidence.

The sad thing is that we might be amidst some kind of golden age for journalism and are largely unawares.

For evidence, visit sites and services like ProPublica, NPR.org, McClatchyDC, THe Center for Investigative Reporting, Global Voices, Mother Jones, Global Post.

Separate from these organizations are independents who are putting it on the line every day just for passion.

And then there are aggregators like Arts & Letters Daily to help navigate it all and organizations like Media Mobilizing to help empower acts of journalism to be created.

In Philadelphia some investors just made a large bet that Philadelphia Inquirer, Daily News, and Philly.com, part of this city’s infrastructure of journalism has a promising future.

For impact consider what it took to write the “Tainted” Justice” series in the Daily News or “Justice Delayed, Dismissed, Denied” in the Inquirer.

Recently Clay Shirky spoke of the importance of organizations like the Inquirer and Daily News (The Boston Globe in this case) in reporting the Boston Catholic Church abuse scandal.

The news ecosystem is evolving and Philadelphia matters as a testbed for the rest of the nation.

For more examples of this consider the following list of Philadelphia independents, non-profits, for-profits, and organizations: NEPhilly.com, OurPhiladelphia, Philadelphia Neighborhoods, The Frankford Gazette, The Broad Street Review, WHYY, thenotebook, Phawker, Philebrity, Citypaper, Philadelphia Weekly, The Philadelphia New Media Hub, Technically Philly, and the yearly Bar Camp NewsInnovation Philadelphia. And then there is the ever growing quality list covering the arts, food, and sports, way too many too mention in this space.

J-Lab, The Institute for Interactive Journalism, recently published a report on Philadelphia’s news landscape and made some recommendations. Check it out.

Programmers and Journalists are realizing common motivations and many journalists have been thinking about computing in whole new ways that relate to their work.

There are threats. It is harder for acts of journalism we need to know, but are not aware of it, to reach us. The old economic models that have supported it have crumbled. Changes in technology and culture have brought upheaval and amidst that upheaval those with power will abuse that power when not watched. The constraints on our attention and business pressures on those to breach it are huge. It’s important to lay out these threats because they get to core issues having to do with the infrastructure required for acts of journalism to be produced and be effective.

But to re-emphasize my point – there are many organizations and individuals who are doing it today. In some cases have been doing it for years, that we need to somehow amplify among the din.

As a programmer, I recognize this has everything to do with information science, communications, marketing, and development. As a citizen I recognize it has everything to do with our communities, our neighborhoods, cities, our country and navigating the world at large and hopefully making it a better place. One story at a time.

Which makes this a sad moment to note – Bill Moyers has broadcast his last episode of “Bill Moyers Journal” and ended a run of one of the best sources of journalism on television. The Journal will be missed.

NPR.org: “After Four Decades In TV News, Bill Moyers Retires”

NYTimes: “A Breather for Moyers; Next Step Is Unclear”

On “finding truth in the world and about ourselves”

Posted on April 8, 2010 by Karl

Is Programming more like ‘art’ then ‘science’? A debate that is continuous, but I know where Richard P. Gabriel stands. In 2003 he wrote the forward to “Successful Lisp: How to Understand and Use Common Lisp,” by David B. Lamkins titled “The Art of Lisp and Writing”. Recently it got shared at “Hacker News”.

I admit to knowing enough about Lisp to be intrigued (inspired by it even) but have never used it at work or in a personal project. His essay while touching on some differences between Java and Lisp (and he would know – he worked at Sun), talks more of the act of writing and creation and how programming is akin to that. It was a good read.

Taught that programming–or the worse “developing software”–is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn’t a science and unlike science and engineering, it isn’t a serious activity. Judgments like this, though, are easiest made by people who don’t seriously engage in making both science and art. Art, engineering, and science are–in that order–part of a continuum of finding truth in the world and about ourselves.

…The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you’re inadvertently making.

There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus–when we are in flow–we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.

Read the whole piece.

Share this:
Mastodon
Reddit
Pocket
Facebook
LinkedIn
Email
Print

What is software testing

Posted on March 28, 2010 by Karl

We just concluded a lab week at CIM that was awesome. No other short way to put it. Read Jon’s post for the details.

For this lab week I worked with folks from QA exploring a tool (a MIT research project called “Sikuli”) for its applicability in functional testing. I’ll have a post sharing how well it went soon. We learned quite a bit, had a great exchange of experience across a departmental boundary, and now have an additional tool in the tool belt that we will be using in some cases.

I had an interesting mountain to climb to become familiar with the challenges faced in QA. What helped set the stage for me was a great Google Tech Talk by James Bach on becoming a Software Testing Expert. His video is really about becoming an expert in almost anything but the slide on “Perfect Testing” made me take pause (literally – I paused the video to consider the slide because it is so expansive and almost poetic):

Perfect testing is…

Testing is the infinite process

of comparing the invisible

to the ambiguous

so as to avoid the unthinkable

happening to the anonymous.

In other words, perfect testing is a challenge.

That’s quite a statement!

Bach goes on to fill in the picture around this statement. Watch the entire video for the context.

After taking part in this lab week, a lot of what James Bach said in this presentation has sunk in further.

I had thought I was empathetic to the work that is encompassed in software testing. What I found out was I wasn’t even close, and this experience has left me a bit humbled and inspired.

I have a feeling some of this applies to becoming a better communicator overall

Posted on March 27, 2010 by Karl

NYTimes: “Building a Better Teacher”:

But what makes a good teacher? There have been many quests for the one essential trait, and they have all come up empty-handed. Among the factors that do not predict whether a teacher will succeed: a graduate-school degree, a high score on the SAT, an extroverted personality, politeness, confidence, warmth, enthusiasm and having passed the teacher-certification exam on the first try. When Bill Gates announced recently that his foundation was investing millions in a project to improve teaching quality in the United States, he added a rueful caveat. “Unfortunately, it seems the field doesn’t have a clear view of what characterizes good teaching,” Gates said. “I’m personally very curious.”

When Doug Lemov conducted his own search for those magical ingredients, he noticed something about most successful teachers that he hadn’t expected to find: what looked like natural-born genius was often deliberate technique in disguise. “Stand still when you’re giving directions,” a teacher at a Boston school told him. In other words, don’t do two things at once. Lemov tried it, and suddenly, he had to ask students to take out their homework only once.

It was the tiniest decision, but what was teaching if not a series of bite-size moves just like that?

Uncommon Schools

Change This: Jon Wortmann: “The Best Communicator in the World”