Stevey and overengineering
Radomir 'The Sheep' Dopieralski
I'm sure many of you read "Stevey's Blog Rants", but if not,
there is a piece that relates to roguelike development (especially
to the cases of "I'm writing my game for 10 years now"). Enjoy!
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
Beauty is the ultimate defense against complexity. -– David Gelernter
Ido Yehieli
<n...@sheep.art.pl> wrote:
> http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
Yea that's a good read; Better than some of his other recent writing.
I hope I'm now at the verge of ending my teenager phase :p
-Ido.
Ulf Åström
wrote:
> I'm sure many of you read "Stevey's Blog Rants", but if not,
> there is a piece that relates to roguelike development (especially
> to the cases of "I'm writing my game for 10 years now"). Enjoy!
>
> http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
I'm not sure how this relates to roguelikes, really. Most RL source
I've seen appears to be without comments entirely.
The "I'm a veteran so I don't need to comment" argument is just silly;
code should be commented, but in a sane way.
-the ru
Radomir 'The Sheep' Dopieralski
Ulf Åström wrote:
>> http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
Indeed, that point is rather moot. For me the important part is the fact
that data modelling *is* addictive. It may be needed or may not, but once
you start doing it, it sometimes becomes very hard to stop. I know,
I spent several years of my "development" on this. Of course, it depends
on your personality and will.
Ulf Åström
wrote:
> At Tue, 12 Feb 2008 02:34:41 -0800 (PST),
>
> Ulf Åström wrote:
> > On 12 Feb, 10:37, Radomir 'The Sheep' Dopieralski <n...@sheep.art.pl>
> > wrote:
> >> I'm sure many of you read "Stevey's Blog Rants", but if not,
> >> there is a piece that relates to roguelike development (especially
> >> to the cases of "I'm writing my game for 10 years now"). Enjoy!
> >>http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
> > I'm not sure how this relates to roguelikes, really. Most RL source
> > I've seen appears to be without comments entirely.
> > The "I'm a veteran so I don't need to comment" argument is just silly;
> > code should be commented, but in a sane way.
> Indeed, that point is rather moot. For me the important part is the fact
> that data modelling *is* addictive. It may be needed or may not, but once
> you start doing it, it sometimes becomes very hard to stop. I know,
> I spent several years of my "development" on this. Of course, it depends
> on your personality and will.
It doesn't have to be about picking either extreme. It's possible to
write a *game* and still think one step ahead - the danger is always
trying to think ten steps ahead and never get past the "engine stage".
-the ru
agnas
> On Feb 12, 10:37 am, Radomir 'The Sheep' Dopieralski
>
> <n...@sheep.art.pl> wrote:
> >http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
>
> Yea that's a good read; Better than some of his other recent writing.
>
What? The Elisp primer was a excellent Lisp introduction and "Code's
Worst Enemy" was just his best post ever.
What you mean saying "Better than some of his other recent writing"
--
/\+++/\
< agnas >
\/+++\/
Krice
<n...@sheep.art.pl> wrote:
> there is a piece that relates to roguelike development (especially
> to the cases of "I'm writing my game for 10 years now"). Enjoy!
I didn't get the part about commenting. I have had always the
same kind of style in commenting, which is explaining the source
code in couple of comment lines, like this:
http://koti.mbnet.fi/paulkp/temp/vck2.gif
btw, that Stevey's recent source code is pretty unreadable.
He just can't seem to get it right:)
Gerry Quinn
@e6g2000prf.googlegroups.com>, pau...@mbnet.fi says...
> On 12 helmi, 11:37, Radomir 'The Sheep' Dopieralski
> <n...@sheep.art.pl> wrote:
> > there is a piece that relates to roguelike development (especially
> > to the cases of "I'm writing my game for 10 years now"). Enjoy!
>
> I didn't get the part about commenting. I have had always the
> same kind of style in commenting, which is explaining the source
> code in couple of comment lines, like this:
> http://koti.mbnet.fi/paulkp/temp/vck2.gif
And my commenting style is much like yours.
A pretty silly article, in my view. He makes up extreme caricatures to
argue with and insult, and despite all the wind I find it hard to see
much actual content.
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
Ido Yehieli
> What? The Elisp primer was a excellent Lisp introduction and "Code's
> Worst Enemy" was just his best post ever.
> What you mean saying "Better than some of his other recent writing"
I mean I used to read anything he wrote up to about a year ago, after
which (some of) his articles became much less interesting to me.
This is one of the recent ones I have found interesting (as well as
"Code's Worst Enemy").
-Ido.
not...@gmail.com
comments.
My personal philosophy: If I can't fit an algorithm/function in one
screen-full, I'm doing something wrong.
This leads to code I can understand at a glance three years later, but
which other people find completely incomprehensible (especially
because I always use the same space saving macros, to the point that I
pretend they're part of the language).
Martin Read
>This leads to code I can understand at a glance three years later, but
>which other people find completely incomprehensible
Remind me never to hire you or join a team you work on.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
Ulf Åström
> This leads to code I can understand at a glance three years later, but
> which other people find completely incomprehensible (especially
> because I always use the same space saving macros, to the point that I
> pretend they're part of the language).
Does this actually work? Have you looked at any three year old code of
your recently, and just thought "a-ha!"?
-the ru
Brog
> not...@gmail.com wrote:
> >This leads to code I can understand at a glance three years later, but
> >which other people find completely incomprehensible
>
> Remind me never to hire you or join a team you work on.
>
Because people use exactly the same coding style for personal and
professional work. If you accidentally end up hiring him, just make
sure he follows the same style guidelines as everyone else.
Jeff Lait
> I find myself completely agreeing with everything he said about
> comments.
>
> My personal philosophy: If I can't fit an algorithm/function in one
> screen-full, I'm doing something wrong.
A very useful philosophy. However...
> This leads to code I can understand at a glance three years later, but
> which other people find completely incomprehensible (especially
> because I always use the same space saving macros, to the point that I
> pretend they're part of the language).
You don't seem to have learned the lesson of the philosophy. The
"solution" isn't to compactify and remove white space until it fits on
a screen. That is like fulfilling a 5 page essay requirement by
tweaking the font size. It fulfills the text of the requirement while
violating the spirit.
The answer is, when you are faced with too long a function, to find a
way to factor out or simplify the function until it does fit on a
screen.
Even then, the rule should be taken with a heaping tablespoon of
salt. Some algorithms are naturally ugly and intractable. Splitting
them up along unnatural lines to fit a "one function one screen"
paradigm merely increases your LOC and maintance burden. And to
delete a comment to fit such a requirement? Unforgivable.
Keeping each function simple is meaningless if doing so results in
your program-as-a-whole becoming too complicated.
Of course, I tend to use 100 row screens now, so what constitutes one
screen is up for debate.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
<n...@sheep.art.pl> wrote:
> I'm sure many of you read "Stevey's Blog Rants", but if not,
> there is a piece that relates to roguelike development (especially
> to the cases of "I'm writing my game for 10 years now"). Enjoy!
>
> http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
It is a good rant. Opinionated and one-sided, but that is what a rant
should be.
I agree about data modeling being addictive and dangerous. That is
the point I always warn people about OOP and Roguelikes - people want
to move data (Studded Leather Tunic) into their class hierarchies, and
that way lies madness.
His hatred of static types seems entirely misplaced. I think he hates
the excessive boiler plating most static type implementations impose.
Having had the opportunity to use Haskell recently, it really shows
why static types don't require any extra typing. Calling static types
"meta-data" is like calling unit tests "meta-data".
His points about comments are correct but rather meaningless.
Excessively verbose comments are a very rare problem - sure, a problem
if they occur, but damn rare. He does have a point that boiler plate
comments can be dangerous, I know I can be guilty of this.
The story of Emily, http://en.wikipedia.org/wiki/Emily_Oster, hardly
proves his point. "All two year olds" do *not* do that. We're
talking about one specific child that did that.
konijn_
<n...@sheep.art.pl> wrote:
> At Tue, 12 Feb 2008 02:34:41 -0800 (PST),
>
> Ulf Åström wrote:
> > On 12 Feb, 10:37, Radomir 'The Sheep' Dopieralski <n...@sheep.art.pl>
> > wrote:
> >> I'm sure many of you read "Stevey's Blog Rants", but if not,
> >> there is a piece that relates to roguelike development (especially
> >> to the cases of "I'm writing my game for 10 years now"). Enjoy!
> >>http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
> > I'm not sure how this relates to roguelikes, really. Most RL source
> > I've seen appears to be without comments entirely.
> > The "I'm a veteran so I don't need to comment" argument is just silly;
> > code should be commented, but in a sane way.
>
> Indeed, that point is rather moot. For me the important part is the fact
> that data modelling *is* addictive. It may be needed or may not, but once
> you start doing it, it sometimes becomes very hard to stop. I know,
> I spent several years of my "development" on this. Of course, it depends
> on your personality and will.
I think the point is also that you need a stronger personality and
will with some languages like C++ and Java. That's why I am staying
the hell out of C++'s way, I already got Javanized ;) There was a
great discussion on #rgrd about this yesterday.
Cheers,
T.
>
> --
> Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
> Beauty is the ultimate defense against complexity. -- David Gelernter
Kenneth 'Bessarion' Boyd
> I find myself completely agreeing with everything he said about
> comments.
I found his summary of comment tolerance vs. experience accurate. It's why I
sometimes put in comments that I personally *don't* need, on anything that I
plan on releasing eventually. I only matured enough to start doing this in
2004.
I'd rather have proper field/variable/function names that are their own
comments, use asserts or other debug-only constructs to document
pre/post-conditions, and so on.
> My personal philosophy: If I can't fit an algorithm/function in one
> screen-full, I'm doing something wrong.
Not necessarily. In C/C++, I always think twice about static functions called
once -- I'd rather properly comment them as inlined where they are called.
There's no intelligibility gain to one-call functions, although if they remove
variables from the caller I might go ahead with that anyway.
> This leads to code I can understand at a glance three years later, but
> which other people find completely incomprehensible (especially
> because I always use the same space saving macros, to the point that I
> pretend they're part of the language).
Missing the point.
Multiple statements on one line defeats the purpose of any screen/line size
heuristic. I anathematize those in my own projects. Macros/inline functions
that only save space are anathematized as well. [But macros that are only
useful in a specific context *are* used -- they just get #undef'ed immediately
after they are no longer useful. The next release of Zaiband will feature some
macro awfulness in the maybe 10% Crawly monster AI, but it's not the worst ever
I've used and kept.]
not...@gmail.com
> You don't seem to have learned the lesson of the philosophy. The
> "solution" isn't to compactify and remove white space until it fits on
> a screen. That is like fulfilling a 5 page essay requirement by
> tweaking the font size. It fulfills the text of the requirement while
> violating the spirit.
>
> The answer is, when you are faced with too long a function, to find a
> way to factor out or simplify the function until it does fit on a
> screen.
Generally, I try to separate into smaller functions first. The macro
thing is for things that I use a lot, and take up lots of space. Take
a look at the all shortest paths algorithm:
for (int i = 0; i < n; ++i) { // all shortest paths algorithm
for (int j = 0; j < n; ++j) {
for (int k = 0; k < n; ++k) {
if (distance[j][i] + distance[i][k] < distance[j][k]) {
distance[j][k] = distance[j][i] + distance[i][k];
}
}
}
}
I've used it so often that this is what I tend to write instead:
#define f(x,y) for (int x = 0; x < y; ++x)
f(i,n) f(j,n) f(k,n) if (distance[j][i] + distance[i][k] < distance[j]
[k]) distance[j][k] = distance[j][i] + distance[i][k]; // all
shortest paths algorithm
My code becomes full of little idioms like this (such as table driven
logic for moving up/down/left/right), which I recognize, but other
people don't. (YES, I KNOW THAT #define MACROS ARE EVIL. SO AM I. I
KILL C# PROGRAMMERS FOR PLEASURE.)
> Even then, the rule should be taken with a heaping tablespoon of
> salt. Some algorithms are naturally ugly and intractable. Splitting
> them up along unnatural lines to fit a "one function one screen"
> paradigm merely increases your LOC and maintance burden. And to
> delete a comment to fit such a requirement? Unforgivable.
>
> Keeping each function simple is meaningless if doing so results in
> your program-as-a-whole becoming too complicated.
>
> Of course, I tend to use 100 row screens now, so what constitutes one
> screen is up for debate.
> --
> Jeff Lait
> (POWDER:http://www.zincland.com/powder)
It isn't a hard and fast rule. But algorithms which force me to
violate it are very very rare, especially since I keep my text editor
as big as possible.
Kenneth 'Bessarion' Boyd
I've had it work for me across twelve years. That didn't prevent me from fixing
that design error when I saw it.
The only code I want to leave incomprehensible to other people, is code whose
domain is itself incomprehensible without an appropriate background. (But it
had better be understandable with that background).
Paul Donnelly
> for (int i = 0; i < n; ++i) { // all shortest paths algorithm
> for (int j = 0; j < n; ++j) {
> for (int k = 0; k < n; ++k) {
> if (distance[j][i] + distance[i][k] < distance[j][k]) {
> distance[j][k] = distance[j][i] + distance[i][k];
> }
> }
> }
> }
>
> I've used it so often that this is what I tend to write instead:
>
> #define f(x,y) for (int x = 0; x < y; ++x)
It baffles me that this hasn't become standard C/C++. From where I'm
standing, (x = 0; x < y; x++) is so common and error prone that you'd be
nuts not to automate it when you've got a perfectly adequate macro
facility built in. I probably would call it "INCL" (incrementing loop,
with "DECL" defined as well), but it's the same thing. What gives?
Kenneth 'Bessarion' Boyd
> not...@gmail.com writes:
>
> > for (int i = 0; i < n; ++i) { // all shortest paths algorithm
> > for (int j = 0; j < n; ++j) {
> > for (int k = 0; k < n; ++k) {
> > if (distance[j][i] + distance[i][k] < distance[j][k]) {
> > distance[j][k] = distance[j][i] + distance[i][k];
> > }
> > }
> > }
> > }
> >
> > I've used it so often that this is what I tend to write instead:
> >
> > #define f(x,y) for (int x = 0; x < y; ++x)
>
> It baffles me that this hasn't become standard C/C++.
Boost.Foreach is trying.
As for the example in question:
* Lines of code saved (ignoring line committed to macro): 0
* Fails to compile as C89
* Scoping bug in some compilers doesn't lock down x to the loop body
* Assumes you don't want to use the value of the index variable outside of the
loop when used on a C99 compiler
The first point is the killer. There are some times when I have macro-ized a
for loop, but these generally involve using ## to let the preprocessor construct
standardized variable or constant names.
> From where I'm
> standing, (x = 0; x < y; x++) is so common and error prone that you'd be
What's error prone is not immediately verifying loop start, end, and iteration
conditions *before* coding the body of the loop.
Ray Dillinger
> The only code I want to leave incomprehensible to other people, is code
> whose
> domain is itself incomprehensible without an appropriate background. (But
> it had better be understandable with that background).
In the middle of my random-number code I have a comment that says
/* DO NOT mess with these constants unless you have read Knuth
v3 pp 102-104 and understand why they have these exact values. */
Followed by several definitions that are quite cryptic to those who
have not.
I think this sort of thing is fine; you give them a pointer about where
to read so they understand what you're doing (where to acquire the
background needed to understand your code) and you don't have to give
a blow-by-blow explanation.
Bear
Paul Donnelly
I'm not sure what you mean by verifying conditions before coding the
body. Of course I make an attempt to write correct code, but I'm much
more likely to make a mistake typing (and verifying)
for (i = 0; i < MAXIMUM; i++)
than simply typing INCL(i, MAXIMUM) or somesuch. I'd rather not expose
myself to such a dumb error every time I write a loop. Not to mention
that I'm a little offended at being asked to write my iteration variable
three times and explicitly code the starting value, test, and step.
Gerry Quinn
@e4g2000hsg.googlegroups.com>, torespon...@hotmail.com says...
> The story of Emily, http://en.wikipedia.org/wiki/Emily_Oster, hardly
> proves his point. "All two year olds" do *not* do that. We're
> talking about one specific child that did that.
Well, two year olds *do* often tell themselves, or their mothers,
stories of that kind. I doubt whether it has any connection with code
commenting practices in later life though.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
>
> > On 2008-02-13 22:41:15, Paul Donnelly wrote:
> >
> >> From where I'm standing, (x = 0; x < y; x++) is so common and error
> >> prone that you'd be
> >
> > What's error prone is not immediately verifying loop start, end, and
> > iteration conditions *before* coding the body of the loop.
>
> I'm not sure what you mean by verifying conditions before coding the
> body.
Formal verification and/or Design By Contract. Any start and iteration
conditions that cannot be explicitly proven should have error-trapping code at
least in debug mode. End conditions are harder in general (halting problem),
but the most common ones are induction or finite iteration, both of which are
provable and can be formally verified with no material loop body.
I usually assume working hardware and compiler/interpreter, and then trust that
invariants don't change with const operations for non-volatile data. One of my
applications intentionally doesn't assume this.
> Of course I make an attempt to write correct code, but I'm much
> more likely to make a mistake typing (and verifying)
>
> for (i = 0; i < MAXIMUM; i++)
>
> than simply typing INCL(i, MAXIMUM) or somesuch.
As for the typing part: I find that irrelevant, as my habit is to proofread
everything both immediately after typing, and before moving on to the next
chunk. Anything that gets past both two proofreads and the compiler is bad
variable/function naming conventions.
I have a harder time verifying INCL(i, MAXIMUM) than for (i = 0; i < MAXIMUM;
i++). And take no offense at using the easier-to-verify option.
Ulf Åström
> You don't seem to have learned the lesson of the philosophy. The
> "solution" isn't to compactify and remove white space until it fits on
> a screen. That is like fulfilling a 5 page essay requirement by
> tweaking the font size. It fulfills the text of the requirement while
> violating the spirit.
Using wider margins also works, and seems to be harder for most
teachers to detect. ;-)
> Of course, I tend to use 100 row screens now, so what constitutes one
> screen is up for debate.
Indeed; I use 24 lines, minus two or three eaten up by emacs for the
minibuffer and buffer titles (and often half of that when I have the
compile log open).
I have functions that are 500 lines and more. It's not ideal, but
sometimes there's just so much state information to keep track of that
splitting it up will only make things harder to find.
*Indentation* is much more troublesome, OTOH - especially if it has to
be tracked between screens. My threshold is around 5-6 levels; after
that I start considering moving things around. But as long as the code
is commented, consistently formatted and kept as "flat" as possible, I
don't think the *length* of functions matters much.
-the ru
Risto Saarelma
> His hatred of static types seems entirely misplaced. I think he hates
> the excessive boiler plating most static type implementations impose.
> Having had the opportunity to use Haskell recently, it really shows
> why static types don't require any extra typing. Calling static types
> "meta-data" is like calling unit tests "meta-data".
As far as I've been able to tell, Yegge's issues with static typing are
a bit more subtle and have to do with static type systems' difficulties
in doing reflection. This makes it difficult to do all sorts of
metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
example.
One example of such a trick is hot-swapping running code. A rant about
this: http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html
--
Risto Saarelma
Kenneth 'Bessarion' Boyd
Interesting read (and one which has much useful thought regardless of my
personal bias).
I would suggest that hot-swapping (self-modifying) code is even more limited by
not having a realtime source compiler/interpreter, in conjunction with
incremental linking. That is, the key element of hot-swapping code is having
an eval technique (using JavaScript/Perl notation). The equivalent flexibility
for a static-typed language would be to invoke a compiler and then link in the
just-compiled function in real-time, but a first step would be dynamic loading
of modules/plugins.
I think we have this already for byte-code compiled languages (e.g., Perl), but
machine-compiled languages aren't quite there yet.
Martin Read
>The equivalent flexibility for a static-typed language would be to
>invoke a compiler and then link in the just-compiled function in
>real-time, but a first step would be dynamic loading of
>modules/plugins.
It's called dlopen(), and it's specified in POSIX 1003.1-2003.
Simon Richard Clarkstone
I wonder if he thinks it counts when you can: save a module's precise
state, completely unload it, and reload the new version, which accepts
the old state and continues. There is a library to do that in Haskell
(I forget what it is called). It is an easier technique than in other
languages as Haskell's use of mutable state is constrained. With little
change, the state-saving for reloading a module can be made to serialise
the entire application state to disk.
Also, "traditional" Forth starts off with a dictionary that contains the
built-in words and the compiler, and applications are compiled and
linked directly on top of it; they extend the existing dictionary by
adding words to it. This is all done by interpreting arbitrary Forth
code, so there is no "boundary" between built-in words, the compiler,
and applications words, and no need for relocatable object code. Rather
like his beloved LISP.
--
src
Simon Richard Clarkstone
> Risto Saarelma wrote:
>> One example of such a trick is hot-swapping running code. A rant about
>> this: http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html
>
> I wonder if he thinks it counts when you can: save a module's precise
> state, completely unload it, and reload the new version, which accepts
> the old state and continues. There is a library to do that in Haskell
> (I forget what it is called).
Oops! As (the infamous) Philippa says in the first comment, it is
called hs-plugins:
http://www.cse.unsw.edu.au/~dons/hs-plugins/
--
src
Jeff Lait
First, I think that static typing has little to do with being able to
make a system that doesn't need to reboot or can be hotswapped. We
already mentioned Edit and Continue in MSVC++, which clearly
demonstrates it is not impossible to build such a system.
His rant, while interesting, doesn't in the quick skim I gave it
address the true downfall of systems that never reboot. If you go too
long without rebooting, the system won't be rebootable. This is why
console games are limited as a FEATURE, not a mistake. The entire
design philosophy of console games and hardware is the blank-slate
starting conditions. This makes it practical to guarantee that the
system *will* work *every* time you run it. Very important when your
code is burned on a ROM.
It used to be very fashionable to have year long uptimes. It seems
the consensus now is to instead intentionally reboot systems to make
sure they are not accumulating magic cruft that prevents them from
being rebooted. I've had my experience of linux boxes that decided
not to power on again because one too many patch was run on the live
system.
The other big problem is that we don't need many systems. I don't
want Nethack to have a full shell - that is what my actual command
line shell is! Likewise, it would be a misfeature to have C++ itself
be it's own OS (like smalltalk or LISP) - I already have a perfectly
good OS, thank you very much.
I recently embarked in some Haskell work and will note that I've used
solely the command line compiler. First, the interpreter is too slow
to test against, second, programming in the interpreter means losing
vi, working in a line by line mode as if I were editing the source in
edlin. So while Haskell may (or may not) be "shell complete", I
really couldn't care less personally.
Kenneth 'Bessarion' Boyd
> On Feb 23, 3:20 am, Risto Saarelma wrote:
> > On 2008-02-13, Jeff Lait wrote:
> >
> > > His hatred of static types seems entirely misplaced. I think he hates
> > > the excessive boiler plating most static type implementations impose.
> > > Having had the opportunity to use Haskell recently, it really shows
> > > why static types don't require any extra typing. Calling static types
> > > "meta-data" is like calling unit tests "meta-data".
> >
> > As far as I've been able to tell, Yegge's issues with static typing are
> > a bit more subtle and have to do with static type systems' difficulties
> > in doing reflection. This makes it difficult to do all sorts of
> > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for
> > example.
> >
> > One example of such a trick is hot-swapping running code. A rant about
> > this:http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html
>
> First, I think that static typing has little to do with being able to
> make a system that doesn't need to reboot or can be hotswapped. We
> already mentioned Edit and Continue in MSVC++, which clearly
> demonstrates it is not impossible to build such a system.
Edit and Continue in MSVC++ isn't relevant to the transhumanist religious slant
Steve took on hot-swapping. What he wants is for the program itself to be able
to generate a function, "compile it", and hotswap it in. This is almost
*essential* to actually realize a Vingean Singularity.
MSVC++ Edit and Continue is entirely programmer-controlled. But static typing
has little theoretical significance with program-controlled hotswapping of code;
it has *much* practical significance since so far only the byte-code compiled
languages have the eval capability that allows it. DLLs/plugins are a
second-rate hack.
> His rant, while interesting, doesn't in the quick skim I gave it
> address the true downfall of systems that never reboot. If you go too
> long without rebooting, the system won't be rebootable. ...
Also note that rebooting allows practical immortality for materialist AIs: dump
state on old machine, restart with that state on new machine. The
awareness-process discontinuity could well be no worse than sleep or anesthesia
is for us.
The objections he posits *assume* that a computer AI would be dualist
metaphysics, which is not at all clear. Not only do we know whether *we* use
dualist metaphysics (and if so, that may merely be a limited definition of
"matter and energy"), even if that were granted that would not prove that a
materialist AI was unconstructable.