The Python Paradox is now the Scala Paradox

I disagree somewhat about the "not very productive" part, at least in the particular case of scala.<p>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.<p>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.<p>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).<p>I personally see scala being somewhat in a different category from CPython for 2 main reasons: JVM (stability, maturity) &#38; Java interoperability (vast library resources).<p>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.<p>2. The other (main) reason I'm looking at scala is the HUGE advantage of JVM interoperability and the vast libraries available.<p>From my Python &#38; Java &#38; other language experience, I have learned that:<p>=&#62; 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<p>=&#62; 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 &#38; whatzits nowadays, right?<p>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 &#38; SOA development, DSLs &#38; modeling, reporting, DB persistence, and then write our glue logic in scala or other JVM language of choice.<p>We can even intermix them with other JVM languages in the same project (Groovy, Jython, Jruby, clojure, PNut, etc).<p>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 &#38; 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 :)<p>Wow.

Esoteric languages are a lot of fun. But they're not very productive, exactly for the reasons mentioned: lousy IDE support, buggy compilers, few libraries, few bindings to existing libraries, and so on. When you work in a stable language, you can assume that when something goes wrong -you- messed up. In a new and cool language you don't have that luxury.<p>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.<p>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.<p>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.<p>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.<p>(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.)

Scala is _not_ some esoteric MIT, CMU language to make a point exercise. Its a pragmatic and practical attempt to "fix" Java so it has all the capabilities of Java with the proper foundational coherence which allows for additional, some yet to be defined or added, capabilities. Java has long ago painted itself into a corner. It has reached its evolutionary dead end.<p>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.<p>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.<p>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 ...<p>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"<p>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.<p>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).<p>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.

<i>Because it's down now, a vague summary from what I saw.</i><p>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.

I have to say that, even as someone fascinated with Scala this week, I find the argumentation here a little disingenuous. There are a lot of ways to filter developers and I don't think that the ability to learn a new language sets the bar high enough to actually select for the good ones and potentially means selecting the wrong tool for the job.<p>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.

The Haskell Paradox, too.

Site down. Cancel.