<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>Advogato blog for gmc333</title>
    <link>http://www.advogato.org/person/gmc333/</link>
    <description>Advogato blog for gmc333</description>
    <language>en-us</language>
    <generator>mod_virgule</generator>
    <pubDate>Sun, 19 May 2013 13:35:21 GMT</pubDate>
    <item>
      <pubDate>Wed, 31 Jan 2001 19:53:04 GMT</pubDate>
      <title>31 Jan 2001</title>
      <link>http://www.advogato.org/person/gmc333/diary.html?start=3</link>
      <guid>http://www.advogato.org/person/gmc333/diary.html?start=3</guid>
      <description>It's been nearly a month since my last diary entry, and I'm
at a loss as to what I should write about.

&lt;p&gt; 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.

&lt;p&gt; So I guess I'll talk about the energy crisis out in California.

&lt;p&gt; 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 &lt;i&gt;not&lt;/i&gt; be ignored if
the true costs were being passed on to the consumers.

&lt;p&gt; 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.

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

&lt;p&gt; 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.

&lt;p&gt; 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.

&lt;p&gt; 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.

&lt;p&gt; 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.

</description>
    </item>
    <item>
      <pubDate>Tue, 9 Jan 2001 04:54:55 GMT</pubDate>
      <title>9 Jan 2001</title>
      <link>http://www.advogato.org/person/gmc333/diary.html?start=2</link>
      <guid>http://www.advogato.org/person/gmc333/diary.html?start=2</guid>
      <description>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.

&lt;p&gt; 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?"

&lt;p&gt; 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.

&lt;p&gt; 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?

</description>
    </item>
    <item>
      <pubDate>Sat, 30 Dec 2000 02:56:22 GMT</pubDate>
      <title>30 Dec 2000</title>
      <link>http://www.advogato.org/person/gmc333/diary.html?start=1</link>
      <guid>http://www.advogato.org/person/gmc333/diary.html?start=1</guid>
      <description>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.

&lt;p&gt; 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.)

&lt;p&gt; 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.

&lt;p&gt; 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.

&lt;p&gt; 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.)

&lt;p&gt; 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.
</description>
    </item>
    <item>
      <pubDate>Wed, 20 Dec 2000 19:57:07 GMT</pubDate>
      <title>20 Dec 2000</title>
      <link>http://www.advogato.org/person/gmc333/diary.html?start=0</link>
      <guid>http://www.advogato.org/person/gmc333/diary.html?start=0</guid>
      <description>Jumped to Advogato when I saw a post at &lt;a href="http://www.elj.com/elj-daily.cgi" &gt;ELJ Daily&lt;/a&gt; about 
software bloat. The author claimed that software is getting 
slower faster than hardware gets faster.

&lt;p&gt; &lt;p&gt; &lt;p&gt; Had to laugh at that one. When I started in this 
business, 
the &lt;i&gt;assembler&lt;/i&gt; 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 
&lt;i&gt;as often&lt;/i&gt; as your software does bloat really degrade 
things.

&lt;p&gt; &lt;p&gt; &lt;p&gt; Anyone who's really interested in development tools 
that 
are the antithesis of bloat should check out the &lt;a href="http://smalleiffel.loria.fr" &gt;SmallEiffel 
compiler&lt;/a&gt;. 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."

&lt;p&gt; &lt;p&gt; &lt;p&gt; 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.

&lt;p&gt; &lt;p&gt; &lt;p&gt; 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).</description>
    </item>
  </channel>
</rss>
