Older blog entries for gmc333 (starting at number 2)

The company I work at these days is not too bad. I do have one complaint, though. (The triviality of this complaint will indicate just how good I've got it.) In our break room there's a huge soda machine that's been modified to give out free sodas. There are eight buttons for eight different brands, none of which I like.

Apparently other people weren't happy with the choices either, because the receptionist organized a vote on which brands should be in the machine. I voted for the stuff I like, and asked, "why do we need this monster pop machine? Why not replace it with a stand-up cooler or even a smallish fridge, and just stock it with a bit of everything?"

I guess that would have been too easy, because the vote was tallied, the monster pop machine was kept, and one or two brands changed (not to anything I like). No jokes about recounts, please.

So I had a thought today while talking about it with my son. What if I just took a bunch of free pop out of the machine, say a dozen cans, carried them over to the local Albertson's and exchanged them for something I want to drink? Is this stealing? Or is it only stealing if I drink the new soda off the premises? Can you really steal something that's given away for free? Should I care what the store does with the sodas? Just because I don't want to drink that crap doesn't mean I'd be happy about them just throwing it in the trash. Would my coworkers turn on me for depriving them of their decaff Koke Klassik?

I've been thinking of the potential of adding two new basic data types to Eiffel: BIT_S and BIT_U. These would be similar to the BIT classes already present in SmallEiffel. The basic notion is that you could then declare subclasses to create signed and unsigned integers of arbitrary size. The compiler then optimizes the manipulation of the variables according to the word size of the target machine.

The main reason for doing this? Standard Eiffel only has one integer type. No support for unsigned integers at all, and no direct support for the rich variations found in C or C++. This limits the types of applications for which Eiffel is suitable. (For example, there is no equivalent of a short unsigned int, which would be a useful basis for implementing UTF16 support.)

Almost as bad, the basic INTEGER class for most Eiffel compilers depends on the back end C compiler you use. It maps directly to "int". This is unlike Java, which bit the bullet and standardized integer size on all platforms. This limits portability of the source. Perhaps not as much as some might think; the SmallEiffel compiler supports a pretty broad range of machines. But I think it will become a bigger issue as more 64-bit architectures become available and compilers start to wrestle with the greater length. I'm old enough to remember the grief caused in trying to write code that supported both 16-bit and 32-bit platforms.

By introducing just two new types, we adhere to the RISC- language precept of Eiffel. This is in contrast to the SARITH proposal floated a while back in the Eiffel community, where a large family of integer types was proposed.

The types could greatly expand Eiffel's utility in interfacing to legacy code, operating in embedded systems and efficiently implementing new libraries and features (like UTF16 support mentioned earlier.)

If and when I polish up a firm proposal, I'll be posting it to my Web site and one or two newsgroups, and perhaps a couple other places.

20 Dec 2000 (updated 17 Jul 2001 at 21:21 UTC) »

Jumped to Advogato when I saw a post at ELJ Daily about software bloat. The author claimed that software is getting slower faster than hardware gets faster.

Had to laugh at that one. When I started in this business, the assembler was so slow (as it ran off floppies) that I had plenty of time to learn how to juggle while waiting for my program to be built. Now I compile much larger applications much faster. Much less juggling. Only in the short-term, when you don't upgrade your hardware as often as your software does bloat really degrade things.

Anyone who's really interested in development tools that are the antithesis of bloat should check out the SmallEiffel compiler. The distribution fits on a single floppy(!), includes a bootstrap to install the compiler+utilities, all the source, a standard library and example programs. And with the -0.75 release, it now includes an interactive debugger. It's not a toy compiler, it's being used for some major projects and is a pretty-much complete implementation of Eiffel. You could argue that it cheats by using a C compiler for a backend. To which I would reply "it also compiles to Java Byte Codes. So there."

The compiler is an incredibly aggressive optimizer, eliminating dead code and method dispatching at every opportunity. In many benchmarks, it holds its own to C++ in performance.

Eiffel itself is designed with reusability in mind. In many respects it's a much cleaner language than C++ (which admittedly is a pretty low bar to clear).

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!