160 lines
7.2 KiB
Markdown
160 lines
7.2 KiB
Markdown
---
|
||
created_at: '2016-09-17T00:09:38.000Z'
|
||
title: The Python Paradox Is Now the Scala Paradox (2009)
|
||
url: https://martin.kleppmann.com/2009/09/18/the-python-paradox-is-now-the-scala-paradox.html
|
||
author: tomrod
|
||
points: 72
|
||
story_text:
|
||
comment_text:
|
||
num_comments: 105
|
||
story_id:
|
||
story_title:
|
||
story_url:
|
||
parent_id:
|
||
created_at_i: 1474070978
|
||
_tags:
|
||
- story
|
||
- author_tomrod
|
||
- story_12518333
|
||
objectID: '12518333'
|
||
year: 2009
|
||
|
||
---
|
||
[Tweet](https://twitter.com/share)
|
||
|
||
# The Python Paradox is now the Scala Paradox
|
||
|
||
Published by Martin Kleppmann on 18 Sep 2009.
|
||
|
||
[Paul Graham](http://www.paulgraham.com/) has written a bunch of good
|
||
essays on entrepreneurship, laying down much of the philosophy behind [Y
|
||
Combinator](http://ycombinator.com/). If you’ve not read any of them
|
||
yet, you should go and read them now – they contain lots of wisdom.
|
||
|
||
In his 2004 short essay [The Python
|
||
Paradox](http://www.paulgraham.com/pypar.html), PG argues (perhaps
|
||
controversially) that a company can hire smarter programmers if it
|
||
chooses to write its code in a “comparatively esoteric” programming
|
||
language. At the time, Python was probably considered by most people to
|
||
be esoteric in comparison to Java – in the sense that not many people
|
||
would learn it at university or for career purposes. Therefore, the
|
||
programmers who knew Python were people who learnt it for fun; and
|
||
learning languages for fun is an activity which typically only the
|
||
bright and motivated people engage in. Which makes the language a good
|
||
“quality filter” for people.
|
||
|
||
Of course times have moved on, and Python (and Ruby, for that matter)
|
||
are definitely entering the mainstream. They are still fine languages,
|
||
but they no longer carry as much of an early adopter aura about them.
|
||
The culture of testing and code beauty which is embraced by the Ruby and
|
||
Python communities is still something special, and that is now the
|
||
primary reason why I would choose Ruby and Python over Java or C\#.
|
||
|
||
PG’s observation still holds true. But what are the new technologies to
|
||
look out for? What can you find in 2009 which has the same role as
|
||
Python did in 2004?
|
||
|
||
**Choosing a programming language**
|
||
|
||
A few months ago, when I was designing the system architecture for [Go
|
||
Test It, our awesome cross-browser testing product](http://go-test.it),
|
||
I had a lot of design choices to make. For some parts of the system it
|
||
was fairly clear what we were going to use: for instance, the frontend
|
||
web application was almost certainly going to be Rails, because I had
|
||
some existing tools like [the invoicing
|
||
gem](http://ept.github.com/invoicing/) which I wanted to reuse, and
|
||
because it was simply a good fit for the job.
|
||
|
||
But what about the actual test management infrastructure?
|
||
|
||
I chose to write it in [Scala](http://www.scala-lang.org/). There were
|
||
plenty of reasons why this could have seemed a bad idea:
|
||
|
||
- I had hardly any experience in using Scala, so I would have to
|
||
invest a lot of time learning it as I went along;
|
||
- nobody else I knew had any experience in using Scala at all, so
|
||
anyone I hired would probably also have to learn it (at the cost of
|
||
slower progress);
|
||
- some of the tools (particularly the Eclipse plugin) were still
|
||
packed with bugs;
|
||
- although I had access to Java libraries, I knew that I would have to
|
||
write library wrappers of my own to make use of the Scala language
|
||
features;
|
||
- setting up a proper build process was [pretty
|
||
horrible](/2009/05/13/building-go-test-it-fun-with-scala-and-rest-apis.html).
|
||
|
||
Scala also had some technical merits; particularly the actor model for
|
||
multithreaded programming was a good fit for our problem. Still, in a
|
||
purely technical consideration, it probably wouldn’t have made much
|
||
sense. But my heart still said yes. The prospect of working with a
|
||
language which looked pretty, had static type inference, nice functional
|
||
programming features, and runs on the JVM (battle-tested and optimised
|
||
over many years)… my heart just said yes. It wasn’t a rational choice,
|
||
but an instinctive, emotional one.
|
||
|
||
**Paul Graham was right**
|
||
|
||
Shortly after working this out and drawing my architecture diagram (a
|
||
pretty insane-looking tangle of boxes and arrows on a sheet of paper), I
|
||
was talking to [Sam Stokes](http://samstokes.co.uk/), a freelance
|
||
developer sitting next to me in our shared office. Sam is bright,
|
||
motivated and interested in the things going on in the software world.
|
||
We were talking casually about Go Test It and I showed him my messy
|
||
diagram.
|
||
|
||
And when I had talked him through the architecture (“I think I’ll write
|
||
these three components in Scala, and they will talk to each other via a
|
||
[RabbitMQ message queue](http://www.rabbitmq.com/)”), Sam said, in
|
||
effect, “Hey, this is cool, I want to work on this”.
|
||
|
||
And he did. Over the course of a few weekends, Sam spent several days
|
||
learning Scala and contributing to the [Go Test It](http://go-test.it)
|
||
codebase. When you use Go Test It today, you are using the Scala code he
|
||
wrote. He did this simply because he found it interesting and wanted to
|
||
learn something new. The code he wrote was good, production-quality
|
||
stuff. And he didn’t want a penny for it.
|
||
|
||
It’s not often that you get high-quality contributions to a
|
||
closed-source project from a developer who is busy enough with several
|
||
other projects already, for free.
|
||
|
||
Of course Sam cannot live on technical stimulation and my gratitude
|
||
alone, and since then, we have actually contracted him to do paid work
|
||
on Go Test It. But I found his initial reaction, and his approach to the
|
||
project, a great example to prove Paul Graham’s point.
|
||
|
||
I would say **Scala in 2009 has the place which Python had in 2004**.
|
||
There are a few other languages I would also consider for this title:
|
||
[Haskell](http://www.haskell.org/), [Erlang](http://erlang.org/) and
|
||
[Clojure](http://clojure.org/) come to mind (but don’t take that as a
|
||
recommendation – I’ve not yet used any of them seriously myself). What
|
||
these languages all have in common is that they’ve been around for long
|
||
enough to come out of the purely academic space, are stable enough to be
|
||
production-worthy, but are also new and exciting enough to attract good
|
||
developers.
|
||
|
||
**Fashion-Driven Development?**
|
||
|
||
In [an article about non-relational
|
||
databases](http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/)
|
||
which [Ryan Carson](http://twitter.com/ryancarson) asked me to write a
|
||
few months ago, I suggested that fashion can and should play a role in
|
||
choosing which technologies to use. I got some criticism for this
|
||
remark, but I still stand by my view. It is effectively a different way
|
||
of looking at PG’s statement, provided you look for the fashion in the
|
||
right circles (i.e. amongst experienced developers working at the
|
||
cutting edge).
|
||
|
||
I wouldn’t go with fashion against all technical merit, but provided the
|
||
technology is suitable and won’t increase your costs disproportionately,
|
||
why not do something fashionable and adventurous? In an innovation-based
|
||
technology business, the quality of your developers is key. Investments
|
||
into things which make your good developers happy will pay off
|
||
handsomely.
|
||
|
||
Join the discussion about this article [on Hacker
|
||
News](http://news.ycombinator.com/item?id=831817)
|
||
|
||
Join the discussion about this article [on Hacker
|
||
News](http://news.ycombinator.com/item?id=2218654)
|