The Original Macintosh:    31 of 122 
Author: Andy Hertzfeld
Date: January 1982
Characters: Bud Tribble, Tom Malloy, Charles Simonyi, Bill Atkinson
Topics: Software Design, Technical, Lisa
Summary: A curious style of programming
Charles Simonyi in the early days

The Macintosh used the same Motorola 68000 microprocessor as its predecessor, the Lisa, and we wanted to leverage as much code written for Lisa as we could. But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.

We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish.

The Mac lacked the memory mapping hardware prevalent in larger systems, so we needed a way to relocate memory in software to minimize fragmentation as blocks got allocated and freed. The Lisa word processor team had developed a memory manager with relocatable blocks, accessing memory blocks indirectly through "handles", so the blocks could be moved as necessary to reduce fragmentation. We decided to use it for the Macintosh, again by recoding it from Pascal to assembly language.

The primary author of the Lisa word processor and its memory manager was Tom Malloy, an original member of the Lisa team and Apple's first recruit from Xerox PARC. Tom had worked on the Bravo word processor at PARC under the leadership of Charles Simonyi, and used many of the techniques that he learned there in his Lisa code.

Even though Bud Tribble had to leave the Mac team in December 1981 in order to retain his standing in the M.D./Ph.D. program at the University of Washington, he decided that he could still do the initial implementation of the memory manager, as we were planning all along, hoping to finish it quickly after he moved back to Seattle, before classes started. He obtained a copy of the memory manager source from Tom Malloy, but he was in for a shock when he began to read the code.

The memory manager source lacked comments, which was disappointing, but the biggest obstacle was the names selected for variables and procedures: all the vowels were gone! Every identifier seemed to be an unpronounceable jumble of consonants, making it much harder to understand the code, since a variable's meaning was far from obvious. We wondered why the code was written in such an odd fashion. What happened to all of the vowels?

It turns out that Tom Malloy was greatly influenced by his mentor at Xerox, a strong-willed, eccentric programmer named Charles Simonyi. Charles was quite a character, holding many strong opinions about the best way to create software, developing and advocating a number of distinctive coding techniques, which Tom brought to the Lisa team. One of the most controversial techniques was a particular method of naming the identifiers used by a program, mandating that the beginning of each variable name be determined by the type of the variable.

However, most of the compilers in the early eighties restricted the length of variable names, usually to only 8 characters. Since the beginning of each name had to include the type, there weren't enough characters left over to use a meaningful name describing the purpose of the variable. But Charles had a sort of work-around, which was to leave out all of the vowels out of the name.

The lack of vowels made programs look like they were written in some inscrutable foreign language. Since Charles Simonyi was born and raised in Hungary (defecting to the west at age 17), his coding style came to be known as "Hungarian". Tom Malloy's memory manager was an outstanding specimen of Hungarian Pascal code, with the identifiers looking like they were chosen by Superman's enemy from the 5th dimension, Mr. Mxyzptlk.

Bud decided that it would be too error prone to try to translate the Hungarian memory manager directly into assembly language. First, he made a pass through it to strip the type prefixes and restore the vowels to all the identifier names, so you could read the code without getting a headache, before adding lots of block comments to explain the purpose of various sub-components.

A few weeks later, when Bud came back to attend one of our first retreats, he brought with him a nicely coded, efficient assembly language version of the memory manager, complete with easy to read variable names, which immediately became a cornerstone of our rapidly evolving Macintosh operating system.

Back to The Original Macintosh
Calculator Construction Set

Account Name:


Create new account
Overall Rating: 4.13

Your rating:





I've always wondered how that got started. There was a BYTE article about Hungarian, too... the idea seemed to be an early form of C++ name-mangling, where you could tell the return type and all the parameter types of a function just by looking at the name. This is the first paragraph of a document named "Office Hungarian", still recommended reading at Microsoft today: = = = = This document describes the conventions we use in Office Development for naming stuff in code (variables, functions, constants, etc.). These conventions are collectively known as Hungarian, referring both to the nationality of their original developer, Charles Simonyi, and also to the fact that to the uninitiated programmer, code written using these standards tends to look like a foreign language. For example, here's a chunk of code from the Office97 memory manager. Perfectly readable, no? if ((pfb = PfbReallocHb(sb, cbAlloc, 0)) != (MSOFB *)-1) { // sb is good bet for future realloc mpsbdg[sb] &= ~(msodgOptAlloc|msodgOptRealloc); phb = PhbFromSb(sb); goto DoRealloc; } = = = = = Microsoft turns off symbols before they ship, to hinder third parties from deciphering Microsoft's code. I think if they want to make their output indecipherable, they should leave the symbols on!
As I remember, in the fall of 1982, after the IBM chip ("Integrated Burrell Machine chip") had become history (a story for another day), Andy Hertzfeld talked to me and suggested that I might be of some assistance to the Macintosh ROM team. Apparently, the Bud Tribble memory manager had been taken over by another team member, who had modified it to the point where it was most flakey and unreliable. I agreed to take it over and make it all better. I spent much of the next few months: -rearchitecting the API for the memory manager to rationalize it -reimplementing the memory manager with optional debugging checks at every invocation and exit to ensure that the heap state was consistent at entry and at return (a trick I myself had picked up working for the same Charles Simonyi while we were both at Xerox ASD). -testing and tuning the resultant code I then handed the code off to Larry Kenyon, one of the mostly unsung modest geniuses of the Macintosh ROM team, who as I recall performed at most a few further modifications before the code was in condition to ship.
Actuallt, Microsoft have changed their minds and no longer recommends the "Hungarian" coding style.
I used to be a Cobol programmer, back in early 90's. I was sick of usual Cobol naming for vars(e.g. AC-USV or WS-NAM), although no real coding style exists for Cobol, so I decided to use Hungarian coding style in my projects. It was nice back then, since the concept of types does not exists in Cobol as for many languages and the indication of variable type was really useful. That style helped me to create very complex applications in Cobol, specially those that dealt with UI (yes, it is possible). When I moved into ASP and VB in the late 90's the Hungarian style was well fixed in my mind. It was only when I started to work with C# and Java that the Hungarian coding style showed its cost. It was a pain to give up of it and use Camel instead since the coding style is responsible for a big part of logic development.
This article isn't entirely accurate. The notation style that Charles Simonyi created was based on the usage of the variable, not the type of data it held. Someone along the way misunderstood this very important distinction. At that point two different styles of Hungarian existed: Apps Hungarian and Systems Hungarian. Apps Hungarian (what Charles created) prefixes variables based on intended usage. Systems Hungarian prefixes variables based on the data type. Unfortunately, many others also misunderstood exactly what the prefix was for and started prepending variables with very much useless information. The downside to this is that it is much easier to change a data type than it is to change a variable name. One area this manifested itself in was the Windows API. A number of functions used Systems Hungarian for variable naming. When the data types changed, the variable names didn't... Leading to much confusion. Fortunately, MS came to grips with this and recommended that no one use Hungarian notation. Of course, this meant that "Apps" hungarian was being shot down as well, but IMHO it's a minor casualty in the greater war against meaningless variable names. Which leads us to this article in which the writer most likely exacerbated the original misunderstanding through lack of understanding.