Thinking in Ifs

Joel recently made this comment on Google versus Microsoft:

A very senior Microsoft developer who moved to Google told me that Google works and thinks at a higher level of abstraction than Microsoft. "Google uses Bayesian filtering the way Microsoft uses the if statement," he said. That's true. Google also uses full-text-search-of-the-entire-Internet the way Microsoft uses little tables that list what error IDs correspond to which help text. Look at how Google does spell checking: it's not based on dictionaries; it's based on word usage statistics of the entire Internet, which is why Google knows how to correct my name, misspelled, and Microsoft Word doesn't.

If Microsoft doesn't shed this habit of "thinking in if statements" they're only going to fall further behind.

I would tend to agree that abstraction is not a strength of Microsoft’s business-centric culture. Google has a history of utilizing general techniques besides bayesian filtering such as Map and Reduce and Page Rank. Even, Amazon employs collaborative filtering for personalization.

This view reflects some of my own thinking over the years, as I wondered about the future of control flow in mainstream programming languages. A lot of attention have shifted to constructs like continuations, closures and the like that release us from restrictions of  the stack-centric programming model that originated with Algol.

I came to the conclusion that low-level development with imperative constructs of structured programing like if, while, goto and for loops and even the new stuff—continuations (old-stuff for Scheme’rs)—was somehow impeding the development of “smart” applications. We already have gotten out of some of the hurdle with automatic memory management in which the runtime periodically searches for all available objects to reclaim, and perhaps new ideas in transactional memory will relieve developers from thinking about concurrency.

In the PDC talk, Scripting and Dynamic Languages in the CLR, one of the panelists, David Thomas, the brain behind Eclipse, who also worked with Smalltalk and Forth at IBM, mentioned that there was something wrong with a programming language if an AI backend is required. I was wondering if he thought about the converse statement of whether that there is something wrong if developers need to acquire machine intelligence (ie, think like a compiler) to work effectively within a programming language. Isn’t garbage collection sort of an AI system in which the runtime periodically searches for all available objects to reclaim?

In another interesting video on the future of CLR language support, “CLR Team Tour, Part II – The Future of Languages (PDC panel preview).”

Asked what makes a good language, Eric Meijer pushed his view of the ideal programming language, which is to remove the cognitive dissonance between human world and programming languages. Jim Miller then responded that, in designing the CLR, he tried to meet the needs of three different classes of languages—object-oriented , functional, and dynamic languages—in successive versions of the runtime. However, he left out support for the class of logical languages like Prolog, remarking “that, for my personal taste, it’s a fine one to leave out.” I wondered whether that might turn out to be a mistake years from now, because those languages, Prolog, Mercury, et al, may actually be more cognitively consonant than any of the other mainstream languages. These language don’t use control flow, but instead rely on searches and backtracking, mechanisms that can be difficult to replicate through traditional programming.

When we develop software with low-level control constructs, when we think in “ifs,” three things happen. (1) We are developing and reasoning at the human pace, seconds instead of nanoseconds, (2) we tend to avoid styles of programming that are complicated, styles that only a “computer” can understand, and (3) code doesn’t match the specification, so it’s difficult to read, test and maintain.

There are already declarative programming languages, both functional and logical, which do away with side-effects and traditional control flow structures. Control flow is managed by the compiler and may employ iteration, searches, and queuing.

I do a lot of declarative programming in XML and S-expressions, which is later generated into code or processed as data, to make up for deficiencies in today’s languages. I do think today’s programming languages will progressively become more declarative, while retaining their traditional efficiencies. We already see such progression in C# 3.0.

Comments

[Philipp Schumann]

Prolog.NET exists, though, even though I didn't get a chance yet to play with it.