The Python Paradox is now the Scala Paradox
yes-no-cancel.co.uk
yes-no-cancel.co.uk
I've developed several large projects in Python (specifically CPython 2.x) for $$ for about 6 years and I am learning scala right now. So I have a somewhat interesting perspective on both.
Although I suppose I could be termed a Pythonista since I "do python" for a living, I consider myself more of a true polyglot... I also use Perl, Ruby, C++, Java, Lisp, C#, whatever language I can get my hands on that fits for the project at hand. I don't subscribe to the Golden Hammer theory.
So far, scala does feel like it has that 5x productivity improvement as compared to using straight Java, on par with what I experienced when I started porting significant portions of the code base of a large application from C++ to CPython (embedding CPython in C++, or vice-versa as needed).
I personally see scala being somewhat in a different category from CPython for 2 main reasons: JVM (stability, maturity) & Java interoperability (vast library resources).
1. The JVM is arguably the most widely used, stable, and mature virtual machine ever developed. Not surprising since Sun and IBM have both invested millions (billions?) in JVM development over the last 15+ years. The latest generation JVMs sport multi-threaded garbage collection, profiler support, remote debugging, remote method invocation, compile-and-reload while debugging, and very advanced JIT. JVM runs in more places than any other VM to date. 'Nuf said. Yes CLR is probably on similar footing nowadays. By comparison Python, Ruby, Perl, scheme, or any other language that has its own home-grown VM is always going to be behind that curve... for example, I was just reading about how most of the Common Lisps (many pre-dating the JVM) are still working on adding multi-threaded garbage collection.
2. The other (main) reason I'm looking at scala is the HUGE advantage of JVM interoperability and the vast libraries available.
From my Python & Java & other language experience, I have learned that:
=> cool-language-features-productivity-multiplier = 5x to 10x productivity improvement, such as what Lisp and most of the dynamic interpreted languages (CPython, Ruby, Perl) claim and pretty much deliver
=> existing-library-productivity-multiplier = 100x or more, since I don't have to re-invent every wheel every time for file format X reader/writer, GUI widget, or other library du-jour. Let's face it, we have to interoperate and communicate with a lot of different gizmos & whatzits nowadays, right?
We all know that we as programmers are vastly more productive when we can get almost any library imaginable (usually open source) to do almost anything we want... GUIs, Charting, FFTs/Numerics, networking, 3D graphics, Neural Nets, , and can even leverage Eclipse environment and toolkits for programming in the large for GUI building, writing rich-client platforms (building entire IDE's), Web server frameworks, web services & SOA development, DSLs & modeling, reporting, DB persistence, and then write our glue logic in scala or other JVM language of choice.
We can even intermix them with other JVM languages in the same project (Groovy, Jython, Jruby, clojure, PNut, etc).
The good news is... if I pick scala, and it doesn't work out... I can always selectively replace out the pieces I don't want to keep one-at-a-time in Java or any other JVM language as time permits. But if it works, I'll just leave it alone. Nobody even needs to know my JAR is written in scala except that they have to put a couple of scala JARs on the classpath. Not so for CPython where the installation & deployment overhead is much steeper in my experience. Not everyone has CPython 2.6 installed on every machine for example, but most everyone has a JVM 1.5 or greater whether they know it or not :)
Wow.
You'll be less productive, but you'll have more fun when you get to program in language. A good trade off? I don't think so. A few years down the road you'll have to maintain the same project. The honeymoon period is over, and the code base isn't quite as good as you'd like it to be (you designed the project back when you didn't know the language very well, and it shows). You know you could spend a few weeks refactoring, but that would probably introduce bugs and you'll drive the other people in your team crazy if you start renaming methods, and move stuff around just to make the code "nicer". And besides, you'd much rather be programming in the next-nifty-language, because it lets you extend the syntax at runtime and it has a debugger that will let you go back in time.
The bottom line is that when you pick a language that is on the cutting edge of cool right now will no longer be cool a few years from now, but it still won't have any libraries and other essentials. Languages too have to cross the chasm, and they all have to go through a period where they're neither new and exciting nor stable.
If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. Want a challenge? Write your app in such a way that power can be lost at any point in time without losing any user data. Or (for desktop apps) make sure that the UI -never- hangs, even when the hard drive has to spin up. Software is never done, there are always things you can make better, more fault tolerant, faster. It's not as if we've run out of challenges.
Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
(Of course there are obvious exceptions, and that Clojure and Scala use the JVM does make the whole library thing less of an issue. But it's still a big deal.)
I agree with your basic premise but,
Python and ruby both have extremely good library support. Hell, python's stated aim is batteries included. Both of them have (al least semi-)mature Jvm implementations. Django has a stated policy of not breaking backward compatibility on point releases.
I agree you need to choose stable languages to work with, but if you are selling consulting services around Java god luck competing with BigCo. If you are building your products with Struts, good luck doing xml-situps.
In two years time most libraries will move to Python 3.0, and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works, or I'll have to use insecure libraries. I don't like those options at all. How can we write solid and stable software if we don't have a stable foundation to build on?
C++ code I've written a dozen years ago still compiles and runs fine. Executables still run when double-clicked. If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
Python exists 20 years now and the spec is still not stable. Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
.Net, JVM, Perl. Apart from these, which lanngauge has better Library than Python? Python is available on two of them. Ruby one one of them at least. (I dunno if ruby is avaialble on .Net)
> CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
No. Afaik, Python has never broken backward compatibility in a majot way on point releases, and even minor details are dicussed ad infintum on the mailing list. Py3K was discussed for 8 years, before being released.
> Python 2.6 libraries almost never work in 2.4
Neither do Java's library which use generics or Autoboxing work in Java 1.4. However libaries comaptible with Java 1.4 work in 1.5(or 5.0 if you will), and so do libraries which were written for Python 2.4, do in 2.5 and 2.6. Languages can only guarantee backward compatibility. I am not sure which language you work in that guarantees forward compatibility.
> and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works
Django has a stated security policy. All security bugs must be fixed for 2 point releases prior to latest release. 0.96 got official security upgrades till recently. People have backported it to 0.95 and released.
> How can we write solid and stable software if we don't have a stable foundation to build on?
Sorry, but what you are asking here is again forward compatibilty. What will you have, Django never move to 3.0?
> Python exists 20 years now and the spec is still not stable.
Define stable. Python has 1. A reference implemntation. 2. Mutiple VM implemntations, targetting the popular ones. 3. Others, (Stackless, Pypy etc). Unless you use platform specific functions, your code will run on any of these. Fyi, the reference is, http://docs.python.org/reference/introduction.html .
Probabaly you hold a problem with this philosophy, from the reference (While I am trying to be as precise as possible, I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities.) But this is a debated, and concious decision.
- I don't know if Python on the JVM is stable. Last time I checked Ruby on the JVM and .NET was in its infancy.
- They're not big breaks, and they are, as you say, discussed on mailing lists. The difference is that with a JAR file you can upgrade Java and you _know_ that the JAR will continue to run. With Python the only guarantee you have is that one of your libraries is going to throw an exception at some point after you upgrade. Essentially, you have to keep track of every library you use, and you have to check if it's compatible with the new point release.
- Not forward. Merely backward. Backward compatibility is offered by JAR files. You compile it, and even if the language changes the JAR will stay in place. Because the Java VM is stable you don't have to worry as much about precompiled libraries. I don't think Java is the solution to the world's problems, but at least old JAR files still run on modern JVMs (afaik). You can also design a language grammar in such a way that you leave room for future extensions. That is, to only make previously illegal statements legal. To change the semantics of legal statements (except for the rarest of corner cases) is, I think, a bad (but tempting) idea. You can have forward compatibility if you guarantee that code that uses new features won't compile or even attempt to run on an older interpreter. Essentially, if it runs it works. That is a hard guarantee, and the kind of thing you can build on.
> Define stable? That the language grammar doesn't change. Or more generally, that every version of the interpreter can flawlessly execute code written for version n - 1. Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated. The number of man-hours this will take is staggering.
When you're actively developing in a language, these changes are only a minor nuisance, and upgrades come with a bunch of goodies. 10 years down the road you just want things to run, and with Python the only way to guarantee that is by deleting aptitude.
If you have code that works fine in Python 2.4 upgrading to 2.5, 2.6, 2.7 etc won't break your program. If you write you program in Python 2.6 you have to take special care if you want it to run in 2.4. Until Django decides to bump up the minimum version required, which I believe is at 2.3 now, you have nothing to worry about.
Since Python 3.x is not a point release, compatibility is not guaranteed anymore between 2.x. The 2to3 tool will take care of all the easier but time consuming tasks. Why waste the man hours converting 'print x' to 'print(x)' and 'xrange' to 'range' if there is a free tool to do it for you?
Really you are making a mountain out of a mole-hill. If you are not updating your software/site anymore with new features let it be. Python interpreters can run side by side.
When I see a statement that "backwards compatibility is guaranteed", I generally take that literally. And it's really a binary thing. Either it's guaranteed, or it isn't. And with Python it most definitely isn't.
We clearly look at this from a different perspective. I think it's a big deal, and you don't.
Stop using Python 3 as an example of "python instability" damn it, it's a change known to be incompatible, it's been in preparation for 5 years, it's not an evolution one's supposed to take lightly and it does not mean the end of the 2.x branch for at least a pair of years.
Before that, here's the track record of Python backwards compatibility: you can run Python 1.6 (2000-09-05) code on Python 2.6. In fact that's exactly what ElementTree does.
If Python 2.6 would flawlessly execute all Python 1.6 code I would have no complaint.
Lisp? :-)
CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.
I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.
If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
I think that says more about your deployment methods than about python or django.
Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.
Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.
You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?
The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.
The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?
You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).
I mean, you're not forced to use the newest version of the interpreter. You're not forced to use the newest version of any library. Moreover, you're not forced to use a single specific version of the interpreter on a machine. And with the use of virtualenv or buildout, you won't complain that your application used to work, and it doesn't, because the environment evolved.
And if you're "scpying directories" between servers, relying on whatever version of the interpreter you find, you're doing it wrong.
And also, some esoteric languages, like Haskell, the ML family, Erlang and so on have deep roots, they may not be mainstream but they aren't going away anytime soon. And sometimes something funny happens; anyone who has ML experience is going to feel right at home on F# and suddenly the library problem is solved, the IDE problem is solved, the bindings problem is solved...
None of Haskell, ML or Erlang is an esoteric language.
Esoteric languages are not created for real-world usage (or even for usage at all), examples of such languages are INTERCAL, Thue, Unlambda, Moo, Befunge or Java2K. They can be turing tarpits (languages with extremely low number of commands), funges (multi-dimensional programs), nondeterministic (from a given global state A and a current instruction f, the next state `f A` of the system can't be predicted)…
There's nothing esoteric about a language such as Erlang created very specifically to solve industrial problems, or even about languages originally created for research (ML or Haskell), especially when they've now leaked into practical, real-world programming outside of academia.
No esoteric language was mentioned in TFA.
> But they're not very productive
Esoteric languages aren't "not very productive", they're the most counter-productive langages on the planet. Productivity runs counter to the point of an esoteric language.
> Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish.
Wow. Cocaine is one hell of a drug.
Yes, because purposefully using terms which don't apply to the subject just to insult other people or degrade languages you don't like clearly doesn't.
http://esolangs.org/wiki/Esoteric_programming_language
> It's meant as the opposite of mainstream; languages you won't find at IBM.
Then what you're looking for is "non-mainstream". Or maybe "suit-incompatible". And FWIW IBM has a lot of Python stuff in their developerworks site and newsletter. And given Erlang comes from Ericsson, not exactly a small company, it's hardly "suit-incompatible".
This is valid in a sense, but it is also important to remember that a lot of software was built with emacs and vi or even more ancient editors.
"If you're serious about software, concentrate on writing something that is reliable as hell and easy to maintain and install. "
That is terrible advice, not so much the sentence itself as the "stay away from powerful languages" spin you give it, as in
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. "
There are profitable companies using Haskell and OCaml (and Lisp and J and .. )!
You make a decent point then spoil it by stretching it too far, to the point of farce.
One situation in which you should definitely not use advanced languages is when you know you have (or intend to hire) very dumb "programmers" who won't be able to warp their heads around the "exotic" language, which probably doesn't have a "Learn in 21 days" book to go with it.
Many companies doing outsourced software do hire these "middle of the curve" programmers and will do well to stay with "stable" languages. If you have a bunch of bright programmers doing something innovative, it is a completely different situation.
By your logic PG wouldn't have built Viaweb in Lisp, FlightCaster wouldn't be using Clojure and so on.
Taking just one example, Clojure is evolving very fast, which for you would be "unstable". I know at least 4 startups using Clojure, one using Scala and no one's yet complained of "instability" and lack of IDE support destroying their productivity. There are tradeoffs (IDE maturity being one, if you are an I-can't-program-productively-without-my-IDE kind of guy ) with any language selection, but the consequences aren't as dire as you make it out to be.
As I said, this is bad (or rather very one sided, which amounts to the same thing in practice) advice. There is an excellent rationale for building certain types of applications in powerful languages, what PG calls LFSP - languages for smart people.
PG and other people have made this argument more eloquently than I can, so I'll refrain.
"Python/Django and Ruby/Rails are only barely stable enough to work with."
heh heh! Sure, What do you use then? COBOL? Should be "stable" enough for you I guess.
Somebody should tell all the stupid programmers using RoR or Django to run companies that they are being foolish, using "barely stable" software. ;-)
PG built Viaweb in Lisp because there was no Ruby, Python or Perl back then. When there are no libraries to chose from, you pick a language that lets you write libraries quickly. Today we boldly go where many have gone before, and that means that we can benefit from technologies others have built. Standing on the shoulders of giants, and all that.
I'm arguing that if you want to run a business you should be pragmatic about the language you pick.
The second half of your post seems to consist of mere hyperbole and strawmen (COBOL? Right). If there is excellent rationale for picking an esoteric language, I'd love to hear it.
First, you were the one suggesting we don't use Ruby or Python, in 2009 in the name of "stability". and now you are saying PG would have used these "unstable" languages in 1995 "if they existed" which brings me to
"because there was no Ruby, Python or Perl back then."
You are wrong.
ViaWeb was started in 1995
Perl was available (and being used to build websites) in 1995. Python was available too. Do your research before making ridiculous claims!
As PG says in one of his essays (link below)
"During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers."
;-)
You go on to say,
"If there is excellent rationale for picking an esoteric language, I'd love to hear it."
Start with the PG essay I quoted above, http://www.paulgraham.com/icad.html
many nice points there, for e.g:
"In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language you probably won't need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter."
He (and others) have written a lot about this. Again, do your research. You may or may not agree with the rationale he puts forward, but you undermine your own argument when you make up things to strengthen it (like perl not existing in 1995).
Then why did he build Hacker News in Lisp?
The Java language in its current form is from 2004. The Haskell language in its current form is from 1998. Both originally appeared in 1990. Lisp is much older.
So sometimes "stable" can degenerate into "frozen solid." Not having new libraries is arguably as bad as not being stable.
This gives me a REPL I can use to type in expressions referencing my existing code base and immediately see the result. Clojure has macros that make typing in many Java expressions require even fewer parens than Java itself! PG came up with the sketching analogy to describe what its like trying things in an interactive environment, immediately seeing the results, then modifying little by little to eventually get the result you want.
When I switch back to Java, on the other hand, I feel like I'm chiseling my code in granite. I need to have all of the boiler plate just so before I can see any results at all, followed by a compile and run or debug cycle. Test driven development makes this a little better, but just a little.
"Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place."
It seems that some things never change!
As someone who lead a team which wrote one of the largest retail websites in the earlier days of Java, and as someone who has spent the last year rewriting legacy business logic in Scala, there is no comparison.
Scala wins not because its the new hipster language, it's distinctly superior across the board. You can write better, clearer, far more robust, far more scalable and far more easier to maintain and modify business logic at higher levels of productivity. That and its ability to work with legacy Java code makes it ideal. This is from direct and in-depth experience.
My concern with gizmo's post is its complete lack of claimed experience. No context of based on my experience where ... so we ... and then did a POC comparison with ... and found .... and concluded ...
In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Privately I've played with all of them. I love the shear outrageous power and beauty of Scheme (PLTs impl) and Haskell, the base competency of SML, and I've even used them in the enterprise in isolated in very few situations where the situation demanded it.
However, never once did it cross my mind to even "think" to introduce any of them into the enterprise (well a brief fling with Python for our operations group, it was found to be too hard).
Scala deserves to win. It is decidedly superior, however, lots of deservedly good things, in fact most, never see the light of day in IT.
It's fine to take a calculated risk (Scala) if the direct benefits are measurable and significant. I'm not claiming that people should dogmatically stick to languages from the 90ies because they're safe. I'm saying that you need a very good reason to use a language with an uncertain future.
Also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO.
(a) no one ever diplayed such an attitude on this discussion or put that argument forward. Strawman.
(b) This is what you said.
"Messing around with unstable languages is a lot of fun. It's educational too. But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with. "
which is different from reacting to the non existent "everybody can see how cool we are if use language foo" argument.
"I also note that I (deliberately) didn't put Scala in the list of foolishness that contains Clean and IO."
But you did say " Thinking that using Haskell, Clean, IO or Lisp will be a net benefit to productivity is foolish."
You never really showed where the "foolishness" is.
Also, from your original list that still leaves Haskell and Lisp as languages that don't "provide a net productivity gain", which is a very strange (and as pointed out by boskone above, unsubstantiated) claim. There are profitable businesses built on both these languages (lisp is a family of languages but still .. ), and very capable programmers being massively productive using both.
You said something stupid with nothing to back it up, got hauled over the coals and are now backtracking trying to make a less objectionable claim.
You then claimed Perl didn't exist in 1995 (!) and that's why PG used CL for ViaWeb (!).
quoting boskone "In fact it appears very much to be a direct quote of from the preamble from the "Enterprise IT Managers Survival Handbook For Those Without Experience Or Knowledge Of Software Development Fundamentals"
Indeed.
I stand by what I said in (b). That you shouldn't pick a language because it's fun -- this I find almost self-evident. When you want to build a business you need to be more pragmatic and you need to consider other factors. Django and Rails are now probably the most popular frameworks for web 2.0 shops. I claim they are not very stable (and I provide supporting arguments in other posts). So I argue that using Django/Rails is adventurous enough. Barely stable enough obviously doesn't mean that it's unusable or worthless. The success of many Django/Rails projects is evidence of that.
The onus is on those who use non-mainstream languages to provide evidence there is an advantage. I claim there is no advantage, and I point out several downsides. If I claim that using Assembly for web programming is foolish you wouldn't expect me to show you why either.
"But of course there are obvious exceptions" covers the few businesses that have become successful. Here too, the onus is not on me to prove that Lisp did not contribute to their success, the onus is on those who are successful to show that it is Lisp that made it so. The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know.
I'm not taking back anything I said. I stand by it. I find that some of you are looking for things to disagree with, and you read my statements in the most objectionable way. You're saying you know what I meant better than I did when I wrote it. That's quite presumptuous. To attack my character by implying I'm trying to weasel out of anything is most uncalled for.
My claim that Perl didn't exist when viaweb was started was indeed stupid. Had I known viaweb started in 1995 I would never have said that. I (mis)remembered something pg said some time back, along the lines of "if I had to start viaweb today, I would use Python or Ruby". Maybe pg never said that, I don't know. Either way, I was completely wrong there.
edit: found the reference http://news.ycombinator.com/item?id=36905 (I was wrong)
Some evidence would be nice. I don't see it at all in the sense you claim i.e "we'll use a cool language because it makes us cool". No one I know on HN ever makes that claim or thinks that way. And yet to you it is "very visible". Links please?
"The reddit people drank the cool-aid, and it didn't work out for them. A single data point, I know"
But you don't accept "single data points" in the other direction do you? ViaWeb, Jane Street, Orbitz, FlightCaster?
"single data point I know" ;-)
"The onus is on those who use non-mainstream languages to provide evidence there is an advantage."
You are the one who makes outrageous claims that there is no productivity gain without ever actually using "esoteric" languages in a business context, so you could have some experience backing t your claim that there is no productivity increase. Your troubles upgrading Python (or whatever, your arguments on this are very vague and unconvincing) are not sufficient. Sorry.
When people who actually do use powerful languages to run their businesses report increased productivity, you refuse to accept it or consider it a possibility.
<Shug> Flip Bit. Move on.
"You're saying you know what I meant better than I did when I wrote it."
I don't know you in person. I have to judge your argument by what you actually write not by what you thought in your innermost heart when you wrote it. In your writing you come across as uninformed wrt your claims, and constantly shifting positions when confronted with counter claims, citations or evidence.
That said, I am done discussing this with you. Your argument has nothing backing it but "I think thus and thus with no experience or data or evidence and I refuse to consider anything contrary to my stated position".
Good Bye, Have a nice day.
Python and Ruby are now basically "mainstream" languages with little of the all new sparkle they had several years ago - little early adopter aura around them. What languages have that 2004 shine in 2009? Author decides to try Scala for this reason and likes it. Author thinks Scala is the new Python because people are excited by it.
There are a large group of people that are effectively programming language hobbyists, frequently learning new programming languages for kicks, and while that set intersects the set of good developers, it is not a subset of it.
So you are correct, but you could probably even trust your HR department armed with a suitable list of esoteric languages keywords (instead of their usual "Java" etc) to build you a pretty good first-interview shortlist, even if you were after Java developers.
http://www.google.com/search?q=cache:http://www.yes-no-cance...