econoplas

Apple could easily reject Google voice app with their "thy program shalt not containeth an interpretereth" loophole in the iPhone SDK agreement section 3.3.2... they've done this with at least one app that I'm aware of (http://toucharcade.com/2009/06/20/full-commodore-64-emulator... and http://www.manomio.com/index.php/blog/important_update).

How many programs nowadays of the complexity of Google voice don't use some kind of internal state machine interpreter or domain-specific-language to simplify the programming model?

So they could use that loophole in a negative way to hinder competition whenever they choose to do so, not saying they "would" but they certainly "could".

I disagree somewhat about the "not very productive" part, at least in the particular case of scala.

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.