I’ve never used postgresql before. I’ve forked a part of our software to use it, to see how it goes. My experience so far:
Really, PostgreSQL? Really?
For some reason this doesn’t work (Ubuntu 12.04):
$ sudo apt-get install postgresql ... $ psql # or "psql -U postgres" or ...
After hours of looking through the manual, “beginner” tutorials, and what not, I finally found this blog post that just shows how to get everything running.
Really, PostgreSQL? Really?
One of the things that I like about Perl6 is that the TIMTOWTDI philosophy produces an environment that feels more like an ecosystem than a factory. In perl6, this happens at every level: in addition to being able to solve problems using a variety of techniques, or using different code structures (object-oriented vs. functional vs. …), you can also express particular ideas in various ways grammatically. Rather than requiring a 1:1 mapping of ideas to grammatical structures, there is a lot of expressive freedom in the ideas. What this adds to the language is connotation. Two grammatical renderings may have the same definition (that is, they both have the same effect), but a very different connotation– the human programmer is able to express different intent to the human reader by the way in which the command is
Let’s look at an example. Consider the following script. It defines a class A with a method m that takes a subroutine s and executes it with different arguments depending on other factors.
class A {
method m (&sub, $num) {
print "Selecting a number between 0 and $num: ";
&sub( (rand*$num).Int );
}
}
sub s (Int $num = 12) {
say "your number is $num";
}
A.new.m: &s, 10;
A.new.m(&s, 20);
At the end of the script there are two invocations of the method m: the first is the “traditional” method invocation that uses parentheses to contain method arguments. The second uses the : operator to show that the remainder of the statement is arguments to the method.
While the first approach may not convey any particular intent to me, the second clearly does: it conveys that the rest of the statement is an elaboration on the concept introduced before the colon– just as in the case of the colon in this sentence.
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:
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):
Some of the languages were tougher to cut, but we ended up making the choice not to use them:
That left LISP, Perl6, and Ruby.
Now, Ruby was an obvious choice because we already had been using it a lot. Of the three of us, one really loves Ruby, one is fairly indifferent, and one somewhat dislikes it. Full disclosure: I’m the one that dislikes it (sort of!). My disinclination towards Ruby is a little hard to describe, but I’ll try, briefly. First, I think it’s a fine language that can do lots of great stuff and is not weak and enfeebled like some languages. It borrowed lots of great stuff from other languages (which is a virtue). It removed a lot of Perl5′s warts, it has native support for meta-programming. In short, there’s no “real” reason not to use Ruby … except … . Except that aesthetically, it’s got the opposite problem of Perl5. Perl5 is deeply beautiful with some warts and scars. Ruby is superficially pretty, but sort of vapid. It’s not deeply vapid, it’s just largely unphilosophical. It is following the same basic design pattern that Perl5, Java, JavaScript, and other similar languages followed: do stuff, fix problems, iterate. Over time, the lack of a comprehensive, cohesive philosophy begins to show. Ideological seeds begin to grow and when they grow enough, the collide and conflict. The great news is that that doesn’t seem to bother most people. The bad news (for me) is that when I see that something fudged, it bugs me. Forever. So, for those reasons, I didn’t rule out Ruby… but I put it at the bottom of the list (for me).
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.