gmc333 is currently certified at Journeyer level.

Name: Greg C
Member since: 2000-12-20 19:31:36
Last Login: N/A

FOAF RDF Share This



An Eiffel advocate. I'm involved in the Eiffel NICE standardization effort. I'm also working on a book and putting together some magazine articles. Obviously I'm not interested in getting stinkin' rich. Currently working on a library that will allow an Eiffel programmer to write programs that look a little bit like Perl. Scary thought, eh?

Recent blog entries by gmc333

Syndication: RSS 2.0

It's been nearly a month since my last diary entry, and I'm at a loss as to what I should write about.

Personal issues seem inappropriate for this forum. Work is work, daily dredging through thousands of lines of crappy C/C++ code and all the interpersonal drama that comes from having a real job. My off-time is diminishingly small with no time to accomplish anything significant.

So I guess I'll talk about the energy crisis out in California.

I think it's a mistake to blame the entire mess on deregulation. For one thing, the energy market in CA is not entirely deregulated. The utilities have to live with retail price controls, while their suppliers do not. Believe me, pleas for energy conservation would not be ignored if the true costs were being passed on to the consumers.

Part of the problem has to do with the CA utilities mismanaging their markets and resources. They oversold their capacity too cheaply, too long-term. They compounded this error by taking a few key plants off-line. (Some small plants are needed in a power grid to stabilize voltages and make the whole thing run more efficiently. In CA, these were coal-burning plants, and there were good environmental reasons for taking them off-line, but in the end it makes the grid less efficient and reduces overall capacity.) They also went with natural gas over all other alternatives. It has the advantage of being a very clean fuel and the disadvantage of currently being six times more expensive than the utilities had predicted.

Top that off with a drought, which eliminates hydro-electric power and you have energy shortages up the yin-yang.

If CA had not deregulated, I think they still would have had a crisis, perhaps not now and not as severe, but eventually it would have happened. Regulation would have prevented some of the mistakes, but not all of them. And it would not have spurred development of more capacity. CA has definitely taken a NIMBY attitude towards new power plants. Let NV build 'em.

On the other hand, I've heard more discussion on alternative energy sources in the last two months than at any time since the Carter administration. And I definitely see that as a good thing.

Meantime, Advogato is really intended to be a forum on OSS, and with that in mind, I'll turn my attention to John Ashcroft. It looks like he'll squeak by the senate and be the next US Attorney General. And of course everyone in this industry is curious as to how Ashcroft will handle Microsoft's case.

I don't think it should be taken for granted that Ashcroft will favor MS. After all, there's a strong conservative argument that MS is a monopoly that is damaging the US software industry and that economy as a whole, and that argument may have some appeal to Ashcroft.

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


gmc333 certified others as follows:

  • gmc333 certified gmc333 as Journeyer
  • gmc333 certified berend as Master
  • gmc333 certified elj as Journeyer

Others have certified gmc333 as follows:

  • gmc333 certified gmc333 as Journeyer
  • sad certified gmc333 as Apprentice
  • richieb certified gmc333 as Apprentice
  • RogerBrowne certified gmc333 as Apprentice
  • berend certified gmc333 as Apprentice
  • elj certified gmc333 as Journeyer
  • welisc certified gmc333 as Apprentice

[ Certification disabled because you're not logged in. ]

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!

Share this page