Programming

Why I’m excited about Julia

Julia is a new language that promises (or threatens) to take the best of all existing languages and put them into one fantastic package.

As a Python fan I found the syntax immediately appealing and familiar. However there are a number of Python niggles that appear to be improved in Julia.

Don’t like significant whitespace? Julia is using a end keyword.

function add(x, y) x + y end

Find Python’s keyword initialising rule counter-intuitive? Julia re-initialises on invocation.

function test_init(a, b = [1])
println(a, b)
push!(b, a)
println(b)
end

test_init(5) # Prints 5, 1, 1, 5

test_init(7) # Prints 7, 1, 1, 7

Wish that sequence operations were more consistent?

a = [1, 2, 3] # 3-element Array{Int64,1}: (via type inference)
shift!(a) # 1
pop!(a) # 3

Julia also comes with a shell which has all the niceties of ipython.

Julia is typed but so far the inferencing for primitives has been good enough. For collections you only seem to need a type declaration if the collection is initially empty.

Julia is also trying to do a lot with parallel processing and performance. I haven’t looked into that so much because that isn’t my usecase but so far the requirements for efficient typing aren’t causing any ceremony in the code. There is also some innate immutability in things like tuples but apart from that it is mutable by default with an immutable keyword applied to data structures that allows compiler and GC optimisation.

So Julia is a language that is immediately accessible to all Pythonistas, currently has less surprises than Python and is typed but enough inference to avoid them getting in the way. Pretty exciting!

Standard
Java, London, Programming

London Scala User Group Meeting

Had a good meeting (I thought anyway) at the TW offices that featured a talk from Jamie Webb introducing Scala and then a quick dojo. Scala has a much terser syntax than Java but I managed to do my classic thing of mixing my languages and putting my constructs in the wrong place. The other thing that doing rather discussing taught me is that Scala’s constructor syntax is much better defined than Java with the default constructor going into the declaration of the class. That’s the kind of improvement on Java that I really like in Java. It seems to distill all these lessons you’ve been learning if you write good Java code.

The pub after the event also saw a lot of discussion, there was quite a bit of discussion about testing and dynamic versus static typing. Personally I have decided to follow Neal Ford and reject the issue. To me both Ruby and Scala are low ceremony, high essence languages that choose different approaches to address the same issue. As such I don’t think there is any contradiction in liking and wanting to learn both languages.

Similarly I love compile time checking but I’m not giving up on testing. It’s a synergistic practice and I want to get the benefits from TDD/BDD/Tests as Specification. To me there is some irony that if I do have a test suite then actually I have more flexibility about my choice of languages. Not testing means you get much higher value from strong compile checking and therefore something like Scala is going to deliver much more benefit quickly. At the end of the day though I don’t want to have treat my tests as the gamekeeper of my wild code. I do expect the language and the compiler to give some structure and help to the development process.

Despite (because of?) my mistakes  want to do some more and I think Aaron (the founder of the group) suggested converting an existing Java program to Scala. That seems pretty sensible and I have an old Java program that I use a lot hanging around that needs some TLC.

If you are interested in Scala and in London I would recommend coming along to this meetings because you have the chance to meet and talk to everyone who is really engaged in Scala in the city. And to the guy who came all the way from Belgium; I salute you, you are a real hero!

Standard