It's so true. Though I haven't been nearly as immersed in the Clojure community as Anthony has, two of my last four jobs/internships have been in Clojure (well, really, they hired me back). And I've loved it. I love the language–it's the perfect balance of having fun, being precise, and getting things (anything done). And I love the community. I've met so few Clojurists in person, but the ones I have met have been amazing, and the ones who share their stories and their wisdom via blog or IRC are just so damn intelligent and kind.
More than anything, I Get Things Done with Clojure, and the community helps me do that. And from the feedback/re-hiring I get from my jobs, my employers and the people they serve would agree.
When I started programming at about the same age, living in Tennessee in the Pleistocene era, it took the concerted effort of several adults to even get me access to a computer (actually to a punched card reader that connected to a computer 100 miles away).
Now we take for granted that a smart kid in Alabama has his own personal computer and can participate in a conversation with an expert community anytime he wants. But it's amazing. And more importantly, the experts are so incredibly supportive!
I guess this tradition goes back quite a ways, though...think of Ramanujan and Hardy's mathematical relationship. Perhaps the key is a field that doesn't require expensive equipment and the gatekeepers that go with that. Or does this sort of thing happen nowadays in fields other than CS and math? Do 16-year-olds show up in economics or physics IRC channels and meet supportive communities?
I think part of the reason why programming (and open source especially) allows for very young people to participate easily is simple: bugs always exist. Open source projects need a lot people -- not just A-grade programmers or developers or computer scientists who've had decades of experience. They need documentation, bug reports, patches, active forum/mailing list members, and community organisers to be really successful. It's easy to get started just by hanging out on forums, eventually noticing a bug, reporting the bug, learning more about how the software works by understanding the bug, possibly trying to fix the bug, etc. Over time, it isn't too hard to start making very significant code or documentation contributions to a project.
In contrast, bug-testing Newton's Laws is a waste of time, and bug-testing General Relativity requires a very large budget. Attempting to make a meaningful contribution to physics is very difficult. The same can be said for any pure science.
By definition, any pure science (natural or social) doesn't evolve quickly enough to allow for quick-but-meaningful contributions because pure science is about establishing a base of knowledge that builds directly on previous knowledge. Without an understanding of the "previous knowledge," any newcomer would be lost and wondering what's happening.
In contrast, applied science is often an orchestrated effort that involves experts in different fields and contributions from different fields (e.g. your software is as valuable as its support, and your interface ideas are as good as the person implementing them). Prior knowledge isn't necessarily as valuable as the ability to integrate ideas from different places or collaborate with others.
Would you agree? I ask because part of me feels like I might be missing something.
I don't think you are correct, though you may be partially correct.
Perhaps many people get into programming by fixing bugs, but that never appealed to me, and didn't really appeal to many people I know. It's good advice for newbies trying to get better, I suppose, but it's not very satisfying work (for many).
I got into programming by exploring my computer, websites, and slowly piecing together an understanding of the machine. Eventually, I learned a programming language to (mostly) proficiency. And then another. And then another. I still don't feel like a pro, but I'm getting there. And I still hate fixing other peoples' bugs, or my own.
Fixing bugs can be very enjoyable. I like watching House MD for the same reasons. I feel like House's quest for a diagnosis given a subset of the symptoms and his way of trying to provoke new symptoms to appear in order to narrow the set of possible diagnosis, is just like trying to find the cause of a bug. I don't know if other programmers watch House with this analogy in mind, but I wouldn't be surprise if it's the case, the analogy is really strong.
Investigating bugs seems to me like the only part of computing that could actually be considered a true science. You come up with theories about why a system is going wrong, and then setup experiments based on those theories.
Fixing bugs is something that only becomes enjoyable as you become a little more mature and experienced as a programmer. Bug fixes can be pretty satisfying; it can be a nice change of pace to solve small, well-defined problems.
First job as a programmer -- Clojure backend dev? That's pretty awesome. The joy you derive from the Clojure community comes across loud and clear in your writing.
For anyone else who's been toying with the idea of looking at Clojure, it has, IMO, the best tech community on the web. It seems like every maintainer for every Clojure project I've ever looked at is at least idling in #clojure on freenode 24/7.
Anthony's Conj talk was pretty good all right. He looked completely at ease, and has a great deadpan delivery when he tells a small joke. Knows his stuff. He's grown in the last year, in lots of directions, and he is going to be a Force. Watch and see.
(No pressure, raynes.)
And he's right about the community. Besides attracting some really bright people, there isn't a lot of language chauvinism evident. (Well, the JRuby folks took some shots, but it was all in fun. We love you guys, really.)
I was born and raised in Alabama, too, and it terrifies me to think that there are talented young people living there who have never left the state. The culture there is so unlike the rest of the country, you can get a skewed view of reality really easily. I mean, I have one.
From growing up in the Southeast, I think that's true to varying degrees all over that region. The culture tends toward complacency in its worldview.
One of the most difficult things to do is to suspend your own beliefs, dogmas, and preconceived notions about how the world is or should be, and completely immerse yourself in adapt to another culture, be that culture a foreign country, or just the other side of a big one like the US or Europe.
And that is particularly difficult for Americans who are taught from an early to 'express yourself', rather than to perceive the world or any given situation from the point of view of other people (as many foreign cultures, especially Asian ones, do). It's even more difficult for Southern Americans, who are, on top of all that, brought up with this relatively complacent world view.
I know plenty of exceptions, but in general I agree with your assessment.
So what comes after Haskell? After I had used Haskell for a couple of months and had got a few projects under my belt, it was time for a new step. I felt that my next logical step was a Lisp.
This strikes me as an odd "next step". I don't code in Haskell or clojure, but I've been eyeing both and the impression I got is that Haskell is harder to grasp but more powerful once fully grasped (and nearly as portable as C++). Sort of a superset of lisp. It seems that the next logical step after a couple of months of Haskell is more Haskell. It evidently worked out great for him, but I'd have liked to know why he switched to clojure.
It's certainly more 'advanced' than any Lisp, including Clojure -- for the past few years (or decades now...), Haskell has been where new academic language research has been done. 
But that's just the problem. The fact is that Haskell is a research language standardized by a committee of academics without much experience or interest in real-world use. And it shows. Clojure, in contrast, is a language designed for practical purposes after years of experience from real-world use, mostly by one person, and while he's not as smart as the committee that designed Haskell, he has something committees rarely ever have. Taste.
In practice, I find Haskell beautiful. With Clojure I get things done.
 I'd be willing to say that today, if you are not fluent in Haskell, you are strictly not competent to design a new programming language. For the exact same reason you weren't competent to design new one without knowing Lisp from about the '80s through '00s -- unless you know Haskell, you are passing by most of the new inventions in programming languages done in past few decades simply because you have never heard of them, and don't even know you are missing them.
It wasn't really in the sense that Clojure is the the logical step up from Haskell. It was the next logical step for me as I was learning to program. Lisp and Haskell are the two of the big scary functional (though not purely functional in the case of Lisp) languages. They both warrant knowing.
Furthermore, I'd probably disagree with the assertion that Haskell is more powerful once fully grasped. Lisp gives a lot of power to programmers (exhibit 1: the Lisp macro system). However, that means molding the definition of 'power' to suit my needs, and I don't really want to go there. I think that Haskell and Clojure are both very powerful and amazing languages. They are not mutually exclusive. I just happen to like Clojure more. Plenty of people go the other way. I, of course, still have a lot of respect and love for Haskell and hope to have time to do more with it in the near future.
As for why I switched in the first place, I guess it was mostly because Clojure looked like it would be so much fun. When you're young, what others perceive as weirdness can sometimes be exactly the thing that appeals to you. The reaction I had to parentheses is exactly the opposite of what experienced developers tend to have in the beginning. I loved them.
Travel in the United States is enough of a bother without doing so alone and as a minor. Not something I wanted to deal with. Besides that, there are apparently a lot of problems with liability when someone pays for a minor to travel and it doesn't involve an adult.
Chas Emerick here; I set up the fundraiser for Anthony in 2010. That rule was mine, and it had nothing to do with "typical America" (whatever that means).
If something were to go wrong at any point, I wanted to make sure that someone would be around that had Anthony's best interests at heart (could have been any relative as far as I was concerned — I think Anthony's brother was also an option at one point). Similarly, I made sure I talked to Anthony's mother by phone before I started the fundraiser to make sure she was aware of what was going on and had no objections.
Yeah, there may have been liability involved — for me, for Relevance, for others, who knows — had something gone badly wrong. I'm not a lawyer, so I don't know; but, having a parent or other adult relative along seemed like a relatively simple way to address that unknown.
Fundamentally, this had nothing to do with laws or regulations or even liability — it just seemed like the right thing to do.
The Airlines. When you are at the Airport to pass on your luggage. The give you some forms to fill out. Then you have to give these to somebody befor you get to pass on your luggage. The nice lady then Ask you questions like: "Have you every left your bags unwatched? (That was on the form allready)".
Made the line 2x slower then it had to be. Made me not wanting to go back to Amerika anymore.
Your critique is correct, but doesn't apply to this situation so much. Insurance isn't going to want to cover accidents if no adult is involved and insurance isn't known for making exceptions in the customers' favor.
I was actually going for a reference to Marley & Me. Though, I'm not entirely convinced that it is indisputably incorrect in this case. Even if it is, I highly doubt that it is the worst mistake in my post.