Big Think Interview With David Heinemeier Hansson
David Heinemeier Hansson is a Danish programmer and the creator of the Ruby on Rails open source web development framework. He is also a partner with Jason Fried at the web-based software development firm 37signals. In 2005 he was given with the Hacker of the Year by Google and O'Reilly award for his creation of Ruby on Rails. He and Fried have also co-authored the New York Times bestseller "Rework," which reveals their secrets for boosting business productivity in the Internet age.
Question: What inspired you to create Rails?
David Heinemeier Hansson: Rails really started as an application. It never started as Rails. It just started as me wanting to build Basecamp in this new program language—new to me program language—called Ruby. And as I was starting to build a Basecamp, our project management tool at 37Signals, I found a need to just build a bunch of tools for it. I had to have something to talk to the database, something to generate some HTML. All these things I weren’t finding good existing solutions for in Ruby, so I basically just had to do it myself.
And what I found was someway, halfway into the creation of Basecamp that I had this big toolkit now. I’d been building all these little things that I needed as I needed them, and now I discovered that I had a whole toolkit. And I also discovered that I like programming now so much better than I ever had in the past. So what was making me happy about this? Well, first of all, obviously, the Ruby language, but also all these tools I’d built for myself. They just felt just right in a way that no other programming language or environment had before.
So I started thinking: hey, if I’m having so much fun building with these tools, building with Ruby and then what became Rails, it can be selfish not to share that. All the things that we build at 37Signals are built on top of open source tools. We use Linux, MySQL, Ruby itself. All of these infrastructure components are open source; they’re free, and you can use them, you can change them, you can do whatever you want. So it kind of feels like once you’re in that world, you’d be an ass if you just developed something you liked a lot, and then you just kept it to yourself. Like, “This is my toy, and nobody else can play.” So that seemed like a bad idea.
So about halfway through the development of Basecamp I just realized I’m going to release this. I’m going to put it out into the world, but, before I do so, I want it to be good. I’d used a bunch of software that I found really, really frustrating to get into because either the documentation was bad, or the examples were lacking, or it just didn’t feel polished. So I wanted Rails to feel really polished. I wanted it to have great documentation, be easy to get started with and get into, so I actually waited about a year from when I decided I was going to release this, until I actually did. And it wasn’t until that year later where it felt good enough for somebody else to use.
Question: If you were to start again, would you choose Ruby as the basis for Rails?
David Heinemeier Hansson: If I had to do Rails today, I would absolutely choose Ruby. Since discovering Ruby, I really haven't been all that interested in other program languages. It's kind of funny; when I used to develop in PHP or the stuff I did in Java, I was always looking for something else. I was always looking for another programming language, another... just something else, in part just to distract me from being bored in the languages I was in.
But with Ruby it was kind of different. Ruby right from the beginning just fit like a glove. It was this magic language that sort of like your thought's been waiting for. Like this was the language that was going to express what I have to say in such an eloquent way that I'm frequently just astonished. I'll write a piece of code and look at it and say, “Geez, that's beautiful!” And I would not have that reaction before, just because other program languages just to me don't have that emotional appeal. Ruby has just a deep emotional appeal of how beautiful you can write something. It feels much closer to my thought process. It feels like I'm expressing exactly what I want to say in code without translating it. Usually you call it code because it's sort of hard to read and hard to understand, but Ruby really shouldn't be called code because it's much closer to human thought than code is.
Question: What exactly is the relationship between Ruby and Rails?
David Heinemeier Hansson: Ruby is sort of the basic language. You can say anything in Ruby. You can talk about anything in Ruby. There's no limits to that. Rails is much more like a genre, so rails is like "thrillers." Like, if you want to make a thriller, you use Rails for that. If you're using something else, if you want to write a love story, then you probably use another framework or something else entirely. Ruby is great for both of those things, but Rails is really the tool that sits on top of Ruby that just makes Ruby great for web development... talking to a database, outputting, HTML, putting all these things together and making great web applications.
Question: What makes Ruby a special language?
David Heinemeier Hansson: To me good programming is just like good writing. It's succinct. You're expressing what you want to say in as few words as possible. You're picking just the right words for the sentence, and it's sort of a grand thing. A program is just like an article or a book; it's composed of tiny things like words that form into sentences, and paragraphs, and chapters, and so forth. A programming language—a good programming language—allows you to build a program in just the same way.
So you'll have methods that are really short. A big part of what makes Ruby so special to work with is just how much expression you can pack into few lines of code. When I compare it to something like Java where it takes perhaps ten lines to express a very simple operation, that same operation can be expressed in a single line of Ruby. And that just makes understanding the entire program that much easier when the density of expression is so much higher, and it's not just because it's short. There's plenty of programming languages where you can write exceptionally short code, and it's completely unreadable afterward. Ruby has this uncanny ability to just be shortened the same way your thought would be short, but no shorter than that.
The other part of it is also having a grand or free mode of expression that there are many different ways that you can say something. So for example: Lots of programming languages have—or all program languages have—conditionals. If something is true, do this. Now, sometimes you want the positive version of that. Like, “If employee works here, then print this screen.” Sometimes you want the opposite. In most program languages, you would go about that by saying, “If not programmer works here, then do this.” That's not a very natural way of expressing that. You would never say that in real life.
In Ruby, you can say, “Unless the programmer works here, do this.” So it's just all those little things where the creator of Ruby thought about the whole picture. It's not just that you can get something done. All programming languages can do the same things. There's nothing you can do in Ruby that you couldn't do in some other programming language. What makes Ruby special is how you say it.
Compared to natural languages, I think there's also just something to the tone and they rhythm of it. I'm Danish. I speak Danish, and I admit that Danish is not a very pretty language. Thankfully, it's not as ugly as German, which I think is probably one of the ugliest languages of all time. But if you compare something like German to something like French, you don't have to speak either language to hear that French is obviously the prettier language.
I think if somebody who doesn't even know code, they can look at a piece of Ruby code, and they can appreciate that Ruby is French and Java is German. That's sort of really the appeal to it. Because you have to work with this stuff all the time. Programmers often work for many, many, many hours a day, and this is your main mode of expression. It has to be good. If it's not good, if you're speaking in an ugly language every day for eight or ten hours a day... well, I won't say that it turns you into an ugly person, but I like to just surround myself with beautiful things. Ruby is beautiful; lots of other programming languages are much less so.
Question: Do programmers need to like the languages in which they code?
David Heinemeier Hansson: I think in the past, programming languages and environments have been determined by everything but the beauty of expression. It's been determined by “We have to make this really fast. We have to make this really efficient. We have to make this really logical. There has to be only one way of doing things.” All of these other concerns that you would think about when you would think about somebody approaching it in a very sort of binary approach. That's sort of the best way I can express it.
Ruby comes from a much different angle. In fact, the creator of Ruby said that his main goal of creating Ruby was to make programmers happy. Now, you're introducing something that in many ways seems like a foreign concept. You're talking about code. What does happiness have to do with anything? How does happiness play into this stuff? It absolutely does because programmers—surprisingly enough, I'm sure to a lot of people—are humans, too. And humans just respond to emotional things. They respond to beauty, they respond to a general sense of well being and liking your tools. It's not enough that your tools can get the job done. It's how they get them done. It's whether you like wielding those tools day out and day in.
And I've talked to a lot of Ruby programmers who came to sort of the edge of their career thinking they've been working in Java, or C-Sharp, or some other language that was just driving them miserable. And they were thinking, “You know what? I know how to do this stuff, but it's probably not for me. I'm not happy working with these languages or environments every day. I'm going to quit.” And then some of them found Ruby. And it almost sounds cheesy as sort of a religious experience that they find this program language that all of a sudden makes it interesting for them again to be programmers. But it's absolutely true. I felt exactly the same way. I was absolutely not convinced that I was going to be a programmer when I was working with PHP and Java.
To me, at that point programming was just something I had to do to get programs. It was sort of just a functional thing I unfortunately had to go through in order to realize the ideas that I had for programs. For me, Ruby just changed that such that the act itself was pleasurable. And I think that's just a magic moment. When you change over from not just being able to do the job to actually enjoying the job. That's just a huge difference. And I think that the product in the end also reflects that. The programs I write now are much better than the programs I wrote when I didn't like my tools.
Question: Ruby on Rails lowers the technical expertise necessary to create a web application; is expertise becoming less critical?
David Heinemeier Hansson: I think Ruby on Rails absolutely lowers the bar in terms of what it takes to get a web application going. Some people see that as a negative thing. Like, “Oh, the barbarians are at the gate” or “We've got all of these unwashed masses flowing into our beautiful, pristine programming communities.” I've heard things a lot of times before. Visual Basic before that was chastised for bringing in sort of "unpure" programmers. I think it's bullshit. There is no such thing as the "pure" programmer, and I think that what's magic about the Ruby in Rails community is exactly that it attracts people from all different camps, that it attracts people who are not primarily programmers. I find that often the best ideas come from people who are not programmers, people who bring just an entirely different perspective on things.
In fact, being a newbie is such an important stage because that's where you question everything. When I first came to Ruby, I questioned everything. I was like, “Why doesn't this thing exist? Why is this hard? That's stupid. We should change that.” You have this sort of initial naïve approach to things that makes it impossible for you just to see what should be impossible. You just do.
If I had known in the beginning how much work it would have been to actually create Rails, I probably would never have started. I started because I just found one little thing that to my naive newbie sense seemed easy to do. I think it's really important that we keep this flow of new people, new blood, fresh blood coming into the community, and I also think it's wonderful that we're creating a larger group of people who can create applications. Trying to have protectionism is never a good idea. Trying to sort of set up, like there should only be these carefully trained programmers who are able to make programs... Bah. That's not how it should be. We should absolutely have programmers of all kinds. Some of these programmers will be new, and they won't know everything, and they'll create shitty programs. But you know what? Most of the time, a shitty program solves the problem. You don't need perfect programs all the time. There are so many problems in the world that the tiny group of pristine, white knight programmers just can't solve. They can't solve all of them; there's just not enough of them. So we need programmers of all levels to solve the programming problems of the world.
Question: How simple can things get in terms of programming?
David Heinemeier Hansson: So, for me it's really there's two angles to this. There is we can absolutely make things simpler. I think I made a lot of web development a lot simpler with Rails. But there is a natural physical limit where at the end programming is just choices. How should the program work? What should happen when you click this button? Those choices are ultimately what's the key to programming, and you can't get out of that, which is also why I think that sometimes it's a little bit of a pipe dream to think that there's going to be these magical new environments where somebody who knows nothing about programming will just be able to drag and drop a few things into a box, and then, voila!, you will have the most amazing program in the world. No. It's really not gonna happen like that because to have the most amazing program in the world, you need to care about a thousand decisions, and recording those thousand decisions takes a programming language.
So, there is a lower limit to how simple it can get, and that lower limit is, “Do you care about these decisions?” Once you... All the decisions you care about have to be codified somehow, and I don't know of any more effective way of doing that than with a great program language. So I'm not a big believer that at some point we're all going to create these wonderful applications. There will be a class of applications where you design a niche and say: okay, if I have to just slightly tailor some accounting software—yeah, there can be something simple for that. But if you want the freedom of expression to create any type of web applications today, you need a tool that's expressive enough to enable that, and that is a programming language. It doesn't get any simpler than that.
Question: Last year, you merged the Rails and Merb teams. What has that process been like?
David Heinemeier Hansson: So, I think the merge of the Rails and Merb teams have gone exceedingly well considering what led up to that. What lead up to that was a fair amount of petty and fighting, to be honest. Potshots at crossbow from one camp to another, and it was just bad. And it was useless. What we're here for is moving, sort of, in some ways, the state of the art forward. Why waste time on these petty concerns?
So, I think after the merge we realized that most of those petty squabbles were really just that; they weren't deep philosophical differences. We actually wanted the same things. We were perhaps speaking slightly different languages to each other, and misunderstandings and all the other stuff that goes on when you have sort of two camps working against roughly the same goal... But what we realized was that once it got down to the code, once it got down to the decisions that were really concrete about “How should this work?”—we were in agreement. There was no big philosophical battles back and forth. Once it got down to code we just all magically agreed.
I think that that has worked really well, and I'm incredibly proud of the product that's coming out of that, which is Rails 3, which we're just on the verge of releasing. It's been sort of a long walk to get there, but that's fine. Rails 2, as it is today, works great. There is no immediate rush to get to Rails 3, and now that we're almost here it seems... yeah, it was worth the wait.
Question: When will Rails 3 come out?
David Heinemeier Hansson: Sure. So, we're incredibly close to releasing the final version of Rails 3. Actually, right now we have sort of an internal target that's this week for the release candidate, and then however long it takes after that to get the final version out. But there's already plenty of people who are using Rails 3 in production. At 37signals we have at least a handful of applications that are already running the development version of Rails 3, so we're essentially there. We're dotting the i's and crossing the t's and just making sure that everything is really nice exactly because there is not that... there's not an external push or rush on us. There's no trade show that we have to make, there's no big revenue coming in when we actually release it. It's just mostly for pleasing ourselves, so it just has to be good, and we'll wait until it is, but it looks like we're finally there.
Question: What’s your take on Microsoft’s web platform versus Rails?
David Heinemeier Hansson: So, it's actually been a very long time since I've played around with Microsoft's web offerings myself. I did some ASP back in the late 90's, and then I've been sort of paying attention to C-Sharp and what my fellow Danish countrymen, Annis, Heims, and Burke, have been doing over at Microsoft, and there's definitely some good stuff from their perspective. From that perspective of developing a programming language, and a framework, and the tooling, it's pretty good. It just happens to be that I don't share that perspective.
I don't believe that programming languages need to rely on heavy tooling in the sense that Microsoft does with Visual Studio. I believe that program languages and frameworks should be incredibly pleasurable to write if you have nothing but a text editor. To me it's sort of a crutch when you have to rely on tooling on top. It reveals to me that the underlying language and platform is not succinct enough, it's not expressive enough. So there's just a difference of philosophy there. There's pros and cons, though. There's absolutely pros to the heavy IDE, Visual Studio, assistance, and completion, and all that stuff. It's not that either is completely bad, and the other is completely good. It's just that I enjoy much more that simple, closer to the metal so to speak, approach that we've been taking with Ruby in Raills.
So, it's also funny, though, to see them take inspiration. They've launched an NBC framework for their platform that is heavily inspired—let's say that—from a lot of the ideas that we've had fun with in the Rails camp, and that's great to see. It's great that we can all share ideas. We're all standing on the shoulders of giants, and ideas should move around. I don't think it's anywhere close, still don't. I mean, they've borrowed some good ideas, and that's great, but we still have an incredibly different approach to things. So, if you like the Rails approach to things, I don't think you're gonna be satisfied with the Microsoft expression of that, but that's fine. We don't all have to be the same. Not all programming languages have to be constructed the same. In fact, it would be boring if they were. So the world is a pretty big place. There's plenty of room for many approaches.
Question: What is Microsoft doing to compete with popular open source frameworks like Rails?
David Hansson: So I think the economic motive for Microsoft for doing all this is very clear. They want to sell Windows and they want to sell SQL Server and they want to sell that entire stack of stuff. And that entire stack of stuff doesn't have a very good track record of working well with the other side of things, the open source side of things. So if that's not true, then you pretty much have to do everything yourself. I find that most Microsoft shops are exactly that, they're Microsoft shops. They use Microsoft from top to bottom, everything is Microsoft. It's Microsoft version control, it's Microsoft database server, it's Microsoft web servers, it's Microsoft development languages, it's Microsoft everything. And they get some benefits of sort of the virtual integration from that, but it also makes the community very insular, in my mind. I've met a fair number of Microsoft people who just know a lot about Microsoft stuff. And I mean, that's fair. It's just not the same kind of people that we really associate otherwise.
Versus on the open source side of things, like I talk to plenty of people who work in Python or other languages or frameworks, there's much more, I think, sharing of ideas between the different camps on, that are the line. Like, it's sort of pretty much open source or not open source. If you're in the open source world, you talk to other open source developers and look at other open source solutions. If you're on the sort of proprietary closed, whatever you want to call it, Microsoft-side of things, you just stay in your own camp.
So it makes perfect business sense to me for them to devote all this time to it. I don't know if it makes business sense for a lot of shops to choose that. Most of the time, it doesn't seem to pan out, like I would never want to start my business using stuff that would add up to heavy, heavy license fees. Once you get into the open source mentality and mindset, there's just something almost offensive about that. Just saying, like, "I don't want to be locked in to somebody else's platform that I can't actually change." It comes down to sort of a fundamental sense of freedom. Do I have the freedom to change and switch out and substitute the tools that I'm using with? Or am I bound to some master? And I picked what I find to be freedom in that sort of dichotomy, even if it's a little contrived.
Question: Will Microsoft continue to be dominant in 10 years?
David Hansson: I think that Microsoft is still a huge and profitable company and will be for a very long time. I think that they're dying by 1,000 cuts, but those 1,000 cuts might take 1,000 years to inflict a mortal wound. What I enjoy most, though, is unlike the '90s, where you had to care, and almost fear, Microsoft, that they were the big bully and they could control everything, today, for me, they're irrelevant. I don't care. They have no bearing on what I do. I don't have to use any Microsoft technology, I don't have to use Windows for this or any of their tools for that, and in fact, I don't, and haven't for a very long time. I sort of still have to care about Internet Explorer and making the web apps I create work on their stuff, but even that is becoming less of a concern. Gone are the days of Internet Explorer having 95% market share, long, long gone. Now, it's just sort of a nuisance. "Oh, crap, we have to deal with IE6, oh, all right." But, there's a big difference between fearing the 800-pound gorilla and then just waving at flies. Oh, these are annoying flies, get out of my face.
So, to me, I don't know. I've talked in the past about, it kind of feels sad. Like there was something interesting about having that evil empire there. There was something, a rallying cry, actually, for the open source movement, or we're against the evil Microsoft people. And now, they're not there any more. The evil genius has left the building and now you just have a sales organization that pushes stuff out to grey boxes and corporations that I really don't have to deal with that much. So, it's more just, for me, sad that they've been relegated to irrelevance, from my perspective. I'm sure they're still relevant for a lot of people that have to use it or even, heck, enjoy using it. Weird that might sound from my perspective, but again, big world, lots of room, no longer do you have to fear the gorilla, so that's good. We can just go on with our business and not worry about them coming in and stomping on stuff.
Question: Do you think any company can dominate the Web the way Microsoft dominated computers circa 1992?
David Hansson: I think the wonderful thing about the web is just that it's a level playing field. There is no one company that controls it, in no important way, like it used to be in the past, with the Windows monopoly, or it is today in some senses, with some of the iPhone, iPad, or Android platforms. On the Web, you work for nobody else. On the Web, you work for yourself. And you can pick the tools that you please for it. That's why Ruby and Rails happened for me. If I had had to build OS10 applications, or Windows applications, I would have had to use the tooling that those masters provided me with because that's usually how it goes. Yeah, you can develop with something else, but if you want that native, good experience, you damn well better use their tool and go in and be a sharecropper in their field.
On the Web, there's no such thing. It's an open standard. As long as you can generate HTML, which is something that everybody has sort of agreed upon how it should be read, you can use whatever you damn please. So that's really special. And I think that we sometimes take that for granted. It's easy to forget that it didn't used to be like this. It didn't used to be so open and so free where you could just anything you wanted and the user wouldn't care in the end. You can make the best web application in the world with any program language in the world, which is just incredible freedom and incredible freedom for innovation. New upstarts, new frameworks, new languages, they can all play on the same field. And there's nothing that sort of holds them back or makes them second-rate citizens.
Question: The trend now is towards client-side applications, but Rails deals primarily with server code. Does Rails need to evolve to keep up?
David Hansson: So Rails have actually been interested in the client side for a long time. When AJAX sort of first got its initial push, when it got its acronym, back in, I think, 2006, Rails was one of the first server-side frameworks that said, "This is going to be huge and we're going to do something about that." So we put a Java script library straight in the Rails distribution prototype and we built a bunch of helpers around that to make it easier to create AJAX applications with Rails. And today it's almost inconceivable that you'll build a new, modern web application that doesn't have some aspect of AJAX in it.
Now, some people go a lot further than just having some aspects of AJAX in it. Some people have their entire application in Java script and just use the back end as a data store for that. I don't find that development experience that pleasurable. I have come to tolerate Java script now that there are great libraries and frameworks like Prototype around it to sort of make it a little more pleasurable, but it's still no Ruby. Ruby is still my first love in terms of programming languages. And however much you paint up Java script, it's not going to beat that. Which is fine.
So, from the development side of things, I don't enjoy Java script programming nearly as much or in the same league as I enjoy Ruby programming. Okay, fine. On the client side of things, like is this better for the user? I think there's something special and appealing to me about the mix, the mix of how the web is discreet pages and you use hyperlinks to jump from place to place and AJAX is sort of sprinkled across to make certain common operations a little faster. I tend not to like very heavy, single-screen-based web applications. They can be fine for some things, but I think the Web has this unique category of applications that fit into that sort of middle ground between one screen, or mainly one-screen applications and static web pages. And that's an awesome sweet spot and I think it works incredibly well for a wide array of applications. And I wouldn't want them to be any different. There are certainly some people developing for the web who long for the days of the desktop application and finally see that now AJAX is bringing that back. Well, we've heard that story a lot of times. First it was Java that was going to do this, applets were going to bring back the desktop experience and we could get rid of this nasty HTML. Then it was Flash that would bring this forward. And now AJAX or anything else like that. There's been so many attempts to bring the desktop to the web, and none of them have succeeded in becoming the dominant approach to building web applications, and I think there's a good reason for that, because that's not what users want. Like that sweet spot in the middle is great and it's actually desirable on its own terms.
Question: Will cloud computing take over completely?
David Hansson: Google is certainly trying to bring about the day where you can just have a dumb computer and everything happens in the cloud. I don't know if that's even desirable yet. I don't know why it has to be either/or. There are certain types of applications, especially information-based or network based applications that are just great on the web. Like editing your, say, movies or pictures? Why does that have to be online? Why does the act of doing that itself have to be online? If there's not a big benefit to that, then I don't see any particular reasoning to forcing it to be there. It's fine to have local applications, too. And we don't need the either/or's. We can take the best of the web and the best of the collaboration that that enables and enjoy that, for all those applications where that's a good fit. And then we can use the awesome local, graphical power and computing power of a modern computer to do those other heavy things. I think that that split, that duality is just fine.
Question: What do you make of Apple’s mandate that all apps for iOS devices be written in specific languages?
David Hansson: Apple really let me down, personally. I take personal offense when they started mandating that there are only certain languages and certain platforms that you can use to develop iPhone and iPad apps. It just seemed like such a—and I am overstating this and I know that that's sort of not helpful for the debate, but I can't help it—fascist move. It seemed entirely unnecessary to exert that level of control. To force people into that. Because the fact is, they're winning on their merits. Control and heavy-handed operations like that is something you do when you're desperate. That's something somebody backed into a corner would do. That's something, we used to think that was the stuff that Microsoft pulled and everybody was up in arms about that. We already love Apple! We love Apple on their merits, because they produce superior hardware and software. Why can't they just be confident that we'll continue to do that and if their tools are so wonderful and so magical, of course, people will use them. I find it just absolutely offensive that they would want to dictate, to enter the Magic Apple Kingdom, you can only speak German, no Frenchmen allowed here. Like that just seems—why?
I mean, I read the supposed reasons for why this would happen, oh, if we allowed cross-platformed tools then only shitty applications will be made, blah, blah, blah, blah, blah. Have you so little faith in the marketplace? Have you so little faith in the great native applications winning? Why can't you just see what happens, so if people create cross-platform applications and put them out and they're shitty, nobody will use them, nobody will buy them. It just seems like such an insecure move. And I also think it's incredibly ironic when you look at what Apple does themselves. When they released iTunes for Windows, did they follow all the Microsoft standards, did they use Microsoft development tools? No they didn't. They brought over their cross-platform stuff and they made iTunes work on Windows because of that. And sometimes that's what you do. Apple probably wouldn't have done iTunes, or I don't know, maybe they wouldn't have done it as fast if they had to build it from scratch, even though that from scratch would've been better because iTunes on Windows is supposedly sort of a shitty experience.
And there are plenty of other examples of applications that are great cross-platform applications. Firefox, for example, the majority of the code basis is cross-platform and it's a wonderful application. LightRoom from Adobe is a great application, it works great on multiple platforms. So if great applications can be created, then why would you shut those out just because it's also possible to create shitty stuff?
And now, sort of, I don't know, third or the fourth point against this, the app store is already full of shitty software. There are 200 or 300,000 applications in there. Do you think that they are all creampuffs? That they're all wonderful pieces of unique, beautiful software? No, they're not. Tons of them are just shitty crap. So the argument that Apple is doing this to increase the quality of the app store just falls flat when you look at all the junk that's already in the app store. This is not a carefully selected gallery, this is just a warehouse of shit. So don't give me that.
I think what happens here is power corrupts and absolute power corrupts absolutely. And just as well, market share corrupts, and absolute market share corrupts absolutely. Apple enjoys incredible market share of smart phones with the iPhone. So they can do stupid shit without it costing them everything and they can perceive that because we can, because we're able to force people to work this way, that's a good thing. That's a very short-sighted approach to things. Remember, that's how Apple came into be. The Apple camp is full of Microsoft refugees, people who were tired of being haunted by Microsoft, tired of being forced and controlled into certain ways of working.
It might work in the short term, but it doesn't seem like a long-term play to me. And again, it seems like such an unnecessary thing to do! When you already have the greatest stuff in the world, you don't need to do this stuff. So it was just a massive let down from a company I otherwise love. Which is why it stings double. If it was just somebody I didn't care about, didn't give a shit about, then who cares? This is Apple. This is the same Apple where I frequently cherish their products so much. Like, I really love so much of the stuff that they're putting out that it hurts double bad when they're doing stupid things like this.
Question: Do you see this and the iPhone 4 antenna fiasco as chinks in Apple’s armor?
David Hansson: I think that Apple currently is so good at what it does, so good at the hardware design, so good at the vertical integration of making everything just work, that they will survive this. Unfortunately, because I think that that's sort of the, it's the pros and the cons of this. Like on the one hand, they create so much wonderful stuff, that when they screw up in these minor ways, it doesn't hurt them enough for them to take the true lessons away from this. I don't think that Apple really thinks any differently of mandating these tools to people, say, you have to develop iPhone and iPad applications in these ways. This sting that came from the uproar of developers saying, "This is bullshit, we are walking out," is just not big enough, which is a damn shame.
Which is also way, sort of related to that, the whole iPhone 4 antenna-gate thing, was very interesting to watch. For a long time, they just didn’t give a damn. Bloggers would claim, like shout about it, or other publications would shout about it, nah, nah, nah, it's all isolated case, and then boom! Something hit them really hard, that Consumer Reports thing. And then all of a sudden, oh, wait, maybe it did matter, maybe we should address this. And it didn't even matter for the marriage, because for the marriage, I think there's not a big issue. The iPhone 4 antenna is just fine and I'll take the trade off of sort of better reception and then I can't hold it in a certain way. In some ways, that's exactly what I love about Apple. I love that Apple is willing to make controversial trade offs, because they're willing to say, "All right, fine, we'll increase the reception of this phone, if you just don't hold it in this one way." I actually find that's awesome! I just would've found it slightly more awesome if they would've owned up to it and just said, "Damn, that's how it is, because that's how it works."
Just like with the, I remember with the Macbook error when that came out. No internal CD drive? How is this possible? How can I use a computer that doesn't have that? Well, it's a trade-off. If you want a computer that's so slim that it almost looks like a piece of paper, then you have to give up stuff. I love that. I love those controversial trade-offs. I just don't, I don't love how they went about the iPhone thing, just seemed very PR-driven in the negative sense of that word, and I certainly don't like the way they went about the iPhone developer kit. But none of these things are going to kill Apple. If they continue to rock as they are now, nothing is going to catch them any time soon. And I think that's a shame, I would wish that Apple had better competition. Even the Android stuff now, which is getting pretty good on a lot of levels, is still nasty in so many levels. It's still so poorly designed as a coherent experience. They have these peaks of glory, but the whole package is just, I wouldn't want that phone. And I'm kind of sad about that. I wish Apple had more credible competition that would prevent them from doing the stupid shit that they're doing.
Question: How do you balance developing open source software and the need to grow your own business?
David Hansson: So, the way I divide my time between open source development and growing my own business is to combine those two things. So when I work on open source development, it's usually for myself. I work on features that I need for my business. I work on buck fixes that I need for my business. And I think the wonderful thing about open source is that if we all do that, if we all just work on our own problems and our own design features and then share them with each other, we'll get something amazing. That's exactly what Rails is. In fact, I think things start to go wrong once that's no longer true. Once you start working on features for other people and designing for other people and imagining what they might need and imagining how they might use it, that's hard. It's really hard to design for other people like that. It's so much easier to design for yourself. And when you design for yourself, you know exactly when it's right. You know when the grip is just perfect. You know when the sharpness of the blade is just right, not too sharp, not too dull, just there. You can't get to that point of excellence by approximation. It's very, very hard to just try to envision what the good thing is if you can't feel it on your own body.
So, for me, there's no conflict. I work on open source stuff when I need it. And when I need it, it makes perfect business sense to do it and it's sort of a byproduct of that, that I didn't get to share it. I'm going to be no poorer because I shared this open source software that I developed anyway. I needed it already. So if I give it away after it's already done, what am I losing? Exactly nothing. I'm gaining a ton of stuff though. I'm gaining that I'm putting this into a wonderful, beautiful commons and everybody else is doing the same thing and all the actors walk away from that richer.
Question: Where should a developer draw the line between what should be open source and what should be proprietary?
David Hansson: I'm no open source zealot. I don't need everything in the world to be open source. I don't need all software products to be open source, in fact, I prefer that there are not. I prefer to pay for things. What I do find is that there's a lot of stuff, a lot of infrastructure code in particular, about our applications, that are not part of making our applications special. The Basecamp, the Highrise, the Campfire, the Backpack, all of the applications we have, they could built on something else than Ruby on Rails, to be honest. That means that Ruby on Rails is probably not the secret sauce. It is not what defines these applications, thus if I give it away, I'm not giving something up.
Now, if we open sourced Basecamp and said, hey, "You can just download it, run it on your machine, contribute something back to us," what are we selling? If you're giving it away for free, they're not also going to pay for it, at least not very many are.
Recorded on July 22, 2010
Interviewed by Peter Hopkins
A conversation with the programmer and creator of Ruby on Rails.
Once a week.
Subscribe to our weekly newsletter.
Research shows that those who spend more time speaking tend to emerge as the leaders of groups, regardless of their intelligence.
If you want to become a leader, start yammering. It doesn't even necessarily matter what you say. New research shows that groups without a leader can find one if somebody starts talking a lot.
This phenomenon, described by the "babble hypothesis" of leadership, depends neither on group member intelligence nor personality. Leaders emerge based on the quantity of speaking, not quality.
Researcher Neil G. MacLaren, lead author of the study published in The Leadership Quarterly, believes his team's work may improve how groups are organized and how individuals within them are trained and evaluated.
"It turns out that early attempts to assess leadership quality were found to be highly confounded with a simple quantity: the amount of time that group members spoke during a discussion," shared MacLaren, who is a research fellow at Binghamton University.
While we tend to think of leaders as people who share important ideas, leadership may boil down to whoever "babbles" the most. Understanding the connection between how much people speak and how they become perceived as leaders is key to growing our knowledge of group dynamics.
The power of babble
The research involved 256 college students, divided into 33 groups of four to ten people each. They were asked to collaborate on either a military computer simulation game (BCT Commander) or a business-oriented game (CleanStart). The players had ten minutes to plan how they would carry out a task and 60 minutes to accomplish it as a group. One person in the group was randomly designated as the "operator," whose job was to control the user interface of the game.
To determine who became the leader of each group, the researchers asked the participants both before and after the game to nominate one to five people for this distinction. The scientists found that those who talked more were also more likely to be nominated. This remained true after controlling for a number of variables, such as previous knowledge of the game, various personality traits, or intelligence.
How leaders influence people to believe | Michael Dowling | Big Think www.youtube.com
In an interview with PsyPost, MacLaren shared that "the evidence does seem consistent that people who speak more are more likely to be viewed as leaders."
Another find was that gender bias seemed to have a strong effect on who was considered a leader. "In our data, men receive on average an extra vote just for being a man," explained MacLaren. "The effect is more extreme for the individual with the most votes."
The great theoretical physicist Steven Weinberg passed away on July 23. This is our tribute.
- The recent passing of the great theoretical physicist Steven Weinberg brought back memories of how his book got me into the study of cosmology.
- Going back in time, toward the cosmic infancy, is a spectacular effort that combines experimental and theoretical ingenuity. Modern cosmology is an experimental science.
- The cosmic story is, ultimately, our own. Our roots reach down to the earliest moments after creation.
When I was a junior in college, my electromagnetism professor had an awesome idea. Apart from the usual homework and exams, we were to give a seminar to the class on a topic of our choosing. The idea was to gauge which area of physics we would be interested in following professionally.
Professor Gilson Carneiro knew I was interested in cosmology and suggested a book by Nobel Prize Laureate Steven Weinberg: The First Three Minutes: A Modern View of the Origin of the Universe. I still have my original copy in Portuguese, from 1979, that emanates a musty tropical smell, sitting on my bookshelf side-by-side with the American version, a Bantam edition from 1979.
Inspired by Steven Weinberg
Books can change lives. They can illuminate the path ahead. In my case, there is no question that Weinberg's book blew my teenage mind. I decided, then and there, that I would become a cosmologist working on the physics of the early universe. The first three minutes of cosmic existence — what could be more exciting for a young physicist than trying to uncover the mystery of creation itself and the origin of the universe, matter, and stars? Weinberg quickly became my modern physics hero, the one I wanted to emulate professionally. Sadly, he passed away July 23rd, leaving a huge void for a generation of physicists.
What excited my young imagination was that science could actually make sense of the very early universe, meaning that theories could be validated and ideas could be tested against real data. Cosmology, as a science, only really took off after Einstein published his paper on the shape of the universe in 1917, two years after his groundbreaking paper on the theory of general relativity, the one explaining how we can interpret gravity as the curvature of spacetime. Matter doesn't "bend" time, but it affects how quickly it flows. (See last week's essay on what happens when you fall into a black hole).
The Big Bang Theory
For most of the 20th century, cosmology lived in the realm of theoretical speculation. One model proposed that the universe started from a small, hot, dense plasma billions of years ago and has been expanding ever since — the Big Bang model; another suggested that the cosmos stands still and that the changes astronomers see are mostly local — the steady state model.
Competing models are essential to science but so is data to help us discriminate among them. In the mid 1960s, a decisive discovery changed the game forever. Arno Penzias and Robert Wilson accidentally discovered the cosmic microwave background radiation (CMB), a fossil from the early universe predicted to exist by George Gamow, Ralph Alpher, and Robert Herman in their Big Bang model. (Alpher and Herman published a lovely account of the history here.) The CMB is a bath of microwave photons that permeates the whole of space, a remnant from the epoch when the first hydrogen atoms were forged, some 400,000 years after the bang.
The existence of the CMB was the smoking gun confirming the Big Bang model. From that moment on, a series of spectacular observatories and detectors, both on land and in space, have extracted huge amounts of information from the properties of the CMB, a bit like paleontologists that excavate the remains of dinosaurs and dig for more bones to get details of a past long gone.
How far back can we go?
Confirming the general outline of the Big Bang model changed our cosmic view. The universe, like you and me, has a history, a past waiting to be explored. How far back in time could we dig? Was there some ultimate wall we cannot pass?
Because matter gets hot as it gets squeezed, going back in time meant looking at matter and radiation at higher and higher temperatures. There is a simple relation that connects the age of the universe and its temperature, measured in terms of the temperature of photons (the particles of visible light and other forms of invisible radiation). The fun thing is that matter breaks down as the temperature increases. So, going back in time means looking at matter at more and more primitive states of organization. After the CMB formed 400,000 years after the bang, there were hydrogen atoms. Before, there weren't. The universe was filled with a primordial soup of particles: protons, neutrons, electrons, photons, and neutrinos, the ghostly particles that cross planets and people unscathed. Also, there were very light atomic nuclei, such as deuterium and tritium (both heavier cousins of hydrogen), helium, and lithium.
So, to study the universe after 400,000 years, we need to use atomic physics, at least until large clumps of matter aggregate due to gravity and start to collapse to form the first stars, a few millions of years after. What about earlier on? The cosmic history is broken down into chunks of time, each the realm of different kinds of physics. Before atoms form, all the way to about a second after the Big Bang, it's nuclear physics time. That's why Weinberg brilliantly titled his book The First Three Minutes. It is during the interval between one-hundredth of a second and three minutes that the light atomic nuclei (made of protons and neutrons) formed, a process called, with poetic flair, primordial nucleosynthesis. Protons collided with neutrons and, sometimes, stuck together due to the attractive strong nuclear force. Why did only a few light nuclei form then? Because the expansion of the universe made it hard for the particles to find each other.
What about the nuclei of heavier elements, like carbon, oxygen, calcium, gold? The answer is beautiful: all the elements of the periodic table after lithium were made and continue to be made in stars, the true cosmic alchemists. Hydrogen eventually becomes people if you wait long enough. At least in this universe.
In this article, we got all the way up to nucleosynthesis, the forging of the first atomic nuclei when the universe was a minute old. What about earlier on? How close to the beginning, to t = 0, can science get? Stay tuned, and we will continue next week.
To Steven Weinberg, with gratitude, for all that you taught us about the universe.
Geologists discover a rhythm to major geologic events.
- It appears that Earth has a geologic "pulse," with clusters of major events occurring every 27.5 million years.
- Working with the most accurate dating methods available, the authors of the study constructed a new history of the last 260 million years.
- Exactly why these cycles occur remains unknown, but there are some interesting theories.
Our hearts beat at a resting rate of 60 to 100 beats per minute. Lots of other things pulse, too. The colors we see and the pitches we hear, for example, are due to the different wave frequencies ("pulses") of light and sound waves.
Now, a study in the journal Geoscience Frontiers finds that Earth itself has a pulse, with one "beat" every 27.5 million years. That's the rate at which major geological events have been occurring as far back as geologists can tell.
A planetary calendar has 10 dates in red
Credit: Jagoush / Adobe Stock
According to lead author and geologist Michael Rampino of New York University's Department of Biology, "Many geologists believe that geological events are random over time. But our study provides statistical evidence for a common cycle, suggesting that these geologic events are correlated and not random."
The new study is not the first time that there's been a suggestion of a planetary geologic cycle, but it's only with recent refinements in radioisotopic dating techniques that there's evidence supporting the theory. The authors of the study collected the latest, best dating for 89 known geologic events over the last 260 million years:
- 29 sea level fluctuations
- 12 marine extinctions
- 9 land-based extinctions
- 10 periods of low ocean oxygenation
- 13 gigantic flood basalt volcanic eruptions
- 8 changes in the rate of seafloor spread
- 8 times there were global pulsations in interplate magmatism
The dates provided the scientists a new timetable of Earth's geologic history.
Tick, tick, boom
Credit: New York University
Putting all the events together, the scientists performed a series of statistical analyses that revealed that events tend to cluster around 10 different dates, with peak activity occurring every 27.5 million years. Between the ten busy periods, the number of events dropped sharply, approaching zero.
Perhaps the most fascinating question that remains unanswered for now is exactly why this is happening. The authors of the study suggest two possibilities:
"The correlations and cyclicity seen in the geologic episodes may be entirely a function of global internal Earth dynamics affecting global tectonics and climate, but similar cycles in the Earth's orbit in the Solar System and in the Galaxy might be pacing these events. Whatever the origins of these cyclical episodes, their occurrences support the case for a largely periodic, coordinated, and intermittently catastrophic geologic record, which is quite different from the views held by most geologists."
Assuming the researchers' calculations are at least roughly correct — the authors note that different statistical formulas may result in further refinement of their conclusions — there's no need to worry that we're about to be thumped by another planetary heartbeat. The last occurred some seven million years ago, meaning the next won't happen for about another 20 million years.
Long before Alexandria became the center of Egyptian trade, there was Thônis-Heracleion. But then it sank.
Before Alexander the Great established Alexandria around 331 BCE, one of Egypt's primary ports on the Mediterranean Sea between the sixth and fourth centuries BCE was a place called Thônis-Heracleion.
Now researchers from the European Institute for Underwater Archaeology (IEASM), the same organization that first found the city in 2001, have announced the discovery of a couple of fascinating items from the city's heyday. Pinned beneath fallen temple stones is a surprisingly intact Egyptian military vessel from the second century BCE, and researchers have excavated a large cemetery from the fourth century BCE.
Thônis-Heracleion was one of the two primary access points to ancient Egypt from the Mediterranean. (The other, Canopus, was discovered in 1999.) For millennia, experts assumed Thônis-Heracleion were two different lost cities, but it's now known that Thônis is simply the city's Egyptian name, while Heracleion is its Greek name.
Thônis-Heracleion had been the stuff of legend before it was located, mentioned only in rare ancient texts and stone inscriptions. Herodotus seems to have been referring to Thônis-Heracleion's temple of Amun as the place where Heracles first arrived in Egypt. He also described a visit there by Helen with her lover Paris just before the outbreak of the Trojan War. In addition, 400 years later, geographer Strabo wrote that Heraclion, containing the temple of Heracles, had been located opposite Canopus across a branch of the Nile. Today we know Thônis-Heracleion's location as Egypt's Abu Qir Bay. The sunken port is about 6.5 kilometers from the coast and lies beneath ten meters of water.
Both Thônis-Heracleion and Canopus were wealthy in their day, and the temple was an important religious center. This all ended when the Egyptian dynasty created by Ptolemy set out to establish Alexandria as Egypt's center. Thônis-Heracleion and Canopus' trade — and thus wealth — was diverted to the new capital.
It was perhaps just as well, given that natural forces eventually destroyed Thônis-Heracleion. Located on the Mediterranean, the ground upon which it was built became saturated and eventually began to destabilize and liquefy. The temple of Amun probably collapsed around 140 BCE. A series of earthquakes sealed the cty's' fate around 800 CE, sending a 100 square-kilometer chunk of the Nile delta on which it was constructed under the waves. The Mediterranean's rising sea level over the next couple thousand years completed the drowning of Thônis-Heracleion.
Researchers have recovered a large collection of Thônis-Heracleion's treasures revealing an economically rich culture. Coins, bronze statuettes, and over 700 ancient ship anchors have been pulled from the waters. Divers have also identified over 70 shipwrecks. A giant statue of the Nile god Hapi took two and a half years to bring up.
An ancient vessel and a cemetery
Gold mask found in a submerged Greek cemetery.Credit: Egyptian Ministry of Tourism and Antiques
The newly discovered ship was found beneath 16 feet of hard clay, "thanks to cutting-edge prototype sub-bottom profiler electronic equipment," says Ayman Ashmawy of the Egyptian Ministry of Tourism and Antiques.
The military vessel had been moored in Thônis-Heracleion when the temple of Amun collapsed. The temple's enormous blocks fell onto the ship, sinking it. The boat is a rare find — only one other ship of its period has been found. As underwater archaeologist Franck Goddio, one of the scientists who found the city, puts it, "Finds of fast ships from this age are extremely rare."
At 80 feet long, the boat is six times as long as it is wide. Like its dually-named city, it's an amalgam of Greek and Egyptian ship-building techniques. According to expert Ehab Fahmy, head of the Central Department of Underwater Antiquities at IEASM, the boat has some classical construction features such as mortar and tenon joints. On the other hand, it was built to be rowed, and some of its wood was reused lumber, signature traits of Egyptian boat design. Its flat bottom suggests it was built for navigating the shallows of the Nile delta where the river flows into the Mediterranean.
Also found alongside the city's submerged northeastern entrance canal was a large Greek cemetery. The funerary is adorned with opulent remembrances, including a mask made of gold, shown above. A statement by the Egyptian Ministry of Tourism and Antiques describes its significance, as reported by Reuters:
"This discovery beautifully illustrates the presence of the Greek merchants who lived in that city. They built their own sanctuaries close to the huge temple of Amun. Those were destroyed simultaneously and their remains are found mixed with those of the Egyptian temple."
Excavation is ongoing, with more of Egypt's ancient history no doubt waiting beneath the waves.