Random Questions

[x4000]

I disagree on Java being less verbose. I can almost always tell the C/C++ programmers who've come from a java background, they always have TheseInsaneFunctionNamesThatAreHalfAScreenWideAndReallyMakeItHardToWorkOutWTFIsGoingOn.

I meant the language itself, and the general method names in the libraries for C#.  I didn't say anything about the programming practices of Java/C# programmers as a group.  You definitely get a lot with crap for style.

The C++ standards committe really just needs to give in and include a GC into the spec and the compilers can have it enablable/disablable based on compile flags like they do the dynamic type information; so it can get turned off for the really performance anal, and everyone else can just cope with whatever else. It's not as if there isn't already a half dozen GCs out there already available for both C and C++...

Yeah, this is true.  But even if they did that, I still wouldn't like the language.  I don't like having to mess with separate header files, I don't like how long it takes to compile/link, I don't like a lot of the syntax (-> is really hard to type fast for me), and I don't like how many lines of code it takes to accomplish a number of should-be-simple things.  For me, C# is ideal because it has the power to go pretty low-level when I really need to (and sometimes I do), but otherwise it keeps things at a conversational level that keep the code leaner and moving along.  But, of course, this is mostly a matter of preference and familiarity on both sides, yes?

I really don't think it's that much of a problem. It's like Java vs C#, there really isn't much of a difference in the logic/syntax between them. The functionality supported by the libraries is pretty much the same, it's just a matter of working out what the heck it's called, and that's where code completion and quick-help are good for (or just typing it in a google search box in your browser...).

I didn't really mean syntactically.  The way you organize a good C program is tremendously different from how you organize a good C# program.  And the techniques for optimizing a program with a GC are a lot different than those you would use for one without.

As someone who's job used to be (and to a certain extent still is), building and maintaining code in any language it happens to be in; after a while they all rather merge into being the language groups with minor different syntax. At one point I was using a different programming language every couple of days for a month as there were a couple of dozen various scripting/compiled programs that needed to be updated/moved to a different server, and of course this being a university they were all written in the student's/professor's/staff member's preferred language. Swapping between 10 or 11 different languages in a month was fun.

Yeah, I know what you mean.  I work in about 4 or 5 languages on a weekly basis, and there are about 10 or 11 in all that I am at least reasonably proficient at.  I actually prefer C or ASM to C++, oddly.  I guess my main beef with C++ is that its not quite C, and it's not quite C#, and for me it doesn't fill the middle ground the way I would want.  Again, all just down to preference.  Anything is better than having to work in VB or VBA, at least, haha.

[darke]

I disagree on Java being less verbose. I can almost always tell the C/C++ programmers who've come from a java background, they always have TheseInsaneFunctionNamesThatAreHalfAScreenWideAndReallyMakeItHardToWorkOutWTFIsGoingOn.

I meant the language itself, and the general method names in the libraries for C#.  I didn't say anything about the programming practices of Java/C# programmers as a group.  You definitely get a lot with crap for style.

Can't say my style is particularly good (since I tend to copy whatever the original author's is), but there is a limit to my patience for long variable names.

The C++ standards committe really just needs to give in and include a GC into the spec and the compilers can have it enablable/disablable based on compile flags like they do the dynamic type information; so it can get turned off for the really performance anal, and everyone else can just cope with whatever else. It's not as if there isn't already a half dozen GCs out there already available for both C and C++...

Yeah, this is true.  But even if they did that, I still wouldn't like the language.  I don't like having to mess with separate header files, I don't like how long it takes to compile/link, I don't like a lot of the syntax (-> is really hard to type fast for me), and I don't like how many lines of code it takes to accomplish a number of should-be-simple things.  For me, C# is ideal because it has the power to go pretty low-level when I really need to (and sometimes I do), but otherwise it keeps things at a conversational level that keep the code leaner and moving along.  But, of course, this is mostly a matter of preference and familiarity on both sides, yes?

Ironicly, one of my main grips with C is the continual need for ->, since in C++ I'll use references (which are addressed with "."), or shared pointers (which can also be "." addressed), and the like. Compile/link is always a bit of a pain, but I must admit I really do miss #defines/#includes in pretty much any other language, since they can really fix up annoying language/library flaws really easily, and I've never seen a language get that sort of flexability without it.

I actually don't mind C#, it's just that it's only really supported under windows (MS's attempts to persuade people otherwise not withstanding), and I spend way too much time on everything-but-windows at the moment. It seems to have learnt a lot from Java's failures, but on the other hand it dragged in a little too much of C's crufty syntax that Java had enough common sense to avoid (assignment inside an if() statement being one of the more "doctor it hurts when I do this"/"well don't do that then!" problems ).

Then again I've just started enjoying reading old x86 (of the 286/pre-32bit-protected-mode era) assembler books recently and really enjoying them, so maybe I'm just a little weird.

As someone who's job used to be (and to a certain extent still is), building and maintaining code in any language it happens to be in; after a while they all rather merge into being the language groups with minor different syntax. At one point I was using a different programming language every couple of days for a month as there were a couple of dozen various scripting/compiled programs that needed to be updated/moved to a different server, and of course this being a university they were all written in the student's/professor's/staff member's preferred language. Swapping between 10 or 11 different languages in a month was fun.

Yeah, I know what you mean.  I work in about 4 or 5 languages on a weekly basis, and there are about 10 or 11 in all that I am at least reasonably proficient at.  I actually prefer C or ASM to C++, oddly.  I guess my main beef with C++ is that its not quite C, and it's not quite C#, and for me it doesn't fill the middle ground the way I would want.  Again, all just down to preference.  Anything is better than having to work in VB or VBA, at least, haha.

Unfortunately I must agree with the "anything but VB". I mean I grew up with BASICA/GWBASIC/MS-licenced-basic-on-various-computers, then VB, but when they added the pseudo-OO stuff it really went pearshaped, and the latest .NET version doesn't seem to be any better despite the fact the update broke pretty much every program in existance.

Oddly I prefer ASM over C, simply because at least there's no pretence of ASM being easily maintainable. After a while you get sick and tired of basic stuff like strings and variable arrays not being included in the language specification when you're doing maintenance programming; because everyone needs them, and everyone has their own-damned-implementation of them with subtle bugs which is usually why you're in there fixing it. This is probably about the only real reason I use C++ actually.

I should start writing code in raw MSIL just to really confuse people.

[x4000]

Ironicly, one of my main grips with C is the continual need for ->, since in C++ I'll use references (which are addressed with "."), or shared pointers (which can also be "." addressed), and the like.

Yeah, that's true.  But I like how it doesn't have any pretensions of OOP.  Still not my favorite language, but I like it's simplicity by some comparisons.

Compile/link is always a bit of a pain, but I must admit I really do miss #defines/#includes in pretty much any other language, since they can really fix up annoying language/library flaws really easily, and I've never seen a language get that sort of flexability without it.

I've never run afoul of that, but then again I haven't done enough extended C++ programming to really see where those two would be valuable.

I actually don't mind C#, it's just that it's only really supported under windows (MS's attempts to persuade people otherwise not withstanding), and I spend way too much time on everything-but-windows at the moment.

That part does bug me, too.  I'm quite happy that Mono is growing.

It seems to have learnt a lot from Java's failures, but on the other hand it dragged in a little too much of C's crufty syntax that Java had enough common sense to avoid (assignment inside an if() statement being one of the more "doctor it hurts when I do this"/"well don't do that then!" problems ).

What do you mean about "assignment inside an if()," out of curiosity?  Are you referring to variable scoping?  I really like how that works in C#, I have to say, but maybe that's not what you are referring to.  I'm so used to C# that I really like pretty much all aspects of how it flows syntactically.  But I recognize that that's just a preference, not any sort of "this is better" rule.

Then again I've just started enjoying reading old x86 (of the 286/pre-32bit-protected-mode era) assembler books recently and really enjoying them, so maybe I'm just a little weird.

Yeah, I had a class on that in college, and loved it.  Otherwise, my only experience with it has been for some little ARM microcontrollers, and I wound up not even getting to do much more with that because we moved the functionality that was going to be on microcontrollers on a USB bus onto the main CPU instead.  This is for some robot code that I work on occasionally for these telpresence robots my dad and uncle are building.  That's been like a 5-year project at this point.

Unfortunately I must agree with the "anything but VB". I mean I grew up with BASICA/GWBASIC/MS-licenced-basic-on-various-computers, then VB, but when they added the pseudo-OO stuff it really went pearshaped, and the latest .NET version doesn't seem to be any better despite the fact the update broke pretty much every program in existance.

Yeah, I grew up with QBASIC in particular, and some VB3.  I like VB6 okay, too, though the syntax is not my favorite.  But when it comes to VB.NET, it seems like just C# or VB6 should be used -- this is another of those "middle ground" languages that I'm not a fan of.

[darke]

Compile/link is always a bit of a pain, but I must admit I really do miss #defines/#includes in pretty much any other language, since they can really fix up annoying language/library flaws really easily, and I've never seen a language get that sort of flexability without it.

I've never run afoul of that, but then again I haven't done enough extended C++ programming to really see where those two would be valuable.

It tends to get considerably more use in C from what I've seen, people writing a lot of C++ tend to have a template<> fetish so use that to solve their problems instead. Most people who write fancy variable length arrays or fancy string stuff in C tend to abuse it a lot since it means you can get much cleaner code inline, rather then having to either call a function (with associated overhead) for a simple process, or do lots of casting and stuff inline. It's also very convenient for portability across architectures and operating systems too. Most higher level languages that don't have this functionality tend to be limited to specific systems or are bytecode intepreted so it doesn't really matter with it's absense in portability terms, it's just every now and again you trip over something that would be really easy to be done that way, but you don't have the ability to.

I actually don't mind C#, it's just that it's only really supported under windows (MS's attempts to persuade people otherwise not withstanding), and I spend way too much time on everything-but-windows at the moment.

That part does bug me, too.  I'm quite happy that Mono is growing.

Ya. The only issue is MS's "patent covanent" only covers the MSIL and standard, not the libraries. So reimplementing the windows forms stuff (which is rather important for portability of course) means you're suddenly in "here be dragons" territory. And MS is reallyreally too trigger happy with it's lawyers.

It seems to have learnt a lot from Java's failures, but on the other hand it dragged in a little too much of C's crufty syntax that Java had enough common sense to avoid (assignment inside an if() statement being one of the more "doctor it hurts when I do this"/"well don't do that then!" problems ).

What do you mean about "assignment inside an if()," out of curiosity?  Are you referring to variable scoping?  I really like how that works in C#, I have to say, but maybe that's not what you are referring to.  I'm so used to C# that I really like pretty much all aspects of how it flows syntactically.  But I recognize that that's just a preference, not any sort of "this is better" rule.

if(a == 1) {} tests if a is 1; if(a = 1) {} assigns 1 to a, and tests if a is then true. It's a standard typo for both newbies and experienced programmers alike, it can hide in your codebase for decades (I recently code audited a still maintained C program that has been around for 20+ years and picked up 5 or 6 of these, (some of them that pre-dated the version control information...) among other bugs), and is generally recommended not to write code that assigns in an if statement deliberately because it's so unintuitive and easy to miss at first glance.

Then again I've just started enjoying reading old x86 (of the 286/pre-32bit-protected-mode era) assembler books recently and really enjoying them, so maybe I'm just a little weird.

Yeah, I had a class on that in college, and loved it.  Otherwise, my only experience with it has been for some little ARM microcontrollers, and I wound up not even getting to do much more with that because we moved the functionality that was going to be on microcontrollers on a USB bus onto the main CPU instead.  This is for some robot code that I work on occasionally for these telpresence robots my dad and uncle are building.  That's been like a 5-year project at this point.

I've only really started enjoying ASM recently, even though I've had to deal with reading it for decades since I've always been interested in reverse engineering/decompilation and the like. I just never really liked writing it because when dealing with interrupts and stuff in DOS screwing up meant a reboot and try again rather then your program crashing like a normal program.

Unfortunately I must agree with the "anything but VB". I mean I grew up with BASICA/GWBASIC/MS-licenced-basic-on-various-computers, then VB, but when they added the pseudo-OO stuff it really went pearshaped, and the latest .NET version doesn't seem to be any better despite the fact the update broke pretty much every program in existance.

Yeah, I grew up with QBASIC in particular, and some VB3.  I like VB6 okay, too, though the syntax is not my favorite.  But when it comes to VB.NET, it seems like just C# or VB6 should be used -- this is another of those "middle ground" languages that I'm not a fan of.

Ya.

[x4000]

It tends to get considerably more use in C from what I've seen, people writing a lot of C++ tend to have a template<> fetish so use that to solve their problems instead. Most people who write fancy variable length arrays or fancy string stuff in C tend to abuse it a lot since it means you can get much cleaner code inline, rather then having to either call a function (with associated overhead) for a simple process, or do lots of casting and stuff inline. It's also very convenient for portability across architectures and operating systems too. Most higher level languages that don't have this functionality tend to be limited to specific systems or are bytecode intepreted so it doesn't really matter with it's absense in portability terms, it's just every now and again you trip over something that would be really easy to be done that way, but you don't have the ability to.

Very interesting.

Ya. The only issue is MS's "patent covanent" only covers the MSIL and standard, not the libraries. So reimplementing the windows forms stuff (which is rather important for portability of course) means you're suddenly in "here be dragons" territory. And MS is reallyreally too trigger happy with it's lawyers.

Yeah, I saw that article on Slashdot, too.  I wonder if MS will extend this, or what.  I guess we'll see how it all plays out.

if(a == 1) {} tests if a is 1; if(a = 1) {} assigns 1 to a, and tests if a is then true. It's a standard typo for both newbies and experienced programmers alike, it can hide in your codebase for decades (I recently code audited a still maintained C program that has been around for 20+ years and picked up 5 or 6 of these, (some of them that pre-dated the version control information...) among other bugs), and is generally recommended not to write code that assigns in an if statement deliberately because it's so unintuitive and easy to miss at first glance.

Ohh, now I see what you meant.  Yeah, that is definitely a part of C cruft that I'm not a fan of, either.  I don't run across this often, but I actually had one of these just the other day for the first time in years.  I saw it shortly after compile, when it wasn't working right, and that was what reminded me that this was even possible.  You're right, it is a stupid feature -- it's ironic that you would bring it up right after it bit me for the first time in years.

I've only really started enjoying ASM recently, even though I've had to deal with reading it for decades since I've always been interested in reverse engineering/decompilation and the like. I just never really liked writing it because when dealing with interrupts and stuff in DOS screwing up meant a reboot and try again rather then your program crashing like a normal program.

Yeah, the ability to shoot yourself in the foot is unparalleled.  I prefer coding either inside an emulator (as I did with my 8086 work), or on a secondary chip.  Of course, with most secondary chips you are programming to the emulator first, anyway, so I guess that means that I prefer coding in an emulator with those in general.  I doubt I would ever use ASM on an actual PC (the later extensions and such are so complex, and there's just not much reason for me to do that), but for small embedded work it is pretty cool.  With 256 bytes of working memory on the chip, for instance, ASM is the only way to go.  Some of them are super tiny like that.

[darke]

It tends to get considerably more use in C from what I've seen, people writing a lot of C++ tend to have a template<> fetish so use that to solve their problems instead. Most people who write fancy variable length arrays or fancy string stuff in C tend to abuse it a lot since it means you can get much cleaner code inline, rather then having to either call a function (with associated overhead) for a simple process, or do lots of casting and stuff inline. It's also very convenient for portability across architectures and operating systems too. Most higher level languages that don't have this functionality tend to be limited to specific systems or are bytecode intepreted so it doesn't really matter with it's absense in portability terms, it's just every now and again you trip over something that would be really easy to be done that way, but you don't have the ability to.

Very interesting.

Most warped thing I've seen done with #defines is a massive series of them to help build a subset of an x86 emulator to decode an odd audio compression format so we could play the music to a game engine we were rebuilding (ultima8; the function was annoyingly complex so it was simpler at the time to write a quick and dirty emulator then it was to hand decode what it was doing and rewrite it, we eventually worked out the algorithm though ). The #defines were awfully ugly but the interpreter code was nice and clean as a result, so there is a benefit at odd edge cases.

if(a == 1) {} tests if a is 1; if(a = 1) {} assigns 1 to a, and tests if a is then true. It's a standard typo for both newbies and experienced programmers alike, it can hide in your codebase for decades (I recently code audited a still maintained C program that has been around for 20+ years and picked up 5 or 6 of these, (some of them that pre-dated the version control information...) among other bugs), and is generally recommended not to write code that assigns in an if statement deliberately because it's so unintuitive and easy to miss at first glance.

Ohh, now I see what you meant.  Yeah, that is definitely a part of C cruft that I'm not a fan of, either.  I don't run across this often, but I actually had one of these just the other day for the first time in years.  I saw it shortly after compile, when it wasn't working right, and that was what reminded me that this was even possible.  You're right, it is a stupid feature -- it's ironic that you would bring it up right after it bit me for the first time in years.

Always the way. I recall there was another couple of tricks you could do in C and C#, but they had enough common sense to leave out of Java. They did leave gotos in, which Java left out, but I've never seen anyone accidentally typo a goto, so whatever your opinion it's not too much of a problem. Though I still don't particularly like how their case statements don't fall through in C# (like they do in C/C++, can't remember how Java does it), I've found it to be fall-through to be far more convenient then error prone, but it is another often newbie/accidental mistake, so it makes it easier for the programmer if they don't.

I've only really started enjoying ASM recently, even though I've had to deal with reading it for decades since I've always been interested in reverse engineering/decompilation and the like. I just never really liked writing it because when dealing with interrupts and stuff in DOS screwing up meant a reboot and try again rather then your program crashing like a normal program.

Yeah, the ability to shoot yourself in the foot is unparalleled.  I prefer coding either inside an emulator (as I did with my 8086 work), or on a secondary chip.  Of course, with most secondary chips you are programming to the emulator first, anyway, so I guess that means that I prefer coding in an emulator with those in general.  I doubt I would ever use ASM on an actual PC (the later extensions and such are so complex, and there's just not much reason for me to do that), but for small embedded work it is pretty cool.  With 256 bytes of working memory on the chip, for instance, ASM is the only way to go.  Some of them are super tiny like that.

My first real experience with writing it was the better part of a decade ago the second year of my long delayed, and still not yet finished bachelor of information technology when I had to suffer through coding a mouse driver to talk to a real mouse. On a real dos machine. Which was in a university laboratory and it wiped it's hdd on a reboot (security and all that). So everything had to be done on a floppy. Which was incredibly slow. As you might expect I did not particularly enjoy that experience.

Though I've been playing around recently with thinking about writing an "optimiser" for old dos games when being run inside dosbox. Just something that analyses the code and removes all the compiler optimisations that are performance giving on a "real" dos box (such as converting multiplications by constants into a series of shifts and adds), back into the version that's less optimal on a real machine, but more optimal in an interpreted machine since there's less opcodes to process. Unfortunately it really seems like something on the difficulty level of a PhD thesis, rather then something I can just play with in my spare time.

[x4000]

Most warped thing I've seen done with #defines is a massive series of them to help build a subset of an x86 emulator to decode an odd audio compression format so we could play the music to a game engine we were rebuilding (ultima8; the function was annoyingly complex so it was simpler at the time to write a quick and dirty emulator then it was to hand decode what it was doing and rewrite it, we eventually worked out the algorithm though ). The #defines were awfully ugly but the interpreter code was nice and clean as a result, so there is a benefit at odd edge cases.

Very interesting.  Seems like everything is useful in some sort of odd edge case, at the very least.  Even gotos.

Always the way. I recall there was another couple of tricks you could do in C and C#, but they had enough common sense to leave out of Java. They did leave gotos in, which Java left out, but I've never seen anyone accidentally typo a goto, so whatever your opinion it's not too much of a problem. Though I still don't particularly like how their case statements don't fall through in C# (like they do in C/C++, can't remember how Java does it), I've found it to be fall-through to be far more convenient then error prone, but it is another often newbie/accidental mistake, so it makes it easier for the programmer if they don't.

Yeah, like most people, I'm not a fan of gotos.  Of course, you can use them to simulate falling through case statements, which is a bit more clear than just having it fall through, I think.  In most cases where I forget a break statement, I'm happy that it doesn't allow it to just fall through instead of causing an error.  On the flip side, I use the ability to have multiple cases all use the same code block in a switch all the time, it's super handy.  It's too easy to forget those breaks in a complex switch, so I'm kind of thankful for that one.

My first real experience with writing it was the better part of a decade ago the second year of my long delayed, and still not yet finished bachelor of information technology when I had to suffer through coding a mouse driver to talk to a real mouse. On a real dos machine. Which was in a university laboratory and it wiped it's hdd on a reboot (security and all that). So everything had to be done on a floppy. Which was incredibly slow. As you might expect I did not particularly enjoy that experience.

Yeah, I imagine not!

Though I've been playing around recently with thinking about writing an "optimiser" for old dos games when being run inside dosbox. Just something that analyses the code and removes all the compiler optimisations that are performance giving on a "real" dos box (such as converting multiplications by constants into a series of shifts and adds), back into the version that's less optimal on a real machine, but more optimal in an interpreted machine since there's less opcodes to process. Unfortunately it really seems like something on the difficulty level of a PhD thesis, rather then something I can just play with in my spare time.

Wow, very interesting, though.  Doing that sort of thing would definitely be quite a feat.

[Admiral]

Admiral is actually the terrifying result of someone attempting to set the AI level to 11

I even have my own Wierd Al "AI War Level 11" theme song.

[x4000]

Ahaha.

[Admiral]

Anyway, I'm off to try to find a partner or two, probably to be sprouted from my Xfire friends list... I'm apparently weird in the fact that I'm among 5-10% of the gaming population that plays entirely for multiplayer purposes... I still find that hard to believe .

I don't play almost any single-player game, even really great ones like AI War. I just like playing with people too much. The last one I really got into single player was Master of Orion.

Part of my problem is I don't prefer "story." I can get that from books (I have over 1,600 of those). I prefer good, engrossing mechanics and partnership, and most games don't have one or the other.

Did I mention I play Bridge?

Cheers!

[Admiral]

Swapping between 10 or 11 different languages in a month was fun.

My Computer Science Doctorate will be on the theory of programming languages. It's a very interesting field and one I've followed as a layman for almost two decades.

Of course, I have to finish my Physics Doctorate first, and that's a "life goal." Oh well. Not enough time for all that and AI War!

[Revenantus]

Of course, I have to finish my Physics Doctorate first, and that's a "life goal." Oh well. Not enough time for all that and AI War!

I too, am concerned about not having enough time to play AI War and complete my academic work.

To this end, I am hoping that my university will appreciate my innovative paper, "The Travelling Scoutship - An analysis of scouting techniques in AI War: Fleet Command".

[x4000]

To this end, I am hoping that my university will appreciate my innovative paper, "The Travelling Scoutship - An analysis of scouting techniques in AI War: Fleet Command".

You guys crack me up. 

[darke]

Always the way. I recall there was another couple of tricks you could do in C and C#, but they had enough common sense to leave out of Java. They did leave gotos in, which Java left out, but I've never seen anyone accidentally typo a goto, so whatever your opinion it's not too much of a problem. Though I still don't particularly like how their case statements don't fall through in C# (like they do in C/C++, can't remember how Java does it), I've found it to be fall-through to be far more convenient then error prone, but it is another often newbie/accidental mistake, so it makes it easier for the programmer if they don't.

Yeah, like most people, I'm not a fan of gotos.  Of course, you can use them to simulate falling through case statements, which is a bit more clear than just having it fall through, I think.  In most cases where I forget a break statement, I'm happy that it doesn't allow it to just fall through instead of causing an error.  On the flip side, I use the ability to have multiple cases all use the same code block in a switch all the time, it's super handy.  It's too easy to forget those breaks in a complex switch, so I'm kind of thankful for that one.

Seemingly every program I write ends up being a collection of state machines so I do tend to miss my automatic fall through.

Though I've been playing around recently with thinking about writing an "optimiser" for old dos games when being run inside dosbox. Just something that analyses the code and removes all the compiler optimisations that are performance giving on a "real" dos box (such as converting multiplications by constants into a series of shifts and adds), back into the version that's less optimal on a real machine, but more optimal in an interpreted machine since there's less opcodes to process. Unfortunately it really seems like something on the difficulty level of a PhD thesis, rather then something I can just play with in my spare time.

Wow, very interesting, though.  Doing that sort of thing would definitely be quite a feat.

In theory it's easy, in practice it's not so.

Of course, I have to finish my Physics Doctorate first, and that's a "life goal." Oh well. Not enough time for all that and AI War!

I too, am concerned about not having enough time to play AI War and complete my academic work.

To this end, I am hoping that my university will appreciate my innovative paper, "The Travelling Scoutship - An analysis of scouting techniques in AI War: Fleet Command".

My preference would of course involve studying the following procedure:

1) Find bug.
2) Exploit bug.
3) Report bug.
4) ? ? ?
5) Profit!^WGet sad when bug is fixed. 

As it is, my next semester's course load (starting in a couple of weeks) will involve IT Management (or something annoyingly fluffy like that) and Japanese. Considerably less interesting then blowing up ships.

[x4000]

Yeah, there's never enough time for all that we'd like to do.  There are so many other game that I want to play, too, but I don't have time.  I shouldn't complain (and I'm not, not really), but I would like more time to play Red Faction: Guerrilla, etc.  Ah well!