OS X installation is better suited to proprietary applications, as opposed to the more cooperative software system of a typical Linux computer. On OS X there are a clear set of system libraries that people can be expected to have. (And there's no incremental way to do major upgrades on that system software; also no free way).
When you only depend on system libraries, installation can be pretty simple. But there is little "system" on a Linux computer; libc is system. Is glib? libxml2? Who knows... various vendors define a base system, but it never means a whole lot, since Open Source developers aren't going to pay attention to it.
The Open Source environment encourages little applications and lots of dependencies. The package management has to be a lot more robust. Also, Linux package managers supports legacy applications, OS X does nothing in that case. It lets them run free and unmanaged. There's a virtue in OS X, that they provide clear and strong conventions to their developers; but the actual infrastructure is way less powerful or complete than any Linux distribution.
Because they like don't like Ruby that much (at least compared to some other language)? In the case of Subway, he's putting together pieces that already exist in Python, so it's only a partial reimplementation.
Someone just recently started implementing a Rails-like system in Python: http://st0rm.hopto.org/subway.zip (only suitable for people who want to help its development; it's like 4 days old at this point).
I wrote about Rails a couple days ago on my blog; I think it shows off the difference between a dynamic language and a static language (Java) pretty well. I have a hard time imagining Java maintaining Rails' simplicity, and I think the Rails model starts looking a little silly if it's not simple; it would be rapid application development without the rapid.
Were you running it under CGI? That's not how it's meant to be deployed, that's just a convenient way to get started; mod_ruby would be appropriate for deployment. I haven't used it, but my experience with Python web programming has shown little in the way of performance problems, and Python and Ruby have similar performance.
Centralizing power production isn't entirely positive, as there is a serious amount of energy lost in transmission. There's also an issue where people ignore their inefficiency and pollution unless it's in their face and effecting their immediate environment; though in this case PRT has real efficiency gains.
Underground rail is obscenely expensive for other reasons. And you still don't have a free right of way -- they are digging way down in New York for the new lines, I presume because they couldn't be sure there'd be contiguous free space higher up. Elevated trains can run above streets; but at least in Chicago all newer lines have been built on raised land, I suspect because elevated lines that aren't directly connected on ground are less stable and can't support very fast trains, and are difficult to maintain. 40 ton cars aren't easy to elevate, especially if you are placing them on posts.
One idea is to have some way of rejecting a car if it is messed up (e.g., vomit). Then the car would whisk away to a service station, and you'd get on the next car that came along. I don't really see how homeless people would be a problem -- unlike many transit systems, you don't stay on until you feel like getting off; it takes you to a specific destination you paid for. Then it sits there until you get out. People might hang out in the stations, but that's an issue with any public space.
Incidentally, the designer of the WVU system just passed away (username: cypher@punk.com, password: cypher).
The PRT they're talking about here is sometimes confused with systems like the one in West Virginia (that are also commonly seen in airports). Automated (driverless) transportation systems are really fairly different from the self-navigating on-demand system that SkyWeb is working on.
Cars are having a hard time scaling; that's why traffic is getting so much worse just about everywhere in the country. It seems to come down to the interchanges; highways have huge capacity because they have nonstop intersections (cloverleafs and whatnot). One of PRT's inspirations is to bring that idea -- nonstop transport -- to local transportation where highways are infeasible and unappealing.
Large cities (cities over 500,000 people) -- Too expensive to build and too many places to potentially have to get to.
That seems to lead to the opposite claim. Rail is obscenely expensive, and hard to extend because you have to pay for the right of way. That's expensive in a large, dense city -- PRT could use existing right of ways (i.e., going about a road). Also, it can scale in ways that normal transit can't; as you add more stations and transfers to a normal system, everyone's ride time goes up. It's a pain in the butt in Chicago (for instance) that you can take the train downtown, or along a single line, but you can't traverse the city from one non-downtown location to another; this wouldn't be as much of an issue with PRT, as there aren't any transfers (which take time), and there aren't any specific lines, just a network of lines that all work together.
The other problem with big-city transit is that repairs and upgrades are hard, because there's these incredibly essential lines, and you can't just take them down. Instead you have people working at night and putting everything in place for the morning, or shuttles to deal with missing service, or whatnot. With PRT there's builtin redundancy, so individual lines could be taken off without impacting the entire network.
That said, PRT should work fine alongside other transit options, potentially as a feeder to get people the last mile or two to their actual destination.
Generally it would be better to add more stations instead of making the stations larger. Unlike normal rail, more stations don't slow the entire system down, and they add convenience as well as capacity. So high traffic can be met with a high density of rails and stations. The entire idea of PRT is to support a dense network instead of high capacity single-line hauls.
Simulations seem to show that's it's not too bad. iTS is a neat graphical simulation program for PRT, and this simpler simulation shows what happens with a backup at a single station (that one also has a movie of the simulation, though I believe both are fairly easy to install).
I think they say "no emissions," which is true. They also compare energy costs in the article, which are quite favorable to automobiles and traditional mass transit. Traditional mass transit actually isn't very favorable to automobiles; commuter trains and buses are pretty good, but any system that operates during non-peak hours starts to look a lot like automobiles in terms of energy consumption.
I think they want to avoid walkways, as it adds to the cost and visual impact of the guideway. There would be an emergency stop button that would take you to the nearest station, which should always be close by.
In case the system or car shuts down, there would be some radio system to signal the problem and communicate with the central office, and someone would probably have to come to fetch you. I think they'd rather work on making that extremely uncommon than build up more infrastructure. Anyway, there's no safe way to go walking around on those tracks, it's much safer to stay in the car. Because it's not that high up, any fire truck could get you down, and probably many other emergency or maintenance vehicles could also do it.
Of course, all the engineering takes into account safety in catastrophic situations, like the car in front instantly stopping. The clearances are less than automobiles because the breaking is automated, the track conditions are carefully controlled, and the cars are well maintained.
Cars would also be regularly serviced, driving themselves to the service station on a schedule, or going in for service if any of the internal diagnostic hardware detects a problem.
Besides using two cars, given the size you could probably fit one adult and three children in as well. Some of the designs differ, but I think SkyWeb just uses a bench seat, so it's flexible depending on how cozy everyone wants to get. A single parent with four kids might have a problem.
It's also fairly friendly to families compared to normal public transportation, because you pay one fare no matter how many people use the car. Normal public transportation tends to be very family unfriendly, because it's priced for commuters and single travelers, and round trip fairs for a family of four can get to be really expensive ($10-13 in Chicago).
PRT (Personal Rapid Transit) offers many of the advantages of a car (direct, no-stop transport that isn't shared), but automated. It's basically a very small (up to 3 person) train on a small elevated track.
I can understand why people balk at public transportation -- there are a lot of problems with it. It's slow and it just doesn't scale; in "good" public transit places, it's only good because traffic and parking has crippled car use.
PRT can scale better than typical public transit, when you consider both the density of service, and total trip time. Hopefully a more technical-minded crowd can get over the naive idea that big trains can necessarily carry more people. If you just consider a track with one car per second (1 person per car) -- a very conservative density -- vs. a traditional train with five minute headways, the traditional train doesn't look so hot. Especially when you consider the effort in supporting a 40 ton car (that's just one traditional train car) vs. a 1 ton PRT car (and hopefully they could get that weight down considerably as technology improves); the PRT tracks should be way cheaper, and ultimately cheaper than roads. They couldn't actually replace roads, but they could make expansion unnecessary, or even make contraction of roads possible (e.g., removing lanes), and reduce the load on roads so they don't deteriorate as quickly.
PRT is meant to work with urban areas the way they are, not just the way we wish them to be. And the technology itself doesn't require any breakthroughs, even taking into account safety issues.
Anyway, I really hope something comes of it. Some links: SkyWeb, the PRT company that's furthest along; Citizens for PRT; Advanced Transit PRT Page for a bunch of links and academic studies about PRT.
There's a lot of good office space outside of downtown, too, at least for a smaller company (though large buildings exist as well). Most of the space is old, so there's a greater buildout cost, and maybe some problems (i.e., old building layouts might not meet current desires). I don't think it's that bad, though. I like old buildings.
I think you get most of the advantages of the city that way, without the disadvantages of a downtown. And you get better access employees in the city, who are often reluctant to work in the suburbs.
Of course, this fits a certain demographic. It's not as prestigious as a downtown office, or as modern as a suburban office, and city employees fit a particular demographic. These work well for certain companies, and aren't as important to others. Popular for graphic design companies and little web development shops. Used to be great for light industry, but many of them have moved out; I think that's a shame. I'd really like to see mixed use city neighborhoods take off more than they have; I think it's better for everyone. It's also the antithesis of the suburbs.
Re:Zope great in theory ... not so much in practic
on
Zope X3 3.0.0 Released
·
· Score: 1
Zope 3 is really a reformation of Zope 2. No more Acquisition, for instance (an idea that seemed good, but was really really horrible). Well, for everyone else, Acquisition is something where an object remembers where it came from (more or less); it's very reminiscent of dynamic scoping. People who are familiar with CS will probably note that dynamic scoping is considered a very bad idea, for all the reasons Acquisition ended up being bad.
Zope 3 also strongly encourages development on disk, not through the browser (and not storing your code in the ZODB, the object database).
There's a bunch of other things. Anyway, it's a different world. I don't personally know if I'll partake -- there's lots of other ways to develop web pages with Python, and I'm happy with those.
As I get older, I find I actively am trying to forget the things I've already learned about Linux; I'm quite happy not learning more. The OS is boring, it's only interesting what you can do with it. Obviously not everyone is coming at it like this, but to me it's just the nature of progress.
Universal (aka "single payer") health care came up last in the 90s. Anyone who proposed it was vilified in the press; there were armies of lobbiests and "pundits" (nothing more than whores really) slandering foreign systems. Despite this, the majority of Americans would still support single payer health care, but they aren't given that choice. And I feel confident that for 99% of Americans, a single-payer system would provide superior care. It's not just the uninsured who are being screwed over by this system. And the efficiency claims... what absurdity! We pay through the nose for our crappy system. Sigh.
To the degree that you can know type information statically, you can do many of the same optimizations that OCaml does. Starkiller is a (very experimental) package that does this in Python. Or, you can guess some and then check your guess at runtime, which is what many JITs do, as well as Psyco (another less experimental package for Python). I think Psyco phrases the process internally as partial evaluation -- where you try to pre-calculate any expressions that can be statically evaluated, like if there's the literal expression (1+1), you know that it will always be 2, no matter what else is happening in the system. If you apply this not just to the visible expressions, but also to the vtable (or equivalent) lookups for method access, you get a sort of implicit type inference.
I think the problem you are seeing is Ravioli Code; a (perhaps excessive) reaction to spaghetti code. Also Java (and probably C#) programmers seem to take Patterns too seriously as well, patterns should be descriptive, not prescriptive.
Indymedia is an open organization, so encrypted disks are unnecessary. To the degree possible, Indymedia does not keep any record of who posts or connects to the machine (of course, upstream routers might still keep logs). Of course, there may be mistakes that make it possible to track posters forensically. Anonymity of Indymedia posters is a public policy, and both policy and implementation are discussed publically. The only private communications in Indymedia are related to security, and those communications have only recently been set up; that's purely for technical discussions to protect the servers from attacks.
I doubt law enforcement is actually expecting to find much. This is more likely an attempt to suppress the service and the content on those servers. Indymedia does not have much money, and as a volunteer organization has limited person resources. Also, I don't know what the backup situation is, so confiscation of servers may take some information offline for an indefinite period of time. Though thanks to infrastructure like archive.org, Google cache, and others, important articles can probably be maintained.
Re:Thoughts of Python...
on
Dive Into Python
·
· Score: 2, Informative
Double-underscore should only be used if you are somehow worried about name collisions with subclasses, or you are otherwise a control freak. A single underscore is the proper way of indicating something is a private variable. There's nothing stopping you from accessing such a variable, but Python does not assume Python programmers are idiots, so it lets you choose. Except in the case of double underscore, which is why many Python programmers find them obnoxious (myself included).
There are a variety of other data-hiding techniques. Enforced encapsulation isn't really an essential aspect of OO anyway; Smalltalk has no private methods (except by convention, like Python), and Smalltalk is quintessentially OO. Smalltalk does make all instance variables private; I'd probably agree that it would have been better if Python instance variables were private, but you can use property if you later decide to make a public attribute calculated, or one of the other cases where public attributes cause problems.
Well, Graham doesn't really need me to defend him, but I will anyway. This article doesn't really get the point:
Java has considerably fewer surprises: on this one he might have a point. I might say "Java has fewer orthogonal features" instead. For instance, there's little ability to do metaprogramming in Java (unless you use AspectJ). There's just lots of interesting things you can't do -- and interesting things can also be hard to understand or cause surprises. Java's compromise is arguably valid, though not very exciting.
Java has been considered slow: obviously he doesn't understand where Graham is coming from. Many interesting languages are slower than Java, including many of the languages that Graham suggests (Perl, Python, Scheme).
Swing disasters continue: again, he doesn't understand Graham. To address his criticism of Java, you must ask "is Swing fun to program" not "are Swing apps fun to use".
Java is strongly typed: well, sure. ML is a statically typed cool language. And Lisp, Python, and Smalltalk are all strongly typed. (If you don't understand the distinction between strong and static, read this.) The problem is really that Java doesn't trust the programmer, not the specifics of its typing. Though if you trust the programmer, static typing starts seeming a lot less useful. And yes, great hackers don't like languages that don't trust them, for obvious reasons.
Java has a vast library that is available to all Java developers: this is a guy with a Common Lisp background. He certainly has no problem with good libraries, and he never mentions any problem with extensive libraries. Programming in an open field can be fun sometimes, and can help you think about things differently, but libraries are never a detraction (you can always ignore them if you want).
Java did not have a good IDE: I don't think Graham said that great hackers really like Visual Basic, and that's why they don't use Java. I laugh just considering that argument.
Java is popular: if you ever listen to the users of languages like Smalltalk and Lisp, they will bemoan at great length that they are not as popular as they deserve. Though you'd only know this if you ever looked at these communities.
Java is an application programming platform: so are Lisp, Smalltalk, Python, etc. Most of the kinds of languages Graham is talking about are not systems programming languages.
It's nice this guy tried, but he really doesn't understand what Graham is talking about. Which is kind of the point -- to understand Graham's perspective you need to have the intellectual curiosity to do non-work-related projects, using environments that are unfamiliar to you. You need to reflect on those experiences and make judgements about what you like and what you don't like. If you've only used Sun and Microsoft languages, you won't get it. That doesn't mean you can't do good work in Java, but if that's all you do, then you won't be much of a hacker at all.
Slashdot Mirror
When you only depend on system libraries, installation can be pretty simple. But there is little "system" on a Linux computer; libc is system. Is glib? libxml2? Who knows... various vendors define a base system, but it never means a whole lot, since Open Source developers aren't going to pay attention to it.
The Open Source environment encourages little applications and lots of dependencies. The package management has to be a lot more robust. Also, Linux package managers supports legacy applications, OS X does nothing in that case. It lets them run free and unmanaged. There's a virtue in OS X, that they provide clear and strong conventions to their developers; but the actual infrastructure is way less powerful or complete than any Linux distribution.
Because they like don't like Ruby that much (at least compared to some other language)? In the case of Subway, he's putting together pieces that already exist in Python, so it's only a partial reimplementation.
I wrote about Rails a couple days ago on my blog; I think it shows off the difference between a dynamic language and a static language (Java) pretty well. I have a hard time imagining Java maintaining Rails' simplicity, and I think the Rails model starts looking a little silly if it's not simple; it would be rapid application development without the rapid.
Were you running it under CGI? That's not how it's meant to be deployed, that's just a convenient way to get started; mod_ruby would be appropriate for deployment. I haven't used it, but my experience with Python web programming has shown little in the way of performance problems, and Python and Ruby have similar performance.
Centralizing power production isn't entirely positive, as there is a serious amount of energy lost in transmission. There's also an issue where people ignore their inefficiency and pollution unless it's in their face and effecting their immediate environment; though in this case PRT has real efficiency gains.
Underground rail is obscenely expensive for other reasons. And you still don't have a free right of way -- they are digging way down in New York for the new lines, I presume because they couldn't be sure there'd be contiguous free space higher up. Elevated trains can run above streets; but at least in Chicago all newer lines have been built on raised land, I suspect because elevated lines that aren't directly connected on ground are less stable and can't support very fast trains, and are difficult to maintain. 40 ton cars aren't easy to elevate, especially if you are placing them on posts.
One idea is to have some way of rejecting a car if it is messed up (e.g., vomit). Then the car would whisk away to a service station, and you'd get on the next car that came along. I don't really see how homeless people would be a problem -- unlike many transit systems, you don't stay on until you feel like getting off; it takes you to a specific destination you paid for. Then it sits there until you get out. People might hang out in the stations, but that's an issue with any public space.
The PRT they're talking about here is sometimes confused with systems like the one in West Virginia (that are also commonly seen in airports). Automated (driverless) transportation systems are really fairly different from the self-navigating on-demand system that SkyWeb is working on.
Citizens for PRT is another site that may be of interest.
Cars are having a hard time scaling; that's why traffic is getting so much worse just about everywhere in the country. It seems to come down to the interchanges; highways have huge capacity because they have nonstop intersections (cloverleafs and whatnot). One of PRT's inspirations is to bring that idea -- nonstop transport -- to local transportation where highways are infeasible and unappealing.
The other problem with big-city transit is that repairs and upgrades are hard, because there's these incredibly essential lines, and you can't just take them down. Instead you have people working at night and putting everything in place for the morning, or shuttles to deal with missing service, or whatnot. With PRT there's builtin redundancy, so individual lines could be taken off without impacting the entire network.
That said, PRT should work fine alongside other transit options, potentially as a feeder to get people the last mile or two to their actual destination.
Simulations seem to show that's it's not too bad. iTS is a neat graphical simulation program for PRT, and this simpler simulation shows what happens with a backup at a single station (that one also has a movie of the simulation, though I believe both are fairly easy to install).
I think they say "no emissions," which is true. They also compare energy costs in the article, which are quite favorable to automobiles and traditional mass transit. Traditional mass transit actually isn't very favorable to automobiles; commuter trains and buses are pretty good, but any system that operates during non-peak hours starts to look a lot like automobiles in terms of energy consumption.
In case the system or car shuts down, there would be some radio system to signal the problem and communicate with the central office, and someone would probably have to come to fetch you. I think they'd rather work on making that extremely uncommon than build up more infrastructure. Anyway, there's no safe way to go walking around on those tracks, it's much safer to stay in the car. Because it's not that high up, any fire truck could get you down, and probably many other emergency or maintenance vehicles could also do it.
Of course, all the engineering takes into account safety in catastrophic situations, like the car in front instantly stopping. The clearances are less than automobiles because the breaking is automated, the track conditions are carefully controlled, and the cars are well maintained.
Cars would also be regularly serviced, driving themselves to the service station on a schedule, or going in for service if any of the internal diagnostic hardware detects a problem.
It's also fairly friendly to families compared to normal public transportation, because you pay one fare no matter how many people use the car. Normal public transportation tends to be very family unfriendly, because it's priced for commuters and single travelers, and round trip fairs for a family of four can get to be really expensive ($10-13 in Chicago).
I can understand why people balk at public transportation -- there are a lot of problems with it. It's slow and it just doesn't scale; in "good" public transit places, it's only good because traffic and parking has crippled car use.
PRT can scale better than typical public transit, when you consider both the density of service, and total trip time. Hopefully a more technical-minded crowd can get over the naive idea that big trains can necessarily carry more people. If you just consider a track with one car per second (1 person per car) -- a very conservative density -- vs. a traditional train with five minute headways, the traditional train doesn't look so hot. Especially when you consider the effort in supporting a 40 ton car (that's just one traditional train car) vs. a 1 ton PRT car (and hopefully they could get that weight down considerably as technology improves); the PRT tracks should be way cheaper, and ultimately cheaper than roads. They couldn't actually replace roads, but they could make expansion unnecessary, or even make contraction of roads possible (e.g., removing lanes), and reduce the load on roads so they don't deteriorate as quickly.
PRT is meant to work with urban areas the way they are, not just the way we wish them to be. And the technology itself doesn't require any breakthroughs, even taking into account safety issues.
Anyway, I really hope something comes of it. Some links: SkyWeb, the PRT company that's furthest along; Citizens for PRT; Advanced Transit PRT Page for a bunch of links and academic studies about PRT.
I think you get most of the advantages of the city that way, without the disadvantages of a downtown. And you get better access employees in the city, who are often reluctant to work in the suburbs.
Of course, this fits a certain demographic. It's not as prestigious as a downtown office, or as modern as a suburban office, and city employees fit a particular demographic. These work well for certain companies, and aren't as important to others. Popular for graphic design companies and little web development shops. Used to be great for light industry, but many of them have moved out; I think that's a shame. I'd really like to see mixed use city neighborhoods take off more than they have; I think it's better for everyone. It's also the antithesis of the suburbs.
Zope 3 also strongly encourages development on disk, not through the browser (and not storing your code in the ZODB, the object database).
There's a bunch of other things. Anyway, it's a different world. I don't personally know if I'll partake -- there's lots of other ways to develop web pages with Python, and I'm happy with those.
As I get older, I find I actively am trying to forget the things I've already learned about Linux; I'm quite happy not learning more. The OS is boring, it's only interesting what you can do with it. Obviously not everyone is coming at it like this, but to me it's just the nature of progress.
Universal (aka "single payer") health care came up last in the 90s. Anyone who proposed it was vilified in the press; there were armies of lobbiests and "pundits" (nothing more than whores really) slandering foreign systems. Despite this, the majority of Americans would still support single payer health care, but they aren't given that choice. And I feel confident that for 99% of Americans, a single-payer system would provide superior care. It's not just the uninsured who are being screwed over by this system. And the efficiency claims... what absurdity! We pay through the nose for our crappy system. Sigh.
To the degree that you can know type information statically, you can do many of the same optimizations that OCaml does. Starkiller is a (very experimental) package that does this in Python. Or, you can guess some and then check your guess at runtime, which is what many JITs do, as well as Psyco (another less experimental package for Python). I think Psyco phrases the process internally as partial evaluation -- where you try to pre-calculate any expressions that can be statically evaluated, like if there's the literal expression (1+1), you know that it will always be 2, no matter what else is happening in the system. If you apply this not just to the visible expressions, but also to the vtable (or equivalent) lookups for method access, you get a sort of implicit type inference.
I think the problem you are seeing is Ravioli Code; a (perhaps excessive) reaction to spaghetti code. Also Java (and probably C#) programmers seem to take Patterns too seriously as well, patterns should be descriptive, not prescriptive.
I doubt law enforcement is actually expecting to find much. This is more likely an attempt to suppress the service and the content on those servers. Indymedia does not have much money, and as a volunteer organization has limited person resources. Also, I don't know what the backup situation is, so confiscation of servers may take some information offline for an indefinite period of time. Though thanks to infrastructure like archive.org, Google cache, and others, important articles can probably be maintained.
There are a variety of other data-hiding techniques. Enforced encapsulation isn't really an essential aspect of OO anyway; Smalltalk has no private methods (except by convention, like Python), and Smalltalk is quintessentially OO. Smalltalk does make all instance variables private; I'd probably agree that it would have been better if Python instance variables were private, but you can use property if you later decide to make a public attribute calculated, or one of the other cases where public attributes cause problems.
Java has considerably fewer surprises: on this one he might have a point. I might say "Java has fewer orthogonal features" instead. For instance, there's little ability to do metaprogramming in Java (unless you use AspectJ). There's just lots of interesting things you can't do -- and interesting things can also be hard to understand or cause surprises. Java's compromise is arguably valid, though not very exciting.
Java has been considered slow: obviously he doesn't understand where Graham is coming from. Many interesting languages are slower than Java, including many of the languages that Graham suggests (Perl, Python, Scheme).
Swing disasters continue: again, he doesn't understand Graham. To address his criticism of Java, you must ask "is Swing fun to program" not "are Swing apps fun to use".
Java is strongly typed: well, sure. ML is a statically typed cool language. And Lisp, Python, and Smalltalk are all strongly typed. (If you don't understand the distinction between strong and static, read this.) The problem is really that Java doesn't trust the programmer, not the specifics of its typing. Though if you trust the programmer, static typing starts seeming a lot less useful. And yes, great hackers don't like languages that don't trust them, for obvious reasons.
Java has a vast library that is available to all Java developers: this is a guy with a Common Lisp background. He certainly has no problem with good libraries, and he never mentions any problem with extensive libraries. Programming in an open field can be fun sometimes, and can help you think about things differently, but libraries are never a detraction (you can always ignore them if you want).
Java did not have a good IDE: I don't think Graham said that great hackers really like Visual Basic, and that's why they don't use Java. I laugh just considering that argument.
Java is popular: if you ever listen to the users of languages like Smalltalk and Lisp, they will bemoan at great length that they are not as popular as they deserve. Though you'd only know this if you ever looked at these communities.
Java is an application programming platform: so are Lisp, Smalltalk, Python, etc. Most of the kinds of languages Graham is talking about are not systems programming languages.
It's nice this guy tried, but he really doesn't understand what Graham is talking about. Which is kind of the point -- to understand Graham's perspective you need to have the intellectual curiosity to do non-work-related projects, using environments that are unfamiliar to you. You need to reflect on those experiences and make judgements about what you like and what you don't like. If you've only used Sun and Microsoft languages, you won't get it. That doesn't mean you can't do good work in Java, but if that's all you do, then you won't be much of a hacker at all.