Russ Teabeault and I were just talking about our recent experiences with Objective-C and developing applications for either the iPhone or OS X. In general, we both agree that Objective-C is necessary, but painful. The language is quasi-dynamic, not very modern and poorly adopted.
Let me clarify that a bit. Objective-C is dynamic but lacks nice features that most modern dynamic languages provide such as closures (although these aren’t strictly tied to dynamic languages by any means). It also uses a fairly non-standard message passing syntax, that is probably because it had to select something that would not conflict with C and C++. It also still uses header files and lacks good namespacing, both of which are obvious signs of antiquity. Plus, we both shared stories of having impossible times finding good open source libraries, tools and framework. The last bit of our conversation was the extreme lackluster of the XCode IDE, which is more like a text editor than a modern development environment.
I mentioned that prior to 10.4, Apple had provided integration of most of the Cocoa libraries with Java and had even written some OS applications in Java. Not surprising, we both thought the shift from Java to Objective-C was a step in the wrong direction. It seemed as though the correct direction would be a better, faster and more integrated VM that would run many languages including Java, much like the CLR offers developers on Windows. Instead, Apple seems to be chugging along the CPU native path and providing bridges between Objective-C and various scripting languages. This means that each new language they want to support on the operating systems requires work to bridge effectively and that work can only be done well by Apple. If they had gone down the VM path, new languages would be supported once the community built support for them on the VM. Therefore, if I wanted to write my next application for OS X in Scala, I could.
This brought us to a discussion of the merits of Android for mobile development. This is where we had different opinions. I think Android will be great and the development community and support behind it will be much larger than the iPhone. He thought that Apple might release a Java VM for the iPhone if Android picks up steam and believes that the iPhone is still the best platform for mobile.
The reason I like the idea of Android (although the G1 might be a crappy implementation without the ease of use and cool features of the iPhone) because it was fundamentally VM based. This meant that the platform was based on Java-byte code rather than the CPU instruction set. It also meant that the platform had modern concepts like garbage collection, memory management, ClassLoading and all the other good parts of the VM. But it also meant that it will be capable of running any Java-byte code regardless of the language it is written in. Therefore, I could write my Android application in Groovy and with the help of a few extra JARs, get it running just as well as plain old Java.
(Update 10/22/08 Groovy doesn’t quite work yet, because of a number of additional classes and JARs it uses. However, the principle is sound because Android is VM based. JRuby might be a better solution than Groovy depending.)
The problem with the iPhone is that it is tied directly to the CPU instruction set and the Objective-C language. This means you take a step backwards 20 years and now have all the overhead of header files, pre-compilers, directives, manual memory management, no-namespacing, and numerous other headaches that VMs have done exceedingly well in fixing.
What I wonder is why Microsoft is the only operating system company to figure out that wiring a VM, capable of everything we except out of a modern VM plus application isolation, into the lowest levels of the OS is a great idea. In fact, this idea is fantastic. This means applications targeted to the VM improve as the VM improves, without any code changes.
The Java VM still has a long way to go to catch up with the CLR as a full platform. JSR 121 was finalized a few years back, which will provide good application isolation within a single Java VM instance. This means that you can start up the Java VM and then run multiple applications inside it without any conflicts or concerns about one application impacting the others (such as an application calling System.exit or running out of memory). The Java VM still needs extremely tight integration with the operating system and needs to be started when the OS boots. It also needs new ways to start applications and manage applications, which JSRs 277 and 294 should help with. I think though that Google has done all of this work for Android. It runs multiple applications in isolation well, it provides a mechanism for applications to start and stop and the Java VM is completely integrated into the operating system of the mobile device.
I think this is the way of the future. I’m just trying to figure out where Apple is going and why they are heading that way.
Invert your Mind 
I will start out by agreeing with you on one of your points:
“It also still uses header files and lacks good namespacing, both of which are obvious signs of antiquity.”
I do agree on the namespacing point, as a former java dev, I sometimes wish that we had packages in obj-c, however I see nothing wrong with header files.
Now I have to rebut some of your points:
“Plus, we both shared stories of having impossible times finding good open source libraries, tools and framework. ”
There is a tremendous amount of code written in the “antique” languages of C/C++ both of wich are well supported on the iPhone. This is where android falls down as you would have to find a “java” version.
So far as xcode goes, i will admit that it doesn’t do all of the “cool” things that eclipse does, but interface builder will beat anything out there right now.
The entire tone of your post seems to lean toward java being the silver bullet in all cases, and anything not java is the wrong choice. I see nothing wrong with native code. I mean at some point EVERYTHING is native code. I’m sure there is a good reason that garbage collection hasn’t been implemented on the iPhone. First of all it is a phone which has very tight memory constraints. Many people look at the iPhone and Android for that matter like they would a desktop or a server.
“The problem with the iPhone is that it is tied directly to the CPU instruction set and the Objective-C language. This means you take a step backwards 20 years and now have all the overhead of header files, pre-compilers, directives, manual memory management, no-namespacing, and numerous other headaches that VMs have done exceedingly well in fixing.”
There is nothing wrong with manual garbage collection, in fact I find it a breath of fresh air that I can manually manage my own memory. I can write more more “tighter” code in Obj-c/C than I can in java. Garbage collectors are not the end all be all.. that’s just laziness. Don’t get me wrong, there are legitimate uses for garbage collection, but to imply that the iPhone is 20 years behind the times is just ignorant.
“What I wonder is why Microsoft is the only operating system company to figure out that wiring a VM, capable of everything we except out of a modern VM plus application isolation, into the lowest levels of the OS is a great idea. In fact, this idea is fantastic. This means applications targeted to the VM improve as the VM improves, without any code changes.”
I would believe that statement if they totally got rid of their win32 api and everything and I mean everything in vista was .NET but it’s not.
In closing I do think apple has some work to do to make development a bit easier especially for newcomers but their objective-c runtime is extremely fast and efficient and their cocoa frameworks are top notch. I think other languages such as Java could learn a thing or two.
LikeLike
@ Hasani
First of all, thanks for the great comments. Here’s some replies:
“I do agree on the namespacing point, as a former java dev, I sometimes wish that we had packages in obj-c, however I see nothing wrong with header files.”
There are a lot of reasons header files aren’t necessary. I argue that most languages have gotten rid of them. Here are just a few, Ruby, Python, Groovy, Scala, Haskel, Erlang, Clojure, Java, C#. There are a lot more and for good reason. They serve no purpose.
“There is a tremendous amount of code written in the “antique” languages of C/C++ both of wich are well supported on the iPhone. This is where android falls down as you would have to find a “java” version.”
The Java VM has far more open source libraries, tools and projects than C/C++. Andriod gains a lot by selecting the Java VM. You gain all of the libraries written in Java and everything that has been compiled into Java byte code from other languages supported on the Java VM. It sounds like you don’t understand the difference between the Java VM and Java language.
“So far as xcode goes, i will admit that it doesn’t do all of the “cool” things that eclipse does, but interface builder will beat anything out there right now.”
Interface builder is decent, but uses models that are supported by the Apple Objective-C runtime. It really doesn’t provide huge benefits over other UI builders for other languages.
“The entire tone of your post seems to lean toward java being the silver bullet in all cases, and anything not java is the wrong choice. I see nothing wrong with native code. I mean at some point EVERYTHING is native code. I’m sure there is a good reason that garbage collection hasn’t been implemented on the iPhone. First of all it is a phone which has very tight memory constraints. Many people look at the iPhone and Android for that matter like they would a desktop or a server.”
Again, I think you might not understand the difference between Java the language and Java the VM. I’m talking specifically about the VM, which is capable of running applications written in hundreds of languages. You cannot say the same thing for the iPhone. It supports 3 languages and you really should be using Objective-C. Andriod phones will naturally support hundreds of languages because they selected a VM.
In terms of memory constraints and stating that phones can’t run VMs or shouldn’t is also not necessarily correct because we have had numerous phones with VMs on them for years. And now Andriod will propel this even further with a much more complete vision of a VM on a constrained device.
By no means will phones continue to stay constrained either. Most full VMs require 100MB of disk and 16MB of memory to run. Most phones have that and more. So banking on a VM in the long run is a much better solution.
“There is nothing wrong with manual garbage collection, in fact I find it a breath of fresh air that I can manually manage my own memory. I can write more more “tighter” code in Obj-c/C than I can in java. Garbage collectors are not the end all be all.. that’s just laziness. Don’t get me wrong, there are legitimate uses for garbage collection, but to imply that the iPhone is 20 years behind the times is just ignorant.”
Your arguement about manual memory management has been proven to be wrong by a lot of folks, namely Microsoft. Manual memory management in most cases is dangerous, error prone and wrong. You have worse memory leaks and often aren’t really saving much at all. Modern VMs have been shown to perform within less than 5% of manual memory managed applications and in some cases better. Microsoft has even gone so far as to support managed C++. The reason everyone is heading in that direction is that a VM will almost always be better at GC than developers will. You really should consider reading up on the VM technologies and how they are in fact not laziness. Microsoft and Sun have a number of great white papers on the subject as does IBM, Oracle and many others. There are reasons why so many developers, languages and VMs are in use. I’d venture a guess that manual memory developers are roughly 1% of the development population.
I don’t really agree with your ignorant statement. If you look at the two paths side by side, you will see that Google is using technology that is very modern, such as a VM, garbage collection and more. If you look at the iPhone it is using machine language and using a language based on technology written well over 30 years ago. From a developers perspective, the iPhone offers nothing modern at all.
“I would believe that statement if they totally got rid of their win32 api and everything and I mean everything in vista was .NET but it’s not.”
This probably has little to do with .NET and the CLR as it does politics and historical code. Having talked with many of the people behind the CLR, Microsoft is banking on the fact that the CLR will eventually be the only way applications are written. Think of the savings of time and money if you could write everything on a VM like the CLR. I’m sure Microsoft is thinking this exact same way.
“In closing I do think apple has some work to do to make development a bit easier especially for newcomers but their objective-c runtime is extremely fast and efficient and their cocoa frameworks are top notch. I think other languages such as Java could learn a thing or two.”
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.
I also think that Cocoa is a nice API, but it is just that – an API. I don’t think you understand the difference between a language and an API. If did your research you would also realize that Cocoa was originally written specifically to fully be used from Java. So, Cocoa is actually a Java API. I don’t think Java has anything to learn from Cocoa or Objective-C at all. If we are talking purely about APIs, I consider Cocoa a good API and there are also MANY good Java APIs out there. If we are talking purely about languages, well, then I think Objective-C could learn a lot from Java and many other languages.
I definitely think you are missing some key information about the difference between Java the language, Java the VM and the JDK APIs. My main point was that Apple needs to head down the VM route. My second point was I think Objective-C is just an old language and that Apple should move forward and pick a language that is more modern. They actually are in the process of doing that. They have selected Ruby and Python. But, I think they should go the extra step and create something new.
LikeLike
Thanks for your quick reply!
A few thoughts:
“There are a lot of reasons header files aren’t necessary. I argue that most languages have gotten rid of them. Here are just a few, Ruby, Python, Groovy, Scala, Haskel, Erlang, Clojure, Java, C#. There are a lot more and for good reason. They serve no purpose.”
Serve no purpose?? So I suppose that apple,microsoft,openbsd,linux, etc are just using header files for nostalgia?
“Again, I think you might not understand the difference between Java the language and Java the VM. I’m talking specifically about the VM, which is capable of running applications written in hundreds of languages. You cannot say the same thing for the iPhone. It supports 3 languages and you really should be using Objective-C. Andriod phones will naturally support hundreds of languages because they selected a VM.”
Even though I do understand the difference between a language and a vm, i was under the impression that the only supported programming language for andriod is JAVA, not Scala,Ruby or Python. So to imply say that just because Google is using a VM that all of these other languages will be supported is false.
“In terms of memory constraints and stating that phones can’t run VMs or shouldn’t is also not necessarily correct because we have had numerous phones with VMs on them for years. And now Andriod will propel this even further with a much more complete vision of a VM on a constrained device.”
I wasn’t saying that JAVA had never run on mobile phones before, my point is that up until this point the memory and cpu constraints really lended itself to developing in languages such as C or C++ therefore out of necessity you had to have full control over how you were using your memory.
“The reason everyone is heading in that direction is that a VM will almost always be better at GC than developers will. You really should consider reading up on the VM technologies and how they are in fact not laziness. Microsoft and Sun have a number of great white papers on the subject as does IBM, Oracle and many others.”
Again, I’m not saying that GC is bad. What I am saying is that at this point, it isn’t a silver bullet and in some cases creates more problems than it solves. For example, why do we have multiple garbage collection strategies in Java? Garbage collection isn’t even guaranteed to run. I agree that the technology is getting better and you very well may be right in the long term.
“There are reasons why so many developers, languages and VMs are in use. I’d venture a guess that manual memory developers are roughly 1% of the development population.”
Again, I’m not saying there isn’t a place for VMs. But at the lowest level I don’t see them gaining much traction. And by lowest level, I’m talking kernel development, etc.
“Actually, Objective-C is dynamic and so it actually does method look ups for all calls. This means it will be considerably slower than C++ and probably about the same speed or slower than Java.”
Care to back that up?
“I also think that Cocoa is a nice API, but it is just that, an API. I don’t think you understand the difference between a language and an API. If did your research you would also realize that Cocoa was originally written specifically to fully be used from Java. So, Cocoa is actually a Java API. I don’t think Java has anything to learn from Cocoa or Objective-C at all. If we are talking purely about APIs, I consider Cocoa a good API and there are also MANY good Java APIs out there. If we are talking purely about languages, well, then I think Objective-C could learn a lot from Java and many other languages.”
Cocoa came from the OpenStep project between Sun and NeXT. Java doesn’t have categories or informal protocols to name a few features that a objective-c developer use on a regular basis.
“I definitely think you are missing some key information about the difference between Java the language, Java the VM and the JDK APIs. My main point was that Apple needs to head down the VM route. My second point was I think Objective-C is just an old language and that Apple should move forward and pick a language that is more modern. They actually are in the process of doing that. They have selected Ruby and Python. But, I think they should go the extra step and create something new.”
Apple is heading down the vm route with CLANG http://clang.llvm.org/. Tossing something out just because its “old” is as ridiculous as jumping into something purely because its “cool”. There has to be valid practical reasons for doing so in either case.
LikeLike
“Serve no purpose?? So I suppose that apple,microsoft,openbsd,linux, etc are just using header files for nostalgia?”
Yes. These languages and compilers lack a way to compile against something without a header. This is legacy. If you can find any other reason, feel free to toss it out. This is also why these languages and compilers can’t have classes reference themselves easily.
“Even though I do understand the difference between a language and a vm, i was under the impression that the only supported programming language for andriod is JAVA, not Scala,Ruby or Python. So to imply say that just because Google is using a VM that all of these other languages will be supported is false.”
No. Andriod is the VM and SDK. Therefore, it runs byte code as does any Java VM. Are you really sure you know what byte code and VMs are? Anything that compiles to Java byte code will run.
“I wasn’t saying that JAVA had never run on mobile phones before, my point is that up until this point the memory and cpu constraints really lended itself to developing in languages such as C or C++ therefore out of necessity you had to have full control over how you were using your memory.”
Not true as is apparent with Andriod. Google is one of the smartest companies in the world and there is a reason they selected Java and a Java VM.
“Again, I’m not saying that GC is bad. What I am saying is that at this point, it isn’t a silver bullet and in some cases creates more problems than it solves. For example, why do we have multiple garbage collection strategies in Java? Garbage collection isn’t even guaranteed to run. I agree that the technology is getting better and you very well may be right in the long term.”
I’m pretty much right in the now-term. It is not a silver bullet, but better in most cases. That’s why most of the worlds largest computing clusters and environments run on Java or C#. Having worked at Orbitz I can tell you first hand that VMs are better. The reason there are multiple GCs is mostly legacy at this point due to slower, non-parallel CPUs. Orbitz for example uses the standard GC for JDK 6 and having tried to tweak the JVM and use other GCs, they don’t work and are mostly obsolete at this point.
“Again, I’m not saying there isn’t a place for VMs. But at the lowest level I don’t see them gaining much traction. And by lowest level, I’m talking kernel development, etc.”
I do. I see the VM moving more and more into the kernel and lower and lower. The lower they go, the faster and better they will be. Microsoft will show us all how it is done in the near future with respect to VMs at the lowest levels.
The kernel will always be written native, and so will most drivers and such. Once you get into the application layer, it will be all managed.
“Care to back that up?”
I can prove that it is dynamic and method lookups occur, but as for metrics, that will be hard. Looking around, most of the good comparisons are gone and most comparisons in general are flawed. However, a lot of folks have done good metrics against Objective-C and Apple has been working for a while to get it faster.
I think another way to compare them would be memory issues and leaks. I would contend that overall the Java VM is one of the most sophisticated VMs and that most applications written for it would be simpler and perform better from a memory perspective than an Objective-C counterpart.
“Cocoa came from the OpenStep project between Sun and NeXT. Java doesn’t have categories or informal protocols to name a few features that a objective-c developer use on a regular basis.”
Cocoa was fully written with Java support in 10. Just go look at some old API docs and you will see it was. Java support was removed in 10.4. It was from Open/NextStep, but it also had great Java support before 10.4.
Java the language doesn’t have categories or informal protocols. Java the VM does support languages with these. Groovy has categories and it also has many other great features that Objective-C lacks. Plus, the Java VM has namespacing. If OS X was based on a VM, then you could code in JRuby if you liked. Or code in Groovy or Java or whatever. That’s why the CLR is nice, you get to pick the best language for the job. Trying to use a single language for everything is “ignorant”.
“Apple is heading down the vm route with CLANG http://clang.llvm.org/. Tossing something out just because its “old” is as ridiculous as jumping into something purely because its “cool”. There has to be valid practical reasons for doing so in either case.”
LLVM is different. It isn’t a high level VM. It can be used to create higher level VMs and then have languages added on top of that, but it would be a lot of work. I doubt that this is what Apple has in mind. They are looking for a better way to compile Objective-C. The Objective-C VM is available in 10.5 and is coming along, but they have a LONG way to go to catch up with Microsoft and Sun.
I think what you are missing is code overhead. That’s what I mean by “old”. C/C++/Objective-C have a certain amount of code overhead that isn’t necessary. They should get rid of it. Java also has some code overhead, but less.
Objective-C could easily be updated to drop header files and simplify the code. This would break it from C and force developers to pull the C code out into separate files and have different compilation steps.
The practical reason is that it is simpler, faster and less error prone to write in new languages using a VM. That’s the reason to drop the “old” stuff and pick some of the “cool” stuff. There are good reasons why stuff is “cool”.
LikeLike
“Google is one of the smartest companies in the world and there is a reason they selected Java and a Java VM.”
I was really hoping for a much more technical explanation than that, but
“I’m pretty much right in the now-term. It is not a silver bullet, but better in most cases. That’s why most of the worlds largest computing clusters and environments run on Java or C#. Having worked at Orbitz I can tell you first hand that VMs are better. The reason there are multiple GCs is mostly legacy at this point due to slower, non-parallel CPUs. Orbitz for example uses the standard GC for JDK 6 and having tried to tweak the JVM and use other GCs, they don’t work and are mostly obsolete at this point.”
I’m talking about mobile phones and keeping things lean and mean and you’re talking about huge computing clusters. Those environments have very different requirements. I’m not talking about scaling up as much as scaling down.
“I think another way to compare them would be memory issues and leaks. I would contend that overall the Java VM is one of the most sophisticated VMs and that most applications written for it would be simpler and perform better from a memory perspective than an Objective-C counterpart.”
I would agree that the Sun JVM is one of the most sophisticated VMs out there, however I detect a bit of arrogance in your statement that most apps would be better written in java as opposed to objective-c. There is a reason that Apple has been pushing developers to use Cocoa and objective-c. To reuse your previous statement:
“Apple is one of the smartest companies in the world and there is a reason they selected Cocoa and a Objective-c.”
Just because Cocoa had Java support doesn’t mean that it is a Java API. Cocoa would have to be written in JAVA for that statement to be true.
“I think what you are missing is code overhead. That’s what I mean by “old”. C/C++/Objective-C have a certain amount of code overhead that isn’t necessary. They should get rid of it. Java also has some code overhead, but less.”
What code are you referring to as overhead? What isn’t needed? Again, unless you know first hand of the “code” overhead that C/C++/Objective-c have over Java, I’m willing to listen. Otherwise that statement is also false.
“Objective-C could easily be updated to drop header files and simplify the code. This would break it from C and force developers to pull the C code out into separate files and have different compilation steps.”
I’m sure that if it was that easy, it would have been done years ago. But it hasn’t. Besides, what would Apple gain by removing C compatibility? Kinda hard for Objective-c to break with C when it is a SUPERSET of C http://en.wikipedia.org/wiki/Objective-C .
“The practical reason is that it is simpler, faster and less error prone to write in new languages using a VM. That’s the reason to drop the “old” stuff and pick some of the “cool” stuff. There are good reasons why stuff is “cool”.”
I can actually agree with most of that statement. The errors are just different from one language to another regardless if a VM is in use or not.
LikeLike
“I was really hoping for a much more technical explanation than that, but”
Okay, Google uses Java in many of their applications. They are highly experienced developers and have one of the most rigorous hiring processes out there, if not the most rigorous, to ensure the best engineers are hired. They also have language developers, old Sun folks, old Apple folks, VM developers, etc. They have enough people there to make the correct decisions. They also plan very long term, like 10-15 years according to their CEO in an interview with NPR recently. This means that Andriod uses Java for a very good reason, which is the VM.
On the flip side, Apple has some smart people as well, but not as many and I’d say not quite the same level of expertise. Apple plans long term, but on a different scale with fewer products and more hardware interests. Apple also had good reason to select Objective-C for the iPhone. Money. It was cheaper to use the same base platform for the iPhone as the OS.
Google didn’t have this constraint and had the resources and time to select whatever they wanted. They selected a VM and Java because it would capture a larger group of developers, a larger open source community, increase application development time/quality and reduce overhead.
“I’m talking about mobile phones and keeping things lean and mean and you’re talking about huge computing clusters. Those environments have very different requirements. I’m not talking about scaling up as much as scaling down.”
I believe you were talking about GCs being bad and not efficient. My point is that phones or clusters, GC is the way to go and that they are _really_ good these days.
“I would agree that the Sun JVM is one of the most sophisticated VMs out there, however I detect a bit of arrogance in your statement that most apps would be better written in java as opposed to objective-c. There is a reason that Apple has been pushing developers to use Cocoa and objective-c. To reuse your previous statement:”
I don’t think it is arrogance. It is pragmatic. If I can uses language that is just as powerful, but simpler, easier and less error prone, I’m gonna use it. In fact, I’d prefer to use something like Groovy over Java. And for Cocoa, well that could be made to work from any language, so I don’t really consider that part of the discussion – it’s just an API and not tied to the language.
Remember, that what I’m talking about in the paragraph above are languages, not VMs.
In terms of why Apple is pushing Objective-C (again ignoring Cocoa) is probably legacy. I would assume that they will eventually migrate to other languages, just like Microsoft has done. I’m hoping that do this via a solid VM.
“Apple is one of the smartest companies in the world and there is a reason they selected Cocoa and a Objective-c.”
Not really. I don’t think Apple isn’t as smart as Google. I think they make great consumer products, but bad developer products and have made bad technical decisions over the past decade or so.
“Just because Cocoa had Java support doesn’t mean that it is a Java API. Cocoa would have to be written in JAVA for that statement to be true.”
It does though. An API is simply a collection of functions and data at the most fundamental level. How those APIs are invoked depends on what languages they have been integrated with. I could write an API in assembler and then open it up to Ruby, Python, Java, Objective-C and others. This doesn’t make it an assembler API, but a Ruby, Python, Java, Objective-C API because I can call it from those languages.
This is why Microsoft is banking on the CLR. You can invoke managed C++ directly from IronPython, no problem. It looks and acts just like Python and is therefore a Python API. The CLR makes it possible to ignore languages and just focus on APIs as collections of functions and data.
“What code are you referring to as overhead? What isn’t needed? Again, unless you know first hand of the “code” overhead that C/C++/Objective-c have over Java, I’m willing to listen. Otherwise that statement is also false.”
More lines of code and more files. More stuff that isn’t necessary. Objective-C as a language requires more lines of code and files to accomplish the same thing Java does in less. But you can swap out Java with most modern languages and that statement will still be true.
Here’s an example.
Simple Objective-C class to add two numbers
2 files
11 lines of code
Simple Java class to add two numbers
1 file
5 lines of code
That’s half the code.
“I’m sure that if it was that easy, it would have been done years ago. But it hasn’t. Besides, what would Apple gain by removing C compatibility? Kinda hard for Objective-c to break with C when it is a SUPERSET of C http://en.wikipedia.org/wiki/Objective-C .”
The reason it hasn’t is because it would break C compatibility and Apple doesn’t want to do that. I can code an class entire in Objective-C, without any C. This class could easily be defined in a single file. When the compiler parses the file, it generates the native instructions. The step missing here is that for me to use this class somewhere else, I need to have it in my build path so I can reference it and the compiler doesn’t freak out. Since Objective-C is dynamic, it really doesn’t need this information. It just needs to understand that the class exists. This is what the @class is for.
So, if someone wanted to remove header files from Objective-C, they could because it is all dynamic. You could declare instance variables of other classes, as long as you define the classes somewhere. They don’t need to be in your build path. Might look like this:
@external Foo
@class Bar {
Foo foo;
– (void) someMethod {
[foo callSomeMethod];
}
}
This would work fine since Objective-C doesn’t need to perform any compile type checking, just like Ruby and other languages.
LikeLike
Just a couple of notes.
While I agree with you that the message passing syntax is a little weird looking to someone coming from Java/C++/other languages. Objective-C’s style is based on Smalltalk’s syntax. I think this was done to avoid the confusion of message passing between objects and the “function pointer in a struct” style that is still used in plain C. C++ went the opposite way by intentionally mimicking that syntax. Personally, I like the infix parameter names. I think it makes longer argument lists a lot more readable. Just today in java I ended up calling a method that had 5 boolean arguments and trying to keep them straight was a bit of a pain. At the same time, it would have been nice to have Smalltalk’s Blocks make it over into Objective-C (closures), though it looks like that may happen in the not-too-distant future.
On another note, have you seen MacRuby? It’s an implementation of Ruby on top of Cocoa. This means that standard Ruby types like String and Object are mapped directly to NSString (or NSMutableString) and NSObject. It looks very promising and has Xcode/Interface builder integration as well. Here’s hoping that it becomes available for iPhone dev as well. http://developer.apple.com/mac/articles/scriptingautomation/cocoaappswithmacruby.html
LikeLike
@Doug
Thanks for the reply.
“(snip) Just today in java I ended up calling a method that had 5 boolean arguments and trying to keep them straight was a bit of a pain. At the same time, it would have been nice to have Smalltalk’s Blocks make it over into Objective-C (closures), though it looks like that may happen in the not-too-distant future.”
I agree with you on closures all the way. Every language needs these now. I also agree with the message calling and how Objective-C does method lookups, it definitely cleans things up, but some of the nasty situations are due to poor API creation by developers. We’ve all seen those 5 boolean methods and they suck. This can be flipped to a simple struct parameter with clean named properties. But this is one thing that annoys me because it is code overhead again.
VB (I know laugh it up folks) had a similar approach that allowed named parameters while keeping the C based syntax, which helped with its adoption.
I think there are reasonable ways to improve on this pattern. Again, this is where syntax really becomes an issue and changing existing languages is near impossible. But creating something new is definitely a possibility.
“On another note, have you seen MacRuby? It’s an implementation of Ruby on top of Cocoa. This means that standard Ruby types like String and Object are mapped directly to NSString (or NSMutableString) and NSObject. It looks very promising and has Xcode/Interface builder integration as well. Here’s hoping that it becomes available for iPhone dev as well. http://developer.apple.com/mac/articles/scriptingautomation/cocoaappswithmacruby.html”
Yeah, this is what I was referencing in my commnets with Hasani. I think it is a step in the right direction, but I have a few issues with this though.
1. This language support is a bridge, just like Java was
2. It still uses the C-Ruby VM, which compared to Java’s VM is fairly primitive
3. When Apple decides to support other languages, they have to create a bridge to them, which is restrictive and time consuming.
If Apple would take an approach like Microsoft did with the CLR,and bind Cocoa using the common byte-code, then any language on that VM could be used to develop applications. This would also open things up to much more community development, support, innovation, etc.
LikeLike
“Not true as is apparent with Andriod. Google is one of the smartest companies in the world and there is a reason they selected Java and a Java VM.”
Partially true. Google chose Java the language, but not Java the VM. Code is written (only) in Java, and then compiled to run against a Davlik VM, not a standard Java VM. You can argue that Google gets the benefits of having *A* VM on Android, but not the benefits of having a Java VM, because they do not.
LikeLike
@Greg
I did not know this bit of information, so thanks for the clarification.
However, it is still a VM that can run Java-byte code via a transformation process. So, although not strictly a full Java VM, it can still run Java byte code. It still has garbage collection and other types of management. It also has some features that most Java VMs lack, such as process isolation via the OS interface without incurring major overhead for new VMs to be spawned.
Therefore, I’d still classify this in the VM category and also state that very little precludes Google from writing compilers for other languages directly into DEX.
LikeLike
“The reason I like the idea of Android (although the G1 might be a crappy implementation without the ease of use and cool features of the iPhone) because it was fundamentally VM based. This meant that the platform was based on Java-byte code rather than the CPU instruction set. It also meant that the platform had modern concepts like garbage collection, memory management, ClassLoading and all the other good parts of the VM. But it also meant that it will be capable of running any Java-byte code regardless of the language it is written in. Therefore, I could write my Android application in Groovy and with the help of a few extra JARs, get it running just as well as plain old Java.”
Just wanted to point out that this assumption you make is wrong. Android’s Dalvik VM is not 100% Java SE compatible, so you won’t be able to just drop in a few extra JARs and get crackin’ with Groovy. You’ll need to port Groovy to the Android environment.
LikeLike
@PJ
Someone else brought this up, which is true, but it is still capable of running Java byte code via a transformation. More importantly though, it is a VM. My points wasn’t that it is a fully compliant Java SE VM, just that it is a VM.
In terms of running Groovy, I don’t see why this would be an issue since Groovy code is compiled to Java byte code, the Groovy runtime is Java byte-code and if you transform both to DEX it should run fine.
Please correct me if I’m wrong here.
LikeLike
I have been learning Groovy and Objective-C, and have some limited perspective on this. I would like to see Apple do for Objective-C what Groovy did for Java. In fact, I would love to see Apple adopt the Groovy language specification and perhaps contribute to its evolution and produce a ‘CocoaScript’ language that adhers to the Groovy spec but compiles to native code “C” code and interfaces with Objective-C. This would produce one language that would be implemented as Groovy for Java and CocoaScript for Objective-C that would share the same, or extremely similar syntax and appeal to a wider audience than Objective-C does. Furthermore, it would be nice to see this CocoaScript replace or augment AppleScript on MacOS X. It would also be nice to have the same language supported on JavaScript and baked into WebKit, call it “WebScript”. In short, one language spec could be implemented across the JVM, Cocoa Frameworks, and WebKit. while the libraries available in each environment would be different, the language would be the same and be treated as a “First Class” language in each environment. Furthermore, standardized libraries for basic Date/Time, File, etc. could be made available on each platform, making alot of code cut and paste between runtimes.
LikeLike
@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’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’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’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.
LikeLike
I’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’s quite the task possibly involving BufferedReader’s and several classes.
Ex.
http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/842009413931
Now there’s libraries that do this for you, but in Objective-C that’s:
NSString* contents = [NSString stringWithContentsOfFile:@”file.txt” encoding:NSUTF8StringEncoding error:nil];
Done. How about writing back out to a file? 😉
Then there’s issues of extending classes at runtime, message passing, delegates, categories and generic typing like id. Java is a significantly more restrictive language that’s not nearly as dynamic or flexible. Java’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’t support new ScriptingBridge languages is also silly, there’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’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’s own dog food with .NET, it’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 “native” 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:@”out.txt”], while in Java that’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’t even get my started on NPE’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’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’d end up porting the entire game engine!
btw: “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.”
This is blatantly false. The runtime flat out doesn’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&lang=objc&lang2=java
And that’s with the GNU runtime which is slower than Apple’s runtime. Yes it’s missing tests, but look at the recursion test. That’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’t true. 😛
This isn’t to say Java is bad. I develop in Java for web applications and enterprise platforms all the time. It’s a pretty awesome platform for developing large scale applications that need to be clustered with caching and load balancing. In fact I’m pretty sure the push components of the iPhone network are JMS powered. It’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’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’s eyes. It’s the eye of the beholder! And what it’s really about is getting the job done anyway.
LikeLike
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’s arguing about languages and I’m arguing about VMs. I do have to blast him for a few things.
You line count file example is horrible. That’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’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, “it’s WAY better than Obj-C, Java, C++, Ruby, Python, etc”.
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’t slow. Most large applications in the world use it. Third, Obj-C isn’t native. It is LLVM intermediate code. Lastly, if I’m gonna write true native code because of speed, I’ll use a better language like ‘D’ 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’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’m not sure how you expect games to just magically port to the iPhone. Not gonna happen I’m 100% positive. Plus, you really don’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’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’t true. You like Obj-C and will defend it. I like Java, but I’m not saying it is the best out there. I’m saying it is better than Obj-C because of overhead. However, Groovy is better than Java.
And to conclude, I’m still talking about VMs and better languages. Obj-C doesn’t have a full VM and it has too much overhead. I’m still betting on Android and VMs. Although, I think that the CLR and Mono are way ahead of the JVM and I’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’s going into 4.0. Very cool dynamic languages stuff.
LikeLike
What on earth are you talking about?
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. 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’s ABI is identical to C’s. Or maybe it’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(“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.
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!
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++!
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.
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!
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.
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.
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’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:
http://gizmodo.com/5081969/firefox-mobile-wont-be-foxing-up-android-anytime-soon
Ooooh snap! 😉
LikeLike
Elliott,
You posts are becoming quite aggressive. I think we should call a truce on the personal attacks and just focus on facts. I’ve approved this one, but let’s keep it civil.
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.
Yes. Please try to keep it civil here.
Okay, this is really important to me and you are to be tossing it out completely, which I can’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’ll get to speed in a second). The Java source files are about 50% less code than the C++ source files. That’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’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’t using classes. If you really want to compare, I’d ask you to write the following: “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).” If you compare these in Objective-C and Java, Objective-C has more overhead.
My library is faster in Java and it is a valid benchmark and it is a complex and highly used API. This isn’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.
I’m not saying that Java is faster than C++ and I wouldn’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’t necessary and this includes games. You can easily write games in something like D.
I do understand dynamic lookups as do you. You can’t have a dynamic language without method lookups and dynamic invocation. You just can’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.
If you are writing a game, why would you use ObjC? You’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.
Any IDE that does as much work as Java IDEs do will incur some performance overhead. Visual Studio doesn’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’t slow. There are many that are very fast. I’ve also seen horribly slow C++ apps. This is usually because of bad programming, not language or VM versus native.
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.
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’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’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’ll never need C++ or ObjC on Android, so I’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.
LikeLike
Maybe Oilcan will simplify things!
http://oilcan.jsharkey.org
LikeLike
That’s an interesting exchange you guys have back and forth. I know its somewhat aged at this point but I’d like to add to it.
“C++ is fast as long as you write it correctly and are really good at memory management.”
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’d also like to chime in on the Java/C++ performance comparison. I’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’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 “fast enough” 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’s VM is quite impressive and yes there are many corner cases where performance is best described as “fast”. Just the same, few applications can survive alone on corner cases.
I will also add, I am an Android developer. I’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’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’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’s not including NetBooks. I personally believe 6-12 is more likely but I’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’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’s momentum, the G1 has already matched the iPhone’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.
LikeLike
I hope it doesn’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’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’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’t see why you need a VM. Java hasn’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.
LikeLike
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?
LikeLike