It can now be found at http://planetscala.com/
The old location and feeds will continue to work for the foreseeable future, but I’d appreciate it if people were to start using the new URL instead.
Category Archives: programming
Filtered feed to Planet Scala
I’ve just noise reduced the first feed on Planet Scala, as it really had a bit too much totally irrelevant stuff on it.
Specifically, mine. :-) You guys don’t really need the feed spammed when I decide to write fiction, recipes or whatever. This blog is about a bit too many things, and only a subset are relevant. So I’ve cut it down to only publish the programming related posts.
As always, do let me know if you think there are any other feeds that should be treated similarly.
How do you talk about Scala?
I gave a talk about Scala at Last.fm last night (It’s not online: not on Last.fm. At. I physically walked over to their offices and gave the talk to some of their devs).
Depending on how you look at it, it either went moderately well or was a complete disaster. People seemed interested, and went away knowing more about Scala than they came in with, so that part went well. The big issue is that I never actually talked about the subject I went in prepared to talk about. Oops.
I think part of the problem is that I aimed the talk at slightly too high a level. The talk I had designed was about testing with ScalaCheck, as that’s a pretty nice distinguisher of Scala from most of the other JVM languages – it’s something that really takes advantage of the type system in powerful ways, but isn’t too scary. I went in with a set of code I’d already written and was going to live code the tests for it. I still think this would have been a good talk, but I think it would have been a much better second talk on Scala than an introduction.
What happened instead was that we very quickly got diverted onto basic questions of syntax and semantics, and ended up touring Scala through the interpreter and performing a sort of general Q&A about it. This worked reasonably well (at least partly because Miles joined in and backed me up on some of the questions. Thanks, Miles), and would probably have worked even better if I’d come in with a couple small examples to demo this way. So maybe there’s something worth refining in there – certainly the “Here’s the interpreter. Let’s talk about code” model seemed like a pleasant one.
But I feel the talk still sortof missed the mark. It wasn’t a bad introduction to Scala, but it wasn’t a good “Here’s why you should use Scala”. And I’m still not sure how to do one.
The traditional way to present Scala seems to be to present it as a better Java. “Here’s an example in Java. Let’s translate it to Scala. Oooh, look how much shorter it is!”. This seems to go pretty well from what I’ve heard reported. But I have a couple problems with it: Some philosophical, some practical.
The biggest one is that the JVM is not short of languages which are better than Java. I don’t consider the question “Should I use Scala instead of Java” interesting. The answer, as far as I’m concerned, is obviously YES. Except for a few remaining interoperability issues I don’t consider that there’s any good reason to use Java these days (Disclaimer: The one exception I grant is in creating other JVM languages which you don’t want to be burdened with the Scala standard library on top of your language’s runtime). The interesting questions are “Should I use Scala instead of Clojure?” or “Should I use Scala instead of JRuby?”.
And here’s the thing: Rewriting a simple Java example in a better language looks exactly the same with almost any nicer language. You do a straight port, you find opportunities to introduce some functional programming, maybe you take advantage of sequence comprehensions or such like, etc. but basically what you end up with is the original program with a terser syntax and a few obvious abstractions factored in. It’s really not that exciting, and it doesn’t sell the language well. It might, if you’re talking to a group that has no experience of other languages (I wasn’t), but even then you’re basically playing on your group’s ignorance rather than making a compelling argument.
There are a bunch of neat things in Scala that could be used as a compelling argument: Scalacheck, actors, parser combinators, pattern matching in general, etc. but I’m not really how to go from zero to a full fledged example in one of these in only an hour. Perhaps if (rather than starting from a blank slate like I did) I started from a pre written example and disected it, but I’ve no idea if that would work any better.
So, what have you done? Did it work? Any ideas for how to do it better?
Not really LÖVING it
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:
- I’ve been saying for ages that I wanted to play around with creating little games. I’ve never gotten around to doing so. LÖVE made it sufficiently easy for me to get started that I no longer had an excuse for not doing so.
- It’s really very good at getting all the annoying cruft of creating a basic game out of the way.
- I had a lot of fun playing with it.
- I’m really glad I gave it a try, and if you’ve never written a game before and want to, you probably should too.
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)
Criticizing programming languages
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:
- All languages have problems with them
- There are very few languages which don’t have something good about them as well
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. :-)
Scala
Good:
- Very interesting modularity features
- Implicit arguments are great.
Bad:
- The standard library is pretty embarrassing
- It’s very easy for it to look like Java with weird syntax, particularly when using Java libraries.
Haskell
Good:
- Extremely powerful and interesting type system
- Purity enforced at the language level often makes it much easier to write correct code
Bad:
- Really weak support for modularity
- Aspects of the type system make it difficult to reuse nearly identical code across different contexts (consider sort vs. sortBy and map vs. mapM).
Ruby
Good:
- Flexible syntax and semantics make it easy to write some very terse code
- Makes general purpose scripting tasks very easy to hack together
Bad:
- Namespacing issues abound, between open classes and a tendency to stomp all over the global scope.
- The implementations.
Java
Good:
- High quality implementation, with very good JIT and garbage collector.
- Very rich ecosystem with lots of libraries.
Bad:
- Bindings to native libraries tend to be rather low quality or non-existent (JNI is a pain)
- Their closest Java equivalents typically are too
C
Good:
- Gives you a lot of fine grained control over details that higher level languages hide
- High performance native code compilers for just about every platform ever
Bad:
- Almost no capability for abstracting over type.
- Language level support for modularity basically doesn’t exist – namespacing by prefixing your function names, yay.
Ocaml
Good:
- Provides a lot of shiny new features over standard ML – lazy evaluation, row polymorphism, polymorphic variants, etc
- Very powerful module system (which I’ll admit to not entirely understanding)
Bad:
- If you ignore the shiny new features, the core language is basically a worse Standard ML.
- Although it has a justified reputation for writing high performance code, this seems to be only true if you write it as if it were C.
Lua
Good:
- Borrows many more features from functional languages (tail calls, lexical scoping, etc) than most of its peers.
- Very embeddable, rendering it very easy to use in the context of applications where the core is written in other languages.
Bad:
- Weirdly deficient standard library (I know this is related to ease of embedding, as it seems to be the result of a desire to keep Lua small)
- The language can be very verbose in places – consider the use of “local” to mean “Hey, I like not stomping all over the global scope”.
Python
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:
- Has a lot of really cool libraries / projects built on top of it. (NLTK, NumPy, Sympy, pygame, etc).
- The batteries included philosophy of the standard library is very appreciated.
Bad:
- I find the “there is only one way to do it” attitude of community very dogmatic.
- I’m not a big fan of the syntax. (I know, I know).
SQL
Good:
- Forms a nice back end for a data processing app
- Extremely good for constructing ad hoc queries against your data model
Bad:
- Dear god can it be verbose.
- Total lack of standardization a pain in the ass.
Javascript
Good:
- Pretty decent support for functional programming
- The prototype based OO is interesting and useful.
Bad:
- Really weird scoping issues in places (particularly behaviour of globals and “this”).
- The implementations are weak and inconsistent
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).