Slashdot Mirror

I cited a comprehensive survey. You just talked about github. Yes, a particular open-source repository (Github) is popular among Ruby developers. The fact that you confuse this with language popularity is another hint about your critical thinking skills.

There is indeed economic merit in choosing developer productivity over runtime performance. However, there is no need to choose one or the other. Many other languages exist that are fine competitors to Ruby in terms of developer productivity, and most will not run as slowly. If you ignore them, your career will suffer.

I have invested many years in Ruby at this point, and I hope you can see that I am not unaware of its benefits. This is how I came to be in the position to scale Ruby applications, though of course, rather than have the droll exercise of being blindly accused of being "bad at it," I will refer you to the innumerable published experiences of famous Ruby developers who had to abandon the language due to scale issues. For theory, I will refer you to the excellent work of Charles Nutter, author of JRuby, currently among the best performing Ruby VMs, and far beyond Matz's work.

I have backed up every statement I've made, though if you feel that having a global interpreter lock is some kind of virtue, and does not reduce the scalability case of your language, you are stating something so extraordinary and beyond the pale of any conventional wisdom or common sense, it is upon you to prove it - to the astonishment of all, I assure you.

If you are getting by with forks and multi-tiered archtectures and high-open file limits and Passenger, I salute you. But if you really are this insecure and uninformed about Ruby, I suggest you learn another language - Groovy perhaps, or Python - or push yourself and learn Objective C or C++. Alternately, consider work on addressing the flaws in Ruby - your help is certainly needed, and you might give your beloved platform better hope for the future.

Making your mobile platform incompatible with anything already out there is a choice, and not a choice I agree with.

Do you make phones? If not your opinion is worthless as you are not a Google customer for Android.

Google have to do what the likes of HTC, Samsung, Motorola and whoever else want. That means they want to be able to build a phone manufacturer specific "look and feel" on top of android that makes their android unique. They usually do not want to open source this work because these are hardware manufacturers. Companies that design their own hardware are generally reluctant to embrace open source for some reason.

That rules out OpenJDK (also, OpenJDK did not exist when Android was initially developed according to a footnote here: http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-google.html)

So that leaves building on a Sun / Oracle product and paying them revenue. This has two problems:

1) Oracle's director is apparently a personal friend of Steve Jobs so Oracle would overcharge Google or demand that each hardware company had to negotiate with Oracle directly for the rights to use Android. This would make the platform a joke.

2) This would eat into either Google or the hardware vendors profits. Google might be able to take the hit, but companies like Motorola (The handset division anyway) cannot.

Much more in-depth: http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-google.html Especially the second part, where he analyzes each patent's claims.

P.S. Anyone else chuckled after reading the name Charles Nutter?

Yes, but probably not for the reasons you did. I chuckled because I used to work with Charlie, was good friends with him at the University job he mentioned in his blog post, and was glad to see him land somewhere doing something he loved to do (JRuby). We should all be that lucky. Go, Charlie.

I think I'll go email him now, catch up on things.

I wanted to recommend this detailed blog posting (about 8,500 words, plenty of scrolling) on Oracle vs. Google.

It discussed many aspects of the dispute and in particular goes into detail on the seven patents Oracle seeks to enforce against Google, and inhowfar they may or may not read on Android.

I posted a correction in the comments there to point out that Oracle changed its stance on software patents years ago, not just after acquiring Sun's patent portfolio.

You can import class files compiled from other languages such as Scala, Jython, etc.

http://blog.headius.com/2009/08/return-of-ruboto.html
http://www.scala-lang.org/node/160

With Java's built in support for dynamic languages, and a little more time, you'll able to compile any language of your choosing into a .class that can be used in Android.

JVM is going to get invokedynamic instruction soon - http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

Even without 'invkoedynamic', JRuby is one of the best-performing Ruby interpreters.

MacRuby matters for a lot of reasons. Early benchmarks aren't one of them. http://blog.headius.com/2009/03/on-benchmarking.html

MacRuby's potential for Cocoa integration is fantastic and great, and something i very very much want to see.

It's not clear however what relationship benchmarks at this stage (with an incomplete implementation) will actually correspond to in the future. They are a total red herring for discussion.

Look at MacRuby on the merits! not the benchmarks!

One interesting feature of the competition is that .NET and JVM are also looking to make themselves more friendly to dynamic languages, so it's not a totally stationary target. The most promising seems to be the proposal to add an "invokedynamic" bytecode to the JVM, which would allow a bunch of stuff dynamic languages do to be handled by the JVM (instead of them having to build their own dispatch mechanisms on top of it).

You can use C with JRuby too, using the exact same interface as MRI and Rubinius.

This was discussed at the Ruby implementor's summit at RubyConf.new(2006), and Charles Nutter has started a ruby spec wiki:

http://www.headius.com/rubyspec

Also discussed was specification through tests (that is, if an implementation passes the unit tests for the most commonly used set of ruby applications/libraries, then it is good enough).

For the notes on the summit:

http://wiki.rubygarden.org/Ruby/page/show/RubyImpl emntersSummit2006Nov
http://www.google.com/search?q=cache:wylYVnj0RpIJ: wiki.rubygarden.org/Ruby/page/show/RubyImplemnters Summit2006Nov&strip=1

(User #5562 Info | http://www.headius.com)

User #5562? Aren't you a little old to be trolling? Have you played with Linux since you got your account on /.? X windows *isn't* slow. It's got a number of issues, but speed doesn't even loom large among them. The reason other recent OSes haven't gone with X windows is either because they don't want open source, they want other *features*, or they don't want to deal with maintaining a fork that huge.

Hell. Mac OS X's windowing environment *does* have hooks for Client/Server operation. They went with something else because they wanted to be like display postscript. And it helps them charge $$ for their OS.

And it's slower than X anyway... what was your point?