This is why Apple uses Objective-C - to make code reuse easy. In many cases, the code being reused is code that has become part of the OS for all developers to reuse.

I guess I'm looking for a programmers review of Xcode 4.0. How does Objective C compare with Java and C#. What's new between Xcode 4.0 and Xcode 3.2 besides the interface changes. Are there any new coding paradigms in Objective C or is it all good. Beside C/C++ and Objective C does Xcode support other languages (e.g. Java, Rudy, PHP, etc.). Those are just some things I'd be interested in since I haven't used Xcode 4.0 before and plan to soon.

I'm used to Visual Studio and C/C++/C# on Windows. I'm hoping Objective C as much a pleasure to code in as C# if not better. It appears Xcode 4.0 is along the way of ease of use as Visual Studio.

Does Xcode 4.0 ship with built-in source control or can it easily plug into some free version out there (subversion)?

Well isn't that special! Those boys at Apple come up with the darndest things.

> Developers say it could also signal a new push into Adobe's territory

File this under "D" for "Duh". Why else would Apple sit on the release of SDK4 until the day before the release of Adobe CS5 if not to maximize the damage to that product?

Only a rube would believe SDK4 just happened to be finalized on that day. Everyone else is trying for the highest bounty in the Valley right now: getting a copy of that internal Apple memo....

I reported the post as SPAM but feel free to do the same...


The spam bots are getting better all the time...

This one:

1 - Creates a new account
2 - Finds a discussion thread
3 - Comes up with some sembilance of semi on-topic one line post
4 - Then links to their spam site

This sucks cause in no time the boards will be destroyed by the likes of these bots unless someone can find a new way to thwart them.

I don't get where the HTML or Adobe stuff fits in... Xcode 4 is great, but it will never be for HTML or eBooks. I could see this being a precursor to other things... maybe a new programming language. Really all we can read from Xcode 4, is that Apple is finally releasing an IDE to be proud of. It is also the culmination of many of the goals of the LLVM project (moving the compiler in to the IDE for instance). Dashcode has not changed in a long time and (although contains some neat ideas) is too limited to use in the real world for HTML development. The only goal that Xcode is pursuing is the creation of higher quality apps on the app store. It has very advanced tools to locate memory retain/release errors and other features that prevent programs from crashing.

The conclusion he is jumping to is a _really_ big stretch. There is no way the work done on Xcode could translate to HTML. It is all designed for imperative programming, not declarative programming. There is no way this code could result in an HTML editing environment. Not to mention that completely different teams work on the html and iwork side. Dashcode is the only place that HTML falls under the Xcode team and that was created as a necessity to support Dashboard.

I used to like the Roughly Drafted articles, but they have really gone down hill lately.

So I take it that it is too much trouble to download Xcode 4.0 and check it for yourself?

This is only a coincidence, Apple isn't targeting Adobe they are just one of the first offenders... Apple was starting to see too many third party runtimes that would constrain their efforts to advance iOS. It is the same reason Apple dumped their own other framework/runtime Carbon. Before that they dumped Cocoa for Java.

Apple never dumped Cocoa (unless you are referring specifically to webobjects moving to Java, which I believe predates Apple buying NeXT).

No, I am referring to the port of Cocoa on java that nobody used. I was not referring to Objective-C Cocoa (duh) or Objective-C WebObjects (different platform). I wouldn't be surprised if you never heard of it because it was deprecated in 2005. It was a side project to WebObjects. Carbon is the better example because that had widespread use.

I was basically trying to say that they hold themselves to the same standards as everyone else. This was definitely being done for technical reasons. They are essentially trying to prevent lowest common denominator apps that target both iPhone and Android. We will all be a lot better off for this. If you have a very simple application where this doesn't matter so much, then you can use AJAX to implement. That is easier to support moving forward because it is an open standard.

Pursuing a multi-platform app that can communicate between the platforms is very complex endeavor. User experience suffers greatly if you try to avoid the problems by bolting on a layer that makes both platforms look identical. There are very few good cross-platform apps for this reason. All of the good ones do not use a third party user interface layer. These apps write from scratch, but follow a compatible specification. This usually requires more work then writing separately for both platforms without compatibility. These interface layers drastically cut development costs, but they also cut corners that significantly hurt user experience. Games are a notable exception because they inherently have user interaction methods that work better with cross-platform tools. It seems that Apple is creating exceptions for games engines for precisely this reason.