Coding Horror

I no longer own any laptops. Everything in our house is a tablet: multiple Nexus 7s, multiple iPad 4s, and a Surface Pro. In fact, the only traditional computers I own are my triple-monitor desktop home office beast, and the small Home Theater PC (HTPC) that drives all our home entertainment in the living room.

It's a Mini-ITX case with compact, console-like 3.8" × 8.7" × 12.9" dimensions. It is a class act, totally at home in any civilized home theater environment.

I love that little HTPC to death. It is such a versatile, flexible, always-on box. The longer I work on my HTPC project, the more I believe the evolution of the HTPC is a nice metaphor for the overall future direction of the PC. In summary:

15 watts at idle! Incredible, isn't it? But you probably also noticed how some of these stats aren't improving so much. Basically, they don't need to – we've reached such an absurd overabundance of computing power that slathering more on top no longer gets us much. It's been about 2½ years since my last HTPC build, and (*) all I did this year is swap out the motherboard, CPU, and RAM:

• Intel Core i3-4130T ($139)
• ASRock B85M-ITX motherboard ($79)
• 8GB DDR3-1600 ($69)

I started by removing the overhead drive tray, then pulling out the motherboard and anything attached to it. Notice there's a ton of room in the front of the case where the old power supply used to be. No need for it. We're using a more efficient and way smaller PicoPSU. That space is now available for an extra 2TB 2.5" drive, sitting there on some mildly sticky sheets of sorbothane. Once you factor in the PicoPSU, it's a roomy build despite the compact dimensions.

Then I mounted the motherboard, attached the front USB and eSATA headers, the power/reset switches, and the aforementioned PicoPSU, which you can see sticking out of the motherboard's power header near the hard drive. Note that everything not directly attached to the motherboard is driven off a single power connector, so there are two SATA splitters in use. This particular PicoPSU and power brick are rated to 60 watts which is enough for what we're doing.

The top drive tray slides in with 3 screws. There's also a place just underneath the two drives above for a slimline Blu-ray or DVD drive, but I found I have virtually no use for optical media any more, so I've skipped it.

The main motivation for this upgrade is the lower power usage and better GPU performance of the Haswell CPU, versus the Sandy Bridge CPU that was in there. Everything else remains the same, though I have been selectively upgrading bits and pieces since 2011:

• Samsung 840 512GB SSD
• Western Digital 2TB 2.5" HDD (× 2)
• Pico-PSU-90 + 60w adapter
• Antec ISK 310-150 ITX case

Yes, that's right, 4.5 terra-friggin-bytes of storage. What can I say? I like me some media, man. The 512GB boot SSD is a little excessive, I'll grant you that, so feel free to replace the drives with something more modest in your build. I'm just addicted to SSD speed and didn't want to compromise too much on total storage.

You may wonder why I bothered upgrading memory, since the trusty DDR3-1333 RAM in the old HTPC works fine in the new motherboard. Fair question. Normally, RAM speeds are little more than a curiosity on modern computers, as minor improvements in memory speed have long since ceased to produce meaningful differences in benchmarks. But we are using Haswell's on-die GPU, and it relies on main memory as graphics memory. Even a low-end video card will have 1GB of ram on it these days, and games certainly expect GPUs with at least 256MB or 512MB of dedicated, extremely high speed graphics memory. This is the rare case where you do care about memory performance. Consider these AnandTech game benchmark results:

It's a bit difficult to read, but think of it as "percent better than vanilla DDR3-1333", since that's the baseline zero value here. The sweet spot is DDR3-1866 CL9 (light blue bar). That grade of memory is only nominally more expensive, and gets you reasonably near the top of each graph, but this motherboard doesn't support anything higher than 1600. DDR3-2133 CL9 (dark purple bar) is also out there.

Other than lower power consumption, and a modest bump in CPU power, the really big improvement is GPU performance. It's kind of a complicated matrix, but the i3-4130T chip has an Intel HD 4400 GPU, compared to the HD 2000 GPU that was in the i3-2100T I upgraded from. For example, Dirt 3 on medium detail at 1024x768 notebookcheck.net shows a gain from 21.4 fps to 44.6 fps for these specific GPUs – more than double the GPU performance, at the same 35 watt TDP!

That's the other reason I was excited about this upgrade: Steam's Big Picture mode. With that doubling of GPU power, this 15 watt idle HTPC we just built … is now a credible gaming machine!

So what exactly do we get for our upgrade troubles, 2½ years on?

• A 32% drop in idle power, from 22 watts to 15 watts. And an overall reduction in power consumption when the machine does happen to be doing something. 17 watts when in an active torrent, for example, up to around 50 watts when playing GRID 2.
• A credible gaming box for the first time, thanks to 2× the GPU power. It also coincides nicely with the maturing of Steam's Big Picture mode. When Gabe Newell talks about Linux as the future of gaming, this is the sort of machine he's referring to.

I'm not sure how much lower we can go on power, but I'm absolutely certain that Intel's on-die GPUs will continue to roughly double in power each generation for the forseeable future. This little HTPC box just keeps getting more versatile over time, while costing me less (in power consumption, at least) every year. It's the funnest build ever. HTPC, I love you, man!

What would you do, if you could do anything?

I don't mean in a fantasy superhero way, but in terms of resources. If someone told you that you now had the resources to attempt to make one thing happen in the world, one real thing, what would that be?

If you're Elon Musk, the patron saint of Hacker News, then you create an electric car and rocket ships. And then propose a hyperloop. Not bad. Not bad at all.

My dream is more modest. I decided to create a keyboard.

I've talked about keyboards here for years, but The CODE Keyboard is the only simple, clean, beautiful backlit mechanical keyboard I've ever found. Because we built it that way.

The name is of course a homage to one of my favorite books.

That's what I've always loved about programming, the thrill of discovering that communicating with other human beings in their code is the true secret to success in writing code for computers. It's all just … code.

CODE
/kōd/
A system of words, letters, figures, or other symbols used to represent others

The projects I've worked on for the last eight years are first and foremost systems for efficiently communicating with other human beings, not computers. Both Stack Exchange and Discourse are deeply concerned with people and words and the code they use to talk to each other. The only way those words arrive on your screen is because someone, somewhere typed them. Now, I've grown to begrudgingly accept the fact that touchscreen keyboards are here to stay, largely because the average person just doesn't need to produce much written communication in a given day. So the on-screen keyboard, along with a generous dollop of autocomplete and autofix, suffices.

But I'm not an average person. You aren't an average person. We aren't average people. We know how to use the most powerful tool on the web – words. Strip away the images and gradients and vectors from even the fanciest web page, and you'll find that the web is mostly words. If you believe, as I do, in the power of words, then keyboards have to be one of the most amazing tools mankind has ever created. Nothing lets you get your thoughts out of your brain and into words faster and more efficiently than a well made keyboard. It's the most subversive thing we've invented since the pen and the printing press, and probably will remain so until we perfect direct brain interfaces.

I was indoctrinated into the keyboard cult when I bought my first computer. But I didn't appreciate it. Few do. The world is awash in terrible, crappy, no name how-cheap-can-we-make-it keyboards. There are a few dozen better mechanical keyboard options out there. I've owned and used at least six different expensive mechanical keyboards, but I wasn't satisfied with any of them, either: they didn't have backlighting, were ugly, had terrible design, or were missing basic functions like media keys.

That's why I originally contacted Weyman Kwong of WASD Keyboards way back in early 2012.* I told him that the state of keyboards was unacceptable to me as a geek, and I proposed a partnership wherein I was willing to work with him to do whatever it takes to produce a truly great mechanical keyboard. Weyman is a hard core keyboard nut who absolutely knows his stuff – I mean, he runs a whole company that sells custom high end mechanical keyboards – but I don't think he had ever met anyone like me before, a guy who was willing to do a no strings attached deal just for the love of an idealized keyboard. At one point over a lunch meeting, he paused, thought a bit, and said:

So … you're like … some kind of geek humanitarian?

I don't know about that.

But I'm not here to sell you a keyboard. Buy, don't buy. It doesn't matter. I'm just happy to live in a world where the first truly great mechanical keyboard finally exists now, in exactly the form it needed to, with every detail just so, and I can type this very post on it. As glorious as that may be, I'm here to sell you on something much more dangerous: the power of words. So whether you decide to use the CODE Keyboard, or any keyboard at all, I'm glad you're thinking about writing words with us.

* Yep, we software guys are spoiled – hardware takes forever.

Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived. We think we've built software that is a general purpose solution to some set of problems, but we are almost always wrong. We have the delusion of reuse. Don't feel bad. It's an endemic disease among software developers. An occupational hazard, really.

If I have learned anything in my programming career, it is this: building reusable software, truly reusable software, is an incredibly hard problem – right up there with naming things and cache invalidation.

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.— Jeff Atwood (@codinghorror) August 31, 2014

My ideas on this crystallized in 2004 when I read Facts and Fallacies of Software Engineering for the first time. It's kind of a hit-or-miss book overall, but there are a few gems in it, like fact #18:

There are two "rules of three" in [software] reuse:

• It is three times as difficult to build reusable components as single use components, and
• a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Yes, this is merely a craftsman's rule of thumb, but the Rule of Three is an incredibly powerful and effective rule of thumb that I have come to believe deeply in. It's similar to the admonition to have at least one other person review your code, another rule of thumb that is proven to work. To build something truly reusable, you must convince three different audiences to use it thoroughly first.

OK, so you built a solution that scratches your itch … but does anyone else care? How many other people have the problem that your software or website addresses? How many other competing solutions are there to choose from? Outside of your personal patient zero case, can you convince anyone to willingly, or even enthusiastically, adopt your solution? That's your first hurdle. Can you even get to number one?

How deeply do I believe in the Rule of Three? So deeply that I built two whole companies around the concept.

With Stack Overflow, we didn't set out to build a general purpose Q&A engine. We only wanted to solve the problem of programmers looking for fast, solid technical answers to their programming problems, instead of the endless pages of opinions and arguments they usually got. Oh yeah, and also to deal with that hyphenated site. One of the greatest pleasures of my life is meeting programmers that have never heard of this hyphenated site now. I hope you can forgive me, but I mentally superimpose a giant Dubya-style "Mission Accomplished" banner over their heads when they say this. I grin a mile wide every time.

We launched Stack Overflow to the public in August 2008. It was such a runaway early hit that I started to get curious whether it actually would work for different audiences, even though that was never the original idea. But we decided to play the six degrees of Kevin Bacon game and take some baby steps to find out. Less than a year later we had Stack Overflow for programmers, Server Fault for system administrators, and Super User for computer power users – the full trilogy. Three sites with three distinct audiences, all humming right along.

One customer or user or audience might be a fluke. Two gives you confidence that maybe, just maybe, you aren't getting lucky this time. And three? Well, three is a magic number. Yes it is.

Once we proved that the Stack Overflow engine could scale to these three distinct communities, I was comfortable pursuing Stack Exchange, which is now a network of over 100 community-driven Q&A sites. The programming audience derived assumptions that the engine was originally designed around means it can never scale to all communities – but for communities based on topics that can be understood via questions about science, facts, and data, there is no finer engine in the world. Not that I'm biased or anything, but it's stone cold truth. Don't believe me? Ask Google.

When we launched Discourse in February, I had zero illusions that we had actually built workable general purpose forum software, even after eight months of hard work. That's why the "buy it" page still has this text at the top:

Unfortunately, you can't buy Discourse … yet.

Our immediate plan is to find three great partners willing to live on the bleeding beta edge and run forums with us, so that we can be confident we've built a discussion platform that works for a variety of different communities. We promise to do everything we can to host your forum and make it awesome for two years. In return, you promise to work with us on ironing out all the rough edges in Discourse and making sure it scales successfully – both socially and technologically – to those three very different audiences.

Hey, there's that magic number again!

Even now, months later, we're not even pretending that we have open source discussion software that works for most communities. Hell, the FAQ literally tells you not to use Discourse. Instead, we're spending all our effort slowly, methodically herding the software through these three select partners, one by one, tweaking it and adapting it for each community along the way, making sure that each of our partners is not just happy with our discussion software but ecstatically happy, before we proceed to even tentatively recommend Discourse as any kind of general purpose discussion solution.

Because I worship at the altar of the Rule of Three, it's pretty much been my full time job to say "no" to people every day for the last 6 months:

Hey, Discourse looks great, can you host an instance for us?

Sorry, not yet. Probably in 2014!

We desperately need great forum software for our community! Can you help us set up Discourse?

Sorry, I can't. We're focused on building the software. It is 100% open source, and we do have a pretty good install guide if you want to grab the code and set it up!

We'll pay you to host Discourse for us! Shut up and take my money!

Sorry, I wish I could. It's not complete enough yet, and the last person I want to disappoint is a paying customer, and we don't even have a billing system! We plan to get to hosting in early-ish 2014.

So yeah, I won't lie to you – I'm basically a total bummer. But I'm a total bummer with a plan.

The solution we constructed in Discourse was a decent start, but woefully incomplete – even wrong in some areas. The only way we can figure this out is by slowly running the solution through its paces with our three partners, to live in the same house of software they do as roommates, to walk alongside them as they grow their discussion communities and do everything we can to help build it into a community we enjoy as much as everyone else does. And when there were only one set of footsteps in the sand, well … that's because we were carrying you.

We haven't made it all the way through this process yet. We're only on partner #2; it takes the time it takes. But thanks to the Rule of Three, I'm confident that by the time we finish with partner #3, we will finally have a truly reusable bit of general purpose open source discussion software to share with the world – one that I can recommend unhesitatingly to (almost) anyone, because it'll probably work for their community, too.

So the next time you think "I've built a reusable thing!", stop, and think "how can I find three users, customers, or audiences, to prove that I've built something reusable?" instead.

I get a surprising number of emails from career programmers who have spent some time in the profession and eventually decided it just isn't for them. Most recently this:

I finished a computer science degree last year, worked about a year in the Java EE stack. I liked requirements engineering and more 'management stuff' in university, but let's face it: you tend to be driven to be a programmer.

I enjoy programming itself. I'm not doing it that badly, I even do it better than some people. But it's too frustrating. Stupidly complex stuff (that people consider "standard" even if it's extremely complicated!), fighting against the computer, dumb errors, configuration, and stuff that people even worse than me implemented and I have to take care of. New stuff which is supposed to be incredibly easy, and it's just one more framework.

I think I realized I don't want to program because I landed at a company where people are quite good. And I honestly think I won't achieve that level, ever. And I don't enjoy programming as a hobby.

I'm sure that I'm good enough to be able to make a living continuing as I am … but I don't want to.

And this:

Since the first year of studying programming at university I have known in my heart that computer programming is not meant for me, but I was afraid to do anything about it and here I am now 12 years later programming with no passion. I am a career programmer and an average one at best.

I come to work every day with no passion I just do it to pay the bills. I have done some good projects but I am not at all into it.

It was always our hope that concrete, substantive programming career questions could be asked on Stack Overflow, and some early ad-hoc polling indicated that career questions might be accepted by the community, but if you look at later poll results, it's clear that the career questions came out juuuust under the cutoff point as determined by the Stack Overflow community.

Well, what about the rest of the Stack Exchange network? How about our sister site at programmers.stackexchange which is less about programming problems with source code and more about whiteboard style conceptual programming questions? Apparently, career questions are not welcome there either. But wait! Surely programmer career questions are a fit on a site that's explicitly about career related topics? The very same question was asked on workplace.stackexchange:

I'm graduating soon with a Bachelor's in Software Engineering, however during the course of getting my degree I decided I do not want to be a programmer.

I minored in Business Management and really enjoyed that, particularly the management side of psychology and the basics of the processes involved with restructuring a business, but don't really want to throw away my programming degree either.

Is there a field for someone with a Software Engineering degree who wants to get into business management instead of programming? I'd like to combine my knowledge of making software with some kind of business process oriented work. How should I go about changing to this field? Is this possible without going back to school?

I am sympathetic to this quandary because career questions, by their very nature, tend to be so narrow and opinionated that they are frequently only useful to the person who asked – which is completely counter to the goal of Stack Exchange. You know, endless permutations of things like "My boss Jeff is a total jerk, he constantly changes my code without asking and overrides me all the time with his BS arbitrary decisions, should I quit?"* I can understand deciding to outlaw the entire class of career questions because they're frequently soft, opinion-y, and highly specific to the person asking. It's easier to throw out the whole category rather than do the painful work of sifting through them all to reveal those few rare workable gems.

Stack Exchange wants questions that are as useful to as many people as possible, and actively closes (sorry, "puts on hold") the ones that are not. I will now reprint my favorite diagram, ever, which attempts to explain this:

The colored part in this target that says "All Programmers"? That's the goal at Stack Exchange. Well, maybe "all bicyclists", or "all cooks", but you get the general idea.

We try our best to teach you to ask questions that hit this sweet spot: answers that get you the information you so desperately need, yes, but also help your peers along the way without devolving into meaningless opinion honeypots. Overshoot and you get either "Too Broad" or "Too Localized". Hitting that target with our questions – or at least making a best faith effort to attempt to, anyway – is how we maximize the results of our collective efforts. Write once, read many.

But back to the topic: what career options are available to programmers who no longer want to program? I feel there is a way to answer this question that would be helpful to many other programmers, that is supported by facts and data and science.

Programming is indeed a field that does require some passion. If you've been programming for a few years and haven't developed a taste for it by now, it seems doubtful to me that anyone would suddenly develop one overnight. However, if you were able to stick with doing something you're not very enthusiastic about for a period of years, maybe there's still a kernel of something there to work with. Or perhaps you're just wearing golden handcuffs.

Environment plays a big part in any job, no matter how intrinsically amazing that job might be. Who do you work with? What are you working on? What kind of environment do you program in:

• A startup?
• A small business?
• A big business?
• A consultancy?
• Freelance?

The "programming" in each of these situations, and the other peer programmers you'll be working with, will be radically different. Consider if the environment and peers may be the problem. Have you tried changing those up, first, before conclusively deciding you need to leave the field forever?

Beyond that, there are lots of related fields where programming skills are advantageous, without having "sit down and write code all day" as part of the job description. So let's think. What jobs exist where …

1. Programming skills and a deep technical background are typically in the hiring requirements.
2. There is a documented record of ex-programmers moving into these positions and being successful.
3. There are a reasonable number of such jobs available worldwide.

Here's where I really wished I could have asked this on Stack Exchange, because I'd much rather crowdsource data to support the above three points, but the best I could come up with on my own is:

• Product/Program Manager
• Project Manager
• QA / Testing (good testers are worth their weight in gold)
• Build Engineering (this stuff is hard)
• System Administrator
• Technical Sales
• Technical Writer
• Business Analyst / Programming Analyst

In many of these roles, people that truly know the nuts and bolts of programming are quite rare. That's unfortunate, because a deep technical background lets you actually understand and explain what is going on, to customers, to business stakeholders, to peers on related teams. At the very least nobody can dazzle you with technical BS, because you're equipped to call their bluff.

I've seen less "adept" programmers self-select into related roles at previous jobs and do very well, both financially and professionally. There is a lot of stuff that goes on around programming that is not heads down code writing, where your programming skills are a competitive advantage.

Career questions are tough, because ultimately only you can decide what's right for you. But if you're a programmer who no longer likes to program, your technical background can at least open the door to a number of related professions.

* Yes, you should quit. Jeff is a total jerkface.

I've been a Microsoft developer for decades now. I weaned myself on various flavors of home computer Microsoft Basic, and I got my first paid programming gigs in Microsoft FoxPro, Microsoft Access, and Microsoft Visual Basic. I have seen the future of programming, my friends, and it is terrible CRUD apps running on Wintel boxes!

Of course, we went on to build Stack Overflow in Microsoft .NET. That's a big reason it's still as fast as it is. So one of the most frequently asked questions after we announced Discourse was:

Why didn't you build Discourse in .NET, too?

Let me be clear about something: I love .NET. One of the greatest thrills of my professional career was getting the opportunity to place a Coding Horror sticker in the hand of Anders Hejlsberg. Pardon my inner fanboy for a moment, but oh man I still get chills. There are maybe fifty world class computer language designers on the planet. Anders is the only one of them who built Turbo Pascal and Delphi. It is thanks to Anders' expert guidance that .NET started out such a remarkably well designed language – literally what Java should have been on every conceivable level – and has continued to evolve in remarkably practical ways over the last 10 years, leveraging the strengths of other influential dynamically typed languages.

All that said, it's true that I intentionally chose not to use .NET for my next project. So you might expect to find an angry, righteous screed here about how much happier I am leaving the oppressive shackles of my Microsoft masters behind. Free at last, free at least, thank God almighty I'm free at last!

Sorry. I already wrote that post five years ago.

Like any pragmatic programmer, I pick the appropriate tool for the job at hand. And as much as I may love .NET, it would be an extraordinarily poor choice for an 100% open source project like Discourse. Why? Three reasons, mainly:

1. The licensing. My God, the licensing. It's not so much the money, as the infernal, mind-bending tax code level complexity involved in making sure all your software is properly licensed: determining what 'level' and 'edition' you are licensed at, who is licensed to use what, which servers are licensed... wait, what? Sorry, I passed out there for a minute when I was attacked by rabid licensing weasels.

   I'm not inclined to make grand pronouncements about the future of software, but if anything kills off commercial software, let me tell you, it won't be open source software. They needn't bother. Commercial software will gleefully strangle itself to death on its own licensing terms.

2. The friction. If you want to build truly viable open source software, you need people to contribute to your project, so that it is a living, breathing, growing thing. And unless you can download all the software you need to hack on your project freely from all over the Internet, no strings attached, there's just … too much friction.

   If Stack Overflow taught me anything, it is that we now live in a world where the next brilliant software engineer can come from anywhere on the planet. I'm talking places this ugly American programmer has never heard of, where they speak crazy nonsense moon languages I can't understand. But get this. Stand back while I blow your mind, people: these brilliant programmers still code in the same keywords we do! I know, crazy, right?

   Getting up and running with a Microsoft stack is just plain too hard for a developer in, say, Argentina, or Nepal, or Bulgaria. Open source operating systems, languages, and tool chains are the great equalizer, the basis for the next great generation of programmers all over the world who are going to help us change the world.

3. The ecosystem. When I was at Stack Exchange we strove mightily to make as much of our infrastructure open source as we could. It was something that we made explicit in the compensation guidelines, this idea that we would all be (partially) judged by how much we could do in public, and try to leave behind as many useful, public artifacts of our work as we could. Because wasn't all of Stack Exchange itself, from the very first day, built on your Creative Commons contributions that we all share ownership of?

   You can certainly build open source software in .NET. And many do. But it never feels natural. It never feels right. Nobody accepts your patch to a core .NET class library no matter how hard you try. It always feels like you're swimming upstream, in a world of small and large businesses using .NET that really aren't interested in sharing their code with the world – probably because they know it would suck if they did, anyway. It is just not a native part of the Microsoft .NET culture to make things open source, especially not the things that suck. If you are afraid the things you share will suck, that fear will render you incapable of truly and deeply giving back. The most, uh, delightful… bit of open source communities is how they aren't afraid to let it "all hang out", so to speak.

   So as a result, for any given task in .NET you might have – if you're lucky – a choice of maybe two decent-ish libraries. Whereas in any popular open source language, you'll easily have a dozen choices for the same task. Yeah, maybe six of them will be broken, obsolete, useless, or downright crazy. But hey, even factoring in some natural open source spoilage, you're still ahead by a factor of three! A winner is you!

As I wrote five years ago:

I'm a pragmatist. For now, I choose to live in the Microsoft universe. But that doesn't mean I'm ignorant of how the other half lives. There's always more than one way to do it, and just because I chose one particular way doesn't make it the right way – or even a particularly good way. Choosing to be provincial and insular is a sure-fire path to ignorance. Learn how the other half lives. Get to know some developers who don't live in the exact same world you do. Find out what tools they're using, and why. If, after getting your feet wet on both sides of the fence, you decide the other half is living better and you want to join them, then I bid you a fond farewell.

However, I'd also be lying if I didn't mention that I truly believe the sort of project we are building in Discourse does represent most future software. If you squint your eyes a little, I think you can see a future not too far in the distance where .NET is a specialized niche outside the mainstream.

But why Ruby? Well, the short and not very glamorous answer is that I had narrowed it down to either Python or Ruby, and my original co-founder Robin Ward has been building major Rails apps since 2006. So that clinched it.

I've always been a little intrigued by Ruby, mostly because of the absolutely gushing praise Steve Yegge had for the language way back in 2006. I've never forgotten this.

For the most part, Ruby took Perl's string processing and Unix integration as-is, meaning the syntax is identical, and so right there, before anything else happens, you already have the Best of Perl. And that's a great start, especially if you don't take the Rest of Perl.

But then Matz took the best of list processing from Lisp, and the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.

And he somehow made it all work together so well that you don't even notice that it has all that stuff. I learned Ruby faster than any other language, out of maybe 30 or 40 total; it took me about 3 days before I was more comfortable using Ruby than I was in Perl, after eight years of Perl hacking. It's so consistent that you start being able to guess how things will work, and you're right most of the time. It's beautiful. And fun. And practical.

Steve is one of those polyglot programmers I respect so much that I basically just take whatever his opinion is, provided it's not about something wacky like gun control or feminism or T'Pau, and accept it as fact.

I apologize, Steve. I'm sorry it took me 7 years to get around to Ruby. But maybe I was better off waiting a while anyway:

• Ruby is a decent performer, but you really need to throw fast hardware at it for good performance. Yeah, I know, interpreted languages are what they are, and caching, database, network, blah blah blah. Still, we obtained the absolute fastest CPUs you could buy for the Discourse servers, 4.0 Ghz Ivy Bridge Xeons, and performance is just … good on today's fastest hardware. Not great. Good.

  Yes, I'll admit that I am utterly spoiled by the JIT compiled performance of .NET. That's what I am used to. I do sometimes pine away for the bad old days of .NET when we could build pages that serve in well under 50 milliseconds without thinking about it too hard. Interpreted languages aren't going to be able to reach those performance levels. But I can only imagine how rough Ruby performance had to be back in the dark ages of 2006 when CPUs and servers were five times slower than they are today! I'm so very glad that I am hitting Ruby now, with the strong wind of many solid years of Moore's law at our backs.

• Ruby is maturing up nicely in the 2.0 language release, which happened not more than a month after Discourse was announced. So, yes, the downside is that Ruby is slow. But the upside is there is a lot of low hanging performance fruit in Ruby-land. Like.. a lot a lot. On Discourse we got an across the board 20% performance improvement just upgrading to Ruby 2.0, and we nearly doubled our performance by increasing the default Ruby garbage collection limit. From a future performance perspective, Ruby is nothing but upside.

• Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn't cool, it's just a bunch of boring old Ruby code. Personally, I'm thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. That means the rest of us who just like to Get Shit Done can roll up our sleeves and focus on the mission of building stuff with our peers rather than frantically running around trying to suss out the next shiny thing.

And of course the Ruby community is, and always has been, amazing. We never want for great open source gems and great open source contributors. Now is a fantastic time to get into Ruby, in my opinion, whatever your background is.

Even if done in good will and for the best interests of the project, it's still a little scary to totally change your programming stripes overnight after two decades. I've always believed that great programmers learn to love more than one language and programming environment – and I hope the Discourse project is an opportunity for everyone to learn and grow, not just me. So go fork us on GitHub already!