
The Python Paradox is now the Scala Paradox - hendler
http://martin.kleppmann.com/2009/09/18/the-python-paradox-is-now-the-scala-paradox.html
======
al3x
This is from 2009. Scala has only improved since then, although it's still not
a "mainstream" programming language by any stretch. You can talk to a crowded
room of programmers who either haven't heard of Scala, or have heard of it
only in passing and don't really know what it's about. That's fine.

Programmers who are interested in learning and growing will always be
attracted to new languages and technologies. What's interesting about Scala is
that it's not solely academic. You can learn and do useful things with it at
the same time. Later, when you've learned more, you can go back and improve
your old code for added beauty and performance. That's a fun process, I think.

~~~
swannodette
I think the title could be updated for 2011 - "The Python Paradox is now the
Functional Programming Paradox". Scala, Clojure, Haskell, and Erlang - all
your points apply equally well to them.

~~~
BMorearty
The author says exactly that, near the end of the article. He names those
languages in particular.

------
hassy
It's "whatever programming language is not mainstream paradox" to be precise
(and the author of the blog post would agree since he also nominates Haskell,
Erlang, and Clojure). Which is obvious. And since "whatever programming
language is not mainstream paradox" is a mouthful, "Python paradox" is a much
better name. Those unfamiliar with the term can always be directed to PG's
article to enjoy.

 _EDIT:_ Using "esoteric" languages can also be a good long-term hiring
strategy. It's pretty easy to get a place in people's minds as the "go to"
company to work with a language. Google did that with Python, Twitter is doing
it with Scala, Basho are doing it with Erlang.

~~~
billmcneale
> Using "esoteric" languages can also be a good long-term hiring strategy.

Actually, it's a good short term hiring strategy but a terrible long term
strategy. Most of these languages remain a niche (Ruby, Scala, Clojure,
etc...) and hiring more than a couple of people that know how to use them
turns out to be a very, very tough challenge.

I have seen several companies try that and then revert back to Java just
because they couldn't staff up to meet the demand.

Overall, color me still extremely skeptical of Paul Graham's original argument
(which was that Lisp gave his company an advantage over the competition).
Interestingly, ViaWeb was quickly switched back to a more mainstream language
shortly after PG sold out. Deduce from that what you will.

~~~
harryh
> hiring more than a couple of people that know how to use > them turns out to
> be a very, very tough challenge

That's tackling the wrong challenge. Almost none of engineering staff at
foursquare had used scala before starting here. But they're all talented
engineers who can learn new skills and thought that learning scala would be
interesting. We've had very few problems with people picking up the language.

~~~
billmcneale
That was my point: by choosing an esoteric language, you raise the bar for the
people you need to hire, which makes hiring very challenging.

Now go scale that up to 50 or 100 engineers and you understand why it's not a
viable strategy.

Try it yourself, go pitch a startup and then tell the VC's and their
consultants that you're going to use Scala...

I know you're going to say that they don't know their stuff and you should be
the one deciding, but it's actually the other way around: they know how to
grow a business, and nobody with that knowledge will ever recommend to go with
non mainstream language and technologies.

~~~
technomancy
It almost sounds like you're saying raising the hiring bar is a bad thing.

~~~
technomancy
got cut off on my phone; meant to add: why would you ever need 50 Clojure
engineers?

~~~
billmcneale
For the exact same reason you might one day need 50 programmers in any
language: if your company flourishes.

What makes Clojure so special that you'll never need that many?

------
Stormbringer
Upfront I want to be very clear that I'm not hating on any of the languages
that he mentions in the article. okay, maybe secretly hoping that Ruby will go
die in a fire somewhere, but let's put that aside.

What grieves me as I read that article is that it seems like he had a
perfectly good way of doing it simply and easily, but then decided to go for a
much more complex and risky solution (with what _he_ describes as poor
tooling) ... for what? Simply to increase the difficulty level?

Take the analogy of a backyard pool. Instead of just running up to the pool
and doing a bomb (or even a belly flop), he has to climb up on the roof of
neighbours rickety garage, where he is going to attempt to do a triple twist
half pike helicopter/superman maneuver in order to score higher from the
judges. Problem is, he's got a real risk of either missing the pool entirely
or cracking his head open on the concrete.

I'm not saying we should never use new languages or techniques or tools. What
annoys me is that given the choice of doing something simple, or doing
something complex, he chose the complex way, and then piled on the risk, with
a side order of complexity.

From the article:

 _"Shortly after working this out and drawing my architecture diagram (a
pretty insane-looking tangle of boxes and arrows on a sheet of paper)"_

Shouldn't that have been a pretty big red flag? Sure he found some superstar
programmer to pull it off for him, but I can't help but think that a little
bit of darwinian natural selection would have been in order here.

The annoying thing is that you see this all the time in the Enterprise. Time
and time again someone with architect in their title goes and makes an
appalling horrible mess of the design, leaving the poor bastards at the coal
face to sort it out and try to make the abominable crime against nature,
reason and common sense actually work.

~~~
fleitz
If you're dealing with message passing architectures a language like Scala is
a good way to go. Actors or Mailboxes in F# parlance fit perfectly with the
way the architecture was described.

His point about code fashion is also equally valid, what Seurat did with
pointillism is impressive, printing a picture on on your inkjet is not, even
though what Seurat did is essentially the same thing.

Coming from an imperative background writing in a functional style has risk,
coming from a functional background imperative style has risk. You can
implement the lambda calculus on a UTM and implement a UTM in the lambda
calculus, for all intents and purposes they are the same, however, in terms of
elegance they are far different. (And there are arguments on both sides as to
which is more elegant).

I tend to agree with you particularly on 'enterprise architects' but the
solutions are usually a reinvention of the wheel rather than marrying two
disparate technologies that actually fit quite well together. Scala or another
functional language is a great fit to a message bus architecture. Doing
something for the difficulty of it usually doesn't attract a lot of smart
minds, putting two things together that at first one wouldn't think of but
that makes sense WILL pique the interest of a talented developer because he
wants to see if it actually bears fruit.

~~~
Stormbringer
I'm sorry, I think I don't understand the point you are trying to make. Are
you really complaining that Java doesn't do messaging? Surely not, because
that would be like saying that Lisp is okay, but it would be better with a
heap more parenthesis.

When you get down to it, pretty much any language with even a rudimentary
ability to manipulate strings and connect to a socket can do messaging. But
right from day one Java has had the capability of communicating with remote
machines baked in.

Oh wait, I just checked, I'm wrong. The Remote and Serializable interfaces
date since Java 1.1, NOT since day 1. My bad. Of course 1.1 was released Feb
19, 1997 so RMI is _almost exactly 14 years old at this point_.

So my conclusion is that if you've been living under a rock for exactly 14
years, you have an excuse when you say that Java can't do messaging.

\----

Someone always comes along and says "what about $blindingly_obvious_thing and
gets massive amounts of karma for doing so, so let me just say that yes, I am
aware of... bugger it, I'll do it myself and reap the karma. Muahahahaha!

...

...dang, there's no reply to my own message option. (For obvious reasons) Oh
well, we'll have to settle for option #2 which is that someone comes along and
posts an objection which has nothing to do with any of the posts before it,
and gets masses of karma for it.

\----

Addendum:

If you're implementing a messaging system in your handy dandy language with
sockets and strings, _and you want it to be robust_ , you will _of course_
need to take into account this:

[http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...](http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)

or a more in-depth look at them:

<http://www.rgoarchitects.com/Files/fallacies.pdf>

cheerio, pip pip

------
StavrosK
Does anyone know of a concise way to learn Clojure or Scala? I'd like to learn
one of these languages, but I don't want to wade through interminable books to
do it. Rather, I'd prefer it if there were a place where I could quickly pick
up some basics and get a few ideas/exercises I could work on to discover the
language on my own, a bit like "Learn Python in 10 Minutes"
(<http://www.korokithakis.net/tutorials/python>).

~~~
bitsai
For Clojure, this is a good place to start:
<http://en.wikibooks.org/wiki/Learning_Clojure>

I also like the lengthier, but most excellent, tutorial by Mark Volkmann:
<http://java.ociweb.com/mark/clojure/article.html>

Project Euler worked well for me as warm-up exercises. And I just found a Wiki
of Project Euler solutions in Clojure: <http://clojure-euler.wikispaces.com/>

~~~
StavrosK
Fantastic, thanks. Especially the project Euler idea, I was under the
impression that they were Python-specific problems (in retrospect, I have no
idea why I ever thought that).

~~~
silentbicycle
You may be thinking of the Python Challenge; I could see them being mentioned
together when someone asks for programming puzzle sites.

~~~
StavrosK
Probably, yes. It's one of those things you never realise are wrong until you
think about them.

------
jleader
Previously discussed on HN: <http://news.ycombinator.com/item?id=831817>

~~~
hendler
Thanks - hadn't seen this. HN didn't catch the dupe as the same article was
submitted from a different url, which is now a 301 to this article.

------
l0nwlf
> Of course Sam cannot live on technical stimulation and my gratitude alone

Alas. If only we could live on technical stimulation alone :(

------
bootload
_"... 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... what are
the new technologies to look out for? ..."_

<http://nodejs.org/>

------
gtani
<http://news.ycombinator.com/item?id=2084732>

(the last pardox thread)

------
BonoboBoner
I have been reading books about Scala and used it for scripting here and
there. I gained some Scala experience over the last years, yet it still amazes
me how often people state:

"Scala is not ready yet, but when it is, it is gonna take over Java as the
next big language".

Years have passed and this has failed to materialize. Maybe it will never be
'ready enough' to take over? What do you think?

------
benreesman
scala is quite complex. it has O(m + n) complexity from functional and "object
oriented" (single dispatch, backported type system) requirements, plus
whatever their interactions cost, plus the novel shit. I admire anyone who
really grasps it in it's entirety.

as a mere mortal I gravitate to simpler things.

