I must say, 2008 was a disappointment in one very important way: Flying cars are still not affordable and widespread.
(Yeah, this is a copout post. Happy New Year!)
Wednesday, December 31, 2008
Monday, December 29, 2008
The Curious Case of Good Sci-fi
I saw the Benjamin Button movie today. It was pretty good, all things considered, even if it was incredibly sad at the end. At some point I found out that it was based on a book by F. Scott Fitzgerald, which was a shock to me, probably because I can only name one other book by him. (Granted, they changed a lot for the movie. Put it this way: If you were to sum up the movie in one sentence, that would be all that it has in common with the book.)
One thing really struck me, though. To me, the movie was obviously sci-fi, yet I feel somehow like most of the people in the theater would have disagreed with me. There is a widespread perception that a sci-fi movie has to be fairly shallow, set in the future, and involve one or more of lasers, aliens, and time travel. I consider this a shame, because most things that fall into this category are terribly uninteresting. (I'm making a distinction here between entertaining and interesting: Entertaining's value is while you're in the theater; interesting's value is more when you're thinking about it afterward. Good movies will have both, but the latter is more important.)
I used to be extremely upset that sci-fi and fantasy are lumped into one genre, but it makes a little more sense to me now. There's kind of a gradient between the two, and the major dividing factor is how much of a break the story makes with reality. At the sci-fi end of the spectrum, the world is basically recognizable, except for a small change which drives the story. For example, Paycheck was an excellent sci-fi movie (and book). (The small change is spoiler, so I won't give it away here - read the linked article if you're curious.) At the other end of the spectrum, we have stuff like The Lord of the Rings, where the entire world is replaced.
Sci-fi seems to take up most of the spectrum; stuff like Star Wars is really more fantasy, but it still gets labeled sci-fi. For some reason, most people get their impression of sci-fi from the fantasy end of the spectrum, even though the interesting stuff is generally clustered at the other end. That's what I usually call "good" sci-fi - broadly, it proposes a small tweak to the world as we know it, and then explores some of the consequences. The fact that much of what I consider to be "good" sci-fi won't even be seen as sci-fi by most people will probably irritate me for some time to come.
One thing really struck me, though. To me, the movie was obviously sci-fi, yet I feel somehow like most of the people in the theater would have disagreed with me. There is a widespread perception that a sci-fi movie has to be fairly shallow, set in the future, and involve one or more of lasers, aliens, and time travel. I consider this a shame, because most things that fall into this category are terribly uninteresting. (I'm making a distinction here between entertaining and interesting: Entertaining's value is while you're in the theater; interesting's value is more when you're thinking about it afterward. Good movies will have both, but the latter is more important.)
I used to be extremely upset that sci-fi and fantasy are lumped into one genre, but it makes a little more sense to me now. There's kind of a gradient between the two, and the major dividing factor is how much of a break the story makes with reality. At the sci-fi end of the spectrum, the world is basically recognizable, except for a small change which drives the story. For example, Paycheck was an excellent sci-fi movie (and book). (The small change is spoiler, so I won't give it away here - read the linked article if you're curious.) At the other end of the spectrum, we have stuff like The Lord of the Rings, where the entire world is replaced.
Sci-fi seems to take up most of the spectrum; stuff like Star Wars is really more fantasy, but it still gets labeled sci-fi. For some reason, most people get their impression of sci-fi from the fantasy end of the spectrum, even though the interesting stuff is generally clustered at the other end. That's what I usually call "good" sci-fi - broadly, it proposes a small tweak to the world as we know it, and then explores some of the consequences. The fact that much of what I consider to be "good" sci-fi won't even be seen as sci-fi by most people will probably irritate me for some time to come.
Thursday, December 25, 2008
Boxing Day
In the spirit of the holidays, I thought I'd borrow the Wikipedia article for the holiday that's on everybody's mind:
Boxing Day
Boxing Day is a holiday celebrated in certain other, less punctual countries. The origin of the holiday traces back to the birth of Christ. It's a little known fact that four wise men were actually sent to Jesus with gifts; however, the fourth overslept on Christmas day. In his hurry to deliver the gift on the next day, he forgot to actually package the gift, and ended up delivering an empty box a day late, along with a card wishing Christ a "Happy Belated Birthday". Because of this incident, he was stripped of his title as a Wise Man, and later accounts omit him entirely, mostly out of embarrassment.
The holiday is celebrated today by giving empty boxes to friends and relatives, along with sheepish apologies. Boxing Day parties are also popular, with the caveat that guests must show up late - showing up on time is considered extremely rude. Some people take the holiday spirit even further, and simply don't show up to the parties at all. Long ago, a tradition was established that, if you wanted to give an actual Boxing Day present, you had to give it one day later than the recipient was actually expecting it; however, this quickly got out of hand. The last actual Boxing Day present was given on October 4th, 1793. The next expected date for a gift to be given is not until early 2011, and is moving back at an exponentially increasing rate.
Boxing Day
Boxing Day is a holiday celebrated in certain other, less punctual countries. The origin of the holiday traces back to the birth of Christ. It's a little known fact that four wise men were actually sent to Jesus with gifts; however, the fourth overslept on Christmas day. In his hurry to deliver the gift on the next day, he forgot to actually package the gift, and ended up delivering an empty box a day late, along with a card wishing Christ a "Happy Belated Birthday". Because of this incident, he was stripped of his title as a Wise Man, and later accounts omit him entirely, mostly out of embarrassment.
The holiday is celebrated today by giving empty boxes to friends and relatives, along with sheepish apologies. Boxing Day parties are also popular, with the caveat that guests must show up late - showing up on time is considered extremely rude. Some people take the holiday spirit even further, and simply don't show up to the parties at all. Long ago, a tradition was established that, if you wanted to give an actual Boxing Day present, you had to give it one day later than the recipient was actually expecting it; however, this quickly got out of hand. The last actual Boxing Day present was given on October 4th, 1793. The next expected date for a gift to be given is not until early 2011, and is moving back at an exponentially increasing rate.
Wednesday, December 24, 2008
Christmas Copout Post!
Yeah, I can't really think of anything to write about today, so I'll just pass on a link and go.
EEStor Issued a Patent For Its Supercapacitor
This is huge news for electric cars. The capacitor they're describing stores about as much energy as the battery for the Tesla Roadster, but weighs a fraction as much and can be charged in a few minutes. If they can actually mass-produce these things, then we're in for some interesting times.
(Personally, though, I'm more interested in whether or not they can scale it down too - laptop batteries, for instance, could benefit tremendously from something like this.)
EEStor Issued a Patent For Its Supercapacitor
This is huge news for electric cars. The capacitor they're describing stores about as much energy as the battery for the Tesla Roadster, but weighs a fraction as much and can be charged in a few minutes. If they can actually mass-produce these things, then we're in for some interesting times.
(Personally, though, I'm more interested in whether or not they can scale it down too - laptop batteries, for instance, could benefit tremendously from something like this.)
Sunday, December 21, 2008
Real-world filesystems
I was thinking today about notebooks, and how you find information in them. When I take notes in my classes, I start at the first page, write down whatever seems important, and pick up where I left off for subsequent classes. When I want to look something up from my notes, I try to remember when we talked about it in class, and then do a sort of binary search through the notebook based on that. If I don't remember well enough, I fall back on linear search.
This is very nearly optimal for writing notes, but pretty damn bad for actually going back and reading them. (Probably, this reflects poorly on my study habits. >_>) More rigorously: Writing involves a O(log n) seek, which can be amortized over the length of a class period. Reading involves a seek which varies between O(log n) and O(n), depending on how well I remember the contents of the notebook. O(log n) is pretty acceptable performance, all things considered, but an O(n) worst case is pretty bad.
This is where the CS nerd in me immediately starts drawing comparisons to filesystems. Unfortunately, the comparisons are pretty worthless in the end, because a notebook has fundamentally different characteristics when compared to a computer's hard drive. Also, and probably more importantly, humans are fundamentally different from the computers which access hard drives - algorithms involving hashing, for example, are a no-go. Still, there's a lot of potential here for better filesystems.
First: indexing. This is basically the same algorithm used in books, for the table of contents - you dedicate a few pages at the beginning to a list of all the sections in the notebook, along with their page numbers, and then number the rest of the pages in the book. This gives you guaranteed O(size of index + log n) performance for looking stuff up, at the cost of some time every time you write in the notebook (because you have to update the index). Multi-level indexing is possible, but they don't make notebooks big enough for it to matter.
Second: file fragmentation. This is akin to what newspapers do, with continuations from the front page a few pages deeper in. If you're writing on a subject that you think you might want to come back to later, you can reserve some space at the end. When you continue writing later, on some other page, you can then go back and write the page number you continued on in that space.
Here's another thing to consider: If you use a binder instead of a notebook, you can move the pages around at will. While this is useful, it also renders your page numbers useless. This is kind of an interesting tradeoff, and it remains to see what can be done with it; I'll probably be posting on this topic again.
(Also, shameless plug: A good friend of mine (and also a frequent commenter here!) has started his own blog! Props to him for this.)
This is very nearly optimal for writing notes, but pretty damn bad for actually going back and reading them. (Probably, this reflects poorly on my study habits. >_>) More rigorously: Writing involves a O(log n) seek, which can be amortized over the length of a class period. Reading involves a seek which varies between O(log n) and O(n), depending on how well I remember the contents of the notebook. O(log n) is pretty acceptable performance, all things considered, but an O(n) worst case is pretty bad.
This is where the CS nerd in me immediately starts drawing comparisons to filesystems. Unfortunately, the comparisons are pretty worthless in the end, because a notebook has fundamentally different characteristics when compared to a computer's hard drive. Also, and probably more importantly, humans are fundamentally different from the computers which access hard drives - algorithms involving hashing, for example, are a no-go. Still, there's a lot of potential here for better filesystems.
First: indexing. This is basically the same algorithm used in books, for the table of contents - you dedicate a few pages at the beginning to a list of all the sections in the notebook, along with their page numbers, and then number the rest of the pages in the book. This gives you guaranteed O(size of index + log n) performance for looking stuff up, at the cost of some time every time you write in the notebook (because you have to update the index). Multi-level indexing is possible, but they don't make notebooks big enough for it to matter.
Second: file fragmentation. This is akin to what newspapers do, with continuations from the front page a few pages deeper in. If you're writing on a subject that you think you might want to come back to later, you can reserve some space at the end. When you continue writing later, on some other page, you can then go back and write the page number you continued on in that space.
Here's another thing to consider: If you use a binder instead of a notebook, you can move the pages around at will. While this is useful, it also renders your page numbers useless. This is kind of an interesting tradeoff, and it remains to see what can be done with it; I'll probably be posting on this topic again.
(Also, shameless plug: A good friend of mine (and also a frequent commenter here!) has started his own blog! Props to him for this.)
Thursday, December 18, 2008
What I think of religion
People are, without exception, terrible at scale.
Consider, if you will, the Universe. Since you are terrible at scale, you obviously can't, so let's try again. :p
Consider, if you will, a largish field which is infested with ants. Imagine that, for some reason, you select a particular anthill to be special. But this is not nearly specific enough. Imagine that then, you pick up a particular ant, and let it run around blindly on your hand. Since you'd like to see it a bit closer, you set that ant under a microscope. You see a single cell which particularly strikes your fancy, so you zoom in on that. You are so taken with this one cell on this one ant, that you spend all your time examining it, and eventually, you become acquainted with its very atoms. You decide then that you will grant the wishes of these atoms; but only the carbon atoms, we wouldn't want to be too generous, now.
You would agree, I'm sure, that the above is a fairly ludicrous example; unfortunately, I fear that I've underestimated the scale, if anything. And yet, this is what every theistic religion would have us believe. The idea of a creator, I have no problem with - a creator can't be proven or disproven, so there's no reason to dismiss the possibility. But to think that, after creating the entire Universe, a being that powerful would then look at me, a speck living on a speck orbiting a speck on the arm of a not-especially-impressive galaxy, for even a femtosecond, well, that would be more than I could stand.
If you want, you can believe in a God who meddles in the lives of atoms jostling around on an ant's back. I won't try to stop you; I won't even disagree with you. My Universe is a cold, lonely, and sensible place, though, and that's the way I prefer it.
Consider, if you will, the Universe. Since you are terrible at scale, you obviously can't, so let's try again. :p
Consider, if you will, a largish field which is infested with ants. Imagine that, for some reason, you select a particular anthill to be special. But this is not nearly specific enough. Imagine that then, you pick up a particular ant, and let it run around blindly on your hand. Since you'd like to see it a bit closer, you set that ant under a microscope. You see a single cell which particularly strikes your fancy, so you zoom in on that. You are so taken with this one cell on this one ant, that you spend all your time examining it, and eventually, you become acquainted with its very atoms. You decide then that you will grant the wishes of these atoms; but only the carbon atoms, we wouldn't want to be too generous, now.
You would agree, I'm sure, that the above is a fairly ludicrous example; unfortunately, I fear that I've underestimated the scale, if anything. And yet, this is what every theistic religion would have us believe. The idea of a creator, I have no problem with - a creator can't be proven or disproven, so there's no reason to dismiss the possibility. But to think that, after creating the entire Universe, a being that powerful would then look at me, a speck living on a speck orbiting a speck on the arm of a not-especially-impressive galaxy, for even a femtosecond, well, that would be more than I could stand.
If you want, you can believe in a God who meddles in the lives of atoms jostling around on an ant's back. I won't try to stop you; I won't even disagree with you. My Universe is a cold, lonely, and sensible place, though, and that's the way I prefer it.
Tuesday, December 16, 2008
A disappointing bit of UNIX trivia
So here is something I discovered today, in the course of other pursuits.
As you all may or may not know, every script in a UNIX environment begins with a "#!", followed by the name of the program that should be used to run the script. This feature was added in the early '80s to allow for alternate shells, along with increased portability and a few other benefits. With this, you can run a script as though it were an executable binary, and the system will handle all the messy stuff for you behind the scenes.
Fast-forward to today, where I'm writing my latest project. (More on this project when it's somewhat complete and usable.) I have this program, which takes a data file as an argument. It struck me while I was in the shower (I have a lot of good ideas in the shower!) that it'd be really useful to have the data file executable as a script itself, using the #! syntax. So I try it, and lo and behold, it... fails horribly. Tried it again slightly differently, and another failure.
When things fail inexplicably, I do what any good geek does, and turn to the Internet! A bit of quick googling leads me to the Wikipedia page, which is informative but not terribly helpful. Going a little further, I end up on this page, which has a lot of arcana about history and portability, along with this little tidbit:
"In practice, env must not be a script, because the #! mechanism only accepts binary executables (except on very few implementations like UWIN and Minix)."
Unfortunately, my interpreter is itself a script, so it looks like that particular idea was doomed from the beginning. :( If it works out, though, I'm planning to rewrite this particular project in C, so maybe it'll work out someday.
As you all may or may not know, every script in a UNIX environment begins with a "#!", followed by the name of the program that should be used to run the script. This feature was added in the early '80s to allow for alternate shells, along with increased portability and a few other benefits. With this, you can run a script as though it were an executable binary, and the system will handle all the messy stuff for you behind the scenes.
Fast-forward to today, where I'm writing my latest project. (More on this project when it's somewhat complete and usable.) I have this program, which takes a data file as an argument. It struck me while I was in the shower (I have a lot of good ideas in the shower!) that it'd be really useful to have the data file executable as a script itself, using the #! syntax. So I try it, and lo and behold, it... fails horribly. Tried it again slightly differently, and another failure.
When things fail inexplicably, I do what any good geek does, and turn to the Internet! A bit of quick googling leads me to the Wikipedia page, which is informative but not terribly helpful. Going a little further, I end up on this page, which has a lot of arcana about history and portability, along with this little tidbit:
"In practice, env must not be a script, because the #! mechanism only accepts binary executables (except on very few implementations like UWIN and Minix)."
Unfortunately, my interpreter is itself a script, so it looks like that particular idea was doomed from the beginning. :( If it works out, though, I'm planning to rewrite this particular project in C, so maybe it'll work out someday.
Sunday, December 14, 2008
Small things
Today's post will be about a lot of minor things, I'm afraid. Couldn't think of a proper entry. The first small thing, unfortunately, is the laptop I'm typing this post on. My desktop isn't up and running yet (too lazy), so I'm having to use the Eee and its microscopic keyboard. (Some of you will say that microscopic is an exaggeration, to which I say: I can see at least a bit of it through a microscope, can't I?!)
The next minor thing is an update to the last post. I talked to David for a bit about the archival filesystem thing, and he pointed out that deletes didn't make a lot of sense in such a system. So, to clarify what I said before: the goal is to adjust filesystem semantics so that replicas can be arbitrarily out-of-date without affecting the correctness of applications. This means that there can be no deletes, and no updates to existing files. Not all applications are amenable to this sort of meddling, but many are.
Bugs: Houston has a lot more of them than Austin, and that makes me sad. :(
Anime: At Kiriska's urging, I've been watching Nodame Cantabile. (Kiriska: Why are all your recommendations so awesome, it's uncanny D:) Only halfway through the first season; may write something about it here when I finish it.
Christmas: Oh hey so it turns out I still haven't bought gifts for anyone. There's still time right?
Sleep schedule: It's not even 1 AM; why am I tired already :(
Friday, December 12, 2008
Random idea post: Heated clothin, archive-only filesystems
Okay, so to be honest, it's 5 AM and I've realized that I don't have much to write about today. So, here are two ideas that have been knocking around in my head lately.
Heated clothing: It should not be too terribly difficult, from any perspective, to run some wires through a jacket so that when a battery is plugged in, the jacket heats up. (For some reason, this idea comes back to me every winter, and then I forget it again come spring. >_>) Obviously, you need to be careful with this or you're going to catch fire and burn to death. For bonus points, there could also be a digital thermometer in there somewhere, so that you could target a geven temperature.
Archive-only filesystems: This is basically a relaxation of traditional filesystem semantics. Traditional semantics are problematic for distributed filesystems, because there's no good way to resolve conflicting updates. However, archives are a pretty common use case, where files are never updated, and never (or rarely) deleted. Therefore, if we relaxed the filesystem semantics to disallow writes to complete files (obviously, you still need to be able to write to incomplete files, and the FS would have to track that bit of state), and to allow delayed deletes (so that the file is still allowed to be readable for an arbitrary amount of time after it is deleted), it seems like we could build something that performs a lot better than the current batch of distributed filesystems, while still being pretty useful.
Heated clothing: It should not be too terribly difficult, from any perspective, to run some wires through a jacket so that when a battery is plugged in, the jacket heats up. (For some reason, this idea comes back to me every winter, and then I forget it again come spring. >_>) Obviously, you need to be careful with this or you're going to catch fire and burn to death. For bonus points, there could also be a digital thermometer in there somewhere, so that you could target a geven temperature.
Archive-only filesystems: This is basically a relaxation of traditional filesystem semantics. Traditional semantics are problematic for distributed filesystems, because there's no good way to resolve conflicting updates. However, archives are a pretty common use case, where files are never updated, and never (or rarely) deleted. Therefore, if we relaxed the filesystem semantics to disallow writes to complete files (obviously, you still need to be able to write to incomplete files, and the FS would have to track that bit of state), and to allow delayed deletes (so that the file is still allowed to be readable for an arbitrary amount of time after it is deleted), it seems like we could build something that performs a lot better than the current batch of distributed filesystems, while still being pretty useful.
Tuesday, December 9, 2008
"Blackjack!!"
First off: I have to thank a butterfly somewhere for giving me an incredible birthday gift: As I'm writing this, it's snowing outside. Sure, it's not snowing much, and it's not sticking to the ground really, but I still have to hand it to those butterflies. :D
So, as of right now, I am 21 years old. Frankly, I'm not sure what to make of it. It's simultaneously overwhelming and underwhelming - on the one hand, this is pretty much the last major milestone in my life that I get for free. On the other hand, I know that tomorrow, I'm going to be basically the same person that I was yesterday. The biggest change I am expecting is the number of posts on my Facebook wall; so much for major life milestones.
To be honest, I feel like I've spent most of the past 21 years coasting; waiting for stuff to happen, and then reacting to it. It's a little worrying. When I look back at my life, I find myself wondering how much credit I can really take for it. I've spent far too much time on the path of least resistance. Therefore, from now on I'm going to try to take steps from time to time to get myself out of this rut.
Here is the second of those things. (The first was a little less than two weeks ago. Only two people that read this blog know about it, and I'm keeping it that way.) I will not be seeking an internship at a large company for summer '09. I don't know what I'm going to do instead. I have a couple ideas, but none of them are fleshed out enough to even mention here. This coming summer may not turn out to be especially lucrative, if I'm unsuccessful. But, regardless of how things end up, I know that whatever I do will be interesting. It will be worthwhile. It will be a chance to try something new.
I am going to make it the end of my life so far, and the beginning of the rest of my life. Take that, 21st birthday: that's what a milestone is supposed to look like.
So, as of right now, I am 21 years old. Frankly, I'm not sure what to make of it. It's simultaneously overwhelming and underwhelming - on the one hand, this is pretty much the last major milestone in my life that I get for free. On the other hand, I know that tomorrow, I'm going to be basically the same person that I was yesterday. The biggest change I am expecting is the number of posts on my Facebook wall; so much for major life milestones.
To be honest, I feel like I've spent most of the past 21 years coasting; waiting for stuff to happen, and then reacting to it. It's a little worrying. When I look back at my life, I find myself wondering how much credit I can really take for it. I've spent far too much time on the path of least resistance. Therefore, from now on I'm going to try to take steps from time to time to get myself out of this rut.
Here is the second of those things. (The first was a little less than two weeks ago. Only two people that read this blog know about it, and I'm keeping it that way.) I will not be seeking an internship at a large company for summer '09. I don't know what I'm going to do instead. I have a couple ideas, but none of them are fleshed out enough to even mention here. This coming summer may not turn out to be especially lucrative, if I'm unsuccessful. But, regardless of how things end up, I know that whatever I do will be interesting. It will be worthwhile. It will be a chance to try something new.
I am going to make it the end of my life so far, and the beginning of the rest of my life. Take that, 21st birthday: that's what a milestone is supposed to look like.
Monday, December 8, 2008
Shameless Holiday Post!
Here is a list of things I think would be neat to get for Christmas:
Edit: A new pair of sandals would be nice too, since my good ones just broke. :(
- A remote-controlled helicopter. Seriously, those things are awesome.
- More RAM, you can never have too much of that stuff
- Membership in the ACLU (with a card for me to carry! :D)
- Funny T-shirts
- Quarters (I can never seem to find them when I need them :( )
- Things which could potentially be hung on my walls
- A whiteboard
- A second monitor
- Yarn
- A head-mounted display
- A good night's sleep
Edit: A new pair of sandals would be nice too, since my good ones just broke. :(
Friday, December 5, 2008
Dijkstra Part II
So I was talking to a friend of mine (I dunno if he minds his name being on the internet, so for now he is Friend) about the Dijkstra talk I linked in my last post, and he pointed out something interesting. Basically, Dijkstra spends 15 pages or so talking about how useless it is to try and use analogy to understand "radical novelties". Then, he talks about how useless current software methods are, since they basically try to apply to software analogies which are a poor fit. Then... he suggests applying mathematical methods to software. Way to deal with radical novelty, Edsger!
Somehow I didn't notice that inconsistency, so props to Friend for that. What I did notice, at least in my mind, was how much weaker the second part of the talk was compared to the first half. If I were to take a wild stab at why, I would say that perhaps Dijkstra himself realized that formal mathematical techniques weren't a perfect fit either for software. It's too much of a reactive step; it solves the problems of the current paradigm but replaces them with plenty of new ones.
What, then, should we do instead? It will surprise approximately none of you that I have an opinion on this. :) I haven't quite worked out how it would look (yet), but I think an ideal solution to managing the complexity of software would be to manage as little of it as possible; or, in other words, to get the computer to do the work for you. Computers are astonishingly good at doing regular, repetitive tasks. We need to find those tasks, find some way to make the computer take care of them, and then look at what's left over and repeat.
In other words, rather than logic and proofs, I would teach automation as the fundamental building block of programming. This works in two directions - programs should be designed not only looking down, at the task they immediately perform, but also up at future programs which may want to use this program as a building block. (This is why GUIs are no good - there is as yet no good way to use a GUI from another program.) This method also instills the correct frame of mind in the programmer, by making a clear split between things that computers are good at, and things that people are good at, and assigning responsibilities properly. These days, this split is all but ignored, which is how we end up with absurdities like people happily doing repetitive, automatable tasks, and then turning around and asking computer programs for (admittedly artificial) intelligence.
Somehow I didn't notice that inconsistency, so props to Friend for that. What I did notice, at least in my mind, was how much weaker the second part of the talk was compared to the first half. If I were to take a wild stab at why, I would say that perhaps Dijkstra himself realized that formal mathematical techniques weren't a perfect fit either for software. It's too much of a reactive step; it solves the problems of the current paradigm but replaces them with plenty of new ones.
What, then, should we do instead? It will surprise approximately none of you that I have an opinion on this. :) I haven't quite worked out how it would look (yet), but I think an ideal solution to managing the complexity of software would be to manage as little of it as possible; or, in other words, to get the computer to do the work for you. Computers are astonishingly good at doing regular, repetitive tasks. We need to find those tasks, find some way to make the computer take care of them, and then look at what's left over and repeat.
In other words, rather than logic and proofs, I would teach automation as the fundamental building block of programming. This works in two directions - programs should be designed not only looking down, at the task they immediately perform, but also up at future programs which may want to use this program as a building block. (This is why GUIs are no good - there is as yet no good way to use a GUI from another program.) This method also instills the correct frame of mind in the programmer, by making a clear split between things that computers are good at, and things that people are good at, and assigning responsibilities properly. These days, this split is all but ignored, which is how we end up with absurdities like people happily doing repetitive, automatable tasks, and then turning around and asking computer programs for (admittedly artificial) intelligence.
Wednesday, December 3, 2008
Dijkstra was a badass
The Paxos project is due soon! D:
Therefore, in lieu of a post today, I'm just going to mention something written by Dijkstra which was on Slashdot the other day, along with my fervent wish that someday I, too, will be remembered as a badass.
(Notice how many of my blog posts are mirrored in that one essay of his? I have a feeling I'd have liked the guy.)
Therefore, in lieu of a post today, I'm just going to mention something written by Dijkstra which was on Slashdot the other day, along with my fervent wish that someday I, too, will be remembered as a badass.
(Notice how many of my blog posts are mirrored in that one essay of his? I have a feeling I'd have liked the guy.)
Monday, December 1, 2008
WhEee!
In the spirit of ill-advised purchases, I bought a tiny laptop! (Rationale: my laptop battery has been kinda useless for a little while now, and a replacement battery would have cost a significant fraction of what I paid for this new laptop. >_>) It's an Eee 701, with windows XP and some extra RAM for some reason.
So far, it's pretty neat - my biggest complaint is the keyboard, which is kind of lame. Surprisingly, windows XP isn't as much of a pain as I'm used to, probably because the guy I bought it from put some nontrivial work into shrinking the install and setting it up. Still, my patience for XP probably won't last very long, so I'm looking at Linux distros to put on it.
My first choice would be Gentoo, under normal circumstances, but somehow I think that compiling software on a 900 MHz celeron is going to be a massive pain. I considered using Ubuntu briefly - very briefly, in fact. Ubuntu is a very solid system, I'm sure, but it just makes everything so easy; that's not how Linux is supposed to be! Various distros have specialized versions for the Eee, and these seem like good candidates. First, though, I kind of want to try Damn Small Linux, because it's just like the name says.
Unfortunately, one of the things they saw fit to leave out with the Eee was a CD drive. I suppose it's understandable, since I honestly can't see where you'd even put one, but it means I'll have to go out and get a couple of extra SD cards.
So far, it's pretty neat - my biggest complaint is the keyboard, which is kind of lame. Surprisingly, windows XP isn't as much of a pain as I'm used to, probably because the guy I bought it from put some nontrivial work into shrinking the install and setting it up. Still, my patience for XP probably won't last very long, so I'm looking at Linux distros to put on it.
My first choice would be Gentoo, under normal circumstances, but somehow I think that compiling software on a 900 MHz celeron is going to be a massive pain. I considered using Ubuntu briefly - very briefly, in fact. Ubuntu is a very solid system, I'm sure, but it just makes everything so easy; that's not how Linux is supposed to be! Various distros have specialized versions for the Eee, and these seem like good candidates. First, though, I kind of want to try Damn Small Linux, because it's just like the name says.
Unfortunately, one of the things they saw fit to leave out with the Eee was a CD drive. I suppose it's understandable, since I honestly can't see where you'd even put one, but it means I'll have to go out and get a couple of extra SD cards.
Subscribe to:
Posts (Atom)