And boy is it getting dehydrated.
Ahem. Sorry.
I’ve moved planet scala to run on Venus, the successor to planet-planet. This should fix some bugs we were seeing with post titles getting mangled for some feeds. Unfortunately it may also cause your feed reader to go crazy and report a bunch of stuff as new which isn’t. That should be a one off thing though.
That is all.
As you might have noticed if you don’t just come here via the RSS feed, I’ve spent the last day or two redesigning my site (with a fair bit of help from Victoria). The old layout had started to piss me off – the sidebar always either looked too small or too cluttered whatever I put in it, and the lack of definition for the posts made everything look a bit amateurish.
Which is not to say the new look is a miracle of modern design either, but I’m a lot happier with it.
If you notice any bugs with the new version (stuff I’ve forgotten to update, browser bugs, etc.) please let me know. Particularly those of you using IE (that is, IE7+. If you’re using IE6, get yourself a real browser), as I’ve only tested on firefox and konkeror (the latter is usually bug compatible enough with Safari that I’d expect it to work). Feel free to suggest any visual improvements as well, but I’m more likely to ignore those. :-)
So I spent yesterday playing around with LÖVE, a really cute little platform for writing 2D games. It got linked on reddit on friday, and it looked neat so I thought I’d give it a try.
As you can tell from the title, this is not going to be a very positive post. So in order to brighten the mood I’m going to start by saying positive things about it:
Also, the website is adorable.
Unfortunately, that’s about where the positive side of things stops.
First off, the biggest problem with it is that it’s really unreliable. It will sit on a CPU and eat 100% of it, for even the smallest of games. It seemed very crashy – on my work PC it tended to randomly crash other applications. People who tried to play my games said that it seems to crash itself and other things when you try to close it (this was under both macs and windows. I never had this problem under linux). Between these two factors I’d basically never consider it for a real game. Hopefully both will be fixed at some point. (Yes, yes, I know, open source, I should look into it. Unfortunately it seems to be written in C++, which I have approximately zero interest in writing).
The other major problem with it is that it’s actually not very powerful. What it basically comes down to is an infrastructure for loading files, an ok graphics API and fairly basic physics and sound APIs (there’s also an animation API which I didn’t bother to look at. It may be better than the others, I don’t know). So although it helps you get started it doesn’t really do much for you once you have.
As an example to illustrate the above: I had a bit of a play with the physics engine. Basically I created a green square that could jump about (he’s a very abstract representation of Victoria’s very abstract representation of a frog). That worked quite nicely – he could jump, he could move from side to side, he could land on stuff.
The point at which it stopped working nicely was when I wanted him to not be able to jump while already in mid air. See, it turns out that the physics engine has no way (or rather no way exposed in the API) of detecting if two bodies were in contact, so I couldn’t easily detect if he was on the ground or not. I asked in #loveclub on freenode (a much less dubious channel than the name might suggest), and various things were suggested. The best idea I encountered was checking vertical distance from the point of contact. This unfortunately proves to have a bunch of problems as well. The method I eventually settled on was that he could only jump if his vertical speed was already zero (actually, < 0.001) and hope that the player’s reactions weren’t good enough to jump during hang time.
At this point I more or less decided I’d had enough of the physics engine. I went back to the first game I’d made, turned it into something that was actually a proper game (it hadn’t previously been possible to lose. Now it’s only really hard to lose) and declared myself all out of LÖVE. It was a fun little encounter, and I do hope they do well, but unfortunately I’m not really left with any desire to use it.
If you want to check out the code I wrote for this, it’s available from the github repo. Be warned though: It’s really bad. It started out slightly crummy because I was just exploring the API, and then in that last “right, let’s get something actually playable” push I started factoring things out nicely before I realised that I was never going to touch the code again and just brutally copied and pasted and hacked until it worked. I should also warn you that the games themselves are correspondingly lame. :-)
(As an aside, also in that repo are today’s experiments at recreating something like the Love API but more reliable and/or powerful in Scala. But more on those later)
Here are snippets from two conversations I had recently:
20:03 < psnively> DRMacIver: I do think of you as taking a “Scala is one of the few languages worth criticizing” stance.
llimllib @DRMacIver So by my count, you’ve been in public arguments over the quality of Scala, Java, Ruby, Lua, Haskell, and OCaml? Missing any?
psnively’s comment is of course patently untrue. I criticize all sorts of languages. It just happens that Scala is one of those I use the most (at least in my free time), so I tend to criticize it more often than others. It’s true that as I rather like it I hold it to higher standards, but I feel no problem with criticizing other languages. :-)
llimllib’s comment is much more close to home. I get into arguments about languages all over the place. The problem is that:
So the first point gets me into arguments with the people who love the language, the second gets me into arguments with people who hate it. I really can’t win. :-)
So, just to piss everyone off, I figured I’d write a post about the different programming languages I have opinions on. The structure of this will be simple: For every language I feel like I’ve used enough (or at least know enough about and have used some), I will write four items: Two saying what’s good about it, two saying what’s bad about it. These points are not intended to be the best or worst things about the language, or even neccessarily representative. They’re just something that has struck me as good or bad. Also, the format practically guarantees that I’m probably not saying anything anyone else hasn’t said a few dozen times already. :-)
Good:
Bad:
Good:
Bad:
Good:
Bad:
Good:
Bad:
Good:
Bad:
Good:
Bad:
Good:
Bad:
This one is a bit weak, as I’ve only really used python in a few contexts, and haven’t really formed any strong negative opinions about it aside from a generic mild dislike. :-)
Good:
Bad:
Good:
Bad:
Good:
Bad:
And there we have it. :-) Some of these I could probably say a lot more good and bad about, some of them I struggled a bit on one side or the other and probably couldn’t, but those tend to be the languages I’ve used the least (in particular I’ve used Lua, Python and OCaml dramatically less than I have the others on the list).
I’ve uploaded a version of the Pearson’s Coefficient code which runs on postgresql. You can download it here.I wrote this as an experiment to see if Postgres could help us with some of our MySQL performance woes.
Some brief experimentation suggests that once you fix PostgreSQL’s ridiculous default configuration the performance story is relatively happy. At small sizes MySQL is moderately faster, but as the sizes get large PostgreSQL seems to take the lead. I don’t have any sort of formal benchmark yet: This needs much more testing before I can definitively claim either is faster than the other, but for now the signs in favour of PostgreSQL are promising.