Older blog entries for gmc333 (starting at number 1)

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.

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).