Let me get this straight. You're a virtual celebrity, virtually rich and virtually powerful. Thousands on people hang on your every virtual word. You get mobbed in the virtual streets. And you can't figure out a way to make any non-virtual money?
Jeez, man, here's an easy one: start a blog, stick up a PayPal "donate" button, post "Thedeacons's Daily Dose of Wisdom" on how to prosper in AO, and then promote the site every chance you get (like, say, in the New York Times). I'm pretty sure you could at least make enough to pay the rent.
Now, here's a hard one: take a long look at what you did to succeed in the game, and translate that into real life.
I try to avoid posting "me, too" comments, but: me, too. This is the first/. article that I've actually hardcopied. Thanks to Fyodor for taking the time to prepare such great responses.
Possibly the best argument for giving chimpanzees a bit more credit in the taxonomic hierarchy is that we tend to waste our lives worrying about such things, whereas the chimps don't care.
What Paul Graham is driving at seems to me to be that the creation of a program by a hacker is more akin to the creation of painting by a painter than it is to the creation of, say, a blueprint by an architect. He spends a lot of time complaining about the economic and academic pressures that make it hard for hackers to hack, if you will, and he touches on the negative effect that these pressures have on our view of how to write software (as expressed in certain views on "software engineering").
I think some prominent authors are thinking along the same lines. For example, Alistair Cockburn (Writing Effective Use Cases) bases much of what he writes in Agile Software Development on the Peter Naur's Programming as Theory Building. By "Theory", Naur means the sort of uniquely humans understanding of a concept (Naur, in turn, bases this on the work of Gilbert Ryle). Cockburn points out, quite effectively, that the purpose of software documentation is to communicate the theory that underlies the software.
Unfortunately, communicating theory is a hard thing to do. Personally, I argue that there are two ways to do it. The first is via a two step processs: through expressive thought, the theory (which is ephemeral in the theory owner's mind) becomes "knowledge" (which is a somewhat more "concrete" thing). That knowledge is then communicated, usually concretely in a language like english, sometime in a formal language like UML, sometimes through sketches or through analogies (communicated knowledge is "information"). Of course, something (and potentially, a lot) is lost at each step (hence the ineffectiveness of documentation). It's more effective to directly express the theory. This sort of expression is "artistic expression". Often, its end result is a painting or a poem. But it seems that it can also be a program -- and this is the key point. This has some interesting implications for the future of programming languages, IMO.
So, Graham's analogy is not flawed, because both painters and hackers are directly expressing theory.
I believe the researchers' point was that existing filesystems were (understandably) not designed with a RAM component in mind. Therefore, caching controllers and similar solutions are inefficient compared to Conquest, which assumes the presence of the RAM and is optimized appropriately.
Hundreds of millions of people worldwide piss away their disposable income instead of using it to further some worthy cause. The total amount they waste dwarfs Paul Allen's entire fortune. So, it's hardly fair to pick on Paul.
That said, it does seem weird that he would choose to build an SF shrine before getting his teeth taken care of.
I can easily see how they'd view the web and computer gaming as "the enemy"
At least one company has taken an opposite attitude. Columbia Games is downright generous with its copyrights, and fully supports fans who create and make freely available via the Internet their own supplements for its "Harn" roleplaying world and system. Many of these supplements are of a truly professional quality that rivals the products sold by Columbia.
Then it's a motto with a rather slanted translation, IMO. "Une idée préconçue" might be more accurately translated as "a preconceived idea", which is a decidedly less pejorative way of putting it than "prejudice".
Nobody really has a clue what programming languages will be like in a hundred years, but if all the Perl and Python weenies would learn LISP then maybe we could get somewhere within the next decade.
The priest brews in accordance with the Reinheitsgebot, the German beer purity law that dictates only water, malt, hops (and now yeast) shall be used in making beer.
Another example of legislation failing to keep up with technology. I'm sure that whoever wrote the Reinheitsgebot would have prohibited using computer-driven washing machines if only they'd anticipated their existence.
The problem I have with this whole thing isn't whether you can build a PC that does all the tricks. I think you can, and I think you can even find a nice A/V component style case for it. The only thing I'd do that I haven't yet heard of someone else doing is make it remotely manageable via SOAP, so that I can build my own user interface or integrate it with other stuff.
My problem is finding a receiver that's built to handle the whole deal and provide the sort of user interface you need to manage it. OK, I can hook up my PC to my receiver as an A/V source and sink, no problem. I can do the same thing (as sources, sinks, or both) with my satellite, CD, tuner, DVD, TV, VCR, cassette deck, phonograph, PS/2 or XBox or whatever, etc. But now try to route all the signals just the way you want, and then get device A (sink) to tune device B (source) to the desired channel. It's a nightmare, if it's even possible.
Those who think of things in terms of computers are still too far removed from those who think of things in terms of A/V components. I'd like to see a forward-thinking company that builds high-end receivers engineer something really non-traditional that lets you take any source signal and route it to any/multiple appropriate sink(s) (note that speakers are a sink), that handles multiple such paths simultaneously, that operates all your devices remotely via I/R or RF or SOAP, and that does it all through an easy front-end. You should be able to apply decoding (e.g., Dolby) to any appropriate signal. You'd probably need a notebook as your remote (client) communicating via wireless to your receiver (server).
I'd also like to see satellite/digital cable tuners get a bit more real...these things should provide multiple outputs, each of which can be tuned independently. Who wants to have to buy another tuner just so you can watch A while recording B? Maybe I haven't done enough research: does such a beast exist?
Others don't agree with the conclusion that the drugs had no effect. Here's a story about it. The manufacturers of the drugs say that they can impair judgement.
Testing and debugging are two seperate activites, and it's important not to try to confuse them.
I think the two activities are converging. Tools like junit and methodologies like XP are extending testing to the point that when you want to find out what caused a bug, you might consider building tests instead of stepping through your code and watching variables. The resulting test then becomes not only a tool for debugging, but a tool for proactively detecting the bug again should you make a code change that would cause it to resurface.
Consumers want: To be able to get good quality copies of shows they missed and/or would like to see again.
Networks want: To sell advertising.
PVR Vendors want: To sell PVRs and subscriptions
Dumb solution: Networks yell at PVR vendors about enabling piracy, and yell at consumers about being pirates. Consumers yell at networks about not giving them any means to see the shows they missed. PVR vendors yell at networks, because consumers are reluctant to buy PVRs given the network's attitude. Nobody wins, except the lawyers.
Smart solution: Networks do a deal with PVR vendors: we give you copies of our shows, with commercials intact, that you provide for download to your subscribers to view using their PVR...the combination of PVR firmware and show recording format is such that the commercials can't be skipped (there are ways to deal with the hackers). Consumers get to view shows whenever they want, as often as they want. Networks sell more ad time because more consumers will be watching the shows. PVR vendors sell more PVRs and have a service to add to their subscription offering, so they sell more of that, too. Everybody wins, except the lawyers.
Slashdot Mirror
In related news, Cambodia has changed its name to Nymbodia and applied to ISO for a new digraph.
Let me get this straight. You're a virtual celebrity, virtually rich and virtually powerful. Thousands on people hang on your every virtual word. You get mobbed in the virtual streets. And you can't figure out a way to make any non-virtual money?
Jeez, man, here's an easy one: start a blog, stick up a PayPal "donate" button, post "Thedeacons's Daily Dose of Wisdom" on how to prosper in AO, and then promote the site every chance you get (like, say, in the New York Times). I'm pretty sure you could at least make enough to pay the rent.
Now, here's a hard one: take a long look at what you did to succeed in the game, and translate that into real life.
Simple machine. Simple language. Instant feedback. Sound and graphics. 'Nuff said.
The authors have created fictional stories based on non-fictional concepts that could really happen to our computer systems today.
Wow. This could spawn a whole genre of books. We could call it "Science Fiction".
My brother is an idiot most of the time but
I don't see the "but".
I try to avoid posting "me, too" comments, but: me, too. This is the first /. article that I've actually hardcopied. Thanks to Fyodor for taking the time to prepare such great responses.
The stuff they put in solid rockets to keep them burning, you don't want to be inhaling that stuff.
Whereas nitrous oxide and burnin' rubber, well, shucks, that's better'n air!
Possibly the best argument for giving chimpanzees a bit more credit in the taxonomic hierarchy is that we tend to waste our lives worrying about such things, whereas the chimps don't care.
Did either of you read his comment? He likes to look for errors on paper.
I don't know about anybody else, but I was kidding.
I print to paper first. Then I can photocopy as many times as I want.
I'm sorry, but that joke's been done here.
He is aiming for a July 4th, 2006 first coast-to-coast ping.
Considering the latency, I'd aim for July 4th, 5th, and 6th.
What Paul Graham is driving at seems to me to be that the creation of a program by a hacker is more akin to the creation of painting by a painter than it is to the creation of, say, a blueprint by an architect. He spends a lot of time complaining about the economic and academic pressures that make it hard for hackers to hack, if you will, and he touches on the negative effect that these pressures have on our view of how to write software (as expressed in certain views on "software engineering").
I think some prominent authors are thinking along the same lines. For example, Alistair Cockburn (Writing Effective Use Cases) bases much of what he writes in Agile Software Development on the Peter Naur's Programming as Theory Building. By "Theory", Naur means the sort of uniquely humans understanding of a concept (Naur, in turn, bases this on the work of Gilbert Ryle). Cockburn points out, quite effectively, that the purpose of software documentation is to communicate the theory that underlies the software.
Unfortunately, communicating theory is a hard thing to do. Personally, I argue that there are two ways to do it. The first is via a two step processs: through expressive thought, the theory (which is ephemeral in the theory owner's mind) becomes "knowledge" (which is a somewhat more "concrete" thing). That knowledge is then communicated, usually concretely in a language like english, sometime in a formal language like UML, sometimes through sketches or through analogies (communicated knowledge is "information"). Of course, something (and potentially, a lot) is lost at each step (hence the ineffectiveness of documentation). It's more effective to directly express the theory. This sort of expression is "artistic expression". Often, its end result is a painting or a poem. But it seems that it can also be a program -- and this is the key point. This has some interesting implications for the future of programming languages, IMO.
So, Graham's analogy is not flawed, because both painters and hackers are directly expressing theory.
I believe the researchers' point was that existing filesystems were (understandably) not designed with a RAM component in mind. Therefore, caching controllers and similar solutions are inefficient compared to Conquest, which assumes the presence of the RAM and is optimized appropriately.
Hundreds of millions of people worldwide piss away their disposable income instead of using it to further some worthy cause. The total amount they waste dwarfs Paul Allen's entire fortune. So, it's hardly fair to pick on Paul.
That said, it does seem weird that he would choose to build an SF shrine before getting his teeth taken care of.
I can easily see how they'd view the web and computer gaming as "the enemy"
At least one company has taken an opposite attitude. Columbia Games is downright generous with its copyrights, and fully supports fans who create and make freely available via the Internet their own supplements for its "Harn" roleplaying world and system. Many of these supplements are of a truly professional quality that rivals the products sold by Columbia.
[i]It's the motto of my university actually.[/i]
Then it's a motto with a rather slanted translation, IMO. "Une idée préconçue" might be more accurately translated as "a preconceived idea", which is a decidedly less pejorative way of putting it than "prejudice".
Here's what I got out of it:
Nobody really has a clue what programming languages will be like in a hundred years, but if all the Perl and Python weenies would learn LISP then maybe we could get somewhere within the next decade.
The priest brews in accordance with the Reinheitsgebot, the German beer purity law that dictates only water, malt, hops (and now yeast) shall be used in making beer.
Another example of legislation failing to keep up with technology. I'm sure that whoever wrote the Reinheitsgebot would have prohibited using computer-driven washing machines if only they'd anticipated their existence.
The problem I have with this whole thing isn't whether you can build a PC that does all the tricks. I think you can, and I think you can even find a nice A/V component style case for it. The only thing I'd do that I haven't yet heard of someone else doing is make it remotely manageable via SOAP, so that I can build my own user interface or integrate it with other stuff.
My problem is finding a receiver that's built to handle the whole deal and provide the sort of user interface you need to manage it. OK, I can hook up my PC to my receiver as an A/V source and sink, no problem. I can do the same thing (as sources, sinks, or both) with my satellite, CD, tuner, DVD, TV, VCR, cassette deck, phonograph, PS/2 or XBox or whatever, etc. But now try to route all the signals just the way you want, and then get device A (sink) to tune device B (source) to the desired channel. It's a nightmare, if it's even possible.
Those who think of things in terms of computers are still too far removed from those who think of things in terms of A/V components. I'd like to see a forward-thinking company that builds high-end receivers engineer something really non-traditional that lets you take any source signal and route it to any/multiple appropriate sink(s) (note that speakers are a sink), that handles multiple such paths simultaneously, that operates all your devices remotely via I/R or RF or SOAP, and that does it all through an easy front-end. You should be able to apply decoding (e.g., Dolby) to any appropriate signal. You'd probably need a notebook as your remote (client) communicating via wireless to your receiver (server).
I'd also like to see satellite/digital cable tuners get a bit more real...these things should provide multiple outputs, each of which can be tuned independently. Who wants to have to buy another tuner just so you can watch A while recording B? Maybe I haven't done enough research: does such a beast exist?
Others don't agree with the conclusion that the drugs had no effect. Here's a story about it. The manufacturers of the drugs say that they can impair judgement.
It's not the vitamins I'm worried about, it's the 'nutraceuticals' that these patches deliver. This, I consider to be taking drugs.
One might have hoped that tragic events in Afghanistan would have taught the US military that drugging your troops is a bad idea.
Testing and debugging are two seperate activites, and it's important not to try to confuse them.
I think the two activities are converging. Tools like junit and methodologies like XP are extending testing to the point that when you want to find out what caused a bug, you might consider building tests instead of stepping through your code and watching variables. The resulting test then becomes not only a tool for debugging, but a tool for proactively detecting the bug again should you make a code change that would cause it to resurface.
Consumers want: To be able to get good quality copies of shows they missed and/or would like to see again.
Networks want: To sell advertising.
PVR Vendors want: To sell PVRs and subscriptions
Dumb solution: Networks yell at PVR vendors about enabling piracy, and yell at consumers about being pirates. Consumers yell at networks about not giving them any means to see the shows they missed. PVR vendors yell at networks, because consumers are reluctant to buy PVRs given the network's attitude. Nobody wins, except the lawyers.
Smart solution: Networks do a deal with PVR vendors: we give you copies of our shows, with commercials intact, that you provide for download to your subscribers to view using their PVR...the combination of PVR firmware and show recording format is such that the commercials can't be skipped (there are ways to deal with the hackers). Consumers get to view shows whenever they want, as often as they want. Networks sell more ad time because more consumers will be watching the shows. PVR vendors sell more PVRs and have a service to add to their subscription offering, so they sell more of that, too. Everybody wins, except the lawyers.