I own a software company. We’re doing R&D right now; it’s pretty cool stuff.
We’ve been working for about a year and a half so far, and have made some good milestones. But in the last couple of months we saw that we needed a “pivot”. We worked through a lot of ideas, we thought, talked, prayed, searched, and so on. Finally, we understood some important parts of our problem domain in a new light and decided that what we really needed was to re-work our solution from the ground up. If it turned out that we could re-use all of our code, great. If it turned out we needed to re-write everything, fine. With our new understanding of the problem domain, we had come up with a broader, more powerful solution that was (and is) very exciting! We needed to do it — and we needed to do it right.
First, we decided that we didn’t want to hold anything sacred. We decided that we would design from scratch and make whatever choices best fit our needs.
Second, we defined our needs. Whatever we choose for our business, it has to be capable, flexible, elegant, and fun.
We’ve got a “back end” that does a lot of the mechanical heavy lifting, and a “front end” that does a lot of the conceptual heavy lifting. In essence, the front end translates the technology’s power into concepts that are accessible (and manipulable) by the users. You could reasonably say that the front end translates user intent into conceptual instruction. The back-end, on the other hand, translates conceptual instruction into technological instruction.
Both ends need to be able to represent and manipulate the conceptual elements of our problem domain and solution, and because of our particular space, that means that both ends need to be able handle some fairly esoteric ideas. Equally important, both ends need to be able to present the concepts concisely into their counter-domains (the hardware, protocols, etc. on the back-end and the users on the front-end)– both of which have significantly narrower conceptual bandwidth, generally.
For the past year, we coded in Ruby, which is a nice language. We decided we would re-evaluate our choice of programming language– we might still work with Ruby, but we wanted to make sure that it was the best choice for us as we moved forward.
We made a list of languages we were willing to consider, for the back-end and front end (a lot of this happened informally over a few weeks). Our list looked like this:
- LISP (of some flavor)
We threw out some choices pretty quickly, which I’ll outline here (though I’ll be brief: the goal is not to slam other people’s work, but to explain our choices):
- C/C++ was out because it’s just not that much fun to write in. You get power and speed, but at what cost?
- We threw out Java for reasons that were fairly obvious to us, but not really worth getting into here.
- Python was out because … well, it’s really a very nice language, it’s just sort of unobtrusively uninteresting.
Some of the languages were tougher to cut, but we ended up making the choice not to use them:
- There was a split about Perl5: I love Perl5 because it’s deeply beautiful, despite superficial warts. My two compatriots have never really written any modern perl, so they still think it’s basically Perl4. The split was reason enough to rule out Perl5, for the sake of harmony.
That left LISP, Perl6, and Ruby.
LISP had a lot to recommend it. I don’t suppose I even need to say that it’s got a rock-solid, comprehensive, cohesive philosophy: It is a description of abstract, general computing, after all. It’s crazy powerful, with a tight, terse syntax. It does have a few drawbacks, though. The cost of a light grammar with lots of power is pretty low semantic compression. In addition, the LISP community is deeply fragmented (and, weirdly, sometimes hostile to newbies). All in all, LISP is a good, solid choice for a project like ours.
Finally, Perl6. The major obstacle to using Perl6 is that there’s not a “mature, stable” release of it yet. Rakudo and Niecza are coming along nicely, but, as one of the developers cautioned me, if we were to choose Perl6, we should expect “some potholes.” On the other hand, one thing that Perl6 has in common with LISP is that it’s a specification! That’s a big deal (to me). It means that Perl6 has a comprehensive, cohesive philosophy, like LISP. I’ve been following Perl6′s conceptual development (from a distance) for about 6 years. Like LISP, it’s very powerful. Unlike LISP, it doesn’t seek to keep the grammar uncomplicated. Instead, Larry Wall (& co) decided to design for semantic compression at the cost of syntactic compression (that’s my analysis… I have no idea if they would say that’s a legitimate description of what they did =).
In the end, we decided to write our back end in Clojure, a LISP dialect that runs on the Java Virtual Machine, and the front end in Perl6 (using Rakudo right now, which runs on Parrot– a Perl6 Virtual Machine). I like the VM aspect of both languages, for reasons I can go into later.
Anyway, at the request of one of the guys on the #perl6 irc channel, I set up this blog to chronicle the use of Perl6 in a major commercial endeavor. I intend to be pretty candid about it, potholes, warts, and all. There might also be some LISP stuff from time to time. My hope is that Perl6 will work out for us, and that this blog will be an encouragement to others to use the language for their projects.