What you're touching on is the essential problem of AI: nothing that AI does is easy to do for computers. In fact, most things that AI researchers do is ridiculously computationally expensive (you know, 2^100-state optimization problems and the like) and simply cannot be approached by traditional algorithms. What AI researchers give up, explicitly, are the guarantees that you're concerned about. They say, "Well, let's see how well we can do on this problem if we give up the guarantee of completeness." And lo and behold, your 2^100-state problem becomes a lot easier- you can either get the best answer in a trillion years (actually quite a bit longer than that, if I did my math right) or a very good answer in a week.
So the thing is: if you can't live without that guarantee, you probably can't solve your problem at all.
And incidentally, neural nets are, in practice, enormously profitable to use for systems in which there is no standard algorithmic solution. Face recognition, image processing, real-time traffic shaping- bunches of things. Not space-craft flying, though- NASA uses different AI techniques that have much better safety guarantees.
"Overfitting" is the AI terminology. When you do neural networks, you feed the net some set of data that they "learn." Continuously iterating that set, over and over again, will always yield higher and higher results for that set- however, if that set is not completely and utterly representative of the entire set of possible things the net might be asked about when it's finished training, it will have learned too much specific information about the training set (which might just be happenstance- it so happens that 80% of the pictures in the "good guys" set have a pixel of color #09C45A in coordinate (564, 345), while it's only true of 10% of the pictures in your "bad guys" set) to be of use with any other set than yours.
Ha ha... "Not only did Smith fight in Congress for more education funding and prison reform, he also worked with Alan Cox to patch USB support into Linux!"
Katz's description of the "net pol" reminds me a lot of all of the "look at what you could do if only you took advantage of our wonderful technology" that we've heard countless times from countless sources (Jaron Lanier with virtual reality, Bill Gates- time and again- with OLE, multimedia computers and a million other things, Scott McNealy with Java, to name a few). But that argument doesn't really compel anybody- to compel people to use your technology, you need to actually do something compelling. So far, I know of no political "killer app" of the internet, and if there isn't one, it would be dumb of politicians to waste their time campaigning here.
Think about it- yeah, it would be really cool if George W. Bush posted a follow-up to this article, but would you base your vote on that? And even if everybody who read it immediately decided to vote for him, how much does that really buy him? (Not to mention the fact that in popular culture, being a Slashdot denizen might hurt his popularity rather than helping it...)
And in the past, politicians have done that very thing, with little effect. When Bush Sr. was campaigning against Clinton, he answered questions on Prodigy (did do the same thing on AOL?). Did it help? I think the fact that nobody remembers it is answer enough. You might be able to show a tiny effect, but certainly nothing compelling enough to make everyone jump on the bandwagon.
Now, had Clinton and Bush gotten into a Prodigy flame war, that would've been awesome... =)
Re:The slashdot moderation system is flawed
on
Moderation Ideas
·
· Score: 1
Solution: Use a network of preferences to tailor the rankings that a user sees and to delegate the ranking of articles.
Hey, that gives me an idea- make everyone a moderator, then combine all the scores with an initially unweighted neural net! If you don't like the way an article was rated, you click a button and say what it should've been rated. Slashdot evolves the perfect moderator for you!
Tee hee...
(actually, that's not such a bad idea, if there were even close to enough computational/storage resources for it...)
Re:For all the wrong reasons.
on
Linux Lite?
·
· Score: 1
Err... lemme guess, you're a C hacker. I find that C hackers are usually the ones who go on and on about how "computers are hard and we shouldn't pretend they're easy." Myself, I prefer Java, Scheme, Perl, Python, and the like, and I think computers are easy and we shouldn't pretend that they're hard.
Of course, I'm not ignorant of the gawdawful complexities of real low-level computer workings. It used to be that computers had to be hard, for that reason- the big bulky computers didn't have any cycles to spare for abstraction. If I remember correctly, you programmed ENIAC by literally wiring the program in to the logical units. And I imagine they'd have killed for assembly language- and why? Because it's easier! It hides away the yuckiness so that nobody but the yuckiness-builder has do deal with it! And it's not even the case that programming assembly vs. running wires is different than editing inittabs (etc.) vs. a cuddly GUI in that in the first case you lose no power, whereas in the second case, you do, because it's not true- guess what? You can't do everything in assembly that you can do by direct wiring- you can only do the sensible things! No dangling wires or outputs hooked up to other outputs by accident- these are the decisions that assembly takes away from the programmer. And a good GUI/installer ought to do the same thing- take away the user's ability to screw up and do something stupid, leaving only the reasonable choices left. That makes everybody's work easier- I don't have to worry with thinking about every little detail, making sure that I have no dangling wires that will make my computer behave stupidly, so I can concentrate on what I want to do.
This has been the trend in computing since the very first days, is still the trend, and is still a good idea. Programming languages, operating systems, applications, input devices even- you name it, it's getting simpler. And everyone benefits from it- I promise you would not be smugly posting about how the hoi polloi shouldn't be afforded a "dumbed down" version of your operating system if someone hadn't first "dumbed down" computing to the point where the outputs of billions of NAND gates, themselves "dumbed down" versions of NMOS and PMOS (if memory serves), got interpreted all the way into Slashdot.
That idea is called abstraction. Abstraction is fundamental to computer science and everything else that has to do with computing at all. Abstraction is the reason why computers are useful (bold claim alert!). Lack of abstraction is what makes computing difficult. For instance, the reason why you may think that "computers are hard" is that UNIX is complicated- but that doesn't prove that computers are hard at all. UNIX is complicated because UNIX is a crappy operating system that does a very poor job of abstraction. It may be the best we have, but that doesn't mean that dozens upon dozens of illogical, poorly-documented, ad-hoc systems slapped together are a blessing from above. (Which is why Windows is even worse, by the way- I consider the OS choice much less a question of "which is the best OS?" than of "which OS sucks the least?")
I'm not trying to say that all abstractions are equally good, and I'm certainly not trying to claim that Windows is better than Linux because it hides more from the user- all I'm saying is that it not true that computer ease-of-use is a myth, nor is it reasonable to say that adding a layer of abstraction that hides bad ideas from novice users is a bad thing. I actually think the cool thing about Linux is that it lets you strip away some of those layers when you don't want them. But guess what? I use X-Windows, and I use Netscape- I never slashdot by telnetting to 209.207.224.40 port 80 and writing raw HTTP. And I would not be happy if someone told me to and said, "Netscape is for drooling idiots who don't want to think for themselves or learn how their computers work." For the same reason, I would be upset if someone told me that I shouldn't want my favorite OS to be easy to use on the grounds that easy things are for morons, which is what you suggested.
Wow. This post is really long and rambling. I guess this must be something I'm interested in... =)
Nethack is loads of fun. However, the best has got to be ADOM. It has many of the familiar "Rogue-like" game qualities, but feels more like a pencil-and-paper RPG than any of the others (IMHO)- there are multiple dungeons, quests, etc. I have lost far more hours than I care to admit trying to beat that game...
Your toothbrush keeps talking about the evils of eating meat? Bad ass! Guess it must be bad for the bristles or something...
=)
Seriously- hackers come in all shapes, sizes, and affiliations. One would be wise not to create the equation "hip punk kid == skript kiddy && dull boring geek == Real Hacker". The best programmers I've met have all been really interesting people who were quite different from each other.
And the article is quite clueless. It implies that software is too limiting (only 0s and 1s, after all), so playing with FPGAs will open wider horizons. And the researcher speaks of not understanding what's going on like it is a good thing...
I think you missed the cool part of the research- Thompson didn't understand what was going on because what was going on was fundamentally different from how the electrical engineers do things. In the Discover article, they went into more detail on that point. Apparently, some of the designs that the GA evolved contained components that were entirely unconnected to the main circuitry, but that couldn't be taken out without making the chip stop working.
And the point about software being too limiting: they're talking about efficiency. If you want to solve the problem using software, think about all the gates you have to use! It's not that it can't be done, but if you can do it with 100 gates in hardware, that's probably better than a 10,000+ gate software solution. Particularly when no one has ever been able to do it with less than 1,000 gates using traditional techniques.
Sigh... his point is that "business" really sucks for an industry that is supposed to be creative. That is- just because you will buy PopularProgram version 26 doesn't mean it will be entertaining to program PopularProgram version 26 (or CopyProgram version 1, for that matter, either). While it seems to be sound from a profitibility standpoint to hack away at the same old thing, because the same old thing sells, it isn't after a while because your programmers don't enjoy what they're doing. I would rather have a fresh, exciting program that the programmers really believed in than one in which they didn't.
That said, I don't really think that any of the games you mentioned suffer from that syndrome- reading interviews with the Unreal, Half-Life, and Quake people makes it abundantly clear that the people on those teams really believed that they were programming the coolest game ever, and all of their managements seemed to just get out of their way and let them do what they were going to do (would you second-guess John Carmack?).
Actually, I prefer to think of it as Steve Ballmer catching on rather than Steve Ballmer endowing the idea with viability. Like I said, I don't think Microsoft will be able to pull it off, just that Ballmer has put his finger on a cool trend of the future. This is impressive for Ballmer, as he has shown himself to be pretty (probably deliberately) obtuse in precisely these areas in the past: in Nerds 2.0.1, Ballmer is quoted as saying that the Java Virtual Machine, some variant of which would be essential for rent-an-app style distribution of any kind, is
like this funny layer that slows Windows down... [Scott McNealy, Sun's CEO] would say it's a breakthrough. I would say it's sort of a return to the dark ages of operating systems when they had no capabilities and they ran terribly slowly. That's what I would say. I think you would get different viewpoints on the level of breakthrough-ness of that piece of Java.
(that's Nerds 2.0.1, page 338, in case anybody wants to look it up.)
From that perspective, we have to give Ballmer some credit: it is unusual for people who hold such incredibly irrationally negative opinions about things to go so far in realizing their usefulness. So I will say again, we should not assassinate the idea just because Ballmer said it. Sure, he's not the first to come up with the idea of on-demand programs. Us geeky-types would certainly be able to point to a few innovations that predate Steve's by quite a wide margin (Java being the clearest example I can think of). We also justifiably mistrust Microsoft's motivations in pushing on-demand software, as we probably should. But so what? That doesn't mean it's a bad idea, which is what most people around here seem to be saying.
There is NO possible way to justify putting a price-tag on software.
Doesn't that strike you as just a little extreme? Anyone who makes a living writing software wants there to be some kind of pricetag for software, or else they're working for free. That doesn't necessarily mean today's pay-per-copy model of software, but the argument that one should never pay any money for software is about as reasonable as saying that no one should pay for a book, or the food a chef cooks, or any other product of intellectual labor.
In other words: saying "People shouldn't rent programs, they should get them for free" is saying "programmers shouldn't get money every time someone uses their program, because they should do it for free." Speaking as a programmer: I would certainly write some programs for free. The database system I'm working on now is NOT one of them. That doesn't mean that I'm endorsing rental as the way to go (but see my earlier post), just that a radically free software paradigm (ie no money anywhere) only works if the whole society is radically free.
(A bit far afield from the topic of discussion, I'm afraid. I promise to do better next time.)
A general response to most of the posts on this topic: everyone seems to missing the point. While we are focusing on evil domination or tyrannical pricing schemes or lots of inconvenience, we are missing the point that it is becoming increasingly important for computers to be able to load software on demand. That is really all the article was saying, plus a little indirection because of Ballmer's utter Microsoftism. And it is true and pretty important for those of us who pay a lot of attention to software and/or hardware to notice that the hot things to have are portable devices and wireless networks to connect them. It makes perfect sense, therefore, to have a huge library of software sitting on a server somewhere where storage is cheap, but available on demand to all of the network devices, where storage is expensive.
That doesn't mean that devices shouldn't be allowed to store programs or data permanently on their own storage. It just means that for programs of occasional use, it is more expedient to load them occasionally and use them right away than it is to have them sit around unused but taking up important storage space. One can imagine a person's personal computer-watch thingy having OS software always loaded, and then just enough space to store one user program. When the user wants to run a program, the watch downloads it off the app server and executes it. When he quits or switches programs, it unloads the program so it can put something else in.
Now, the logical extension of that is for companies to run their own app servers and charge users for accounts. Probably a flat per-month fee would be workable- wouldn't you pay $15/month or some other reasonable fee to have on-demand access to, for instance, a huge library of database tools that you could transparently install and run on your super-portable computer watch without ever having to worry about making sure that everything was upgraded properly, that everything was set up right (installation is transparent, remember?), or that you would run out of space? Not to mention the fact that you'd be paying far less than the purchase price of the apps you get access to...
It seems pretty clear that on-demand software loading is going to be big, and that it will be a good thing. With that said, though, Microsoft is still being stupid: in order to write good on-demand software, it will need to be a) small, b) efficient, c) standards-compliant, and d) installable/uninstallable immediately and without a trace. Microsoft gets about a 60% on part D, and about 0% on parts A, B, and C. =)
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
Actually, the STL isn't broken at all because of that inconsistency. What's broken is the C-ism of using char *'s as strings. The hash table hashes char *'s based on all the data from the address until the next '\0' not because the programmers were morons who didn't know what they were doing, but because in C people use pointers to characters as an expedient hack for a string data type, which C is sadly lacking. C++ with the STL fixes that with the string class, but if you insist on giving a char * a meaning that it doesn't have naturally, then you don't have the right to get upset when the programmers of your tools make concessions so that you can use it with a minimum of hassle.
If it bothers you that you're really doing a pointer comparison when you say (charPtrA == charPtrB), the solution is to use STL strings instead, which hash just fine with no inconsistency of hashing vs. equality (that is, *stlStringPtrA == *stlStringPtrB if they have the same string value, and hashValue(*stlStringPtrA) == hashValue(*stlStringPtrB) as well). In fact, you should use STL strings for everything anyway if you're programming in C++, because they're far superior to char * pseudostrings, whose disadvantages are myriad (such as segfaults if you don't do things to them that would seem illogical to do to strings, linear time length-finding, non-growability, and so on), and whose only advantages are that they're easy to implement and have very small memory overhead. But you don't have to implement strings yourself, and I don't know about you, but my computer has enough memory that it can spare a few bytes if it makes my life easier.
Re:I have never seem a large GUI scheme app...
on
GCC 2.95 Released
·
· Score: 1
Hmm... well, if I was already off-topic enough to mention the interjection thing, I suppose it can't hurt to be off-topic enough to explain it... =)
I haven't ever used that feature myself, and it is certainly good and probably advisable to write programs that don't use it. I think it's one of those things that you want to avoid if you can, but that can really be a lifesaver every once in a while. A situation I can imagine- say somebody wrote a Car class, and subclassed it to Toyota, Honda, Ford, Chevy, et cetera, and then models for each company, from which you are deriving your instances. Now you realize that you have a need to override a method in the Car class for cars built after 1985- so you'd really like your class hierarchy to have Car on top, with all of the companies models as subclasses of Car, and then NewCar as another class, also with all of the companies underneath. There are two problems, though- first, you're duplicating code for a potentially huge hierarchy, which is never good. Second, you may not have access to the source of the classes you're using, or permission to change them, in which case you're SOL with Java or C++. You could make a NewCar subclass of every model, but then you're duplicating your method a huge number of times, and it's a big pain too. The best solution is just to be able to take an object and figure out dynamically whether it's a Car or a NewCar- at some point after all the fields are set, just say "if you were built after 1985, interject NewCar in between Car and your company."
I should again mention that I'm not a hard-core object-oriented Schemer, so I don't really know if that's the point of it or not, but it does seem that it would be useful occasionally.
(Incidentally, I think JavaScript allows for the same sort of thing. Just kinda funny. I'd hate to think that JavaScript might be the choice of a new generation...)
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
No, I meant what I said. The only way to do generic types for a container in C/C++ without templates (afaik) is by casting a pointer to what you want to store to a void * when you put it into the container, then casting back to a (whatever) * when you take it out. However, C++ won't (and can't) ever check, not even at run-time, to see whether the void * that pop() returned really is an int *, like your cast asserted, or in fact a SuperComplicatedObject *, like it was when you inserted it. That means that you can manufacture huge headaches for yourself, not the least of which are the fact that C++ will happily figure out for you what your SuperComplicatedObject would have been if it were an int, so you'll just see the problem as bizarre run-time behavior that you can't figure out.
If you use STL, you'll try to compile your program, and it will say:
gcc: error in myFabulousProgram.cc line 85: You can't assign an int * the value of a SuperComplicatedObject * without an explicit cast, you bonehead!
Which is a whole lot better.
Templates are good. Void pointers are evil. Think of them as Obi-Wan Kenobi and Darth Vader, respectively.
I agree that the utility of both Swing and STL are hindered by their sometimes awkward syntax. Those two pieces of technology in particular really make me tend to think that the "language of the future" will use first-class functions. After all, Swing's anonymous interface-implementors are just make-believe first-class functions, and the same is true of the function-objects that you have to use in STL. It seems that both of those areas highlight the fact that if you want to have a useful collection of generalized data, you sometimes need to be able to plug in an arbitrary algorithm just as much as you need to be able to plug in an arbitrary datum. From there, first-class functions are a short step. They'd go a long way towards cleaning up the mess that STL (and Swing too, to a lesser extent) can sometimes be.
On the other hand- STL is STILL easier than the alternative, writing your own hash table for every new data type you need to keep in a hash and every possible key you could store that data with. Digging through levels of templates is bad, but you probably don't have to if you want to debug an STL class: in all of my experience with STL, I have never found a serious bug that didn't ultimately turn out to be my own fault. For example, I have certainly had my fair share of data-losing hash maps, and I've learned that you should always look extremely closely at your comparator before you start scouring the STL code and cursing about the library programmers and how they somehow released a hash table that randomly loses data (though I freely admit to jumping directly to step 2 myself- it makes it all the more humiliating later when somebody points out that I'm using '=' instead of '==' or something =]).
That's pretty harsh. On the other hand, it IS true that there is a learning curve to STL, and once you get to the top of that curve, it becomes quite a bit easier to use STL than to make your own versions of everything, because it is really likely that the STL list class, for instance, is more flexible, more robust, and more efficient than the list that you would write in 30 minutes or an hour. While it probably won't be as intuitive for you at first, a little perserverence is all it takes. For a good STL starting point, check out SGI's documentation. It's pretty good. To keep this at least somewhat relevant, I think that despite all of the language-theory arguments against C++, STL and the extremely wide support of C++ practically everywhere make it really useful to know. Is it the best language possible? No. Is it the best language right now? Depends on who you are and what you want to do.
<ASIDE> Someone in this thread mentioned hash maps losing data- sounds very much like a comparator problem. Whoever had that problem should make SURE that the hash map has a working comparator. In my experience, 95% of hash map problems turn out to be a broken comparator. To see if that's the case, you can check to see what's in your hash map with a simple snip of code. Assuming you've typedef'ed your hash map's type as "hash_type": hash_type::iterator i = hash.begin(); while (i != hash.end()) { cout << "Key: " << *i.first() << endl; cout << "Value: " << *i.second() << endl; i++; } </ASIDE>
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
I'd agree with all that with the exception that the templates in the STL are incredibly useful and ought not be avoided.
Amen! Anyone who thinks that STL is useless has obviously never spent 4 hours discovering that they're pushing A pointers onto a stack and casting the void pointers their pop() function returns to B pointers, 10,000 lines and many files away. Compiler errors are your friends!
Re:I have never seem a large GUI scheme app...
on
GCC 2.95 Released
·
· Score: 1
As far as large Scheme apps, Dr. Scheme is one (a Scheme IDE that Rice University puts out- follow the link in my original post), though I don't really know how large "large" is in your estimation. A friend of mine is working on a big graphical theorem prover in Scheme. He's not working on the GUI, but finds Scheme's lambda-expression-esque classes really great. Apparently Scheme allows you to make a function that takes an interface and returns a class that implements that interface. Also it allows you to dynamically (ie at runtime) interject a class in your hierarchy- so if A extends B, but you want to put C in between so that A extends C extends B, you can do that. Pretty cool, imho. He says it makes his work a whole lot easier, even if Scheme is somewhat hard to understand if you come from an imperative background.
Though in all honesty, GUIs are much more easily programmed when you have languages with real first-class functions (eg Python, Scheme).
Of course GUIs can be done other ways, but why would you want to? Speed? Bah. Scheme and Python both run plenty fast enough to handle waiting for you to click on things. Just take the parts that really NEED optimization (which will not be the GUI) and write them in C or assembly. So you get ease of programming with a nice high-level language, and speed where you need it from a low-level language. Don't try to find one language that will do both for you, because you'll probably end up with the worst parts of each rather than the best.
With that said, I should admit that I usually program in C++. What can I say? I don't often program GUIs, and I like to overload operators. "You have no power! I will TELL you what addition is! Hahahahaha!" =)
-jacob
Hmm. I imagine I should air out the asbestos suit right about now...
How can anything be more important to the development of the internet than the RFCs establishing TCP/IP, FTP, IRC, HTTP, telnet, and a variety of other protocols?
Answer: it provides a reason for wanting TCP/IP, FTP, IRC, HTTP, and telnet in the first place.
If you understand, for example, exactly how to implement a CSS Level 2 renderer, but don't understand how the World Wide Web got to the point where people cared about what web pages looked like- regardless of content- enough to want CSS Level 2, you don't understand the most significant aspect of the internet.
It seems to me that while some RFC's, particularly the most important ones, are certainly good candidates for inclusion on a "history of the internet" anthology, the internet transcends in significance the protocols from which it arises, and that fact is what makes it important. Therefore, articles about people are certainly as significant as articles about UDP.
Slashdot Mirror
What you're touching on is the essential problem of AI: nothing that AI does is easy to do for computers. In fact, most things that AI researchers do is ridiculously computationally expensive (you know, 2^100-state optimization problems and the like) and simply cannot be approached by traditional algorithms. What AI researchers give up, explicitly, are the guarantees that you're concerned about. They say, "Well, let's see how well we can do on this problem if we give up the guarantee of completeness." And lo and behold, your 2^100-state problem becomes a lot easier- you can either get the best answer in a trillion years (actually quite a bit longer than that, if I did my math right) or a very good answer in a week.
So the thing is: if you can't live without that guarantee, you probably can't solve your problem at all.
And incidentally, neural nets are, in practice, enormously profitable to use for systems in which there is no standard algorithmic solution. Face recognition, image processing, real-time traffic shaping- bunches of things. Not space-craft flying, though- NASA uses different AI techniques that have much better safety guarantees.
"Overfitting" is the AI terminology. When you do neural networks, you feed the net some set of data that they "learn." Continuously iterating that set, over and over again, will always yield higher and higher results for that set- however, if that set is not completely and utterly representative of the entire set of possible things the net might be asked about when it's finished training, it will have learned too much specific information about the training set (which might just be happenstance- it so happens that 80% of the pictures in the "good guys" set have a pixel of color #09C45A in coordinate (564, 345), while it's only true of 10% of the pictures in your "bad guys" set) to be of use with any other set than yours.
Ha ha... "Not only did Smith fight in Congress for more education funding and prison reform, he also worked with Alan Cox to patch USB support into Linux!"
Katz's description of the "net pol" reminds me a lot of all of the "look at what you could do if only you took advantage of our wonderful technology" that we've heard countless times from countless sources (Jaron Lanier with virtual reality, Bill Gates- time and again- with OLE, multimedia computers and a million other things, Scott McNealy with Java, to name a few). But that argument doesn't really compel anybody- to compel people to use your technology, you need to actually do something compelling. So far, I know of no political "killer app" of the internet, and if there isn't one, it would be dumb of politicians to waste their time campaigning here.
Think about it- yeah, it would be really cool if George W. Bush posted a follow-up to this article, but would you base your vote on that? And even if everybody who read it immediately decided to vote for him, how much does that really buy him? (Not to mention the fact that in popular culture, being a Slashdot denizen might hurt his popularity rather than helping it...)
And in the past, politicians have done that very thing, with little effect. When Bush Sr. was campaigning against Clinton, he answered questions on Prodigy (did do the same thing on AOL?). Did it help? I think the fact that nobody remembers it is answer enough. You might be able to show a tiny effect, but certainly nothing compelling enough to make everyone jump on the bandwagon.
Now, had Clinton and Bush gotten into a Prodigy flame war, that would've been awesome... =)
Hey, that gives me an idea- make everyone a moderator, then combine all the scores with an initially unweighted neural net! If you don't like the way an article was rated, you click a button and say what it should've been rated. Slashdot evolves the perfect moderator for you!
Tee hee...
(actually, that's not such a bad idea, if there were even close to enough computational/storage resources for it...)
Err... lemme guess, you're a C hacker. I find that C hackers are usually the ones who go on and on about how "computers are hard and we shouldn't pretend they're easy." Myself, I prefer Java, Scheme, Perl, Python, and the like, and I think computers are easy and we shouldn't pretend that they're hard.
Of course, I'm not ignorant of the gawdawful complexities of real low-level computer workings. It used to be that computers had to be hard, for that reason- the big bulky computers didn't have any cycles to spare for abstraction. If I remember correctly, you programmed ENIAC by literally wiring the program in to the logical units. And I imagine they'd have killed for assembly language- and why? Because it's easier! It hides away the yuckiness so that nobody but the yuckiness-builder has do deal with it! And it's not even the case that programming assembly vs. running wires is different than editing inittabs (etc.) vs. a cuddly GUI in that in the first case you lose no power, whereas in the second case, you do, because it's not true- guess what? You can't do everything in assembly that you can do by direct wiring- you can only do the sensible things! No dangling wires or outputs hooked up to other outputs by accident- these are the decisions that assembly takes away from the programmer. And a good GUI/installer ought to do the same thing- take away the user's ability to screw up and do something stupid, leaving only the reasonable choices left. That makes everybody's work easier- I don't have to worry with thinking about every little detail, making sure that I have no dangling wires that will make my computer behave stupidly, so I can concentrate on what I want to do.
This has been the trend in computing since the very first days, is still the trend, and is still a good idea. Programming languages, operating systems, applications, input devices even- you name it, it's getting simpler. And everyone benefits from it- I promise you would not be smugly posting about how the hoi polloi shouldn't be afforded a "dumbed down" version of your operating system if someone hadn't first "dumbed down" computing to the point where the outputs of billions of NAND gates, themselves "dumbed down" versions of NMOS and PMOS (if memory serves), got interpreted all the way into Slashdot.
That idea is called abstraction. Abstraction is fundamental to computer science and everything else that has to do with computing at all. Abstraction is the reason why computers are useful (bold claim alert!). Lack of abstraction is what makes computing difficult. For instance, the reason why you may think that "computers are hard" is that UNIX is complicated- but that doesn't prove that computers are hard at all. UNIX is complicated because UNIX is a crappy operating system that does a very poor job of abstraction. It may be the best we have, but that doesn't mean that dozens upon dozens of illogical, poorly-documented, ad-hoc systems slapped together are a blessing from above. (Which is why Windows is even worse, by the way- I consider the OS choice much less a question of "which is the best OS?" than of "which OS sucks the least?")
I'm not trying to say that all abstractions are equally good, and I'm certainly not trying to claim that Windows is better than Linux because it hides more from the user- all I'm saying is that it not true that computer ease-of-use is a myth, nor is it reasonable to say that adding a layer of abstraction that hides bad ideas from novice users
is a bad thing. I actually think the cool thing about Linux is that it lets you strip away some of those layers when you don't want them. But guess what? I use X-Windows, and I use Netscape- I never slashdot by telnetting to 209.207.224.40 port 80 and writing raw HTTP. And I would not be happy if someone told me to and said, "Netscape is for drooling idiots who don't want to think for themselves or learn how their computers work." For the same reason, I would be upset if someone told me that I shouldn't want my favorite OS to be easy to use on the grounds that easy things are for morons, which is what you suggested.
Wow. This post is really long and rambling. I guess this must be something I'm interested in... =)
Nethack is loads of fun. However, the best has got to be ADOM. It has many of the familiar "Rogue-like" game qualities, but feels more like a pencil-and-paper RPG than any of the others (IMHO)- there are multiple dungeons, quests, etc. I have lost far more hours than I care to admit trying to beat that game...
There are some interesting projects for UIs intuitive enough that manuals would probably be pretty much useless. Think Star Trek computers.
"Computer, buy me the cheapest airline tickets to Maui for September."
"How long would you like to stay?"
"Ummm... a couple weeks, I guess."
"Very well. I have a profile that will cost $3,000, meals included."
"Yikes! That's too much!"
"Very well. I have a profile that will cost $1,500, meals included."
"That's better. Place the order."
Notice that nowhere does the computer ever say, "Please read the man page and talk to me with proper syntax."
Oh, and this isn't science fiction, either- MIT, for example, is working on exactly the system I describe right now (they're calling it Oxygen).
Your toothbrush keeps talking about the evils of eating meat? Bad ass! Guess it must be bad for the bristles or something...
=)
Seriously- hackers come in all shapes, sizes, and affiliations. One would be wise not to create the equation "hip punk kid == skript kiddy && dull boring geek == Real Hacker". The best programmers I've met have all been really interesting people who were quite different from each other.
I think you missed the cool part of the research- Thompson didn't understand what was going on because what was going on was fundamentally different from how the electrical engineers do things. In the Discover article, they went into more detail on that point. Apparently, some of the designs that the GA evolved contained components that were entirely unconnected to the main circuitry, but that couldn't be taken out without making the chip stop working.
And the point about software being too limiting: they're talking about efficiency. If you want to solve the problem using software, think about all the gates you have to use! It's not that it can't be done, but if you can do it with 100 gates in hardware, that's probably better than a 10,000+ gate software solution. Particularly when no one has ever been able to do it with less than 1,000 gates using traditional techniques.
You can't make a creative product if you don't pay people to have fun. You end up with just plain product, IMHO.
Sigh... his point is that "business" really sucks for an industry that is supposed to be creative. That is- just because you will buy PopularProgram version 26 doesn't mean it will be entertaining to program PopularProgram version 26 (or CopyProgram version 1, for that matter, either). While it seems to be sound from a profitibility standpoint to hack away at the same old thing, because the same old thing sells, it isn't after a while because your programmers don't enjoy what they're doing. I would rather have a fresh, exciting program that the programmers really believed in than one in which they didn't.
That said, I don't really think that any of the games you mentioned suffer from that syndrome- reading interviews with the Unreal, Half-Life, and Quake people makes it abundantly clear that the people on those teams really believed that they were programming the coolest game ever, and all of their managements seemed to just get out of their way and let them do what they were going to do (would you second-guess John Carmack?).
From that perspective, we have to give Ballmer some credit: it is unusual for people who hold such incredibly irrationally negative opinions about things to go so far in realizing their usefulness. So I will say again, we should not assassinate the idea just because Ballmer said it. Sure, he's not the first to come up with the idea of on-demand programs. Us geeky-types would certainly be able to point to a few innovations that predate Steve's by quite a wide margin (Java being the clearest example I can think of). We also justifiably mistrust Microsoft's motivations in pushing on-demand software, as we probably should. But so what? That doesn't mean it's a bad idea, which is what most people around here seem to be saying.
Doesn't that strike you as just a little extreme? Anyone who makes a living writing software wants there to be some kind of pricetag for software, or else they're working for free. That doesn't necessarily mean today's pay-per-copy model of software, but the argument that one should never pay any money for software is about as reasonable as saying that no one should pay for a book, or the food a chef cooks, or any other product of intellectual labor.
In other words: saying "People shouldn't rent programs, they should get them for free" is saying "programmers shouldn't get money every time someone uses their program, because they should do it for free." Speaking as a programmer: I would certainly write some programs for free. The database system I'm working on now is NOT one of them. That doesn't mean that I'm endorsing rental as the way to go (but see my earlier post), just that a radically free software paradigm (ie no money anywhere) only works if the whole society is radically free.
(A bit far afield from the topic of discussion, I'm afraid. I promise to do better next time.)
A general response to most of the posts on this topic: everyone seems to missing the point. While we are focusing on evil domination or tyrannical pricing schemes or lots of inconvenience, we are missing the point that it is becoming increasingly important for computers to be able to load software on demand. That is really all the article was saying, plus a little indirection because of Ballmer's utter Microsoftism. And it is true and pretty important for those of us who pay a lot of attention to software and/or hardware to notice that the hot things to have are portable devices and wireless networks to connect them. It makes perfect sense, therefore, to have a huge library of software sitting on a server somewhere where storage is cheap, but available on demand to all of the network devices, where storage is expensive.
That doesn't mean that devices shouldn't be allowed to store programs or data permanently on their own storage. It just means that for programs of occasional use, it is more expedient to load them occasionally and use them right away than it is to have them sit around unused but taking up important storage space. One can imagine a person's personal computer-watch thingy having OS software always loaded, and then just enough space to store one user program. When the user wants to run a program, the watch downloads it off the app server and executes it. When he quits or switches programs, it unloads the program so it can put something else in.
Now, the logical extension of that is for companies to run their own app servers and charge users for accounts. Probably a flat per-month fee would be workable- wouldn't you pay $15/month or some other reasonable fee to have on-demand access to, for instance, a huge library of database tools that you could transparently install and run on your super-portable computer watch without ever having to worry about making sure that everything was upgraded properly, that everything was set up right (installation is transparent, remember?), or that you would run out of space? Not to mention the fact that you'd be paying far less than the purchase price of the apps you get access to...
It seems pretty clear that on-demand software loading is going to be big, and that it will be a good thing. With that said, though, Microsoft is still being stupid: in order to write good on-demand software, it will need to be a) small, b) efficient, c) standards-compliant, and d) installable/uninstallable immediately and without a trace. Microsoft gets about a 60% on part D, and about 0% on parts A, B, and C. =)
Actually, the STL isn't broken at all because of that inconsistency. What's broken is the C-ism of using char *'s as strings. The hash table hashes char *'s based on all the data from the address until the next '\0' not because the programmers were morons who didn't know what they were doing, but because in C people use pointers to characters as an expedient hack for a string data type, which C is sadly lacking. C++ with the STL fixes that with the string class, but if you insist on giving a char * a meaning that it doesn't have naturally, then you don't have the right to get upset when the programmers of your tools make concessions so that you can use it with a minimum of hassle.
If it bothers you that you're really doing a pointer comparison when you say (charPtrA == charPtrB), the solution is to use STL strings instead, which hash just fine with no inconsistency of hashing vs. equality (that is, *stlStringPtrA == *stlStringPtrB if they have the same string value, and hashValue(*stlStringPtrA) == hashValue(*stlStringPtrB) as well). In fact, you should use STL strings for everything anyway if you're programming in C++, because they're far superior to char * pseudostrings, whose disadvantages are myriad (such as segfaults if you don't do things to them that would seem illogical to do to strings, linear time length-finding, non-growability, and so on), and whose only advantages are that they're easy to implement and have very small memory overhead. But you don't have to implement strings yourself, and I don't know about you, but my computer has enough memory that it can spare a few bytes if it makes my life easier.
Hmm... well, if I was already off-topic enough to mention the interjection thing, I suppose it can't hurt to be off-topic enough to explain it... =)
I haven't ever used that feature myself, and it is certainly good and probably advisable to write programs that don't use it. I think it's one of those things that you want to avoid if you can, but that can really be a lifesaver every once in a while. A situation I can imagine- say somebody wrote a Car class, and subclassed it to Toyota, Honda, Ford, Chevy, et cetera, and then models for each company, from which you are deriving your instances. Now you realize that you have a need to override a method in the Car class for cars built after 1985- so you'd really like your class hierarchy to have Car on top, with all of the companies models as subclasses of Car, and then NewCar as another class, also with all of the companies underneath. There are two problems, though- first, you're duplicating code for a potentially huge hierarchy, which is never good. Second, you may not have access to the source of the classes you're using, or permission to change them, in which case you're SOL with Java or C++. You could make a NewCar subclass of every model, but then you're duplicating your method a huge number of times, and it's a big pain too. The best solution is just to be able to take an object and figure out dynamically whether it's a Car or a NewCar- at some point after all the fields are set, just say "if you were built after 1985, interject NewCar in between Car and your company."
I should again mention that I'm not a hard-core object-oriented Schemer, so I don't really know if that's the point of it or not, but it does seem that it would be useful occasionally.
(Incidentally, I think JavaScript allows for the same sort of thing. Just kinda funny. I'd hate to think that JavaScript might be the choice of a new generation...)
If you use STL, you'll try to compile your program, and it will say:
Which is a whole lot better.
Templates are good. Void pointers are evil. Think of them as Obi-Wan Kenobi and Darth Vader, respectively.
I agree that the utility of both Swing and STL are hindered by their sometimes awkward syntax. Those two pieces of technology in particular really make me tend to think that the "language of the future" will use first-class functions. After all, Swing's anonymous interface-implementors are just make-believe first-class functions, and the same is true of the function-objects that you have to use in STL. It seems that both of those areas highlight the fact that if you want to have a useful collection of generalized data, you sometimes need to be able to plug in an arbitrary algorithm just as much as you need to be able to plug in an arbitrary datum. From there, first-class functions are a short step. They'd go a long way towards cleaning up the mess that STL (and Swing too, to a lesser extent) can sometimes be.
On the other hand- STL is STILL easier than the alternative, writing your own hash table for every new data type you need to keep in a hash and every possible key you could store that data with. Digging through levels of templates is bad, but you probably don't have to if you want to debug an STL class: in all of my experience with STL, I have never found a serious bug that didn't ultimately turn out to be my own fault. For example, I have certainly had my fair share of data-losing hash maps, and I've learned that you should always look extremely closely at your comparator before you start scouring the STL code and cursing about the library programmers and how they somehow released a hash table that randomly loses data (though I freely admit to jumping directly to step 2 myself- it makes it all the more humiliating later when somebody points out that I'm using '=' instead of '==' or something =]).
That's pretty harsh.
On the other hand, it IS true that there is a learning curve to STL, and once you get to the top of that curve, it becomes quite a bit easier to use STL than to make your own versions of everything, because it is really likely that the STL list class, for instance, is more flexible, more robust, and more efficient than the list that you would write in 30 minutes or an hour. While it probably won't be as intuitive for you at first, a little perserverence is all it takes. For a good STL starting point, check out SGI's documentation. It's pretty good.
To keep this at least somewhat relevant, I think that despite all of the language-theory arguments against C++, STL and the extremely wide support of C++ practically everywhere make it really useful to know. Is it the best language possible? No. Is it the best language right now? Depends on who you are and what you want to do.
<ASIDE>
Someone in this thread mentioned hash maps losing data- sounds very much like a comparator problem. Whoever had that problem should make SURE that the hash map has a working comparator. In my experience, 95% of hash map problems turn out to be a broken comparator.
To see if that's the case, you can check to see what's in your hash map with a simple snip of code. Assuming you've typedef'ed your hash map's type as "hash_type":
hash_type::iterator i = hash.begin();
while (i != hash.end())
{
cout << "Key: " << *i.first() << endl;
cout << "Value: " << *i.second() << endl;
i++;
}
</ASIDE>
Amen! Anyone who thinks that STL is useless has obviously never spent 4 hours discovering that they're pushing A pointers onto a stack and casting the void pointers their pop() function returns to B pointers, 10,000 lines and many files away. Compiler errors are your friends!
As far as large Scheme apps, Dr. Scheme is one (a Scheme IDE that Rice University puts out- follow the link in my original post), though I don't really know how large "large" is in your estimation. A friend of mine is working on a big graphical theorem prover in Scheme. He's not working on the GUI, but finds Scheme's lambda-expression-esque classes really great. Apparently Scheme allows you to make a function that takes an interface and returns a class that implements that interface. Also it allows you to dynamically (ie at runtime) interject a class in your hierarchy- so if A extends B, but you want to put C in between so that A extends C extends B, you can do that. Pretty cool, imho. He says it makes his work a whole lot easier, even if Scheme is somewhat hard to understand if you come from an imperative background.
Though in all honesty, GUIs are much more easily programmed when you have languages with real first-class functions (eg Python, Scheme).
Of course GUIs can be done other ways, but why would you want to? Speed? Bah. Scheme and Python both run plenty fast enough to handle waiting for you to click on things. Just take the parts that really NEED optimization (which will not be the GUI) and write them in C or assembly. So you get ease of programming with a nice high-level language, and speed where you need it from a low-level language. Don't try to find one language that will do both for you, because you'll probably end up with the worst parts of each rather than the best.
With that said, I should admit that I usually program in C++. What can I say? I don't often program GUIs, and I like to overload operators. "You have no power! I will TELL you what addition is! Hahahahaha!" =)
-jacob
Hmm. I imagine I should air out the asbestos suit right about now...
Question:
Answer: it provides a reason for wanting TCP/IP, FTP, IRC, HTTP, and telnet in the first place.
If you understand, for example, exactly how to implement a CSS Level 2 renderer, but don't understand how the World Wide Web got to the point where people cared about what web pages looked like- regardless of content- enough to want CSS Level 2, you don't understand the most significant aspect of the internet.
It seems to me that while some RFC's, particularly the most important ones, are certainly good candidates for inclusion on a "history of the internet" anthology, the internet transcends in significance the protocols from which it arises, and that fact is what makes it important. Therefore, articles about people are certainly as significant as articles about UDP.