The Turing test is, as you pointed out, an example of the sort of AI approach I mentioned, but I think it's testing for something slightly off what AI should really be looking at. It's not testing "is something intelligent," but is instead testing "is something intelligent in the same way humans are intelligent?" That is, it has to be "smart" when humans are and be dumb where humans are. If asked a complex math question, it has to pretend not to be able to compute it instantly, etc. Basically, it requires perfect modeling of human responses, which seems to be missing the point in a way; it should be possible to create an intelligent machine that is intelligent in some way differing from humans. Though I suppose the reason Turing picked it is because of, as was mentioned elsewhere here, the axiomatic assumption that humans are intelligent. But in any case, I think it's somewhat akin to making the goal of aeronautical engineering "make an artificial bird that flies exactly like a crow does, in fact so exactly like a crow that it even fools other crows into thinking it's a crow."
Part of my argument I suppose was focusing on whether there was a meaningful difference between (1) and (2). Is there something that it is to "think" or "possess intelligence" beyond merely acting intelligently? If not, (2) is equivalent to (1). If so, what is the difference?
I think the axiomatic assumption that people think is part of the problem. If we cannot say why the claim is that people think, it's easy to just debunk any AI claims by outright statement. "People think, while computers are just machines." You can't really make any progress in the face of that.
That's part of my problem with Searle's Chinese Room thought experiment. He's saying that an automaton responding to Chinese following rules would not "understand" Chinese in the way a human who speaks the language would. But this is presupposing that the way a human who "understands" Chinese does so is not through just a very long list of rules coded in neurons, which I consider to be a rather controversial assumption.
In short, a lot of anti-AI arguments seem to start from the premise that humans are not essentially biological computers; with that premise, of course you can debunk AI. A lot of AI researchers have grown tired of the argument entirely, and instead of responding to the arguments, have just resorted to saying "ok fine, you're right, we can't make 'really' intelligent computers, but what we can do is make computers that do the same thing an intelligent person would do, which is good enough for us." The idea here being that if a computer can eventually diagnose diseases better than a doctor, pilot a plane better than a pilot, translate Russian better than a bilingual speaker, and so on, it doesn't really matter if you think it's "really" intelligent or not, because it's doing all the things an intelligent thing would do.
As a final comment, I'd agree with the AI being not that fundamentally different from large software systems. The difference is basically one of focus -- AI has been focusing on what it means to "act intelligently" for decades, whereas much CS and software engineering was focused on more low-level details (like how memory or register allocation works). At one point, the division was more clear -- AI people did stuff like write checkers programs that learned from their mistakes, which was not something any CS person not in AI would do. The fields are increasingly blending, and a lot of stuff from engineering disciplines like control logic (how to "intelligently" control chemical plants, for example) is overalapping with AI research. Part of this is because a lot of AI ideas have actually matured enough to become usable in practice.
As a notation for FSA diagramming, statecharts actually are pretty good. They have some handy shorthands that factor out common parts of the state to keep diagrams from blowing up to enormous numbers of states, as would happen if you enumerated all possible states as in a traditional FSA diagram. Sort of a hierarchical way of doing FSA diagramming, which is well-suited to some problems.
A lot of people in Canada and the UK still use imperial units for many things. You've got pints of beer nearly everywhere, for example, and many people in Canada will use Fahrenheit temperatures. The only reason metric is as popular as it is is heavy-handed government mandates; you're not allowed to use Imperial units for many things even if you wanted to, which is bullshit.
If he were taking money to implement DARPA-requested features, I could see the issue. However, if all he's doing is taking no-strings-attached money to do work he'd be doing anyway, I don't see the moral conundrum. If there are any negative effects of his work (OpenBSD being used by TIA, for example), they'd exist even if he wasn't funded by DARPA; the only solution would be to stop developing OpenBSD entirely, not to keep doing it without DARPA funding. So insofar as DARPA funding doesn't change anything, I'd say take it. Plus, at least it ensures that this portion of DARPA's budget goes to something worthwhile and unobjectionable, rather than letting them keep it to spend on something else.
I do in fact use ncftp. I do also, however, think it would be helpful to have a good GUI ftp client for Linux.
ncftp lacks a few features of modern Windows ftp clients as well (besides being CLI). In particular, it has extremely poor queue management. You either have to download a single file (with get) or directory (with get -R), or you have to send them to a background process (with bgget or bgget -R). The background process works somewhat like a queue, but not entirely; if the server is busy, for example, it'll try connecting for each file on the queue. If you have 50 files queued from one server, it'll basically hammer the server, which will often get you banned. The proper behavior, which Windows clients use, is to try once every x seconds (usually 45 or 60) per server, not per file, and not try more than one connection to a server at a time.
I use Linux (Debian) nearly exclusively, but I can definitely see where she's coming from. If I want to do pretty much anything I need to read a bunch of documentation and edit config files. Now this isn't too difficult if you know what you're doing and have spare time, but I can see how most people would find it unacceptable. In Windows and Mac OS, if you want to do something like, say, burn a CD, you just install the necessary software and it Just Works. In Linux you have to find a cd burning HOWTO and figure out how to change permissions so the cd drive is writable by your user (or set the suid bit on your cdwriting software).
My biggest pet peeve though? There don't appear to be any good GUI ftp clients for Linux. There's gftp, which is lacking lots of features and is crashy, and there's something-or-other from the KDE people that's not so good either. Nothing approaching Windows' BulletProof FTP or SmartFTP. So I use ncftp, which is a CLI interface. Works for me, but I doubt it would for most casual computer users.
There's absolutely no reason to stick with stable unless you want a 99.9999% proven to work and free of major problems system. It's somewhat akin to running the stable branch of FreeBSD, but probably even more conservative (Debian has a 2-year release cycle). For most systems, you should almost certainly run at least testing. It only has packages that have been tested for a few weeks (yes, despite its name, this is where packages go after they've already been tested for a bit) and pretty much always works. There hasn't been major breakage in testing for quite some time. For most home users, especially if you know what you're doing, you should run unstable. Despite the name again, it's really quite stable. If packages are broken in any significant way, bugs get filed and a fix is usually up within a day or two, sometimes within hours. I haven't had any major breakage in a few years of running it, despite a gnome1->gnome2 move and a gcc2.95->gcc3.2 move.
As ubiquitous as its usage might seem to us, Google is only used by somewhere around 30% of regular internet users, whose numbers are put at 134 million in the US. That makes google users account for approximately 13% of the US population. The rest of the 87% never use google. Even of the 13%, many probably use it only rarely, or only for school/etc. research. Certainly only a very small percentage of people (slashdotters, basically) are influenced enough by google that it would define their speech patterns. Social influence at school/work/etc. and television/radio are much more likely to do that for the vast majority of people.
Winamp and XMMS can figure out the length of a VBR mp3 if there is a Xing VBR header at the beginning of the file that gives the average bitrate (then they just divide filesize by average bitrate). Many VBR files (probably 10% or so of the VBR files on p2p networks) are either missing the Xing header or have a corrupted one (usually this is because it's partially overwritten by faulty id3 taggers). In those cases, both Winamp and XMMS display wrong track length based on the bitrate of the first block, which is updated as more blocks are read (the average is continually updated). There's no other real way to do it other than scanning all the blocks in the mp3 and computing the average bitrate first...
These students are operating commonly available software packages that basically crawl open NetBIOS shares ("Windows Filesharing") on the university's LAN and produce a searchable index. This includes absolutely anything that anyone on the network is publically sharing. Some of this is data (dumps of physics data, for example), some of it is copyrighted music and movies, some of it is student-produced music and movies (e.g. a project for a film class), etc. The people operating the search engine have no control over what people choose to put on open shares.
When I'm around home, I'll visit other places, usually on a recommendation. But if I'm travelling, it'll be McDonald's or Burger King or some similar major chain. Why? Because they are consistently sufficient. You get the food you expect; it's not going to be much worse than you expected, and more importantly it's unlikely to get you sick. Picking some random non-chain hamburger place in a town you're unfamiliar with is far more risky.
Congress can impeach them if it's determined they did something incompatible with their office (the conditions are similar to those that would warrant a president's impeachment). This almost never happens, which is what makes the judiciary fairly independent. You can impeach a judge if he accepts bribes, for example, but not if he makes terrible decisions you hate.
In standard Condorcet, the only clear winner is one who wins every single pairwise election, not just the one with the most victories. That is, he is preferred to every other candidate, so there is no way you could argue that another candidate would be better suited for the job.
While having the most victories is a possible gauge, one major problem (among others) is that it doesn't weigh victories by importance. For example, if Bush is preferred to 12 minor candidates, and Gore is preferred only to Bush and Buchanan, Bush wins, because he has 12 victories versus 2, which is clearly not good.
Another possible tie breaker is to first find a victory cycle; that is, a set of candidates who are all preferred to every candidate outside the set, but among whom there is no single candidate preferred to all others. Then among this cycle, the tie is broken by some method; a common one (and what Debian seems to be using) is to prefer the candidate with the smallest loss margin. The rationale here is that we'll have to make at least one "wrong" choice (whoever we pick will lose a head-to-head matchup with at least one other candidate), but we should pick the candidate who makes this choice the least wrong. For example, if one candidate loses one head-to-head matchup 90-10, and another loses two matchups, each 55-45, we should prefer the 55-45, because he comes closest to winning all the matchups.
The end result of all this is someone who is either preferred to all other candidates or at least the closest to that that's possible.
If you mean that it is in theory possible to write faster programs in C than in higher-level languages, or that it is possible in theory to write faster programs in assembler than C, then you are correct. However, that's not really interesting, since in many cases it's not feasible (perhaps just on this side of impossible). A compiler can simply optimize large blocks of code better than you can, so for sufficiently large apps, the C version will almost always be faster than the assembler version, because it can find neat optimizations you didn't think of. Already many C compilers ignore the 'register' keyword, because they know they can do a better job allocating registers than you can. Similarly, garbage-collected languages are becoming competitive performance-wise with explicit memory management, because they can just keep track of huge numbers of allocations better than the programmer can, and exploit redundancies and opportunities for optimization across non-local areas of code.
On most platforms, assembly is not in practice faster than higher-level languages. If, for example, you were to actually manage to write an office suite in assembly, in addition to being wholly unmaintainable, it'd likely run slower than the higher-level version. This is because once things get to a certain size, the compiler is simply better at optimizing than the human is. A human can't scan millions of lines of code per second for redundancies and optimizations, and isn't good at judging on the fly which optimizations are worth doing and which aren't. This grows increasingly true as you get into fairly complex architectures features, like filling branch delay slots on the SPARC or ordering instructions for the IA64's pipelining.
This is also increasingly true of using higher-level languages than C. C may allow simple things to go faster, but higher-level languages often allow complex programs to be faster on the whole because they provide guarantees that allow for optimizations a C compiler can't make (that C allows pointer arithmetic and arbitrarily-aliased pointers is a big problem for optimizers, for example). To take a trivial example, consider the following two ways of traversing an integer array:
1. for(int x = 0; x < length; x++) foo(array[x]); 2. for(int *x = array; x < array + length; x++) foo(x);
(1. uses indexing and 2. uses pointer arithmetic). Most C programmers would prefer the second, considering it "more efficient." The idea is that since you're walking through the array you keep adding sizeof(int) instead of starting at the beginning and adding an offset each time. This is especially true, it's claimed, if you access the value multiple times each iteration: instead of computing the offset to array[x] each time, you have a direct pointer to it that you just dereference. And this all used to be true. However, most (though not all) of the time, with modern C compilers 1. will actually be faster, because it allows the compiler to do some neat optimizations that it can't do with 2.
It's hands-down the best way of doing animation on the internet. (Comparatively) good scripting language, vector graphics, good client support, etc. Even Tim Burton uses it for his animations.
I do agree that E17 development has seemed pretty "if you're not one of the core developers, you shouldn't be touching it," but it's moving away from that. The post linked to in this story is a good example of an increasing openness and attention to at least some documentation. A lot of documentation has appeared on enlightenment.org in the past month or two as well; the relatively new build notes are particularly useful when trying to build from CVS.
stick to e16 for a wm, but e17 has nice stuff
on
State of the E-nion
·
· Score: 5, Informative
If you want a working window manager, stick to e16; e17 isn't really being actively worked on as a window manager yet, and doesn't have many features. The work is on a lot of useful backend stuff; the joke is that once the backend is done, the window manager will be five lines of code. Take a look at the components though. Many of them are in a very good state, and the E folk are to be commended for their excellent modular development -- many of these components are already being used by other projects (imlib2 in particular), and many of the others either are or soon will be in shape to be used in other projects too.
Of course perhaps I'm a bit biased, since E16 is still my favorite window manager (a better way to view/edit remembered window/app attributes being my only real feature request), but I think the E17 team is doing a good job contributing to the overall Free Software codebase. And though it's a bit frustrating that E17 is taking so long, reading through the components is impressive -- everything is being engineered carefully. While many window managers hack things in, everything in E -- from the theming engine to the window decorations -- is carefully designed with a clean interface. Should be impressive when it's done.
My only main worry about E17 is that it seems to be going desktop-environment-ish, a la GNOME/KDE, which I really can't stand. Hopefully we'll be able to turn all that off.
Slashdot Mirror
The Turing test is, as you pointed out, an example of the sort of AI approach I mentioned, but I think it's testing for something slightly off what AI should really be looking at. It's not testing "is something intelligent," but is instead testing "is something intelligent in the same way humans are intelligent?" That is, it has to be "smart" when humans are and be dumb where humans are. If asked a complex math question, it has to pretend not to be able to compute it instantly, etc. Basically, it requires perfect modeling of human responses, which seems to be missing the point in a way; it should be possible to create an intelligent machine that is intelligent in some way differing from humans. Though I suppose the reason Turing picked it is because of, as was mentioned elsewhere here, the axiomatic assumption that humans are intelligent. But in any case, I think it's somewhat akin to making the goal of aeronautical engineering "make an artificial bird that flies exactly like a crow does, in fact so exactly like a crow that it even fools other crows into thinking it's a crow."
Part of my argument I suppose was focusing on whether there was a meaningful difference between (1) and (2). Is there something that it is to "think" or "possess intelligence" beyond merely acting intelligently? If not, (2) is equivalent to (1). If so, what is the difference?
I think the axiomatic assumption that people think is part of the problem. If we cannot say why the claim is that people think, it's easy to just debunk any AI claims by outright statement. "People think, while computers are just machines." You can't really make any progress in the face of that.
That's part of my problem with Searle's Chinese Room thought experiment. He's saying that an automaton responding to Chinese following rules would not "understand" Chinese in the way a human who speaks the language would. But this is presupposing that the way a human who "understands" Chinese does so is not through just a very long list of rules coded in neurons, which I consider to be a rather controversial assumption.
In short, a lot of anti-AI arguments seem to start from the premise that humans are not essentially biological computers; with that premise, of course you can debunk AI. A lot of AI researchers have grown tired of the argument entirely, and instead of responding to the arguments, have just resorted to saying "ok fine, you're right, we can't make 'really' intelligent computers, but what we can do is make computers that do the same thing an intelligent person would do, which is good enough for us." The idea here being that if a computer can eventually diagnose diseases better than a doctor, pilot a plane better than a pilot, translate Russian better than a bilingual speaker, and so on, it doesn't really matter if you think it's "really" intelligent or not, because it's doing all the things an intelligent thing would do.
As a final comment, I'd agree with the AI being not that fundamentally different from large software systems. The difference is basically one of focus -- AI has been focusing on what it means to "act intelligently" for decades, whereas much CS and software engineering was focused on more low-level details (like how memory or register allocation works). At one point, the division was more clear -- AI people did stuff like write checkers programs that learned from their mistakes, which was not something any CS person not in AI would do. The fields are increasingly blending, and a lot of stuff from engineering disciplines like control logic (how to "intelligently" control chemical plants, for example) is overalapping with AI research. Part of this is because a lot of AI ideas have actually matured enough to become usable in practice.
As a notation for FSA diagramming, statecharts actually are pretty good. They have some handy shorthands that factor out common parts of the state to keep diagrams from blowing up to enormous numbers of states, as would happen if you enumerated all possible states as in a traditional FSA diagram. Sort of a hierarchical way of doing FSA diagramming, which is well-suited to some problems.
A lot of engineering still uses units like lb-ft for torque, for example. Imperial units are pretty common in architecture and construction as well.
A lot of people in Canada and the UK still use imperial units for many things. You've got pints of beer nearly everywhere, for example, and many people in Canada will use Fahrenheit temperatures. The only reason metric is as popular as it is is heavy-handed government mandates; you're not allowed to use Imperial units for many things even if you wanted to, which is bullshit.
When I read that headline I thought "what's so hard about using Mozilla in testing? Just apt-get install mozilla, same as in woody and sid..."
If he were taking money to implement DARPA-requested features, I could see the issue. However, if all he's doing is taking no-strings-attached money to do work he'd be doing anyway, I don't see the moral conundrum. If there are any negative effects of his work (OpenBSD being used by TIA, for example), they'd exist even if he wasn't funded by DARPA; the only solution would be to stop developing OpenBSD entirely, not to keep doing it without DARPA funding. So insofar as DARPA funding doesn't change anything, I'd say take it. Plus, at least it ensures that this portion of DARPA's budget goes to something worthwhile and unobjectionable, rather than letting them keep it to spend on something else.
I do in fact use ncftp. I do also, however, think it would be helpful to have a good GUI ftp client for Linux.
ncftp lacks a few features of modern Windows ftp clients as well (besides being CLI). In particular, it has extremely poor queue management. You either have to download a single file (with get) or directory (with get -R), or you have to send them to a background process (with bgget or bgget -R). The background process works somewhat like a queue, but not entirely; if the server is busy, for example, it'll try connecting for each file on the queue. If you have 50 files queued from one server, it'll basically hammer the server, which will often get you banned. The proper behavior, which Windows clients use, is to try once every x seconds (usually 45 or 60) per server, not per file, and not try more than one connection to a server at a time.
I use Linux (Debian) nearly exclusively, but I can definitely see where she's coming from. If I want to do pretty much anything I need to read a bunch of documentation and edit config files. Now this isn't too difficult if you know what you're doing and have spare time, but I can see how most people would find it unacceptable. In Windows and Mac OS, if you want to do something like, say, burn a CD, you just install the necessary software and it Just Works. In Linux you have to find a cd burning HOWTO and figure out how to change permissions so the cd drive is writable by your user (or set the suid bit on your cdwriting software).
My biggest pet peeve though? There don't appear to be any good GUI ftp clients for Linux. There's gftp, which is lacking lots of features and is crashy, and there's something-or-other from the KDE people that's not so good either. Nothing approaching Windows' BulletProof FTP or SmartFTP. So I use ncftp, which is a CLI interface. Works for me, but I doubt it would for most casual computer users.
There's absolutely no reason to stick with stable unless you want a 99.9999% proven to work and free of major problems system. It's somewhat akin to running the stable branch of FreeBSD, but probably even more conservative (Debian has a 2-year release cycle). For most systems, you should almost certainly run at least testing. It only has packages that have been tested for a few weeks (yes, despite its name, this is where packages go after they've already been tested for a bit) and pretty much always works. There hasn't been major breakage in testing for quite some time. For most home users, especially if you know what you're doing, you should run unstable. Despite the name again, it's really quite stable. If packages are broken in any significant way, bugs get filed and a fix is usually up within a day or two, sometimes within hours. I haven't had any major breakage in a few years of running it, despite a gnome1->gnome2 move and a gcc2.95->gcc3.2 move.
I spent nearly all my time on the computer when I was a kid, and it's made me socially confident and popular with the ladies!
As ubiquitous as its usage might seem to us, Google is only used by somewhere around 30% of regular internet users, whose numbers are put at 134 million in the US. That makes google users account for approximately 13% of the US population. The rest of the 87% never use google. Even of the 13%, many probably use it only rarely, or only for school/etc. research. Certainly only a very small percentage of people (slashdotters, basically) are influenced enough by google that it would define their speech patterns. Social influence at school/work/etc. and television/radio are much more likely to do that for the vast majority of people.
Winamp and XMMS can figure out the length of a VBR mp3 if there is a Xing VBR header at the beginning of the file that gives the average bitrate (then they just divide filesize by average bitrate). Many VBR files (probably 10% or so of the VBR files on p2p networks) are either missing the Xing header or have a corrupted one (usually this is because it's partially overwritten by faulty id3 taggers). In those cases, both Winamp and XMMS display wrong track length based on the bitrate of the first block, which is updated as more blocks are read (the average is continually updated). There's no other real way to do it other than scanning all the blocks in the mp3 and computing the average bitrate first...
These students are operating commonly available software packages that basically crawl open NetBIOS shares ("Windows Filesharing") on the university's LAN and produce a searchable index. This includes absolutely anything that anyone on the network is publically sharing. Some of this is data (dumps of physics data, for example), some of it is copyrighted music and movies, some of it is student-produced music and movies (e.g. a project for a film class), etc. The people operating the search engine have no control over what people choose to put on open shares.
When I'm around home, I'll visit other places, usually on a recommendation. But if I'm travelling, it'll be McDonald's or Burger King or some similar major chain. Why? Because they are consistently sufficient. You get the food you expect; it's not going to be much worse than you expected, and more importantly it's unlikely to get you sick. Picking some random non-chain hamburger place in a town you're unfamiliar with is far more risky.
Congress can impeach them if it's determined they did something incompatible with their office (the conditions are similar to those that would warrant a president's impeachment). This almost never happens, which is what makes the judiciary fairly independent. You can impeach a judge if he accepts bribes, for example, but not if he makes terrible decisions you hate.
In standard Condorcet, the only clear winner is one who wins every single pairwise election, not just the one with the most victories. That is, he is preferred to every other candidate, so there is no way you could argue that another candidate would be better suited for the job.
While having the most victories is a possible gauge, one major problem (among others) is that it doesn't weigh victories by importance. For example, if Bush is preferred to 12 minor candidates, and Gore is preferred only to Bush and Buchanan, Bush wins, because he has 12 victories versus 2, which is clearly not good.
Another possible tie breaker is to first find a victory cycle; that is, a set of candidates who are all preferred to every candidate outside the set, but among whom there is no single candidate preferred to all others. Then among this cycle, the tie is broken by some method; a common one (and what Debian seems to be using) is to prefer the candidate with the smallest loss margin. The rationale here is that we'll have to make at least one "wrong" choice (whoever we pick will lose a head-to-head matchup with at least one other candidate), but we should pick the candidate who makes this choice the least wrong. For example, if one candidate loses one head-to-head matchup 90-10, and another loses two matchups, each 55-45, we should prefer the 55-45, because he comes closest to winning all the matchups.
The end result of all this is someone who is either preferred to all other candidates or at least the closest to that that's possible.
If you mean that it is in theory possible to write faster programs in C than in higher-level languages, or that it is possible in theory to write faster programs in assembler than C, then you are correct. However, that's not really interesting, since in many cases it's not feasible (perhaps just on this side of impossible). A compiler can simply optimize large blocks of code better than you can, so for sufficiently large apps, the C version will almost always be faster than the assembler version, because it can find neat optimizations you didn't think of. Already many C compilers ignore the 'register' keyword, because they know they can do a better job allocating registers than you can. Similarly, garbage-collected languages are becoming competitive performance-wise with explicit memory management, because they can just keep track of huge numbers of allocations better than the programmer can, and exploit redundancies and opportunities for optimization across non-local areas of code.
On most platforms, assembly is not in practice faster than higher-level languages. If, for example, you were to actually manage to write an office suite in assembly, in addition to being wholly unmaintainable, it'd likely run slower than the higher-level version. This is because once things get to a certain size, the compiler is simply better at optimizing than the human is. A human can't scan millions of lines of code per second for redundancies and optimizations, and isn't good at judging on the fly which optimizations are worth doing and which aren't. This grows increasingly true as you get into fairly complex architectures features, like filling branch delay slots on the SPARC or ordering instructions for the IA64's pipelining.
This is also increasingly true of using higher-level languages than C. C may allow simple things to go faster, but higher-level languages often allow complex programs to be faster on the whole because they provide guarantees that allow for optimizations a C compiler can't make (that C allows pointer arithmetic and arbitrarily-aliased pointers is a big problem for optimizers, for example). To take a trivial example, consider the following two ways of traversing an integer array:
1. for(int x = 0; x < length; x++) foo(array[x]);
2. for(int *x = array; x < array + length; x++) foo(x);
(1. uses indexing and 2. uses pointer arithmetic). Most C programmers would prefer the second, considering it "more efficient." The idea is that since you're walking through the array you keep adding sizeof(int) instead of starting at the beginning and adding an offset each time. This is especially true, it's claimed, if you access the value multiple times each iteration: instead of computing the offset to array[x] each time, you have a direct pointer to it that you just dereference. And this all used to be true. However, most (though not all) of the time, with modern C compilers 1. will actually be faster, because it allows the compiler to do some neat optimizations that it can't do with 2.
It's hands-down the best way of doing animation on the internet. (Comparatively) good scripting language, vector graphics, good client support, etc. Even Tim Burton uses it for his animations.
Sure, it'd be ok if you dropped it, but it'd be much more prone to breaking if it was in your pocket and you accidentally sat on it.
I was under the impression that's what the terms "Free Software" and/or "Open Source" were supposed to be for.
I do agree that E17 development has seemed pretty "if you're not one of the core developers, you shouldn't be touching it," but it's moving away from that. The post linked to in this story is a good example of an increasing openness and attention to at least some documentation. A lot of documentation has appeared on enlightenment.org in the past month or two as well; the relatively new build notes are particularly useful when trying to build from CVS.
If you want a working window manager, stick to e16; e17 isn't really being actively worked on as a window manager yet, and doesn't have many features. The work is on a lot of useful backend stuff; the joke is that once the backend is done, the window manager will be five lines of code. Take a look at the components though. Many of them are in a very good state, and the E folk are to be commended for their excellent modular development -- many of these components are already being used by other projects (imlib2 in particular), and many of the others either are or soon will be in shape to be used in other projects too.
Of course perhaps I'm a bit biased, since E16 is still my favorite window manager (a better way to view/edit remembered window/app attributes being my only real feature request), but I think the E17 team is doing a good job contributing to the overall Free Software codebase. And though it's a bit frustrating that E17 is taking so long, reading through the components is impressive -- everything is being engineered carefully. While many window managers hack things in, everything in E -- from the theming engine to the window decorations -- is carefully designed with a clean interface. Should be impressive when it's done.
My only main worry about E17 is that it seems to be going desktop-environment-ish, a la GNOME/KDE, which I really can't stand. Hopefully we'll be able to turn all that off.