watching it rise

What’s So Precious About Bad Software?

Sure, we are drowned in tides of twaddle about precious IP, Trade Sekkrits, Sooper Original Algorithms that must not be exposed to eyes of mere mortals, and all manner of silly excuses. But that’s all a smokescreen to cover up the real reason: to hide code of such poor quality that even PHBs know to be embarrassed. Exhibit A: Windows itself. Which proves it takes more than throwing billions of dollars and thousands of programmers at a software project to build something that is actually good.
– Carla Schroder

I can usually look at a bug and see at least one way the code could be borked. But this one just boggles me.

Yesterday evening we were alerted to an issue in Excel 2007 (and Excel Services 2007) involving calculation of numbers around 65,535. The first example that we heard about was =77.1*850, but it became clear from our testing as well as additional reports that this was just one instance where Excel 2007 would return a value of 100,000 instead of 65,535. The majority of these additional reports were focused on multiplication (ex. =5.1*12850; =10.2*6425; =20.4*3212.5 ), but our testing showed that this really didn’t have anything do to with multiplication - it manifested itself with many but not all calculations in Excel that should have resulted in 65,535 (=65535*1 and =16383.75*4 worked for instance). Further testing showed a similar phenomenon with 65,536 as well. This issue only exists in Excel 2007, not previous versions.

See also: Explaining the Excel Bug from Joel on Software

And let’s face it — do you really want the bright sparks who work there now, and manage to break lots of perfectly good working code — rewriting the core calculating engine in Excel? Better keep them busy adding and removing dancing paper clips all day long.

Richard Jones treats us to a thoroughly documented implementation of a minimal Forth core, one of my favorite languages.

KernelTrap is looking back at the beginnings of Linux in posts covering the 0.01 release and the following two.

Bootstraping a Forth in 40 lines of Lua code

The core of a conventional Forth system is composed of two main programs: an outer interpreter, that interprets textual scripts, and an inner interpreter, that runs bytecodes; the outer interpreter switches between an “immediate mode”, where words as executed as soon as they are read, and a “compile mode”, where the words being read are assembled into bytecodes to define new words.

In Forth all variables are accessible from all parts of the system. Several important words use that to affect the parsing: they read parts of the input text themselves, process that somehow, and advance the input pointer - and with that they effectively implement other languages, with arbitrary syntax, on top of the basic language of the outer interpreter.

Due mostly to cultural reasons, Forths tend to be built starting from very low-level pieces: first the inner interpreter, in Assembly or C, then the basic libraries and the outer interpreter, in Forth bytecodes, or - rarely - in C. We take another approach. If we consider that Lua is more accessible to us than C or Assembly - and thus for us Lua is “more basic” - then it is more natural to start from the outer interpreter, and the dictionary only has to have the definition for one word, one that means “interpret everything that follows, up to a given delimiter, as Lua code, and execute that”. An outer interpreter like that fits in less than 40 lines of Lua code, and it can be used to bootstrap a whole Forth-like language.
– Eduardo Ochs