For those who are interested, I'd thought I'd explain where I want to go with ScalaBox2D. It's a rather long post Going back to the original goal
I may have forgotten some of my initial goals at some point. The original reason that I started the port instead of just using JBox2D is that I wanted the classes that show up in actual GAME code (Bodies, shapes, vectors etc.) to be as "good API" as possible, and following Scala conventions rather than Java ones:
v.x instead of v.getX(), case classes, immutable Vectors and so on.
I didn't think I could just replace those parts of JBox2D so I ported the whole thing. I must admit I'm not sure I've made as good a job with the API as I hoped, so some more changes may come.
I'm not actually 100% sure about the immutability of vectors any more. I think it's one of the problems with the performance, but I don't know how to measure it without yet again rewriting a whole lot of code. And from some viewpoint it might actually be better API to be able to say body.pos.x += 1 instead of body.pos += (1, 0). At the moment I'm still leaning more towards immutable though.Performance
I don't want to keep improving performance while making the code harder to read. I'll keep doing some more optimisations for now, but eventually what I want to achieve is to keep all the math-heavy methods as concise and understandable as possible and let the compiler optimise things. Unfortunately I haven't found the time to learn how to write Scala compiler plug-ins, and I don't think the scala compiler itself can optimise away the creation of temporary vectors without a special plugin.
Current optimisations are going quite slowly. By now I've spent numerous hours with YourKit, but the effort that I have to put in to gain 10% is too much at this point and I'm making the code uglier, which is going against my original goal.
And it may be actually fast enough for many games. I know it is fast enough for the games I'm working on (they are on hold right now, though)Unicode
Many tools still have problems with UTF-8, but I think they can be mostly configured to work with it. Even the Scala standard library has some methods with unicode characters so any tool for writing Scala should be able to work with unicode. So α, λ, π, ε, × and friends are going to stay for now and the more the code looks like actual mathematics, the better IMHO.
Anyway, user code does not have to use those special symbols, everything has a spelled-out alternative.
I know they are harder to type, but there are solutions: for example in Windows you can add the greek keyboard and switch to that with Alt+Shift. Most of the letters are where you'd expect (a = α, b = β etc.). I don't know what the solutions are on Linux or Mac, but they can't be much worse? I admit I don't know how to type ×, I've used autocomplete and copy&paste.
Maybe this is not reasonable, but I just like seeing that in code and maybe I'm not a completely reasonable person
If more people start using this port and this is actually somehow hindering adoption/development, then I may reconsider