The history of the Lua programming language

I remembered this rather nice article about the evolution of the Lua programming language when I mentioned it in a previous post.

It talks quite pleasantly about how Lua got started, how it underwent changes and where it is today. Quite a fascinating read about a language that was born in South America and is today one of the most widely embedded languages inside of video/PC games in the world. Speaking of which, it also makes for a very clear understanding of the difference between an extensible language and an embeddable one.

Worth the read!

Beyond objects – I

… It’s in words that the magic is–Abracadabra, Open Sesame, and the rest–but the magic words in one story aren’t magical in the next. The real magic is to understand which words work, and when, and for what; the trick is to learn the trick.
… And those words are made from the letters of our alphabet: a couple-dozen squiggles we can draw with the pen. This is the key! And the treasure, too, if we can only get our hands on it! It’s as if–as if the key to the treasure is the treasure!

John Barth, Chimera

It’s a copy of a quotation that appears in The Structure and Interpretation of Programs. It speaks to the fact that if you know the name of something, as in a way to refer to it, then you have control over it. Like functions or closures for instance. If you can refer to it by name, you can tell it to someone else. Or pass it to another function. You can remember the name, so you can speak it when you’re ready. When the context is right. Like when all the variables, objects, and functions have aligned.

The idea of metalinguistic abstraction is a fundamental one. It’s a bottom-up way of thinking about your problem-space, and figuring out primitives and operations on those primitives. Rather than trying to build a system that satisfies a particular set of constraints in the given problem-space, the idea is to build a way to express more complex concepts using those very primitives and operations. That way, changes to the system can be made by changing higher level constructs – and going further down the layered stack of abstractions as needed, depending on how fundamental the changes are. This way, changes (or any new set of constraints) can be handled in a more clean and elegant fashion, and the entire system benefits automatically by a change made at a lower level.

If this sounds like building what these days is called a domain-specific language (DSL), then sure, but it is not a new way of doing things. It is however, possible to do a lot of this stuff easier in “enterprise-type” scenarios, because of a larger acceptance of more dynamic languages. Like Ruby, for example. It isn’t particularly easy to write software this way – it involves a change in the way most of us were taught programming. Everything is not imperative any more, code doesn’t have to be “written” before it runs, lines between data and code begin to blur. On that last point, what is a closure? Is it data or is it a procedure? It’s sometimes one, sometimes the other, and occasionally both, and indeed, sometimes it is neither. Here’s an example –

def create_coord(x, y) { |selector|
if selector == :x
elsif selector == :y

c = create_coord 10, 20
puts "X is " +
puts "Y is " +

So, the question here is, what is c? Is it data? Or is it code, that does something? Here, c is an object that represents a cartesian coordinate, but without any explicit data elements like variables or attributes… so, what is it?

Note – This is Ruby code, but a different language, (like Lua, for example, that has syntactic sugar for things like keys on a hash table) could make it unnecessary for the call(:symbol) syntax and instead, just calling x and y would translate it to a call on the object with the given method name.

The point, however, is that there are more ways to think about abstraction than just OO, and to paraphrase Paul Graham, some of them can transcend objects. The bottom-up approach itself can be implemented using plain objects and OO thinking, but there are other ways which can make for some powerful expressablilty. The code above approaches functional programming, and I’m interested in scaling that model to build large systems from pure or near-pure functional constructs. I’m nowhere close to being proficient in writing software this way, but it is my intention to learn.

Using Emacs for Ruby development

Emacs, the God of all things. I’ve been working my way through, over the past several years (after having been introduced to it by Ravi), all kinds of books and tutorials on lisp. Unfortunately, I’ve not been particularly good at following through and becoming a master, so I’m not really a guru or anything when it comes to Emacs skills. (I promise, it will change this year.)

Anyway, while working on Ruby, I was looking to find a good editor. Who isn’t, after all? I’ve used Eclipse with RDT and RadRails, but it wasn’t compelling (that might change with this stuff). After moving to the Mac, however, I was looking to buy TextMate – which I’ve heard a lot about. Before buying it, I thought that since it was “inspired” by Emacs, why not give it a shot? Ultimately, I got comfortable using Emacs itself, so I haven’t really given TextMate a real shot, despite owning a license (thanks MacHeist!).

So. This is my first in a series of posts about using Emacs for Ruby and Rails. The “cool” thing for this time is – inferior mode for Ruby. This provides a SLIME-like interface for Ruby, and allows you to work really interactively. What that means is, while typing in the editor, you can ask fragments of code to be interpreted, change only particular definitions quickly and rerun other code that uses them, pipe all that back and forth between windows, so on and so forth. And at any time, you can switch to the Ruby process (running with Emacs using irb) in use and explore the current environment.

Check it out, its very neat and it even comes with Ruby.

Why work at ThoughtWorks?

Update: I’ve answered a few questions people asked about this post.

I started my career at IBM. My dad had bought me a PC when I was seven and I started programming computers when I was 10. I’ve always felt most comfortable sitting at a computer screen, trying to communicate with a peice of silicon, than in any other situation. Mostly, anyway. And so, when I graduated with a degree in electrical engineering, I wanted to work at a company that understood computing and software, a company that built software that solved real problems.

This thinking sort of explains how I ended up at IBM (Global Services). Oh, what a load of…. Let’s just say I got out of there as fast as I could.

I joined ThoughtWorks about 5 years ago. And I’m still here. Every time someone asks me how I could manage to stay at one place after all this time, I feel like I’ve been asked a question like “How does one write good software”? I mean this in the sense that there are so many different aspects to the answer that a one or two sentence response can hardly do any justice.

So, what do I find so compelling about ThoughtWorks? First of all, and this is something many ThoughtWorkers will tell you, its the people I get to work with. Almost all are exceptional folks – smart, innovative, and sincere. They’re courageous. They’re caring and well-meaning. Many are actually quite funny. Working with these people on a day-to-day basis is quite a pleasure.

Related to this, is the fact that ThoughtWorks as an organization, truly respects and cares for its people. For example, if I needed something changed about my current project or if I got bored with my role or if I wanted to go to a seminar or something, I could tell someone and more often than not (as long as I wasn’t being totally unreasonable), they would try to fix things for me. It’s quite nice.

ThoughtWorks is a very flat organization – there are hardly any “levels”. There are, of course, roles on every project. Anyone can walk into anyone else’s office to question things – for the most part – without any thought of “proper channels”. As I mentioned earlier, I was at IBM for a while, and since leaving them have consulted at many large companies… believe me, ThoughtWorks is hugely different! Individuals are respected for what they are, not because of a title they might carry. Speaking of which, at ThoughtWorks, you can pick any title you want for your business card – mine says Jedi Master.

One other thing about ThoughtWorks that to me personally is quite enticing is the fact that we play with lots of bleeding edge innovations. We are thought-leaders in the Agile arena, we were early adopters of Java and J2EE, of dotnet and more recently of Ruby, Ruby on Rails, and other dynamic languages such as Python. And I’m talking about applying these things in an enterprise scenario. If it can add value to a client, then ThoughtWorks is not afraid to bring it up as an option. And from a techie point of view, this works out great! ThoughtWorkers are also heavily encouraged to contribute to open-source projects, attend conferences, write papers and books, and in general participate in the community of software development. ThoughtWorks is usually quite happy to support these activities with money – it’s quite fantastic!

There are tons of other things. How about – “architects” actually needing to write code? How about lots of social activities and events – things like geek-nights, dinners and drinking (lots of drinking!)? How about that most people who work here actually have passions outside of work, and can have meaningful and spirited conversations on just about any topic? Even political or religious beliefs? As a company, ThoughtWorks cares about social issues – not that we can always do a lot about everything, but it’s not a faceless corporation that exists solely to make money. Speaking of which, ThoughtWorks is privately held, which means – no pesky shareholders to bother us. Well, almost none.

I want to touch upon innovation again. Apart from the many things that ThoughtWorks is famous for, it also has several open-source projects to its name. More recently we also started a couple of internal teams on product offerings. We looked around and found that the software development industry, as a whole, was missing effective tools for certain things. I can’t say too much just yet – but you can expect to hear some pretty cool things pretty soon.

Another area where we’re innovating is Domain Specific Languages (DSLs). There are really two things – marketing-speak for highly maintainable and customizable systems (the idea being that business users can express or modify business rules using an English-like language steeped in their own domain, for example insurance-gobbledegook) and elegant design with a clean implementation that allows this to be possible. It really is wine in a new bottle (ask any Lisper), but with Ruby and Python gaining popularity in the “enterprise”, this kind of a thing is becoming more accepted. Bottom-line, people get to work on cool stuff and push the envelope on how business systems are being built. Clients get more value for less.

What else is great at ThoughtWorks? Agile processes – XP,Scrum, and the like. Nothing great about a process by itself, of course, but at ThoughtWorks, most people truly get software development. And when you assemble a project team from a bunch of such people, they often end up with an ad-hoc process that is remarkably similar to the name-brand processes mentioned above. In the words of a ThoughtWorker colleague, you can’t do agile, you can only be agile. Further, “common” wisdom states that Agile processes work well only for small teams. We’ve been scaling these processes by being agile for many years now. The current project that I’m working on (as a scrum master/project manager) has a team with a 100+ developers and is based out of three locations – the US, India and Sweden. How do we do it? Carefully.

I feel like I’m writing an infomercial. But there is one more thing I wanted to throw in. This is about the highly trans-national nature of ThoughtWorks. Since 2002, I’ve worked with ThoughtWorkers from more than a couple of dozen countries. The cultural explosion is just awesome. We also have an international exchange program where you can opt to work in another country for a period of time (typically 1+ years) – and a lot of people take this opportunity to travel and work in different environments and cultures. Our new hires get sent to India to what we call ThoughtWorks University for a few weeks to learn about the company, processes, technologies etc. Further, people also transfer out to various other offices. I started out in our Bangalore office several years ago, for instance, and moved to the Chicago office in 2003.

Overall, ThoughtWorks is a phenomenal place to work. Obviously there are drawbacks to working here – the travel is most often upto a 100% (leave home Sunday night or early Monday morning, and go home Thursday evening or on Friday). One other thing – and this one is pretty important – not all projects are sexy. It’s true! We’ve had several people join ThoughtWorks who’d only heard the awesome stuff we’re about, and then felt let down because their project was “regular ol’ dotnet” at some “typical large client”. You have to remember that apart from being all the cool things I described above, ThoughtWorks is a real business and we do a range of different kinds of projects. Sometimes they’re slick and sexy, sometimes they’re slow and steady. It’s the nature of the consulting business.

Finally a few last points before I wrap this up – being a small company, there’s less “security” here than there is in a large organization like IBM – although I’m not sure how true that is anymore. Also, we’re fundamentally an application development company – so if you want to work on embedded systems or compilers, maybe IBM is a better place for you. We’re also not Google. Yet. This means no huge salaries, no stacks of stock-options that translate to retired young millionaires. Yet.

In any case, as far as ThoughtWorks is concerned, at least in my mind, the future is extremely bright. We’re growing, we’re innovating, and we’re only in six countries so far…

P.S. Two more things not in favor of working here – you have to battle Lotus Notes, and not everyone has moved to a Mac yet.

* We do have a VC on board – we had taken their money during the dot-com high.