<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Android, iPhone, Java, Objective-C&#8230; madness</title>
	<atom:link href="http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/feed/" rel="self" type="application/rss+xml" />
	<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/</link>
	<description>Brian Pontarelli</description>
	<lastBuildDate>Wed, 08 Feb 2012 15:34:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: objective c</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-139190</link>
		<dc:creator>objective c</dc:creator>
		<pubDate>Mon, 28 Nov 2011 06:04:02 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-139190</guid>
		<description>[...] c    Objective c Effect of objectiv c in Android apps, iPhone apps, Java apps,   [...]</description>
		<content:encoded><![CDATA[<p>[...] c    Objective c Effect of objectiv c in Android apps, iPhone apps, Java apps,   [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: iPhone App Creator</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-137932</link>
		<dc:creator>iPhone App Creator</dc:creator>
		<pubDate>Fri, 04 Nov 2011 01:52:34 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-137932</guid>
		<description>Thank you for the auspicious writeup. It if truth be told used to be a leisure account it. Glance complex to more brought agreeable from you! By the way, how can we keep up a correspondence?</description>
		<content:encoded><![CDATA[<p>Thank you for the auspicious writeup. It if truth be told used to be a leisure account it. Glance complex to more brought agreeable from you! By the way, how can we keep up a correspondence?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-90394</link>
		<dc:creator>Erik</dc:creator>
		<pubDate>Wed, 16 Sep 2009 20:04:00 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-90394</guid>
		<description>I hope it doesn&#039;t sound offensive but you really need to learn more about the issue, before being so sure of yourself. 

You seem to think one can just make a VM willy nilly and through out all the old stuff. .NET was a huge undertaking by Microsoft. It is not something anybody can do just like that. Microsoft pretty much had to because the development platform they had had severe restrictions. Coding C++ with MFC was horrible. Win32 was a mess after feature after feature had been added with little thought to how it all fit together. Visual Basic was easy to use, but had some serious restrictions. COM was notoriously difficult to get your head around and most could only do it by using tons of cryptic macros. 

At this same time Objective-C and Cocoa existed which was far better thought out and was to many people a dream to work with. Sure it is getting a bit long in the tooth now, but it was just good enough for app development to not need major changes.

You can say what you want about .NET and C#, but the fact is that almost non of Microsofts apps are written in it. While most of Apples are. Cocoa is a large framework which has been refined over many years and which pretty much all Mac apps depend on. Apple can&#039;t just throw it out and replace it with a VM. That would require enormous amounts of work.

A lot of Apples apps has not been created just in the last years you know. Many are improvements of quite old NEXTSTEP apps. I have seen screenshots of Pages  (part of iWork) from the early 90s on NEXTSTEP (from which OS X is derived). 

Now with Snow Leopard Apple has started using LLVM and different people are making compiler for different languages targeting LLVM. It might not be inconceivable that Apple will eventually use that as a basis for letting modules written in different languages interoperate. Regardless it will be quite different from the CLR and the Java VM since it is much more low level.

Finally remember way before Java existed you could compile your program once and run it on any platform supporting OpenStep (Cocoa&#039;s predecessor). They did that with Bundles. An app would be contained within a directory (like today) with one directory for all program resources, like images, sound, GUI, language files etc and a separate directory for each executables for each platform. When you launched an OpenStep application on Windows the system would locate the x86 executable, if you launched it on a Sun workstation it would locate the Sparc executable. 

It worked great, so I don&#039;t see why you need a VM. Java hasn&#039;t been able to provide cross platform apps as painless as OpenStep did back then. 

Apple could do it again, but it has no commercial value to them. They want to keep Objective-C and Cocoa to the Mac platform to give Mac and edge.</description>
		<content:encoded><![CDATA[<p>I hope it doesn&#8217;t sound offensive but you really need to learn more about the issue, before being so sure of yourself. </p>
<p>You seem to think one can just make a VM willy nilly and through out all the old stuff. .NET was a huge undertaking by Microsoft. It is not something anybody can do just like that. Microsoft pretty much had to because the development platform they had had severe restrictions. Coding C++ with MFC was horrible. Win32 was a mess after feature after feature had been added with little thought to how it all fit together. Visual Basic was easy to use, but had some serious restrictions. COM was notoriously difficult to get your head around and most could only do it by using tons of cryptic macros. </p>
<p>At this same time Objective-C and Cocoa existed which was far better thought out and was to many people a dream to work with. Sure it is getting a bit long in the tooth now, but it was just good enough for app development to not need major changes.</p>
<p>You can say what you want about .NET and C#, but the fact is that almost non of Microsofts apps are written in it. While most of Apples are. Cocoa is a large framework which has been refined over many years and which pretty much all Mac apps depend on. Apple can&#8217;t just throw it out and replace it with a VM. That would require enormous amounts of work.</p>
<p>A lot of Apples apps has not been created just in the last years you know. Many are improvements of quite old NEXTSTEP apps. I have seen screenshots of Pages  (part of iWork) from the early 90s on NEXTSTEP (from which OS X is derived). </p>
<p>Now with Snow Leopard Apple has started using LLVM and different people are making compiler for different languages targeting LLVM. It might not be inconceivable that Apple will eventually use that as a basis for letting modules written in different languages interoperate. Regardless it will be quite different from the CLR and the Java VM since it is much more low level.</p>
<p>Finally remember way before Java existed you could compile your program once and run it on any platform supporting OpenStep (Cocoa&#8217;s predecessor). They did that with Bundles. An app would be contained within a directory (like today) with one directory for all program resources, like images, sound, GUI, language files etc and a separate directory for each executables for each platform. When you launched an OpenStep application on Windows the system would locate the x86 executable, if you launched it on a Sun workstation it would locate the Sparc executable. </p>
<p>It worked great, so I don&#8217;t see why you need a VM. Java hasn&#8217;t been able to provide cross platform apps as painless as OpenStep did back then. </p>
<p>Apple could do it again, but it has no commercial value to them. They want to keep Objective-C and Cocoa to the Mac platform to give Mac and edge.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-74341</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Thu, 02 Apr 2009 12:08:21 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-74341</guid>
		<description>That&#039;s an interesting exchange you guys have back and forth. I know its somewhat aged at this point but I&#039;d like to add to it.

&quot;C++ is fast as long as you write it correctly and are really good at memory management.&quot;

This is very much a misnomer and is not reflective of modern C++ coding. Smart pointers very much remove the old emphasis of memory management as a first order focus. To be fair, C++ is far more complex than is Java.

I&#039;d also like to chime in on the Java/C++ performance comparison. I&#039;ve never seen an apples to apples comparison of Java/C++ code where Java performed any significant work and was even close in performance to that of C++. Without fail, every time I&#039;ve seen a Java benchmark where Java was close or claimed faster than C++, it was a farce. 

For example, a couple of years ago someone was claiming various benchmarks proving Java was on par with C++ performance. One specific benchmark was something like 2x faster than the C++ counterpart. I took the C++ code and in less than 20 minutes had the C++ code running almost 200x faster than the Java code - which did make it an apples to apples comparison.  How? The bottleneck in the benchmark was memory management - and was specifically tailored to emphasize construction/destruction while attempting to hide that fact within a more complex set of algorithms. As the Java VM never collected, it never experienced any memory management overhead; which is almost always done to make Java look far, far faster than it is in real workloads.

Simply put, Java, like many other modern languages is often &quot;fast enough&quot; but anyone who claims Java is anything but slow, slow, slow compared to C++ for real work is either misinformed or delusional. To be fair, Java&#039;s VM is quite impressive and yes there are many corner cases where performance is best described as &quot;fast&quot;. Just the same, few applications can survive alone on corner cases.

I will also add, I am an Android developer. I&#039;m living the life of Java/Dalvik now. Slow is a fair statement; relatively that is. Having said that, the Dalvik-VM is very impressive and clever - especially in its memory management and anti-fragmentation strategies. And to boot, much of it is far from optimized and completely lacks any sort of JIT. Which is to say, both the VM is unoptimized and the optimizations possible by the VM are lacking. So while the generally available implementation (G1/1.x SDK) may not shine as everyone would like, the cupcake release will provide a much truer picture as to Dalvik&#039;s performance capabilities. Hopefully April will be the month to re-evaluate Android/G1.

Also, as for native code on Android - absolutely you can run native code. It is unofficially supported but doable. The disadvantage of using native code is, well, your code will not run on all targets. Which is in fact the same disadvantage Apple has with their native code/iPhone approach. 

Surprisingly, Google has a full JNI implementation in place. Even more surprising, Google has some very low overhead back door interfaces which makes C/C++ calls from Java/Dalvik about as low overhead as possible. Again, that&#039;s not officially supported either despite the fact they use both of these interfaces. IMHO, the biggest failing for Google with Android is they completely removed exceptions from their C++ runtime. Again, IMHO, C++ without exceptions is a much more complex, error prone, and dangerous language effectively removing one of its strongest advantages C++ has over C, but I digress

I will say if projections are correct, the iPhone is in serious trouble. By 2012, even with a recession, Android is projected to easily exceed the number of iPhones. By the end of this year, some projections estimate as many as 25 different Android phones will be available world-wide; and that&#039;s not including NetBooks. I personally believe 6-12 is more likely but I&#039;ll be happy to be wrong. And while people love to ding the G1, its hardware capabilities already surpasses that of the iPhone 3G. And while people love to ding the performance of the G1, keep in mind the G1 is running an unoptimized VM, having no JIT, on a significantly underclocked CPU and is still comparable with the iPhone is features; albeit somewhat subpar for performance/latency. If you stop and ponder what that means, by 2010 Apple will have some serious trouble staying ahead of Android&#039;s momentum. Just imagine how Android will perform on a properly clocked CPU and a fully optimized VM with limited JIT capabilities. 

And speaking about Android&#039;s momentum, the G1 has already matched the iPhone&#039;s sales count milestone, for the same period of time. Even worse for the iPhone, the iPhone sold during a booming economy while the G1 made that same milestone in a recession; ouch for Apple.

Long story short, IMO, the writing on the wall is pretty clear. By 2010 there will be a new sheriff in town; called Android. And his performance potential truly seems bright. Needless to say, 2010 and 2011 will be very interesting years for Android indeed.</description>
		<content:encoded><![CDATA[<p>That&#8217;s an interesting exchange you guys have back and forth. I know its somewhat aged at this point but I&#8217;d like to add to it.</p>
<p>&#8220;C++ is fast as long as you write it correctly and are really good at memory management.&#8221;</p>
<p>This is very much a misnomer and is not reflective of modern C++ coding. Smart pointers very much remove the old emphasis of memory management as a first order focus. To be fair, C++ is far more complex than is Java.</p>
<p>I&#8217;d also like to chime in on the Java/C++ performance comparison. I&#8217;ve never seen an apples to apples comparison of Java/C++ code where Java performed any significant work and was even close in performance to that of C++. Without fail, every time I&#8217;ve seen a Java benchmark where Java was close or claimed faster than C++, it was a farce. </p>
<p>For example, a couple of years ago someone was claiming various benchmarks proving Java was on par with C++ performance. One specific benchmark was something like 2x faster than the C++ counterpart. I took the C++ code and in less than 20 minutes had the C++ code running almost 200x faster than the Java code &#8211; which did make it an apples to apples comparison.  How? The bottleneck in the benchmark was memory management &#8211; and was specifically tailored to emphasize construction/destruction while attempting to hide that fact within a more complex set of algorithms. As the Java VM never collected, it never experienced any memory management overhead; which is almost always done to make Java look far, far faster than it is in real workloads.</p>
<p>Simply put, Java, like many other modern languages is often &#8220;fast enough&#8221; but anyone who claims Java is anything but slow, slow, slow compared to C++ for real work is either misinformed or delusional. To be fair, Java&#8217;s VM is quite impressive and yes there are many corner cases where performance is best described as &#8220;fast&#8221;. Just the same, few applications can survive alone on corner cases.</p>
<p>I will also add, I am an Android developer. I&#8217;m living the life of Java/Dalvik now. Slow is a fair statement; relatively that is. Having said that, the Dalvik-VM is very impressive and clever &#8211; especially in its memory management and anti-fragmentation strategies. And to boot, much of it is far from optimized and completely lacks any sort of JIT. Which is to say, both the VM is unoptimized and the optimizations possible by the VM are lacking. So while the generally available implementation (G1/1.x SDK) may not shine as everyone would like, the cupcake release will provide a much truer picture as to Dalvik&#8217;s performance capabilities. Hopefully April will be the month to re-evaluate Android/G1.</p>
<p>Also, as for native code on Android &#8211; absolutely you can run native code. It is unofficially supported but doable. The disadvantage of using native code is, well, your code will not run on all targets. Which is in fact the same disadvantage Apple has with their native code/iPhone approach. </p>
<p>Surprisingly, Google has a full JNI implementation in place. Even more surprising, Google has some very low overhead back door interfaces which makes C/C++ calls from Java/Dalvik about as low overhead as possible. Again, that&#8217;s not officially supported either despite the fact they use both of these interfaces. IMHO, the biggest failing for Google with Android is they completely removed exceptions from their C++ runtime. Again, IMHO, C++ without exceptions is a much more complex, error prone, and dangerous language effectively removing one of its strongest advantages C++ has over C, but I digress</p>
<p>I will say if projections are correct, the iPhone is in serious trouble. By 2012, even with a recession, Android is projected to easily exceed the number of iPhones. By the end of this year, some projections estimate as many as 25 different Android phones will be available world-wide; and that&#8217;s not including NetBooks. I personally believe 6-12 is more likely but I&#8217;ll be happy to be wrong. And while people love to ding the G1, its hardware capabilities already surpasses that of the iPhone 3G. And while people love to ding the performance of the G1, keep in mind the G1 is running an unoptimized VM, having no JIT, on a significantly underclocked CPU and is still comparable with the iPhone is features; albeit somewhat subpar for performance/latency. If you stop and ponder what that means, by 2010 Apple will have some serious trouble staying ahead of Android&#8217;s momentum. Just imagine how Android will perform on a properly clocked CPU and a fully optimized VM with limited JIT capabilities. </p>
<p>And speaking about Android&#8217;s momentum, the G1 has already matched the iPhone&#8217;s sales count milestone, for the same period of time. Even worse for the iPhone, the iPhone sold during a booming economy while the G1 made that same milestone in a recession; ouch for Apple.</p>
<p>Long story short, IMO, the writing on the wall is pretty clear. By 2010 there will be a new sheriff in town; called Android. And his performance potential truly seems bright. Needless to say, 2010 and 2011 will be very interesting years for Android indeed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Todd</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-50072</link>
		<dc:creator>Todd</dc:creator>
		<pubDate>Wed, 07 Jan 2009 17:00:19 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-50072</guid>
		<description>Maybe Oilcan will simplify things!

http://oilcan.jsharkey.org</description>
		<content:encoded><![CDATA[<p>Maybe Oilcan will simplify things!</p>
<p><a href="http://oilcan.jsharkey.org" rel="nofollow">http://oilcan.jsharkey.org</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Pontarelli</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-48028</link>
		<dc:creator>Brian Pontarelli</dc:creator>
		<pubDate>Sat, 20 Dec 2008 16:49:59 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-48028</guid>
		<description>Elliott,

You posts are becoming quite aggressive. I think we should call a truce on the personal attacks and just focus on facts. I&#039;ve approved this one, but let&#039;s keep it civil.

&lt;blockquote&gt;
Objective-C is absolutely native code. It’s straight C with some compiler magic. LLVM wasn’t even around when Objective-C was invented (10 years prior), and most ObjC code isn’t even compiled with LLVM today. 
&lt;/blockquote&gt;

OpenGL is LLVM and Apple is planning to replace most of the gcc with it. You are right that it is mostly native now, but Apple agrees with me and many other people that you need some abstraction if you want polyglot programming. 

&lt;blockquote&gt;
Do you actually know *anything* about ObjC? For that matter do you know *anything* about how a VM works or native code compilers?
&lt;/blockquote&gt;

Yes. Please try to keep it civil here.

&lt;blockquote&gt;
And if you want to ignore API calls (seriously? I mean really?) Then how about hello world:

#include

int main() {
printf(”Hello World”);
return 0;
}

In java that requires the same number of lines of code, and a lot more wordage. That’s about as valid as your example with method calls. Both benchmarks are stupid. Lines of code comparisons are flat out ridiculous unless you look at the API and the flexibility of the language.
&lt;/blockquote&gt;

Okay, this is really important to me and you are to be tossing it out completely, which I can&#039;t do at all.

I maintain a large codebase in Java and C++ and soon will be adding Python, C# and Ruby so I know how the differences work. The code is optimized for both languages and I also have benchmarks for both. The code is a very high performance content processor that uses some very complex data-structures and performance requirements are absolutely necessary (I&#039;ll get to speed in a second). The Java source files are about 50% less code than the C++ source files. That&#039;s a lot of code overhead that is completely unnecessary at this point. As software engineers we should be making the languages smarter and more terse.

First, when I do complexity and overhead comparisons I always ignore library calls because in most languages you can always find libraries to make life easy. You can&#039;t compare things if you get hung up on APIs.

Second, I always compare language features and flexibility including dynamic features.

Third, your example isn&#039;t using classes. If you really want to compare, I&#039;d ask you to write the following: &quot;A library with a single class that adds two numbers and returns the result. This library must be polymorphic and dynamically linked at runtime (no static libs).&quot; If you compare these in Objective-C and Java, Objective-C has more overhead.

&lt;blockquote&gt;
And last, Java *is* slow. It’s painfully slow compared to native code. Period. Have you ever actually tried to implement a complex algorithm in both languages and bench mark it? In fact the JVM itself is written in C++, and delegates into native code for all kinds of things for just that reason. Java is wicked fast compared to ruby, python, and a lot of other things, yes. However, compared to C it’s horridly slow. gdlib will smoke the pure Java JAI in performance any day of the week. A properly written data structure in C/C++ will blast past the same code in Java in performance. Look at the benchmark of Java vs C on the same site, or better yet try it!
&lt;/blockquote&gt;

My library is faster in Java and it is a valid benchmark and it is a complex and highly used API. This isn&#039;t always the case with Java versus C++, but on a million parsers of 1K, Java is faster by about 5-10% faster even with GC.

&lt;blockquote&gt;
Java is fast in micro benchmarks relating to a few things that the JVM is really optimized for. Any large scale application will not show such performance. HotSpot is wonderful, and Java (and .NET) are both about the fastest VMs that exist, but that doesn’t change the fact that they *are* slow compared to native code generated by gcc for C or C++. There is no argument about this. Sun knows this, that’s why they use native code for certain operations. Oh that’s right, HotSpot itself is written in C++!
&lt;/blockquote&gt;

I&#039;m not saying that Java is faster than C++ and I wouldn&#039;t write a VM in Java. C++ is fast as long as you write it correctly and are really good at memory management. For most applications C++ isn&#039;t necessary and this includes games. You can easily write games in something like D.

&lt;blockquote&gt;
And for the record, all Java function calls go through at least one pointer dereference, type and signature checking, security manager checks, and most Java code is actually interpreted and the JIT only kicks in after a large number of calls. Compare that to the bare metal call of a non-virtual method call in C++ and there’s no argument who’s slow. So claiming Objective-C is slow based on some lookup (which you don’t actually understand), is silly. Compared to C++ both languages are stupid slow in function call performance. There’s also IMP calls which skip the potential objc_msgSend() if you really cared that much.
&lt;/blockquote&gt;

I do understand dynamic lookups as do you. You can&#039;t have a dynamic language without method lookups and dynamic invocation. You just can&#039;t. You can optimize them in some cases, but you still need to figure out which method to invoke because you can add new methods to just about anything (classes or instances) at runtime.

&lt;blockquote&gt;
Why would I want to use a language like ObjC and not ruby? Maybe because ruby is disastrously slow compared to native code. How fast do you think Halo 3 would be if it was written in ruby? hah. Then again I have thousands of lines of ruby code I’ve written and use every day, and plenty of projects on it. If I had to pick a favorite language it would be ruby, so it’s funny you mention that!
&lt;/blockquote&gt;

If you are writing a game, why would you use ObjC? You&#039;d probably use C++ but if you wanted to reduce overhead you would use something like D or managed C++ or something with less code overhead.

&lt;blockquote&gt;
Fast enough has a huge amount to do with your application. I do think it’s funny you have another blog post mentiong how slow Java IDEs (Eclipse?) are, but there’s tons of ObjC applications that aren’t slow, essentially every GUI application on OS X (spare iTunes and Finder) is these days. Slow though eh? I don’t see masses of people running from OS X to Windows because it’s so slow. And I certainly don’t see MS rewriting Explorer (or IE) in C# or managed C++. I also don’t see Oracle rewriting their database engine in Java or for a VM.
&lt;/blockquote&gt;

Any IDE that does as much work as Java IDEs do will incur some performance overhead. Visual Studio doesn&#039;t do half of what Eclipse and IntelliJ do and it is pretty slow. That has nothing to do with Java. Look at the speed of ThinkFree. It is faster than MS Office, iWork, and OpenOffice and it is written in Java. Java desktop applications aren&#039;t slow. There are many that are very fast. I&#039;ve also seen horribly slow C++ apps. This is usually because of bad programming, not language or VM versus native.

&lt;blockquote&gt;
Speed has absolutely everything to do with what you’re doing, how it’ll be used, and the bottom line of shipping something that works. That last one is where you’re harping, and yes, it’s the most important.
&lt;/blockquote&gt;

For some cases you are right. For other cases you are wrong. Sometimes cleaner, simpler, and less code are better if you only lose 5-10% speed.

&lt;blockquote&gt;
The fact that you can run native code on the iphone is a huge deal. You can potentially run ruby, python, gecko, and many games with different graphic front ends. Java if you really wanted to, and even groovy. Apple’s licensing is stupid, but that’s another matter. Android on the other hand is very locked into the VM, and you’re totally excluded from all code written in languages and libraries that aren’t supported on the VM, or are written in C/C++ code. Running Firefox on the iphone is *possible*, Apple just has stupid licensing. Running Firefox on Android is actually impossible. In fact:
&lt;/blockquote&gt;

Android runs Chrome and Chrome is 100 of times faster than FireFox, and you can find the benchmarks all over the web. So, I don&#039;t need FireFox, which is slow and bloated at this point, on the gPhone.

As for the iPhone and other languages, unless Apple opens up the APIs and writes hooks for each language you won&#039;t be able to use them on the iPhone. Right now you can only use ObjC as far as I know and I doubt anything else will be added soon. I can see more languages coming to Android though. As for getting native languages onto the VM, well I&#039;ll never need C++ or ObjC on Android, so I&#039;m fine without those. Everything else can be easily run on a VM. But only time will tell.

Just to sum it all up again. My whole point was that I prefer VMs and I find languages with header files and older syntax and features too much overhead to be useful.</description>
		<content:encoded><![CDATA[<p>Elliott,</p>
<p>You posts are becoming quite aggressive. I think we should call a truce on the personal attacks and just focus on facts. I&#8217;ve approved this one, but let&#8217;s keep it civil.</p>
<blockquote><p>
Objective-C is absolutely native code. It’s straight C with some compiler magic. LLVM wasn’t even around when Objective-C was invented (10 years prior), and most ObjC code isn’t even compiled with LLVM today.
</p></blockquote>
<p>OpenGL is LLVM and Apple is planning to replace most of the gcc with it. You are right that it is mostly native now, but Apple agrees with me and many other people that you need some abstraction if you want polyglot programming. </p>
<blockquote><p>
Do you actually know *anything* about ObjC? For that matter do you know *anything* about how a VM works or native code compilers?
</p></blockquote>
<p>Yes. Please try to keep it civil here.</p>
<blockquote><p>
And if you want to ignore API calls (seriously? I mean really?) Then how about hello world:</p>
<p>#include</p>
<p>int main() {<br />
printf(”Hello World”);<br />
return 0;<br />
}</p>
<p>In java that requires the same number of lines of code, and a lot more wordage. That’s about as valid as your example with method calls. Both benchmarks are stupid. Lines of code comparisons are flat out ridiculous unless you look at the API and the flexibility of the language.
</p></blockquote>
<p>Okay, this is really important to me and you are to be tossing it out completely, which I can&#8217;t do at all.</p>
<p>I maintain a large codebase in Java and C++ and soon will be adding Python, C# and Ruby so I know how the differences work. The code is optimized for both languages and I also have benchmarks for both. The code is a very high performance content processor that uses some very complex data-structures and performance requirements are absolutely necessary (I&#8217;ll get to speed in a second). The Java source files are about 50% less code than the C++ source files. That&#8217;s a lot of code overhead that is completely unnecessary at this point. As software engineers we should be making the languages smarter and more terse.</p>
<p>First, when I do complexity and overhead comparisons I always ignore library calls because in most languages you can always find libraries to make life easy. You can&#8217;t compare things if you get hung up on APIs.</p>
<p>Second, I always compare language features and flexibility including dynamic features.</p>
<p>Third, your example isn&#8217;t using classes. If you really want to compare, I&#8217;d ask you to write the following: &#8220;A library with a single class that adds two numbers and returns the result. This library must be polymorphic and dynamically linked at runtime (no static libs).&#8221; If you compare these in Objective-C and Java, Objective-C has more overhead.</p>
<blockquote><p>
And last, Java *is* slow. It’s painfully slow compared to native code. Period. Have you ever actually tried to implement a complex algorithm in both languages and bench mark it? In fact the JVM itself is written in C++, and delegates into native code for all kinds of things for just that reason. Java is wicked fast compared to ruby, python, and a lot of other things, yes. However, compared to C it’s horridly slow. gdlib will smoke the pure Java JAI in performance any day of the week. A properly written data structure in C/C++ will blast past the same code in Java in performance. Look at the benchmark of Java vs C on the same site, or better yet try it!
</p></blockquote>
<p>My library is faster in Java and it is a valid benchmark and it is a complex and highly used API. This isn&#8217;t always the case with Java versus C++, but on a million parsers of 1K, Java is faster by about 5-10% faster even with GC.</p>
<blockquote><p>
Java is fast in micro benchmarks relating to a few things that the JVM is really optimized for. Any large scale application will not show such performance. HotSpot is wonderful, and Java (and .NET) are both about the fastest VMs that exist, but that doesn’t change the fact that they *are* slow compared to native code generated by gcc for C or C++. There is no argument about this. Sun knows this, that’s why they use native code for certain operations. Oh that’s right, HotSpot itself is written in C++!
</p></blockquote>
<p>I&#8217;m not saying that Java is faster than C++ and I wouldn&#8217;t write a VM in Java. C++ is fast as long as you write it correctly and are really good at memory management. For most applications C++ isn&#8217;t necessary and this includes games. You can easily write games in something like D.</p>
<blockquote><p>
And for the record, all Java function calls go through at least one pointer dereference, type and signature checking, security manager checks, and most Java code is actually interpreted and the JIT only kicks in after a large number of calls. Compare that to the bare metal call of a non-virtual method call in C++ and there’s no argument who’s slow. So claiming Objective-C is slow based on some lookup (which you don’t actually understand), is silly. Compared to C++ both languages are stupid slow in function call performance. There’s also IMP calls which skip the potential objc_msgSend() if you really cared that much.
</p></blockquote>
<p>I do understand dynamic lookups as do you. You can&#8217;t have a dynamic language without method lookups and dynamic invocation. You just can&#8217;t. You can optimize them in some cases, but you still need to figure out which method to invoke because you can add new methods to just about anything (classes or instances) at runtime.</p>
<blockquote><p>
Why would I want to use a language like ObjC and not ruby? Maybe because ruby is disastrously slow compared to native code. How fast do you think Halo 3 would be if it was written in ruby? hah. Then again I have thousands of lines of ruby code I’ve written and use every day, and plenty of projects on it. If I had to pick a favorite language it would be ruby, so it’s funny you mention that!
</p></blockquote>
<p>If you are writing a game, why would you use ObjC? You&#8217;d probably use C++ but if you wanted to reduce overhead you would use something like D or managed C++ or something with less code overhead.</p>
<blockquote><p>
Fast enough has a huge amount to do with your application. I do think it’s funny you have another blog post mentiong how slow Java IDEs (Eclipse?) are, but there’s tons of ObjC applications that aren’t slow, essentially every GUI application on OS X (spare iTunes and Finder) is these days. Slow though eh? I don’t see masses of people running from OS X to Windows because it’s so slow. And I certainly don’t see MS rewriting Explorer (or IE) in C# or managed C++. I also don’t see Oracle rewriting their database engine in Java or for a VM.
</p></blockquote>
<p>Any IDE that does as much work as Java IDEs do will incur some performance overhead. Visual Studio doesn&#8217;t do half of what Eclipse and IntelliJ do and it is pretty slow. That has nothing to do with Java. Look at the speed of ThinkFree. It is faster than MS Office, iWork, and OpenOffice and it is written in Java. Java desktop applications aren&#8217;t slow. There are many that are very fast. I&#8217;ve also seen horribly slow C++ apps. This is usually because of bad programming, not language or VM versus native.</p>
<blockquote><p>
Speed has absolutely everything to do with what you’re doing, how it’ll be used, and the bottom line of shipping something that works. That last one is where you’re harping, and yes, it’s the most important.
</p></blockquote>
<p>For some cases you are right. For other cases you are wrong. Sometimes cleaner, simpler, and less code are better if you only lose 5-10% speed.</p>
<blockquote><p>
The fact that you can run native code on the iphone is a huge deal. You can potentially run ruby, python, gecko, and many games with different graphic front ends. Java if you really wanted to, and even groovy. Apple’s licensing is stupid, but that’s another matter. Android on the other hand is very locked into the VM, and you’re totally excluded from all code written in languages and libraries that aren’t supported on the VM, or are written in C/C++ code. Running Firefox on the iphone is *possible*, Apple just has stupid licensing. Running Firefox on Android is actually impossible. In fact:
</p></blockquote>
<p>Android runs Chrome and Chrome is 100 of times faster than FireFox, and you can find the benchmarks all over the web. So, I don&#8217;t need FireFox, which is slow and bloated at this point, on the gPhone.</p>
<p>As for the iPhone and other languages, unless Apple opens up the APIs and writes hooks for each language you won&#8217;t be able to use them on the iPhone. Right now you can only use ObjC as far as I know and I doubt anything else will be added soon. I can see more languages coming to Android though. As for getting native languages onto the VM, well I&#8217;ll never need C++ or ObjC on Android, so I&#8217;m fine without those. Everything else can be easily run on a VM. But only time will tell.</p>
<p>Just to sum it all up again. My whole point was that I prefer VMs and I find languages with header files and older syntax and features too much overhead to be useful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliott Sprehn</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-47919</link>
		<dc:creator>Elliott Sprehn</dc:creator>
		<pubDate>Sat, 20 Dec 2008 09:55:12 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-47919</guid>
		<description>What on earth are you talking about? 

Objective-C is absolutely native code. It&#039;s straight C with some compiler magic. LLVM wasn&#039;t even around when Objective-C was invented (10 years prior), and most ObjC code isn&#039;t even compiled with LLVM today. Have you ever even looked at the assembly generated by gcc from ObjC code? The fact that you debug ObjC with gdb and get assembly dumps should tip you off at the very least. ;) That or the fact that it&#039;s ABI is identical to C&#039;s. Or maybe it&#039;s Objective-C++ that lets you use both. Or are you arguing that C++ is also not native?

Do you actually know *anything* about ObjC? For that matter do you know *anything* about how a VM works or native code compilers?

And if you want to ignore API calls (seriously? I mean really?) Then how about hello world:

#include 

int main() {
   printf(&quot;Hello World&quot;);
   return 0;
}

In java that requires the same number of lines of code, and a lot more wordage. That&#039;s about as valid as your example with method calls. Both benchmarks are stupid. Lines of code comparisons are flat out ridiculous unless you look at the API and the flexibility of the language.

And last, Java *is* slow. It&#039;s painfully slow compared to native code. Period. Have you ever actually tried to implement a complex algorithm in both languages and bench mark it? In fact the JVM itself is written in C++, and delegates into native code for all kinds of things for just that reason. Java is wicked fast compared to ruby, python, and a lot of other things, yes. However, compared to C it&#039;s horridly slow. gdlib will smoke the pure Java JAI in performance any day of the week. A properly written data structure in C/C++ will blast past the same code in Java in performance. Look at the benchmark of Java vs C on the same site, or better yet try it!

Java is fast in micro benchmarks relating to a few things that the JVM is really optimized for. Any large scale application will not show such performance. HotSpot is wonderful, and Java (and .NET) are both about the fastest VMs that exist, but that doesn&#039;t change the fact that they *are* slow compared to native code generated by gcc for C or C++. There is no argument about this. Sun knows this, that&#039;s why they use native code for certain operations. Oh that&#039;s right, HotSpot itself is written in C++!

And for the record, all Java function calls go through at least one pointer dereference, type and signature checking, security manager checks, and most Java code is actually interpreted and the JIT only kicks in after a large number of calls. Compare that to the bare metal call of a non-virtual method call in C++ and there&#039;s no argument who&#039;s slow. So claiming Objective-C is slow based on some lookup (which you don&#039;t actually understand), is silly. Compared to C++ both languages are stupid slow in function call performance. There&#039;s also IMP calls which skip the potential objc_msgSend() if you really cared that much.

Why would I want to use a language like ObjC and not ruby? Maybe because ruby is disastrously slow compared to native code. How fast do you think Halo 3 would be if it was written in ruby? hah. Then again I have thousands of lines of ruby code I&#039;ve written and use every day, and plenty of projects on it. If I had to pick a favorite language it would be ruby, so it&#039;s funny you mention that!

Fast enough has a huge amount to do with your application. I do think it&#039;s funny you have another blog post mentiong how slow Java IDEs (Eclipse?) are, but there&#039;s tons of ObjC applications that aren&#039;t slow, essentially every GUI application on OS X (spare iTunes and Finder) is these days. Slow though eh? I don&#039;t see masses of people running from OS X to Windows because it&#039;s so slow. And I certainly don&#039;t see MS rewriting Explorer (or IE) in C# or managed C++. I also don&#039;t see Oracle rewriting their database engine in Java or for a VM.

Speed has absolutely everything to do with what you&#039;re doing, how it&#039;ll be used, and the bottom line of shipping something that works. That last one is where you&#039;re harping, and yes, it&#039;s the most important.

And as for porting games? How about Neverball? Super Monkey ball? How about Quake? http://toucharcade.com/2008/11/25/another-iphone-quake-port-strives-for-app-store-acceptance/

The fact that you can run native code on the iphone is a huge deal. You can potentially run ruby, python, gecko, and many games with different graphic front ends. Java if you really wanted to, and even groovy. Apple&#039;s licensing is stupid, but that&#039;s another matter. Android on the other hand is very locked into the VM, and you&#039;re totally excluded from all code written in languages and libraries that aren&#039;t supported on the VM, or are written in C/C++ code. Running Firefox on the iphone is *possible*, Apple just has stupid licensing. Running Firefox on Android is actually impossible. In fact:

http://gizmodo.com/5081969/firefox-mobile-wont-be-foxing-up-android-anytime-soon

Ooooh snap! ;)</description>
		<content:encoded><![CDATA[<p>What on earth are you talking about? </p>
<p>Objective-C is absolutely native code. It&#8217;s straight C with some compiler magic. LLVM wasn&#8217;t even around when Objective-C was invented (10 years prior), and most ObjC code isn&#8217;t even compiled with LLVM today. Have you ever even looked at the assembly generated by gcc from ObjC code? The fact that you debug ObjC with gdb and get assembly dumps should tip you off at the very least. ;) That or the fact that it&#8217;s ABI is identical to C&#8217;s. Or maybe it&#8217;s Objective-C++ that lets you use both. Or are you arguing that C++ is also not native?</p>
<p>Do you actually know *anything* about ObjC? For that matter do you know *anything* about how a VM works or native code compilers?</p>
<p>And if you want to ignore API calls (seriously? I mean really?) Then how about hello world:</p>
<p>#include </p>
<p>int main() {<br />
   printf(&#8220;Hello World&#8221;);<br />
   return 0;<br />
}</p>
<p>In java that requires the same number of lines of code, and a lot more wordage. That&#8217;s about as valid as your example with method calls. Both benchmarks are stupid. Lines of code comparisons are flat out ridiculous unless you look at the API and the flexibility of the language.</p>
<p>And last, Java *is* slow. It&#8217;s painfully slow compared to native code. Period. Have you ever actually tried to implement a complex algorithm in both languages and bench mark it? In fact the JVM itself is written in C++, and delegates into native code for all kinds of things for just that reason. Java is wicked fast compared to ruby, python, and a lot of other things, yes. However, compared to C it&#8217;s horridly slow. gdlib will smoke the pure Java JAI in performance any day of the week. A properly written data structure in C/C++ will blast past the same code in Java in performance. Look at the benchmark of Java vs C on the same site, or better yet try it!</p>
<p>Java is fast in micro benchmarks relating to a few things that the JVM is really optimized for. Any large scale application will not show such performance. HotSpot is wonderful, and Java (and .NET) are both about the fastest VMs that exist, but that doesn&#8217;t change the fact that they *are* slow compared to native code generated by gcc for C or C++. There is no argument about this. Sun knows this, that&#8217;s why they use native code for certain operations. Oh that&#8217;s right, HotSpot itself is written in C++!</p>
<p>And for the record, all Java function calls go through at least one pointer dereference, type and signature checking, security manager checks, and most Java code is actually interpreted and the JIT only kicks in after a large number of calls. Compare that to the bare metal call of a non-virtual method call in C++ and there&#8217;s no argument who&#8217;s slow. So claiming Objective-C is slow based on some lookup (which you don&#8217;t actually understand), is silly. Compared to C++ both languages are stupid slow in function call performance. There&#8217;s also IMP calls which skip the potential objc_msgSend() if you really cared that much.</p>
<p>Why would I want to use a language like ObjC and not ruby? Maybe because ruby is disastrously slow compared to native code. How fast do you think Halo 3 would be if it was written in ruby? hah. Then again I have thousands of lines of ruby code I&#8217;ve written and use every day, and plenty of projects on it. If I had to pick a favorite language it would be ruby, so it&#8217;s funny you mention that!</p>
<p>Fast enough has a huge amount to do with your application. I do think it&#8217;s funny you have another blog post mentiong how slow Java IDEs (Eclipse?) are, but there&#8217;s tons of ObjC applications that aren&#8217;t slow, essentially every GUI application on OS X (spare iTunes and Finder) is these days. Slow though eh? I don&#8217;t see masses of people running from OS X to Windows because it&#8217;s so slow. And I certainly don&#8217;t see MS rewriting Explorer (or IE) in C# or managed C++. I also don&#8217;t see Oracle rewriting their database engine in Java or for a VM.</p>
<p>Speed has absolutely everything to do with what you&#8217;re doing, how it&#8217;ll be used, and the bottom line of shipping something that works. That last one is where you&#8217;re harping, and yes, it&#8217;s the most important.</p>
<p>And as for porting games? How about Neverball? Super Monkey ball? How about Quake? <a href="http://toucharcade.com/2008/11/25/another-iphone-quake-port-strives-for-app-store-acceptance/" rel="nofollow">http://toucharcade.com/2008/11/25/another-iphone-quake-port-strives-for-app-store-acceptance/</a></p>
<p>The fact that you can run native code on the iphone is a huge deal. You can potentially run ruby, python, gecko, and many games with different graphic front ends. Java if you really wanted to, and even groovy. Apple&#8217;s licensing is stupid, but that&#8217;s another matter. Android on the other hand is very locked into the VM, and you&#8217;re totally excluded from all code written in languages and libraries that aren&#8217;t supported on the VM, or are written in C/C++ code. Running Firefox on the iphone is *possible*, Apple just has stupid licensing. Running Firefox on Android is actually impossible. In fact:</p>
<p><a href="http://gizmodo.com/5081969/firefox-mobile-wont-be-foxing-up-android-anytime-soon" rel="nofollow">http://gizmodo.com/5081969/firefox-mobile-wont-be-foxing-up-android-anytime-soon</a></p>
<p>Ooooh snap! ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Pontarelli</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-47657</link>
		<dc:creator>Brian Pontarelli</dc:creator>
		<pubDate>Fri, 19 Dec 2008 16:15:10 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-47657</guid>
		<description>Elliott makes some good points but is also not really addressing my post in general. I started replying to each comment and it just became silly because he&#039;s arguing about languages and I&#039;m arguing about VMs. I do have to blast him for a few things.

You line count file example is horrible. That&#039;s an API and Java has tons of them that make reading files one line of code. Comparing APIs is worthless. If you want to do line count comparisons it has to be vanilla code that uses no API calls in either.

Second, my point is primarily about simplicity. I want something that is easy to code in and reduces overhead as much as possible. I&#039;d be in heaven if everyone implemented Groovy because it has the best mix of dynamic and static features right now. To use your style of reply, &quot;it&#039;s WAY better than Obj-C, Java, C++, Ruby, Python, etc&quot;.

Lastly, you talk a lot about speed and native code and dynamic languages. First of all, Microsoft does use .Net. Visual C++ can be managed and does have additional language features to make C++ better (like annotations and loads of good APIs) and they do use them. Second, Java isn&#039;t slow. Most large applications in the world use it. Third, Obj-C isn&#039;t native. It is LLVM intermediate code. Lastly, if I&#039;m gonna write true native code because of speed, I&#039;ll use a better language like &#039;D&#039; or another native language that removes the cruft and makes coding faster and easier. Why would you actually want to use C++ if you can use anything else? For that reason, why would you want to use Obj-C if you can use Ruby?

Just a few more points and then I&#039;m done. We have such different views and you make so many contradictions that it would take a long time to really address your whole post.

I&#039;m not sure how you expect games to just magically port to the iPhone. Not gonna happen I&#039;m 100% positive. Plus, you really don&#039;t need to provide low level memory access. Android has proved that very well. Doing that just increases headaches, bugs, etc.

Plus, Android has made a VM and Java work on a phone. This simplifies code and reduces the time to write apps. Plus, Android is free and open. My money is on Android winning and more and more languages being added. Oh and it does 3D and openGL, so you can do really fast graphics in Java.

Next, Obj-C does do method lookups. They can be optimized, but never removed because you can add and remove methods at runtime. This is standard dynamic language stuff and impossible to refute. You benchmark is pretty lame. It seems that Java and Obj-C are about equal except memory usage, which is to be expected. When Java wins in performance it really wins while Obj-C only slightly wins. I ignored start-up time completely. There are a ton of benchmarks that show Java being faster than C++ and Obj-C. Benchmarks are generally biased and worthless in my opinion, but you gave one that sorta proved me right. Thanks.

Lastly, I can blast any language I want. If it sucks to write in, I&#039;m gonna blast it and Obj-C sucks. Your research is faulty and you make incorrect and invalid statements as well. You missed a number of things and made some statements that just aren&#039;t true. You like Obj-C and will defend it. I like Java, but I&#039;m not saying it is the best out there. I&#039;m saying it is better than Obj-C because of overhead. However, Groovy is better than Java.

And to conclude, I&#039;m still talking about VMs and better languages. Obj-C doesn&#039;t have a full VM and it has too much overhead. I&#039;m still betting on Android and VMs. Although, I think that the CLR and Mono are way ahead of the JVM and I&#039;m hoping they start to pick up steam here as well. The JVM is getting old, crusty and behind the times while the CLR is modern, fast and having new features added to it all the time. Just look at all the stuff that&#039;s going into 4.0. Very cool dynamic languages stuff.</description>
		<content:encoded><![CDATA[<p>Elliott makes some good points but is also not really addressing my post in general. I started replying to each comment and it just became silly because he&#8217;s arguing about languages and I&#8217;m arguing about VMs. I do have to blast him for a few things.</p>
<p>You line count file example is horrible. That&#8217;s an API and Java has tons of them that make reading files one line of code. Comparing APIs is worthless. If you want to do line count comparisons it has to be vanilla code that uses no API calls in either.</p>
<p>Second, my point is primarily about simplicity. I want something that is easy to code in and reduces overhead as much as possible. I&#8217;d be in heaven if everyone implemented Groovy because it has the best mix of dynamic and static features right now. To use your style of reply, &#8220;it&#8217;s WAY better than Obj-C, Java, C++, Ruby, Python, etc&#8221;.</p>
<p>Lastly, you talk a lot about speed and native code and dynamic languages. First of all, Microsoft does use .Net. Visual C++ can be managed and does have additional language features to make C++ better (like annotations and loads of good APIs) and they do use them. Second, Java isn&#8217;t slow. Most large applications in the world use it. Third, Obj-C isn&#8217;t native. It is LLVM intermediate code. Lastly, if I&#8217;m gonna write true native code because of speed, I&#8217;ll use a better language like &#8216;D&#8217; or another native language that removes the cruft and makes coding faster and easier. Why would you actually want to use C++ if you can use anything else? For that reason, why would you want to use Obj-C if you can use Ruby?</p>
<p>Just a few more points and then I&#8217;m done. We have such different views and you make so many contradictions that it would take a long time to really address your whole post.</p>
<p>I&#8217;m not sure how you expect games to just magically port to the iPhone. Not gonna happen I&#8217;m 100% positive. Plus, you really don&#8217;t need to provide low level memory access. Android has proved that very well. Doing that just increases headaches, bugs, etc.</p>
<p>Plus, Android has made a VM and Java work on a phone. This simplifies code and reduces the time to write apps. Plus, Android is free and open. My money is on Android winning and more and more languages being added. Oh and it does 3D and openGL, so you can do really fast graphics in Java.</p>
<p>Next, Obj-C does do method lookups. They can be optimized, but never removed because you can add and remove methods at runtime. This is standard dynamic language stuff and impossible to refute. You benchmark is pretty lame. It seems that Java and Obj-C are about equal except memory usage, which is to be expected. When Java wins in performance it really wins while Obj-C only slightly wins. I ignored start-up time completely. There are a ton of benchmarks that show Java being faster than C++ and Obj-C. Benchmarks are generally biased and worthless in my opinion, but you gave one that sorta proved me right. Thanks.</p>
<p>Lastly, I can blast any language I want. If it sucks to write in, I&#8217;m gonna blast it and Obj-C sucks. Your research is faulty and you make incorrect and invalid statements as well. You missed a number of things and made some statements that just aren&#8217;t true. You like Obj-C and will defend it. I like Java, but I&#8217;m not saying it is the best out there. I&#8217;m saying it is better than Obj-C because of overhead. However, Groovy is better than Java.</p>
<p>And to conclude, I&#8217;m still talking about VMs and better languages. Obj-C doesn&#8217;t have a full VM and it has too much overhead. I&#8217;m still betting on Android and VMs. Although, I think that the CLR and Mono are way ahead of the JVM and I&#8217;m hoping they start to pick up steam here as well. The JVM is getting old, crusty and behind the times while the CLR is modern, fast and having new features added to it all the time. Just look at all the stuff that&#8217;s going into 4.0. Very cool dynamic languages stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliott Sprehn</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-47538</link>
		<dc:creator>Elliott Sprehn</dc:creator>
		<pubDate>Fri, 19 Dec 2008 08:50:52 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-47538</guid>
		<description>I&#039;m going to have to cry foul on the line count argument. For instance, how might you read a file into a string in Java? That&#039;s quite the task possibly involving BufferedReader&#039;s and several classes.

Ex.
http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/842009413931

Now there&#039;s libraries that do this for you, but in Objective-C that&#039;s:

NSString* contents = [NSString stringWithContentsOfFile:@&quot;file.txt&quot; encoding:NSUTF8StringEncoding error:nil];

Done. How about writing back out to a file? ;)

Then there&#039;s issues of extending classes at runtime, message passing, delegates, categories and generic typing like id. Java is a significantly more restrictive language that&#039;s not nearly as dynamic or flexible. Java&#039;s not really that fast for many things either. In fact it dips into native code (written in C/C++) for image manipulation and 3d graphics.

Claiming the community can&#039;t support new ScriptingBridge languages is also silly, there&#039;s lots of documentation. And bindings for Cocoa/Objective-C existed for Ruby, Perl, and Python long before Apple even created the bridge. Java was a special case because the language is so restrictive that they had to constantly maintain the silly bridge to make it work. In ruby you can just dynamically modify the entire message send process and allow creating and extending Objective-C objects totally transparently, unfortunately the same is impossible in Java without tons of class generation.

Note also that header files are ObjC&#039;s way of doing public and private methods. You create two header files. One you mark as private and subject to internal change, the other is public and for anyone to link against. Arguments that this is antiquated are quite silly. Almost all of Windows is C/C++. That includes most every user level program from media player to IE to the calendar. Essentially all of OS X is C/C++ and Objective C. MS is hardly eating it&#039;s own dog food with .NET, it&#039;s just not there yet.

C/C++ is faster, lower level so you can implement certain algorithms tons faster (array operations in Java are wicked slow compared to C++ and make no guarantee for cache locality). Objective-C is really just a thin layer on top of these languages providing the high performance of C code, right inline with your regular code without special &quot;native&quot; classes when you need it, and high level very dynamic (much more so than Java) features when you need that.

And I must say being able to add a method directly to a class so I can have [array writeLinesToFile:@&quot;out.txt&quot;], while in Java that&#039;d mean writing a helper class, and then adding a static function, when from an OO perspective, why not just make the Array smarter? And don&#039;t even get my started on NPE&#039;s instead of nil where you can still call methods on it.

For a mobile device where memory is short, but you want to allow high performance, low level memory control, OpenGL graphics and let developers move code directly from OS X to the smaller device? Objective-C is perfect. It&#039;s stupid easy for game developers who have written most of their code in C++ already to port it to the iphone. The same is not true of Andriod. You&#039;d end up porting the entire game engine!

btw: &quot;Actually, Objective-C is dynamic and so it performs method lookups for every method call. This means it will be considerably slower than C++ and probably about the same speed or slower than Java.&quot;

This is blatantly false. The runtime flat out doesn&#039;t work that way anymore. They cache lookups and do all kinds of things to make them faster.

ex. 
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&amp;lang=objc&amp;lang2=java

And that&#039;s with the GNU runtime which is slower than Apple&#039;s runtime. Yes it&#039;s missing tests, but look at the recursion test. That&#039;s going to generate a lot of function calls, yet somehow ObjC is still faster than Java! Go figure. 

Really do research before you blast a language or runtime about silly things that aren&#039;t true. :P

This isn&#039;t to say Java is bad. I develop in Java for web applications and enterprise platforms all the time. It&#039;s a pretty awesome platform for developing large scale applications that need to be clustered with caching and load balancing. In fact I&#039;m pretty sure the push components of the iPhone network are JMS powered. It&#039;s just to say that claiming one language is antiquated/slow/bad is just plain ridiculous. A lot of the features in Java are stolen right out of the C++ playbook and are stupid restrictive compared to more modern languages like ruby. Certainly in many people&#039;s eyes. A lot of the features of ObjC are borrowed from Smalltalk and are too dynamic and error prone in a lot of people&#039;s eyes. It&#039;s the eye of the beholder! And what it&#039;s really about is getting the job done anyway.</description>
		<content:encoded><![CDATA[<p>I&#8217;m going to have to cry foul on the line count argument. For instance, how might you read a file into a string in Java? That&#8217;s quite the task possibly involving BufferedReader&#8217;s and several classes.</p>
<p>Ex.<br />
<a href="http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/842009413931" rel="nofollow">http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/842009413931</a></p>
<p>Now there&#8217;s libraries that do this for you, but in Objective-C that&#8217;s:</p>
<p>NSString* contents = [NSString stringWithContentsOfFile:@"file.txt" encoding:NSUTF8StringEncoding error:nil];</p>
<p>Done. How about writing back out to a file? ;)</p>
<p>Then there&#8217;s issues of extending classes at runtime, message passing, delegates, categories and generic typing like id. Java is a significantly more restrictive language that&#8217;s not nearly as dynamic or flexible. Java&#8217;s not really that fast for many things either. In fact it dips into native code (written in C/C++) for image manipulation and 3d graphics.</p>
<p>Claiming the community can&#8217;t support new ScriptingBridge languages is also silly, there&#8217;s lots of documentation. And bindings for Cocoa/Objective-C existed for Ruby, Perl, and Python long before Apple even created the bridge. Java was a special case because the language is so restrictive that they had to constantly maintain the silly bridge to make it work. In ruby you can just dynamically modify the entire message send process and allow creating and extending Objective-C objects totally transparently, unfortunately the same is impossible in Java without tons of class generation.</p>
<p>Note also that header files are ObjC&#8217;s way of doing public and private methods. You create two header files. One you mark as private and subject to internal change, the other is public and for anyone to link against. Arguments that this is antiquated are quite silly. Almost all of Windows is C/C++. That includes most every user level program from media player to IE to the calendar. Essentially all of OS X is C/C++ and Objective C. MS is hardly eating it&#8217;s own dog food with .NET, it&#8217;s just not there yet.</p>
<p>C/C++ is faster, lower level so you can implement certain algorithms tons faster (array operations in Java are wicked slow compared to C++ and make no guarantee for cache locality). Objective-C is really just a thin layer on top of these languages providing the high performance of C code, right inline with your regular code without special &#8220;native&#8221; classes when you need it, and high level very dynamic (much more so than Java) features when you need that.</p>
<p>And I must say being able to add a method directly to a class so I can have [array writeLinesToFile:@"out.txt"], while in Java that&#8217;d mean writing a helper class, and then adding a static function, when from an OO perspective, why not just make the Array smarter? And don&#8217;t even get my started on NPE&#8217;s instead of nil where you can still call methods on it.</p>
<p>For a mobile device where memory is short, but you want to allow high performance, low level memory control, OpenGL graphics and let developers move code directly from OS X to the smaller device? Objective-C is perfect. It&#8217;s stupid easy for game developers who have written most of their code in C++ already to port it to the iphone. The same is not true of Andriod. You&#8217;d end up porting the entire game engine!</p>
<p>btw: &#8220;Actually, Objective-C is dynamic and so it performs method lookups for every method call. This means it will be considerably slower than C++ and probably about the same speed or slower than Java.&#8221;</p>
<p>This is blatantly false. The runtime flat out doesn&#8217;t work that way anymore. They cache lookups and do all kinds of things to make them faster.</p>
<p>ex.<br />
<a href="http://shootout.alioth.debian.org/debian/benchmark.php?test=all&#038;lang=objc&#038;lang2=java" rel="nofollow">http://shootout.alioth.debian.org/debian/benchmark.php?test=all&#038;lang=objc&#038;lang2=java</a></p>
<p>And that&#8217;s with the GNU runtime which is slower than Apple&#8217;s runtime. Yes it&#8217;s missing tests, but look at the recursion test. That&#8217;s going to generate a lot of function calls, yet somehow ObjC is still faster than Java! Go figure. </p>
<p>Really do research before you blast a language or runtime about silly things that aren&#8217;t true. :P</p>
<p>This isn&#8217;t to say Java is bad. I develop in Java for web applications and enterprise platforms all the time. It&#8217;s a pretty awesome platform for developing large scale applications that need to be clustered with caching and load balancing. In fact I&#8217;m pretty sure the push components of the iPhone network are JMS powered. It&#8217;s just to say that claiming one language is antiquated/slow/bad is just plain ridiculous. A lot of the features in Java are stolen right out of the C++ playbook and are stupid restrictive compared to more modern languages like ruby. Certainly in many people&#8217;s eyes. A lot of the features of ObjC are borrowed from Smalltalk and are too dynamic and error prone in a lot of people&#8217;s eyes. It&#8217;s the eye of the beholder! And what it&#8217;s really about is getting the job done anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Pontarelli</title>
		<link>http://brian.pontarelli.com/2008/10/19/android-iphone-java-objective-c-madness/#comment-47258</link>
		<dc:creator>Brian Pontarelli</dc:creator>
		<pubDate>Thu, 18 Dec 2008 16:19:25 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/?p=217#comment-47258</guid>
		<description>@Will

This is what the idea of platform VMs is all about. For the desktop you really only have 2, the CLR and the JVM. There are others, but those are the big guns. I&#039;m actually hoping that Mono comes along some more and the CLR wins. Although Microsoft has its faults, they have always done a really good job of keeping up to date. I&#039;m planning a blog post about that shortly.

On the phones though, you really only have Android at this point. Most of the other VMs out there aren&#039;t really competitive any longer and Android looks like it will dominate. In the very near future I see more companies going to Android and I see Android expanding to support more languages.</description>
		<content:encoded><![CDATA[<p>@Will</p>
<p>This is what the idea of platform VMs is all about. For the desktop you really only have 2, the CLR and the JVM. There are others, but those are the big guns. I&#8217;m actually hoping that Mono comes along some more and the CLR wins. Although Microsoft has its faults, they have always done a really good job of keeping up to date. I&#8217;m planning a blog post about that shortly.</p>
<p>On the phones though, you really only have Android at this point. Most of the other VMs out there aren&#8217;t really competitive any longer and Android looks like it will dominate. In the very near future I see more companies going to Android and I see Android expanding to support more languages.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

