Smart Software

Vista Issues

I have been testing my software under Vista pre-RC1 (5536) and noticed some issues.

My multithreaded application is no longer as responsive as it was under Windows XP during scanning. I had done the right thing and separated the scanning code from the UI thread; I also gave the scanning thread a Below Normal thread priority.

I used the AnimateWindows from Win32 to animate various child windows in my application. However, the Vista’s Desktop Window Manager doesn’t play well with AnimateWindows, leaving the windows being animated undrawn, so I will probably remove the animation. Shame. Here’s what it would looked like on XP.

Link to Full Animation Video

Framework Bug #1

This snippet is from the file _baseoverlappedasyncresult.cs in the SSCLI project (aka Rotor). This function is used in the Base Class Library of the .NET Framework.

private void InternalFree()
{
    m_Overlapped = null;
    m_PinnedObjects = null;

    if (m_NativeOverlapped != IntPtr.Zero)
    {
        unsafe
        {
            Overlapped.Free((NativeOverlapped*) m_NativeOverlapped);
        }
        m_NativeOverlapped = IntPtr.Zero;
    }
}

In this snippet is a bug that eluded Microsoft's many static analysis tools (RaceTrack, Spec#, etc). See if you can find it.

Great Developers

Joel have been talking about finding great developers. Every bloggers seems to have their own ideas about what makes a great developer. [1] [2] [3] [4] Maybe I do too.

We could ask widely-acknowledged great programmers, like Stiff did, what makes a great programmer. Ironically, one of these great developers, Linus Torvald, has terrible habits that violate the criteria of each blogger.

Paul Graham, who wrote about Great Hackers, also notes that is difficult to recognize a great hacker without working with one.

So who are the great hackers? How do you know when you meet one? That turns out to be very hard. Even hackers can't tell. I'm pretty sure now that my friend Trevor Blackwell is a great hacker... But when I first met him, I thought he was a complete idiot.

Paul says its also difficult to recognize one's self as a great hacker. Naturally, every one thinks himself to be at least a very good developer. How do you know for sure?

Someone at Reddit asked "How do you know if you're a good programmer?" Interestingly, one replied that only good programmers ask themselves that question. Another commenter, BigTech replied,

To me, a good programmer optimizes code--they can get more done with less code, for example:

If X = 0, then X = 1 else X = 0 End If

becomes X=ABS(X-1)

By BigTech's own definition, he doesn't seem like a good programmer. (He also uses VB--a warning sign.)  His expression could be optimized down to 1 - x or even !x. Apparently, BigTech mistakenly believes he's a good programmer; he didn't realize that he defined a function over two points, which could be directly expressed as a linear function. I also disagree with his optimization theory, but then again Steve Wozniak spent "his whole life trying to optimize things."

BigTech's overassessment of himself reminded me of Chris Sell's post on how to recognize expertise. (Apparently, Chris didn't have a mirror at home.) Chris later mentioned an article called "Unskilled and Unaware of It. How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments," which Alan Bellows has a good summary on:

When asked, most individuals will describe themselves as better-than-average in areas such as leadership, social skills, written expression, or just about any flavor of savvy where the individual has an interest. This tendency of the average person to believe he or she is better-than-average is known as the "above-average effect," and it flies in the face of logic… by definition, descriptive statistics says that it is impossible absurdly improbable for a majority of people to be above average. Clearly a large number of the self-described "above average" individuals are actually below average in those areas, and they are simply unaware of their incompetence.

The inability to recognize one's incompetence is not unlike the experience of being color-blind. [2] [3]

Just as we might overestimate ourselves, so too we might overestimate the abilities of others we regard as great. John Rozewicki argues that we turn great people into superhumans, but in reality no one is a genius. (How else can three housewives outsmart computer engineers, rocket scientists and NSA?) Guardian Unlimited writes how Einstein struggled with his grand theory - and the maths. Einstein also had a smaller than average brain, which probably doesn't mean anything. Another research article, "The Expert Mind," suggests that anyone can become a genius. Even for child prodigies like Mozart, Gauss, and Bobby Fischer, heavy labor spanning over a decade was required to prepare each genius.

Stevey, who equates greatness with fame, writes "get famous by not programming." His programming heroes, he realized, become heroes either because they were more vocal by writing a popular book or blog or were associated with a popular product, neither of which necessarily equate to being a good programmer.

Do you have any programming heroes? I do! Oddly enough, though, I've never really seen much of their code. Most of the famous-ish programmers I respect have actually made their impact on me through writing, and it's usually just prose, with maybe a little code interspersed....

.... But when someone builds a framework — any environment that we live in and actually enjoy programming in — and there's one person who's chiefly identifiable as the primary author of that framework, then I think we tend to admire that person, and unlike other programmers, the person starts to become famous...

Even if they're a crappy programmer.

Joel, I am pretty sure, considers himself a great programmer.  The post suggests that he may just be famous because of the articles he's written and how he leverage that into book sales, product sales, and forum activity. As for whether he's a great programmer, he's has the same natural tendency to inflate his worth as any other developer. He could simply be tooting his own horn, which is larger than everyone else's. Is FogBugz really that technologically impressive? Well, Joel does have one attribute of genius mentioned by Bertrand Russell.

One of the most important elements of success in becoming a man of genius is to learn the art of denunciation. You must always denounce in such a way that your reader thinks that it is the other fellow who is being denounced and not himself; in that case he will be impressed by your noble scorn, whereas if he thinks that it is himself that you are denouncing, he will consider that you are guilty of ill-bred peevishness. Carlyle remarked: ``The population of England is twenty millions, mostly fools.'' Everybody who read this considered himself one of the exceptions, and therefore enjoyed the remark.

In another ironic twist, Bertrand Russell also says that one must delude himself (a common refrain of mine) in order to become a genius.

Ignore fact and reason, live entirely in the world of your own fantastic and myth-producing passions; do this whole-heartedly and with conviction, and you will become one of the prophets of your age.

If we are to delude ourselves, how do tell if we're geniuses or simply incompetents with inflated views of ourselves.

Driving While Talking

Whenever I am talking to a passenger while driving on the freeway, I often miss signs and forget to take the proper exits long after I realize what I have done.

I don't usually edit while I write, except for the usual spell-checking. I don't want to create more work than necessary. The main purpose of posting is to just get some thoughts of mine down in written form. I think the process improves the clarity of one's thinking.

Anyhow, the last few posts contained more than the usual number of errors, so I will be redoing them in the next couple days, possibly adding more information. I have mentioned mistakes in blog posts before.

There are a few differences in my blogging procedure. I have been experimenting with the new Windows Live Writer blogging program from Microsoft, and I have been cutting and pasting links that I have collected and categorized for future posts. These two events introduced combined to form a major distractions. I was also possibly more tired than usual.

High Level Languages & Performance

I suspect that the performance advantage of procedural languages does not necessarily exist over newer exotic languages. Over time, this should the performance gap should lessen. An ecosystem of processor features, developer tools, and algorithms have evolved over the past quarter century that favor the Algol-based languages like C and C++. Fortran once regularly outperform C, probably in part, because it was developed and popularized much earlier.

A large part of performance advantages in a language is due to the quality of the compiler and tools , which is usually dictated by the popularity of a language, its commercialization, and the resulting positive feedback of revenue into the compiler's continued development. New languages are perpetually at a disadvantage as a result.

Logic programming (primarily, Prolog) has always been regard as slower, but there have been a few efforts to make improvements in this area. The Aquarius project aimed to implement a fast compiler for Prolog; the researchers presented their results in Can Logic Programming Execute as Fast as Imperative Programming? Researchers of the Mercury language attempted an even faster industrial strength implementation with a more general logical programming language that supports full first-order predicate logic, not just the Horn subset, and recently added constraint logic programming. Developers can provide determinism modes for each predicate defined, and the compiler will reorder terms appropriately. The compiler automatically recognizes loops and performs aggressive inlining.

New chips are typically targeted at the prevailing language of the day. One article, Next Generation Stack Computing, describes how stack-based chip architectures are superior in performance to conventional register-based cousins in a number of important areas such as faster procedure calls and reduced complexity (short pipeline and simpler compilation) but was accidentally missed in an expensive detour by the computer industry. The approach reminds me of Intel's original design for its 64-bit chip, which Intel forwent for greater 32-bit compatibility. I wonder if such an approach might actually have favored functional languages.

David Chisnall of InformIT debunks the Myth of High-level Languages being slower. Nate criticizes Dave's assertion that high-level languages like Java provide more information to the compiler to do its magic. I think that Dave might have been closer to the truth if he had expanded his discussion to declarative languages with much more optimization opportunities.

Even with the advantages of being first, low-overhead and low-level languages like C and C++ are still being challenged by languages that ought to be slower (see the Computer Language Shootout). C# and Java use the combination of dynamic JIT compiler with runtime information and a very efficient garbage collector with a superfast allocator optimized for locality. Strict functional compilers, like OCAML, sometimes outperform C++ in benchmarks. Recently, Haskell are able to use its laziness to avoid wasted work. New multicore processors tend to favor declarative languages which are more easily parallelizable.

I haven't even touch on the debate of whether relative language performance is important any more or not. Dynamic languages like Ruby and Python are proving to be especially popular and acceptable performance-wise for delivering commercial GUI applications.

Model-View

Last April, I wrote about a profound design change I was making into my document-based applications, which was to make all my document data structures immutable--standard practice in some functional programming languages.

My original motivation was to make each of my model objects an expression that I could work with in a functional way and apply transformation rules to. (My first attempt a few years ago failed because I earlier assumed that mutability was required for editable documents.) The result is substantially less code and tight integration between my document and my AI framework. From the user's point of view, the application would appear more intelligent, permitting more complex document analysis and manipulations than seen in the past.

The document essentially becomes a value. The ease of changing a document in this fashion is comparable to using a TextBox control, which is simply accessed and modified by getting and setting the Text property of the TextBox control.

There is an additional cost of path copying from the root of the document tree to the changed node, but this is more than offset by a number of other direct benefits such as trivial multithreading, elimination of undo work, and other simplified algorithms (eg, easier document comparison/merging). Maintaining an undo log is actually expensive, when the document changes are high during an operation. My algorithms tend to be simpler because of the immutability variant and the access to the before and after state of the operation. My data structures became simpler, because they only need to be descriptive; anything extra is typically caching computed information. I no longer needed to store parent or other information, which enables extensive sharing.

There are some complications. I have lost object identity and each node has to be the document tree now needs to be referred to by its path, but the path can be encapsulated inside its own object and it turns out to be rarely need. Object identity presents problems when persisting, deleting, copying or pasting data (especially multiple times). If identity is really important, the node should contain an ID.

I also don't store an observers collection; I don't need to. After an entire operation is completed, I present the root view with the document before and after an operation. The view proceeds recursively downward to update its own nested views.

Intuitively, this approach makes sense. The model should be pure data, just as a string is in a TextBox ; it shouldn't containing any references to any view. The view should be able to rebuild itself based on the new and old states of the data. If a recently document node contains many children, there is a logarithmic time approach to compare before and after state of document node and find the range of children that were changed that I mentioned in a previous post.

I recently also came to the conclusion that my view data structures should also be immutable. In the course of researching the impact of changing the view, I noticed that a number of special purpose classes would no longer be needed resulting in a substantial decrease in code. I also discovered that I could dispense with a parent pointer and a reference to the model object in the view; these two could be externalized and provided by the parent. This also enables flyweights as well as virtual views, where a rendered model node is not actually backed by its own view node.

The changes are likely to improve performance because the modest costs of path copying are offset by the elimination of additional other processing (and accompanying allocations) and the impact of heavy sharing. The other processing includes layout, notifications between the model and view, and initialization/disposal code. Perhaps immutable objects could make Avalon less complex; however, Avalon might need to forgo the naturalness of property assignment.

This reminds me a blogger post that design-patterns aren't needed in functional programming, because they exist to make up for deficiencies in procedural languages.

Software Design Philosophy

 A year ago, I wrote that I would soon describe my software design philosophy in developing commercial desktop applications. I never actually did write directly on my philosophy. I still had unresolved design issues, which I have since resolved through making document and view objects immutable. I also felt that it was perhaps too early to disclose some information, especially after recalling Joel Spolsky's article "Mouth Wide Shut."

On the other hand, I did offer glimpses of my approach through various seemingly random posts like Silver Bullet and Software Reliability. I also did mention a preliminary wordprocessor I was working on, which, in reality, is a universal document-processing framework that can simply and efficiently store, manipulate, and display all kinds of documents. Despite Avalon architect Chris Anderson's wishes, don't count on Microsoft delivering full-featured application frameworks that could potentially make it easier for competing products to be developed; the MFC framework included a special restriction against developing wordprocessors and spreadsheet software.

My philosophy includes programming in a more declarative and functional programming style. My software is built on the unifying concept of immutable expressions (rather than objects) for representing data, be it mathematical, linguistic, or document. The term-rewriting system for manipulating expressions was inspired by a similar system in Mathematica. The system, which is rooted on the simple, powerful, and well-understood theory of lambda calculus, leads to surprising possibilities by removing the distinction between code and data. (More on that shortly.)

I noticed this article "Out of the Tar Pit," which makes similar points to the ones I raised in my Silver Bullet post. A Turing Tar Pit is an overly-simplified, Turing-Complete language in "which everything is possible but nothing interesting is easy." The classic example is the taped-based Turing Machine, but the authors of the article also implicate imperative programming languages, which are still modeled on a Random Access Turing Machine, which introduces accidental complexity due to state. The authors instead advocate functional relational programming.

I left as a software developer in the applications group at Microsoft in 2000, but I never actually stopped developing desktop applications. I did go through a period of unlearning development approaches used at Microsoft and much of the rest of the computer industry. Imperative programming as well as the evolutionary programming development are fundamentally flawed ways of developing document-processing applications; their continued use hinders the development of intelligent applications.

Programmers in 60's discovered maintainability issues with "goto," and came up with structured programming with decorated gotos with names like "while" and "switch;" this made programming more readable but not any more expressive. We still also live with the word-by-word "assignment bottleneck." As a result, most of the operations in today's applications can be summed up as fundamentally property assignments and vector operations (insert, delete, map) rather than more complex tree transformations.

I noticed that some thinkers at Microsoft are contemplating some of the same issues that I am addressing. Tony Williams, co-inventor of COM, in a recent Channel 9 interview mentioned his interest in the declarative construction of applications. He also referred to Charles Simonyi's obsession with tree transforms, which mirrors my use of "expressions" and transformation rules as unifying concepts in my application. The data access team also refers to a "conceptual layer" made possible by the LINQ technology. (Tony mentioned he was currently working on a new component application framework, debuting in Office 2007. Googling reveals that the framework is probably built on top of COM and going by the name "Octarine." If so, I am pessimistic of any real improvements outside of some reuse. )