
The Python Paradox Is Now the Scala Paradox (2009) - tomrod
https://martin.kleppmann.com/2009/09/18/the-python-paradox-is-now-the-scala-paradox.html
======
crazygringo
"Smarter" programmers are very rarely what a company needs, in my experience
-- it's extremely rare for a startup's success to depend on that. (I mean, I
_love_ clever algorithm programming, but it's just so rarely needed, sadly.)

To the contrary, programmers with the ability to deliver and iterate working
code quickly is what is needed -- and especially without overengineering, or
inadvertently creating huge future technical debt due to inexperience.

And if there are only 2 or 3 or 5 programmers on my team, and one of them gets
sick or leaves, it's far more important to have a big pool of potential
replacements who could can get up-to-speed in a couple weeks, not months --
which means a popular language and a straightforward codebase.

~~~
valw
It saddens me that people advocating mainstream technologies describe "smart
programmers" as unable to ship or make pragmatic choices. There is absolutely
no evidence of that. To me it just sounds like sore losers talking. I've never
met anyone voicing that critic who had actually tried both approaches.

In my opinion, average-level programmers on critical projects with deadlines
will quickly cripple your team's ability to deliver due to technical debt, and
throwing 3x more of those easy-to-hire/fire men at it won't solve the issue.

I've chosen such an "esoteric" technology for my startup, because we had
ambitious technical objectives, and it proved extremely beneficial - we would
never have been able to _deliver_ a system so robust so quickly with
mainstream technologies (which I know because I've used those, so I'm in a
position to make an informed comparison).

There are legitimate uses of both established and cutting-edge technologies,
but from what I've seen the people who fiercely advocate mainstream
technologies are more often reluctant to leave their comfort zone than making
pragmatic, informed choices.

~~~
ubernostrum
You'll sometimes see Python people use not the word "smart", but the word
"clever", with bad connotations. "Clever" programming, in this context, means
valuing line/character count or showing off unusual algorithms or language
tricks only the "clever" programmer knows, at the expense of clarity and
maintainability.

So, for example, the mundane way to square a number in Python would be:

    
    
        def square(n):
            return n**2
    

The "clever" way would be:

    
    
        from itertools import count, ifilter, islice
        s = lambda n: sum(islice(ifilter(lambda n: n % 2, count()), n))
    

The first one was clear, readable, easy to understand and maintain. The second
one is tricky to read, requires some thought to work out what it's doing, and
is written to show off knowledge of a slightly-obscure algorithm and the way
to implement it in Python.

~~~
noobermin
What you call "clever" seems more like "complicated".

~~~
ubernostrum
Yes, but there are people -- I've encountered them! -- who look on this as a
way to show how "clever" they are, and consider it a good thing.

It's like Perl golf take to an extreme.

(admittedly, some of my co-workers and I have been known to golf our interview
questions into ridiculous one-liners, but we do it for amusement value, not
because we'd ever write production code that way)

------
cortesoft
I think there is some serious flaws in the author's logic. Having the free
time to learn the 'fashionable' new language doesn't mean you are smarter or a
better programmer; it just means you have more free time.

In my professional experience, people that are always learning new languages
or are constantly using new libraries and frameworks are never the ones who
accomplish the most. They simply are the ones who are always seeking novelty;
they never become great at a language, because they are always wanting to try
something new. They start lots of projects, but don't finish them.

I don't think those are the best qualities to look for in employees.

~~~
crdoconnor
>In my professional experience, people that are always learning new languages
or are constantly using new libraries and frameworks are never the ones who
accomplish the most.

There's a huge difference between chasing fashion and seeking out what is new
that is actually _better_.

I agree that those people are usually worse. The ones that pick up on new
stuff that isn't necessarily fashionable, assess it intelligently and balance
the trade offs of the good vs the bad - those _are_ the better programmers.

IME scala programmers are better - mostly because they tend to be programmers
who got frustrated with java's shortcomings and realized scala solved many of
those shortcomings, not because it's fashionable to learn scala.

IMO people who chased mongo, on the other hand, demonstrated a responsiveness
to large marketing budgets rather than critical thinking skills.

You don't have to try out every new technology either. There are some that you
just have to read a bit about to know enough to dismiss them.

~~~
pkaeding
Hey, I resemble that comment!

As someone with extensive experience in both Scala and Mongo, I agree. Mongo
is nice for experiments that might go nowhere, but when you give it a real
production workload, it falls apart fast.

------
noir-york
What are you hiring programmers for? A science project, or a company which has
to meet business goals?

If the former, by all means, pick some esoteric language. If its the latter,
more mundane issues like existing codebase, skillset and, I don't know,
perhaps using the right tool for the job? C# can do things Python cannot and
vice-versa.

Learning Scala to show off and fit in Graham's paradox is silly and doesn't
prove that you are a smarter programmer. A smart programmer is someone who
comes up with smart solutions; you can write crap code in any language.

~~~
saosebastiao
I hope you are not suggesting that scala is esoteric or that it is not the
right tool for the job in a huge amount of situations. It is a full on
industrial language that has been proven in tons of high value and
performance-demanding situations. C# might have initially taken Java as an
inspiration, but ever since 2.0, Scala has been the bigger influence on its
design...and rightly so. If a smart programmer is one who comes up with smart
solutions, Scala can be part of that solution.

~~~
freehunter
I think rather the implication is, don't pick Scala just because Python is
more common. If you need to use Scala, use Scala. Like you said, there are
plenty of situations where that is the case. But if Python is the right tool
for the job, don't ignore it just to be different.

The same can be said of other languages with less emotion surrounding them. If
C++ is the right tool for the job, don't use C just because of ideology. You
are running a business, not a religion. You can only afford to be choosy if
there are multiple "right tools for the job".

~~~
noir-york
Well put :)

------
TheMagicHorsey
I would have said Go rather than Scala, but now Go is pretty mainstream.

I think my choice today for a Python Paradox would be Erlang or Ocaml. Ocaml +
MirageOS is a system level simplification that makes application
correctness/security a much more tractable task than [any other language +
linux].

Erlang is the most common sense way to build resilient, distributed
applications. But there is a high barrier to entry to learn both Erlang and
the OTP framework that makes it useful.

Having said that, I've never worked at a company where choosing Erlang or
Ocaml was a possibility. I think there are companies that make bold technical
choices, but I haven't had the good fortune of being given the chance to work
at such a place.

~~~
sidlls
Go is mainstream? In what universe? These are mainstream languages today: C,
C++, Java, PHP, Ruby, Python, JavaScript, and C#. The vast majority of all
applications written today are written using one of those languages. Go barely
registers inside the Bay Area bubble, and far less outside of it. If a "Python
paradox" even is a thing, Go would certainly be a candidate. I think the
"Python paradox" is a silly concept, though.

~~~
TheMagicHorsey
You may be right. I work in the Bay Area, and I see a lot of devops projects
in Go these days. In fact, I'm hard pressed to find a new devops project that
isn't in Go.

But I agree that the Bay Area, and San Francisco specifically, is a bit of a
bubble. So its very possible that there is little Go traction in other cities.

~~~
XorNot
Go has devops traction because of it's deployment story. It solves a bunch of
problems people have with trying to use Python for the types of things you do
in devops.

~~~
BerislavLopac
Such as? I'm honestly interested what problems you have in mind, not implying
that they don't exit.

~~~
bogomipz
Distributing artifacts for one, a single self-contained binary in the case of
Go vs a virtualenv or buildout for shipping and managing dependencies for a
Python app.

------
JohnnyConatus
I used Scala for one company I founded and the Python Paradox to be true.
People who already knew Scala were generally much more accomplished
programmers and for the people who didn't know, the learning of it was a great
test of their ability. Here's why: as a hiring manager, I know it's possible
to learn Scala. So if someone couldn't learn it and be productive within 30
days I knew they weren't sharp. (FYI, everyone did learn it quickly, but
frankly, the best programmers can learn a new language in a weekend.)

------
zerr
These paradoxes come and go, but there is only one paradox that remains the
same: C++ :)

~~~
antod
The original paradox was the Paradox Paradox where you avoided all those blub
Access developers.

------
watmough
What's the feeling on raw C++ these days?

Is it _still_ truly mainstream, or have C++ users, at least on Microsoft,
mostly migrated to managed C# code?

Certainly at the company I work at, there's been an active migration over
maybe the last 5 - 6 years to C# from C++, though we still have millions of
lines of C++ / MFC / WinForms code in the primary application I support and
help maintain.

Career-wise, I'm quite happy to stay with C++, as it's been my experience that
I can throw together utilities that run with minimal, run fast and are
reliable, just using C++ and the standard libraries.

As far as writing Scala or Python, Why write code that goes slower than it
needs to?

~~~
BerislavLopac
> As far as writing Scala or Python, Why write code that goes slower than it
> needs to?

Let me put it this way: why write software that goes faster than it needs to
but is written slower than it needs to be?

~~~
watmough
Good point, but the sort of utilities, data munging code I typically write,
can be hammered out in C, or C++ pretty fast.

I've been easing into the C++ standard library, lambdas etc., and familiarity
makes it easy to write code that uses standard proven, fast, data structures,
and mostly allows me to avoid any non-stack data allocation.

Avoiding heap memory allocation, and taking advantage of the appropriate
idioms, allows much faster development, even in C++.

The huge bonus when done correctly, is very high-performance, clear and
portable code.

------
ludamad
Can't you just bias for people with personal projects in any language?

~~~
biehl
Yes. Leaning new technologies (and using them appropriately) is probably a
valid indicator of something to hire for. But certainly not the only one. A
personal project might show of better indicators - design skills,
communication skills etc

~~~
hughperkins
I vote personal project. Its meritocratic. It involves approximately similar
skills to being successful in a technical role. It contributes something new
and novel to society. Its probably a better predictor than fizzbuzz, or
knowing some technology buzzwords...

------
kozikow
I was there and worked in company that hired for Scala. I've seen teams who
went back to Java 8 be more productive than teams that went hardcore Scala,
including Scalaz.

If you filter for Scala, you are more likely to pick academic purists trying
to show off with their core. If you filter for go, you are more likely to pick
pragmatics, who will be aware that every choice is a trade-off (including no
generics) and will value maintainable code over clever code.

I already made a choice.

------
labrador
If hiring a JavaScript programmer, if he or she had not at least learned the
basics of Dart and TypeScript and done a weekend project in it, I would
consider them incurious. Considering that all the best developers are very
curious people, this would be an effective filter. For c++ programmers, if
they hadn't done something in D it would be a red flag.

~~~
douche
You're selecting for language dilettantes, then, I'm afraid. Especially for
languages like C++ or JS, that contains worlds of different approaches within
their umbrellas, I don't necessarily see not dabbling with something that
fills the same niche as a deal-breaker, or indeed all that valuable, really.

I would consider a more useful filter looking at people that have experience
in multiple levels of the stack, whatever your particular niche happens to be.
For web dev, having a good handle on two or more of: SQL, a server-side
language, and JS/CSS/HTML. Substitute whatever blocks fit in your particular
equation.

~~~
labrador
We're talking about two different types of programmer I think. You're talking
about a maintenance programmer and I'm talking about someone who might be able
to move the technology stack forward and possibly save some money in the
process by finding a new and more efficient way of programming. I wouldn't
expect someone who is happy doing the same thing over and over again in
maintenance mode to be that person, although this type of programmer is a very
necessary part of the team.

~~~
douche
It might be a function of team size. I've spent most of my career in small
teams, and so the flexibility to wear a couple hats at a time is relatively
more important, and helps reduce the bus factor.

------
bogomipz
I am curious what constitutes a programmer who "knows" Scala?

It is enough to be fluent with a common framework such Play? Must one be
proficient in using it in all three - functional, object and procedural
programming contexts? The breadth of the language really is an overwhelming
barrier to entry to someone coming from say Python.

I am interested in hearing what people think.

------
interrrested
What language would it be in 2016 ? Go ? Rust ?

~~~
aikah
> Go

It was specifically design to disallow smart-asses to write ninja-code, so no.
Go is for monkey programmer factories which managers want to make sure they
will only code a certain way because Go doesn't give the developer choices.
It's the anti C++,scala,python,clojure... Go tells you to do this that way,
and doesn't give you the constructs or features to make your own choice about
coding.

~~~
fixxer
If you want to experience a "programmer factory", learn Java and get a job at
a bank.

~~~
bberrry
Damn, that's what I do :(

~~~
fixxer
Damn, me too. Money is nice though, amirite?!

------
meshko
I'm not terribly sure about this, might be my skewed perspective, but it feels
like Scala is being dragged into mainstream by Spark.

~~~
dllthomas
This matches my impression - it seems very much mainstream within the data
analysis niche, and that's leaking a bit.

------
djhworld
I wonder if the author still believes this, 7 years later.

------
BucketSort
It's not a paradox. REEEE

