Sony Adopts Objective-C and GNUstep Frameworks

EMB Numbers writes "Sony has revealed that the new SNAP development environment for 'consumer electronics' is based on Objective-C and the open source GNUstep implementation of Apple's Openstep spec. While Apple has continued to update their specification in the form of Cocoa and Mac OS X, GNUstep has preserved the original standard. Anyone familiar with Cocoa Touch and iOS will feel right at home developing for Sony. There may even be some source code compatibility between the platforms. The world continues to chase apple — probably for the better."

Comments

WebKit?

[Anonymous Coward]

I wonder if this will finally give us GNUStep WebKit. That would be an interesting thing :)

How compatitble

[AnonymousClown]

FTFL:

The GNUstep core libraries strictly adhere to the OpenStep standard and OPENSTEP implementation.

From the submission:

While Apple has continued to update their specification in the form of Cocoa and Mac OS X, ...

So, I take it one would need two code bases?

Re:How compatitble

[TheRaven64]

No, Cocoa is almost a superset of OpenStep (with the exception of a couple of classes like NSDataLink that Apple ditched). We (GNUstep) track the changes from Cocoa and have done for the last ten years. We also track changes from iOS. For example, we have NSRegularExpression, which is only in iOS Foundation, not yet in OS X Foundation.

Re:How compatitble

[WrongSizeGlass]

So, I take it one would need two code bases?

Objective-C: All your code bases are belong to us

Re:How compatitble

[Daengbo]

I read this last night on Reddit, and have been chewing on it. I see this as a move to get mobile developers by piggy-backing on the Obj-C knowledge of iOS devs. Same language -- subset of API.

Re:How compatitble

[MrHanky]

The summary is (surprise!) wrong. GNUstep has been following Cocoa for a while. So says this guy.

Re:How compatitble

[DrXym]

If you track so closely, technically what's to stop GNUStep / LLVM being used as a platform to host and run iOS apps? Potentially GNUStep + LLVM could even find its way into Android or similar and provide a means for people to run iPhone apps on non-iPhone platforms.

Re:How compatitble

[Lucky75]

Same terrible language. I despise Objective-C with a passion. Give me good old C++ any day of the week. None of that gui driven development shit with Cocoa either.

Re:How compatitble

[Abcd1234]

Give me good old C++ any day of the week.

ROFL... yeah... nothing more to be said, really...

Re:How compatitble

[kohaku]

C++ it like a swiss army knife with a multitude of razor-sharp blades and attachments. It can do whatever you want to do, and it can do it pretty cleverly, but if you don't know the tool really, really well, you're going to end up missing fingers :D

Re:How compatitble

[olau]

C++ it like a swiss army knife with a multitude of razor-sharp blades and attachments. It can do whatever you want to do, and it can do it pretty cleverly, but if you don't know the tool really, really well, you're going to end up missing fingers :D

Fingers are overrated.

Re:How compatitble

[iluvcapra]

If you track so closely, technically what's to stop GNUStep / LLVM being used as a platform to host and run iOS apps?

Well, Apple's customer service policies and support agreement would stop it, for any commercial development anyways, but nothing "technically."

Re:How compatitble

[Graff]

If you track so closely, technically what's to stop GNUStep / LLVM being used as a platform to host and run iOS apps?

The only thing stopping this is the Cocoa (Cocoa Touch in the case of iOS) frameworks. They are analogous to the C++ STL but they are not free to use outside of an iOS device. Yes, you could still use them to create a binary and possibly run it on another device but you run the risk of a huge lawsuit if you do that. The GNUStep frameworks are coming along nicely and they can be used as an open-source alternative but you won't be able to take an app programmed using the Cocoa frameworks and simply compile it against the GNUStep frameworks without doing some re-working.

Even with that you can still make an app that uses the classes common to both the Cocoa and GNUStep frameworks and then has some platform-specific code in critical sections, then compile that app against either framework to create a binary that can run on multiple platforms. There are a few apps that do this kind of thing now and I expect that Sony's choice will greatly increase the numbers. It's a good time to be an Objective-C programmer.

Re:How compatitble

[fuzzyfuzzyfungus]

They aren't overrated; but they do have plenty of built-in redundancy...

Re:How compatitble

[jo42]

Idjit! That won't compile. Try:

[codeBases allYourAreWithBelongToUs:YES];

Re:How compatitble

[644bd346996]

If you're not a fan of "gui driven development", why are you commenting on an article about a framework for making GUIs for consumer electronics?

Re:How compatitble

[SuperKendall]

Fingers are overrated.

I typed this faster than you did.

Re:How compatitble

[ultranova]

Have you ever tried to actually do something with a Swiss army knife? Or any other knife with non-fixed blades? Sure, it's possible, but a bunch of special-purpose tools beat it hands-down every time. Which, I suppose, is a pretty good metaphor for C++ :).

Re:How compatitble

[iJed]

C++ is an incredibly powerful language but ObjC is also extremely capable. Cocoa (Touch) is simply the most productive framework that I have ever used. Yes, it has a pretty steep learning curve but once you get used to the Cocoa way of doing things you can produce excellent and rich GUI applications in a fraction of the time it takes in many other development environments that I've used. I work mostly in C# in my day job too...

Re:How compatitble

[HeronBlademaster]

Funny? More like Insightful :(

Objective-C has the most unreadable and unintuitive syntax of any language I've ever worked with, to say nothing of its memory management "best practices". What good do reference-counted pointers do me if I still have to manually release everything to avoid memory leaks? What good does its ability to mix C in with the Objective-C code do me when just mixing their two string types (NSString and char*) is a good way to make my program misbehave?

I can't help but conclude the language was built by a couple of guys saying "wouldn't it be cool if..." without thinking about the consequences. I'm baffled how the summary can claim this is "probably for the better".

Re:How compatitble

[node 3]

Funny? More like Insightful :(

Objective-C has the most unreadable and unintuitive syntax of any language I've ever worked with

What are you talking about? The example you call insightful is very readable. As for intuitiveness, I don't think any language is truly intuitive, but once you learn it, it's very easy to understand, just like any other language. I suspect you are more of a "get off my lawn" type who thinks things should be done the way you learned them and anything different is to be feared.

to say nothing of its memory management "best practices". What good do reference-counted pointers do me if I still have to manually release everything to avoid memory leaks?

renew/release isn't very difficult to understand, but if you can't keep up, Objective-C has garbage collection.

What good does its ability to mix C in with the Objective-C code do me when just mixing their two string types (NSString and char*) is a good way to make my program misbehave?

Objects != string pointers, and that's a problem for you? Seems like a fairly basic idea to grasp.

I can't help but conclude the language was built by a couple of guys saying "wouldn't it be cool if..."

You're referring to C (and that's not meant as a knock against C). Objective-C is a pretty awesome language, especially when coupled with quality frameworks like Cocoa.

I'm baffled how the summary can claim this is "probably for the better".

There is no shortage of developers who enjoy Objective-C and have had no trouble picking it up. Obj-C + Cocoa is very easy to develop with and leads to results very quickly and easily. This is a very smart move by Sony, and has potentially interesting implications for Linux in general. GNUstep is a pretty neat project.

Re:How compatitble

[Cinder6]

There are legitimate complaints of Objective-C (just as there are for all languages), but to say that its method syntax is unclear is...baffling. Let's see some random, naive method I just made up for Java. It will display a Window on a Screen at a certain location with fading. (I realize this isn't how you do it in Swing.)

screen.showWindow(window, 20, 20, 100, 200, true);

Here is the same thing in Objective-C:

[screen showWindow:window
                atX:20
                atY:20
              width:100
              height:200
                fade:YES];

Yes, it's longer. But unreadable? Hardly.

Re:How compatitble

[Cinder6]

Actually, yes, I do think it's better, especially from a readability standpoint. I find I don't need nearly as many reference windows open for Objective-C than I do for other languages. I will agree that function overloading can make editing easier/quicker, though, and it would be nice if Obj-C had it as an option.. To each his own.

As for Xcode, yeah, its autocomplete sucks. Xcode 4 is a lot nicer (or seemed to be during the brief time I checked it out). Too bad it's on developer preview still; I haven't even heard any news about when it's coming out. Last info I saw on it was from July.

Re:How compatitble

[HeronBlademaster]

What are you talking about? The example you call insightful is very readable.

It's the brackets and the "initWithThing:x otherThing:y" paradigm that I find unintuitive and difficult to read, most especially the "let's combine the method name with the name of its first parameter!" idea. Why did they throw out perfectly understandable function call syntax in favor of surrounding everything with brackets? I know they're trying to pretend they're sending "messages", but what they ended up with is virtually identical to the standard in C except in superficial syntax.

Why did they throw out C's perfectly readable struct-definition syntax in favor of this "@interface" and "@end" and "@property" nonsense?

Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.

Why do they use "+" and "-" for static methods vs instance methods? Did they really think "+" and "-" were more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?

Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?

None of these changes from C are for the better.

I will say that #import is an improvement over #include; I wish something similar had been adopted in C++. Still, tiny improvements like this do not offset the idiocy with which the rest of Objective-C was designed.

I suspect you are more of a "get off my lawn" type who thinks things should be done the way you learned them and anything different is to be feared.

I have used languages with widely varying syntaxes and design philosophies (I enjoyed working with Scheme, for example). I don't "fear" different ways of doing things; I do have opinions about which ways of doing things are stupid. Having a negative opinion about a specific language you like does not automatically mean I'm just shaking my bony fist in the air and shouting "get off my lawn".

Let me make myself clearer: what bothers me most about Objective-C is that it tries to pretend it's like C even while doing everything it can to be different from C without being so different that it can't have the C in its name anymore, all while retaining several of C's disadvantages and gaining very few of the advantages it claims.

renew/release isn't very difficult to understand, but if you can't keep up, Objective-C has garbage collection.

No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting. In other words, Objective-C gives you all the downsides of being forced to manage memory, combined with all the downsides of garbage collection.

(I realize garbage collection has advantages; however, by forcing you to manually handle reference counting, Objective-C negates those benefits by design. In other words, all Objective-C gains you is that instead of freeing your memory at predictable times, the garbage collector will come along at unpredictable times and slow down whatever it is your program is doing.)

Objects != string pointers, and that's a problem for you? Seems like a fairly basic idea to grasp.

It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!

Worse, by default, string constants in your code are char*s, not NSStrings! If you want your string constant to be an NSSt

Re:How compatitble

[Savage-Rabbit]

Have you ever tried to actually do something with a Swiss army knife? Or any other knife with non-fixed blades? Sure, it's possible, but a bunch of special-purpose tools beat it hands-down every time. Which, I suppose, is a pretty good metaphor for C++ :).

I have developed in both Objective C and C++ extensively and I have to say I massively prefer Objective C to C++ and I have come to regard the latter as the programming language equivalent of a car that has been run over by a tank (mind you if I was picking a language with ease of coding in mind I wouldn't pick either of them). When you pick apart the complaints you get from C++ devs. who try to develop in Objective C they often don't boil down to Objective C being a bad language. They whine about the fact that this that or the other thing doesn't work like it does in C++ which is not surprising due to Objective C having been influenced by SmallTalk which is way different from C/C++ in many ways.

Re:How compatitble

[doghouse41]

The beauty of a swiss army knife is that it can be always to hand (or in pocket). I could carry around a set of screwdrivers, knives, scissors, tweezers, toothpick, biro, bottle opener, allen keys and torx wrench. I could wear a pair of trousers with pockets large enough to accomodate all of these tools.

Then normal people would no doubt cross the road to avoid me!

Re:How compatitble

[willy_me]

Ok, this was hard to read. It appears that you do not really know anything about objectiveC.

Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.

But you do not have to have every class extend from NSObject - you can write your own. The ObjectiveC language manual is very small and even though I read it ~15 years ago, I still know this. They have a section dedicated to the topic. Did you not read it?

No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting. In other words, Objective-C gives you all the downsides of being forced to manage memory, combined with all the downsides of garbage collection.

Ok, ObjectiveC first got garbage collection in V2.0 - a very recent version. It has nothing to do with reference counting so I don't know what you are talking about in that respect.

Now reference counting has nothing to do with the ObjectiveC language. That's right, nothing. It is one of the reasons why all objects inherit from the NSObject object - that is where the reference counting takes place. It's part of the Cocoa/NextStep framework - not the language.

I could go on, but I'm not going to. You obviously know nothing about the language. Had your comments been negative and reflected that you were knowledgable about the language - then they would have been very insightful. But they are not because you are simply commenting on something that you do not know..

Re:How compatitble

[sznupi]

Would the last bit be a bad thing / anti-beauty?

Re:How compatitble

[shutdown -p now]

The problem with Objective-C is that it has a really low-level base language (C) with a really high-level object model on top of that (late-bound message passing) with nothing in between. It's a very strange combo where you can do things with objects that Java or C# programmers don't even dream of (due to the ability to intercept and handle any message on any object, for example), and yet where you can have a buffer overflow, or a million other ways of getting a segfault, just as easily as you can get with C.

Re:How compatitble

[shutdown -p now]

Just look at Java, which nowadays feels like you're working more with XML files than actual code.

@Not @Necessarily: @You @Can @Also @Screw @With @Actual @Code @Instead.

Re:How compatitble

[shutdown -p now]

Now reference counting has nothing to do with the ObjectiveC language. That's right, nothing. It is one of the reasons why all objects inherit from the NSObject object - that is where the reference counting takes place. It's part of the Cocoa/NextStep framework - not the language.

That's actually quite unfortunate. It would be much easier to manage memory in Objective-C if its object references were smart and did reference counting automatically as you mutate them (as they do in e.g. VB or Python, or shared_ptr in C++).

Re:How compatitble

[shutdown -p now]

I agree with some of your points (and don't much like Obj-C as a language), but others are incorrect.

Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.

You're only going to derive from NSObject when you're writing for Cocoa; it's not a magic base root class that's inherent to the language like java.lang.Object is in Java. It is perfectly possible to use Obj-C with something other than Cocoa, and then you'd have your own root class different from NSObject.

more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?

There's actually nothing particularly clear about the use of "static" modifier to mean class methods. That C++ made a mistake of doing that once in the past, also inventing the misnomer "static method" in the process, which has stuck since then, is a rather poor excuse. Back when Obj-C was designed, anyway, it was not anywhere as widespread as it is today.

I agree that the use of "+" and "-" rather than keywords is silly, though.

Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?

Huh? There's no such thing in C. All parameters are passed by value. Sure, you can pass an address of something (i.e. a pointer) by value. And hey, you can also do that in Obj-C!

Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting.

That is plainly not true. In fact, when you have tracing GC enabled in Objective-C, it doesn't even do reference counting on objects - any explicit "release" and "retain" messages will not even reach them. You do not need to "properly handle your reference counting" etc.

The only annoyance at the moment is that GC is not available on iOS.

It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!

Not any different from std::string or QString, then.

At the very least, they should have made the language automatically convert char*s to NSStrings, and vice versa, where necessary!

Well, that's a bit tricky in practice.

Implicit conversion from NSString to char* is unsafe because you don't know how that char* would be used. What if someone tries to write to it as if it's a buffer? If you give them pointer to internal NSString storage directly, then you can end up with an object in an inconsistent state pretty easily. If you allocate new storage and copy it over, then 1) it's quite expensive for an implicit operation, and 2) who's going to free it, and how do they know they need to?

An implicit conversion from char* to NSString has the same problem of object ownership, but that is moot when GC is there.

Re:How compatitble

[HeronBlademaster]

But you do not have to have every class extend from NSObject - you can write your own.

I didn't say you have to, I said you'd never not want to. (Would you argue less if I said "extremely rarely"?)

Ok, ObjectiveC first got garbage collection in V2.0 - a very recent version. It has nothing to do with reference counting so I don't know what you are talking about in that respect.

Wikipedia indicates otherwise:

When run in backwards-compatible mode, the runtime turns reference counting operations such as "retain" and "release" into no-ops.

If reference counting were unrelated to the language's garbage collection, there would be no need to turn "retain" and "release" into no-ops, so clearly they are not unrelated. (The Wikipedia statement implies that they conflict with each other.)

At any rate, I did indeed misunderstand Objective-C's memory management - there was not and is not a garbage collector in the version of Objective-C in use on iOS devices.

However, I maintain that the memory management practices enforced by Objective-C (or, if you prefer, the NextStep framework that Objective-C's compiler assumes you are using) are unintuitive and difficult to use. (Not reference counting itself, but the fact that various APIs and @property tags are inconsistent about which things retain objects and which things don't. It's not fun having your program crash because you assumed a built in collection object would retain your object, but it didn't, even though other similar objects in the same framework do retain things you give them.)

It is one of the reasons why all objects inherit from the NSObject object - that is where the reference counting takes place. It's part of the Cocoa/NextStep framework - not the language.

That's not entirely true. As I mentioned before, prefixing your string constants with @ turns the string constant into an NSString, so clearly the compiler assumes that at least some portion of the NextStep framework is available.

You cannot say "it's not part of the language" if the syntax of the language itself transforms something into an object in that framework.

Re:How compatitble

[node 3]

None of these changes from C are for the better.

All of those changes you are bitching about (aside from the method naming scheme) are in order to stay compatible with pure C. And they are fairly silly complaints. You learn the syntax of a language, and as far as such things go, Objective-C is pretty easy to grasp.

On the topic of method names, you can call them whatever you want. Cocoa just happens to have a specific style which is really easy to understand. It's almost self-documenting in its simplicity.

No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero.

Um... This is not true. If you use garbage collection, you don't have to retain/release.

It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!

You're confusing Cocoa and Objective-C.

Cocoa might be a quality framework, I don't know; Xcode is such a failure of an IDE that I'll never be able to tell, and I can't force myself to endure Objective-C long enough to try building an application with Cocoa entirely in code.

Surely you're just trolling here. Xcode isn't even remotely a "failure of an IDE". There are definitely other IDEs out there that some people like better than Xcode, but it's a damn fine IDE. The current beta is even better, albeit too buggy at this time.

Re:How compatitble

[jonwil]

You could always produce a source-level compatible implementation of Coca Touch and the iOS APIs that uses nothing thats (c) Apple (after all, you cant copyright an API otherwise WINE would have been shut down years ago) to allow code to be written for iOS and then recompiled using translation libraries to run on other platforms.

Re:How compatitble

[Graff]

You could always produce a source-level compatible implementation of Coca Touch and the iOS APIs that uses nothing thats (c) Apple

Right, that's basically what GNUStep is - an open source implementation of the original OpenStep frameworks plus some of the newer stuff in Cocoa. It's a pretty big effort to duplicate the major parts of Cocoa Touch though, it's taken the GNUStep people a lot of time and effort to get where they are now and they still have a ways to go.

Overall I'd say the best path is to contribute toward GNUStep and produce a branch that tracks Cocoa Touch.

Re:How compatitble

[superdana]

I know they're trying to pretend they're sending "messages", but what they ended up with is virtually identical to the standard in C except in superficial syntax.

They're not pretending, and the difference is anything but superficial. Messages are dispatched and resolved at runtime. Go disassemble a program written in Objective-C if you don't believe me. The object and the message name are pushed onto the stack and then the Objective-C dispatcher is invoked.

Re:How compatitble

[willy_me]

But you do not have to have every class extend from NSObject - you can write your own.

I didn't say you have to, I said you'd never not want to.

Your words: "Why do you have to manually derive all interfaces as children of NSObject?"

If reference counting were unrelated to the language's garbage collection, there would be no need to turn "retain" and "release" into no-ops, so clearly they are not unrelated.

Well, you generally do not want to release memory twice - hence the reason why the garbage collector messes with the retains/releases - this is the extent of their relation. The methods actually used by the garbage collector are of little significance and would likely change if a better method is found. All I know for certain is that it does not use reference counting to get the job done.

but the fact that various APIs and @property tags are inconsistent about which things retain objects and which things don't

Fair enough, I also had this problem in the beginning. Once you figure it out you find that it is very intuitive and fully documented.

prefixing your string constants with @ turns the string constant into an NSString, so clearly the compiler assumes that at least some portion of the NextStep framework is available.

You are assuming that when you import Cocoa/Cocoa.h you are not setting a pile of macros that take care of this for you. Try looking at the examples in the wiki link you provided. You will see that they do not prefix strings with the '@' character and they compile fine without the Cocoa/GNUStep frameworks. In fact, gcc (the same version that is used by Apple) would fail if it saw a '@' in front of a string - but it is still Objective-C.

It appears that you are confusing the language with the framework.

Re:How compatitble

[HeronBlademaster]

I'm willing to admit that my impression of Objective-C is colored by Cocoa's... quirks. It's entirely possible that the resulting judgement is unfair to the language.

I've obviously misunderstood Objective-C's memory management. I also obviously wasn't clear on how exactly parameter passing works in Objective-C; this is partially due to confusion about when library functions affect reference counts and when they don't, which @property settings do what and how, as well as what is (in my opinion) unclear method definition syntax. Misunderstandings feed misunderstandings.

I should also point out that I am rather annoyed by the C++ STL's inconsistency with respect to std::string vs char*.

Re:How compatitble

[shutdown -p now]

I also obviously wasn't clear on how exactly parameter passing works in Objective-C; this is partially due to confusion about when library functions affect reference counts and when they don't, which @property settings do what and how, as well as what is (in my opinion) unclear method definition syntax.

It's actually pretty simple: parameter passing in Obj-C is exactly the same as parameter passing in C. Note that reference counting and other Obj-C quirks have absolutely nothing to do with all this, because they operate on objects, but what is passed as function arguments, stored in variables etc are object references ("identifiers" in Obj-C parlance). This is similar to various resource management schemes imposed by various C libraries (such as Gtk), where you still pass raw pointers around, but have to use special foo_release, foo_addref/release etc functions to manage them as you do.

I should also point out that I am rather annoyed by the C++ STL's inconsistency with respect to std::string vs char*.

It's there for the same reason: there's simply no safe way to do implicit conversions from std::string to char*, because char* can be anything and everything, not just string; and even for a string you don't know if it's intended to be read from or written to. It's just a quirk of C approach to strings, where they are not really values. You can have a single null-terminated char array, and a bunch of pointers within it, and they're all different strings despite (partially) sharing storage. Again, a value here is a particular char*, but it's not a string - just a pointer to some data that may (or may not) be interpreted as a string. If you copy the char* around, you're just copying a pointer.

Note how std::string does have an implicit conversion from char* which you can use. That's because, unlike Obj-C, C++ has the concept of temporary objects complete with well-defined ownership and lifetime semantics for them, so that conversion is safe to use in any context.

Re:How compatitble

[HeronBlademaster]

Yes, I seem to have been conflating Cocoa and Objective-C; hopefully that's understandable given that using the two together has been the most common use of the language.

You learn the syntax of a language, and as far as such things go, Objective-C is pretty easy to grasp.

We'll just have to disagree, here, because my point is precisely that I find Objective-C's additional syntax rules to be unintuitive and unclear. I found Scheme far easier to learn, even coming from a C++ background as I was.

Surely you're just trolling here. Xcode isn't even remotely a "failure of an IDE". There are definitely other IDEs out there that some people like better than Xcode, but it's a damn fine IDE.

No, not trolling, just expressing an opinion based on the month I spent fighting with it. Couple of glaring problems off the top of my head:

- Code completion (its attempt at Intellisense) is horribly broken, *especially* for Objective-C code. This is unacceptable for a modern IDE.
- There are two file browsing panes. The pane on top only includes the files selected in the left pane. WTF?
- If you double-click a file in a file browsing pane, Xcode is inconsistent about when it opens the file in the existing code window and when it opens a separate window.
- The UI editor is an entirely separate program. WTF?
- Deleting a file from the project does not omit it from the compilation process unless you also delete it from disk. If this results in compilation errors, the IDE gives you no indication of where the error occurred other than the compiler output. WTF?

Apple claims that Xcode is what Apple's programmers use for their own software. I'm torn between pitying them for being stuck with this crap, and admiring them for what they have accomplished despite it.

Re:How compatitble

[HeronBlademaster]

Fair enough. But why they think it's better to do that at runtime instead of compile-time is beyond me. Imagine if Java used reflection for every method call... sure, reflection is useful in some cases, but it's hardly a good idea to use it everywhere.

IMO it would have been far better to use standard function calls except where necessary. Using messages for getters and setters is not necessary, and only introduces more potential for bugs. This is especially true given that Objective-C supports standard function calls, so it would not have been difficult to do this instead.

Re:How compatitble

[HeronBlademaster]

Sorry, I don't see how APIs being inconsistent would ever become intuitive, and no amount of documentation is an excuse for inconsistency.

Yes, I have indeed conflated the language and Cocoa. This is perhaps unfair to the language. But when Cocoa is by far the most common framework used with this language, can you really fault me for the mistake? (Not saying I wasn't wrong to do so, just that it's hopefully an understandable error.)

However, one specific complaint (using "+" and "-" as keywords in method definitions) is enough to make me choose another language (any other language!) if given a choice. Neither of those keywords is remotely intuitive in meaning. (Just because you can learn the meanings does not mean those meanings are intuitive.)

Re:How compatitble

[HeronBlademaster]

stored in variables etc are object references ("identifiers" in Obj-C parlance)

See this is what I mean. We already had a word for that: pointers! Objective-C feels like it's trying to be different from C even when it's really not. Is it any wonder I find it confusing?

I suppose an apology is in order; I should not have been so vehement about Objective-C when in reality I both misunderstood the language and blamed the language for the (perceived) failings of one framework.

This is similar to various resource management schemes imposed by various C libraries (such as Gtk), where you still pass raw pointers around, but have to use special foo_release, foo_addref/release etc functions to manage them as you do.

Something being common does not necessarily mean that thing is good ;) People use smart_ptr in C++ for a reason.

I understand the semantic difference between std::string and [const] char*, and why they're not implicitly convertible to each other. (Well, char* is implicitly convertible to std::string, but only because of a std::string constructor.) I'm still allowed to be annoyed by it ;) It seems silly to provide two standard types of strings which are just incompatible enough to be annoying, yet not so incompatible that you decide to stick with just one...

This is getting off-topic, but std::string feels like the ugly cousin nobody wants to play with when I use it with the rest of the STL. For example, ifstream's open() doesn't provide a const std::string& overload for passing the filename. Calling c_str() on my strings all the time gets old.

As another example, the "right" way to read strings that may contain whitespace into a std::string with istreams, by calling getline(is, str), is not compatible with the "right" way to read other values from istreams (the >> operator). You can't use both methods without manually resetting flags on the stream when switching methods.

The inverse is not true - for ostreams, the << operator is the "right" method for all types.

I like C++, but there are things about it I find quite frustrating.

Re:How compatitble

[HeronBlademaster]

you should know that trying to handle primitive data types and objects in the same way is a big no-no.

One could argue that string should be a primitive data type.

Re:How compatitble

[shutdown -p now]

See this is what I mean. We already had a word for that: pointers! Objective-C feels like it's trying to be different from C even when it's really not.

In this case they actually have a point, because an object identifier doesn't have to be a pointer, even though it often is. E.g. all of those are object references/identifiers:

NSObject *o1;
id o2;
id<Foo, Bar> o3;

However, only the first is a pointer doubling as a reference - the other two are effectively opaque handles. Why "id" and not "ref" though is beyond me.

Something being common does not necessarily mean that thing is good ;) People use smart_ptr in C++ for a reason.

Well, it's okay in C because you can't really writeauto_ptr or shared_ptr in C. Technically, the same argument also applies to Objective-C, since the language isn't expressive enough to implement simple scoped or reference-counting smart pointers as a library. But since it's being positioned as a high-level language, I'd certainly count it as a flaw. Well, no matter, since they took care of that one with a proper tracing GC, anyway.

This is getting off-topic, but std::string feels like the ugly cousin nobody wants to play with when I use it with the rest of the STL. For example, ifstream's open() doesn't provide a const std::string& overload for passing the filename. Calling c_str() on my strings all the time gets old.

I agree that it's annoying, but it's actually a deliberate design decision - the "don't use what you don't pay for" rule. Though they fucked it up, IMO. In this particular case, it was either have iostreams provide API for (and therefore depend on) std::string, or have strings provide API for iostreams. In the first scenario, you can't use iostreams without using std::string; in the second, you can't use std::string without iostreams. For some reason the committee decided that streams are more important, and therefore should get the benefit of, ahem, having no strings attached.

As another example, the "right" way to read strings that may contain whitespace into a std::string with istreams, by calling getline(is, str), is not compatible with the "right" way to read other values from istreams (the >> operator). You can't use both methods without manually resetting flags on the stream when switching methods.

Well, getline also exists for char arrays as well. It definitely looks inconsistent on the surface, but actually isn't - << is defined as an operator that reads values (regardless of type) up to the next current delimiter. It does just that for strings too; it just so happens that for strings it's usually not what you want, unlike with other stuff. Of course, for output, there's no such distinction.

Come to think of it, it's not really different from printf vs scanf/fgets when it comes to "%s".

I like C++, but there are things about it I find quite frustrating.

My old-time favorite is a naive attempt to compute an average value of a vector:

int a[3] = { -1, 2, -3 };
std::vector<int> v(&a[0], &a[3]);
int x = std::accumulate(v) / v.size();
std::cout << x;

Can you spot the problem? If no, try running it. It's not really a C++-specific thing, but I find that it's far more common to get tripped by that in C++ because of heavier use of library constructs over manually coded loops and such.

Re:How compatitble

[Anonymous Coward]

> Cocoa might be a quality framework, I don't know;
Why not?

> Xcode is such a failure of an IDE that I'll never be able to tell
What?

> and I can't force myself to endure Objective-C long enough to try building an application with Cocoa entirely in code.
Giving zero credibility to this rant.

Re:How compatitble

[SteeldrivingJon]

"If reference counting were unrelated to the language's garbage collection, there would be no need to turn "retain" and "release" into no-ops, so clearly they are not unrelated. (The Wikipedia statement implies that they conflict with each other.)"

No. This is for when you take a pre-GC app and build it to use GC. You don't have to go through your old code and remove the retains and releases. They just become no-ops because they're irrelevant under GC. That's all the "backward compatibility" means.

Re:How compatitble

[SteeldrivingJon]

"I know they did that for compatibility with C, but that just makes it even more obvious that they should have made their stuff compatible with char*"

They just switched from char*'s everywhere to NSString when they went from NeXTSTEP to OpenStep.

If you want convenience methods for working with char *, write some freaking Categories.

Re:How compatitble

[SteeldrivingJon]

"using the 'static' keyword that was already in the language?"

Are you aware that classes in Objective-C are objects in their own right, and not just something munged onto file scope with a static keyword?

Re:How compatitble

[jeremyp]

OK so you have a problem with your ability to learn Objective-C syntax. But that's your problem not the language's. Your criticisms stem from your ignorance of the language rather than anything legitimate, so if I were you I'd shut up now. Everybody who programs in the language thinks you are an ignorant twat.

Re:How compatitble

[tehcyder]

C++ it like a swiss army knife with a multitude of razor-sharp blades and attachments. It can do whatever you want to do, and it can do it pretty cleverly, but if you don't know the tool really, really well, you're going to end up missing fingers :D

If you don't know your tools really, really well, you are not really a professional user.

Re:How compatitble

[tehcyder]

Have you ever tried to actually do something with a Swiss army knife? Or any other knife with non-fixed blades? Sure, it's possible, but a bunch of special-purpose tools beat it hands-down every time.

Well, yes, obviously. That's like saying that a Leatherman isn't as good as carrying around a pair of needlenosed pliers, a pair of ordinarya wirecutter, a penknife, a serrated blade knife, a wood-saw, a hacksaw, two screwdrivers, a socket set, a can opener, a bottle opener, a pair of scissors, a metal file or whatever.

Re:How compatitble

[jeremyp]

It's called polymorphism. What happens when an object is sent the message depends only on that object and being able to change its behaviour at run time allows some pretty powerful features. For instance, there's a feature of Cocoa called Key Value observing which allows an object to monitor a property on another object and be sent a message when the property changes. And this requires no special programming in the observed property.

There's also a language feature called a category which allows you to add methods to existing classes at run time. So, for instance, Cocoa has no support for JSON, but you can add methods to the NSDictionary and NSArray classes to get them to write themselves out as a JSON string and you can add a method to the NSString class to get it to parse itself as a JSON string.

The dynamic binding comes at a cost. It's quite a bit slower to send a message in Objective-C than to make a function call, but if performance becomes an issue you can drop back to C function calls.

Re:How compatitble

[jeremyp]

Objective-C does not have named parameters, it interleaves the parameters with the method name. So in the above example, the method name (or selector to use the correct terminology) is showWindow:atX:atY:width:height:fade: This is different to showWindow:atY:atX:width:height:fade: which it wouldn't be if Objective-C had named parameters.

Re:How compatitble

[Builder]

I have to do a lot with a swiss army knife because in the UK it is illegal to carry a leatherman in public without a good reason that the police will accept.

I've got several small scars as a result of keeping the world safe from knife crime :(

Re:How compatitble

[Builder]

Sounds to me like you want a leatherman then. All the features of a swiss army knife, but with locking blades.

Unless you live in the UK where you can get a 5 year jail sentence for carrying one. But they don't tell you THAT in the store when you buy it.

Re:How compatitble

[HeronBlademaster]

Integer division is always a fun unintentional bug.

Re:How compatitble

[UnknowingFool]

You could argue that but considering that no language remotely related to C has string as a primitive, you'd be very alone. For the most part, true primitives are only included in a few languages. Smalltalk which most OOP languages are derived considers primitives as objects. Java is one of the few languages that has true primitives, and not even Java has string as a primitive. Strings are objects in Java. The most serious problem with strings as primitives is that strings do not have a fixed size. True primitives have fixed sizes.

Re:How compatitble

[HeronBlademaster]

> Cocoa might be a quality framework, I don't know;
Why not?

The second half of that sentence answers that question... I'm surprised you didn't see it, considering you quoted it next. Since apparently I was unclear I'll restate: Xcode is such a failure of an IDE that it gets in the way of everything, including learning Cocoa, and therefore I will never know whether Cocoa is a decent framework.

I doubt I will ever find myself in a situation where I would need to use Cocoa without needing to use Xcode as well.

> Xcode is such a failure of an IDE that I'll never be able to tell
What?

I answered this question here.

> and I can't force myself to endure Objective-C long enough to try building an application with Cocoa entirely in code.
Giving zero credibility to this rant.

So my comments are not credible merely because I do not want to subject myself to more of the language I find distasteful?

Suppose you hate pineapple for various reasons, so you make the statement that you will never know whether pineapple upside-down cake is good enough that you wouldn't mind the pineapple because you can't make yourself eat it knowing there's pineapple in it. Such a statement would not remove your credibility regarding the reasons for your dislike of pineapple.

Re:How compatitble

[shutdown -p now]

In this case the truncating division is intentional, and not a bug (it's quite often that truncating gives result that is close enough, and integer division is faster).

A bug is caused by the fact that v.size() is unsigned integer, while vector is of signed integers. Consequently, the expression boils down to -2 / 3u. And by C/C++ rules for mixed signed/unsigned arithmetic, signed types are converted to unsigned, and the result is consequently also unsigned. Thus in practice we're computing 0xFFFFFFFEu / 3u (assuming 32-bit int). Then it is silently cast back to int, giving a large positive number rather than the expected 0.

Re:How compatitble

[HeronBlademaster]

Yes, I am aware. I was more referring to the meaning behind what "+" and "-" are assigning to the methods.

In C++ terms, "+" makes the method a static member function, and "-" makes the method an instance member function.

Now, I didn't mean to say that they should have specifically used that keyword, I only showed it as a suggestion. My point was that "+" and "-" are about as unclear as you can possibly be, and it makes absolutely no sense that they did not add new keywords for the purpose.

Re:How compatitble

[HeronBlademaster]

Don't most compilers warn you if you do signed/unsigned arithmetic? I'm pretty sure gcc does, at least with -Wall...

Re:How compatitble

[shutdown -p now]

Don't most compilers warn you if you do signed/unsigned arithmetic? I'm pretty sure gcc does, at least with -Wall...

I'm not sure about -Wall, but it certainly doesn't do so with default settings, and neither does VC++.

Thing is, though, such mixed arithmetic is quite common in practice, simply because most "size-like" quantities in libraries etc are unsigned, while most other values are signed. A good example of a pair which often goes together but which has signed/unsigned mismatch is size_t and ptrdiff_t. So a warning like that will give a lot of false positives.

On the other hand, the problem is actually more broad than just mixed arithmetic. It is also entirely possible to write something as simple as (a-b), where both a and b are unsigned (e.g. size() of two different vectors), and get a result which may be unexpected to some. Especially when you don't expect "a" and "b" to be unsigned in the first place!

As an interesting side note - this problem is one of the major reasons why in C# (which also has both signed and unsigned types, unlike Java), API design guidelines dictate that plain (signed) int is to be used for quantities even when the contract specifies them to be always nonnegative, such as String.Length or ICollection.Count. Unsigned types are relegated to bit twiddling, structs which directly represent on-disk or on-wire data structures, and interop with C.

Re:How compatitble

[willy_me]

Sorry, I don't see how APIs being inconsistent would ever become intuitive, and no amount of documentation is an excuse for inconsistency.

I did not say it was inconsistent. If fact, it is very consistent. You just have to understand the reasoning behind it - and that takes time and practice. The same can be said for any API.

Yes, I have indeed conflated the language and Cocoa. This is perhaps unfair to the language. But when Cocoa is by far the most common framework used with this language, can you really fault me for the mistake? (Not saying I wasn't wrong to do so, just that it's hopefully an understandable error.)

Yes, it is an understandable error - and yes, it is your fault. If you are making such an error then you obviously lack the experience required to make comments about the language/framework. You do not understand it - fine, I'm sure you are good at plenty of other things.

However, one specific complaint (using "+" and "-" as keywords in method definitions) is enough to make me choose another language (any other language!) if given a choice. Neither of those keywords is remotely intuitive in meaning.

Actually, this is one of the things that I like about the language. Object method calls and Class method calls are distinct. This lends to separating object allocation and initialization routines - hell of a lot better then C++ (in my opinion). If anything, it makes things more intuitive - not less. But anyway, if you do not see this then you lack experience in the language. You are likely approaching it from a C++ perspective - ObjC is not C++.

So learn the language if you want to make meaningful comments. As it stands, your comments were... painful. Do not be surprised if people correct you if you make erroneous statements.

Re:How compatitble

[HeronBlademaster]

I didn't mean the distinction between class and instance methods is unintuitive, I meant the keywords themselves are unintuitive. What could possibly be intuitive about "+" meaning a class method, or "-" meaning an instance method?

Perhaps "intuitive" does not mean what you think it means. The meaning of "int" is intuitive. The meaning of "+" in front of a method definition is not.

Re:How compatitble

[HeronBlademaster]

It's clearer than "+".

Re:How compatitble

[TheRaven64]

Currently, the fact that we don't have an implementation of the UIKit framework from Cocoa Touch. Now that Cairo supports Skia as a back end, we can do an Android port pretty easily, and we've supported porting OS X apps to handheld devices for a while (one of our devs is active with OpenMoko and runs GNUstep apps on his OpenMoko phone).

Fortunately, about 80% of UIKit is AppKit-lite, so implementing that stuff should just be a matter of refactoring our existing AppKit implementation. The rest is new (they improved the responder chain a bit, and added some new event types, for example), but I suspect that many of these changes will make their way to the desktop eventually, so we'll have to implement them sooner or later.

LLVM is only tangentially relevant. Clang is currently the only Objective-C compiler that supports Objective-C 2 features with GNUstep, but there's no reason that it should remain so. If the GCC guys want to stop ignoring Objective-C, they could support the new stuff too.

Re:How compatitble

[HeronBlademaster]

I question several of the ways things are done in C/C++. That doesn't mean I can't like the languages, nor does not mentioning those things here mean I'm not allowed to question some of the things Objective-C does.

Re:How compatitble

[Anonymous Coward]

1. That's NOT was polymorphism is. An object does not change its behavior. Different objects have different behavior using a common interface.
2. Dynamic binding is NOT "quite a bit slower." The cost is simply that of two function calls, which is negligible in most cases.

Re:How compatitble

[badkarmadayaccount]

Sounds like something to do while high, and submit to a underhanded programming contest - see what they find out that you didn't know.

Re:How compatitble

[badkarmadayaccount]

I carry all of the above, you insensitive clod! (No, seriously, I'm pretty close.

Re:How compatitble

[badkarmadayaccount]

How does it compare to Qt?

Apple's response?

[symes]

It will be interesting to see if Apple respond to this and how. My feeling is that they might try and protect their assets and restrict developers' options. I haven't really thught this through but I just can't see Apple letting people develop apps for iPads and then recycling ostensibly the same code for some Sony gadget. It is not in their nature.

Re:Apple's response?

[RedK]

The OpenStep specification is... well, Open. What can Apple do ? They don't hold rights that are being infringed here.

Re:Apple's response?

[yabos]

I don't see why. OpenStep has been around for a long time. Obviously they don't have all the same APIs for the UIKit that Apple has but a lot of code could be shared since they implement a lot of the same classes.

Re:Apple's response?

[lurch_mojoff]

Apple don't have to do squat to prevent iPad apps form being "recycled" on a Sony gadget - there are more than enough differences that cannot easily be compensated between this Sony platform and iOS for this to even be a possibility. For example Sony will be using Cairo instead of Apple's Quartz, so any drawing code in an app will have to be rewritten. Also GNUstep does not implement UIKit at all. It doesn't even mimic AppKit all that well. And reverse engineering and achieving parity with either framework is a gargantuan task. So any UI code in an app will also need to be rewritten, or at least significantly modified, at which point you might as well rewrite the whole application in an entirely different language/framework.

Re:Apple's response?

[Bill_the_Engineer]

Well actually they do, but they wanted it "open". Apple also owns the rights to Obj-C and they still support its inclusion in gcc.

Re:Apple's response?

[countertrolling]

Combining efforts to write a better DRM.. If there was any conflict over assets, I'm sure an agreement of sorts has been, or soon will be reached

Re:Apple's response?

[DrXym]

This is more or less their philosophy. Look at their attempts to squash scripting languages, runtimes & browsers on iOS. There is absolutely zero technical reason for this, it's all to force developers to code to Apple's APIs. The last thing they want is for apps to become heterogenous so they do everything in their power to prevent that happening starting with making devs choose which platform to sink their efforts into.

Superficially this is a good strategy but things can easily swing the other way. After all Android is here and takes virtually the opposite approach. It's quite likely in a few years that Apple will be playing second banana to Android and it will be they who are waiting for apps to get ported.

Re:Apple's response?

[tlhIngan]

It will be interesting to see if Apple respond to this and how. My feeling is that they might try and protect their assets and restrict developers' options. I haven't really thught this through but I just can't see Apple letting people develop apps for iPads and then recycling ostensibly the same code for some Sony gadget. It is not in their nature.

Why should Apple be worried? It enhances both ecosystems. People who want to develop for Sony's platform exclusively still need Objective-C developers, and those developers can turn around and write MacOS X and iOS apps as well, enhancing Apple's platforms on the market.

Apple knows they need developers, which is why they threw in the developer tools for free with every Mac. Sony also validates Obj-C as a useful language and that can easily bring in more developers, who after writing apps for the Sony device may decide to re-use their skills on MacOS X and iOS, enhance both ecosystems. In the short term it'll hurt a bit as Obj-C devs get poached by Sony but that'll just bring new entrants into the field.

Right now, other than iOS and MacOS X, development with Obj-C is very minimal. But having two major players in it can entire others to use Obj-C, and hey, they too can develop for MacOS X or iOS. Provided Sony doesn't screw it up too badly.

Re:Apple's response?

[benbean]

There is absolutely zero technical reason for this, it's all to force developers to code to Apple's APIs.

One technical reason for this is to make sure that everybody is on the same playing field when it comes to things like architecture changes.

If you know anything about Apple history, they have been able to make successful transitions between chipsets on more than one occasion. By requiring everybody to use the same development tools, any significant architecture changes are just a recompile away in an updated Xcode.

Just one of several reasons, along with UI consistency and performance amongst others, but one of the most important.

Re:Apple's response?

[ToasterMonkey]

It will be interesting to see if Apple respond to this and how. My feeling is that they might try and protect their assets and restrict developers' options. I haven't really thught this through but I just can't see Apple letting people develop apps for iPads and then recycling ostensibly the same code for some Sony gadget. It is not in their nature.

None of what you said makes any damned sense, but yah.. +1 interesting in the same way a crazy naked man screaming "the end of the world is near!" is I suppose.

BTW, the language & frameworks that iPad apps are built on is the same environment that most OS X apps are built on.

Not to say there shouldn't be any concerns, but Sony is a big boy with more lawyers than people reading this post...

Re:Apple's response?

[codegen]

Apple also owns the rights to Obj-C

???? Obj-C was created by Brad Cox in the early 80s. Next licensed the trademark from StepStone. GCC has had an objective C compiler in it (as described by Cox) since the early 90s. As it is, the compiler used by Apple is the GCC compiler with some extra features such as properties (which have been released as gpl and are available for download from apples website). With the exception of trademarks and patents on an implementation, you can't own a language. Anyone can build a compiler for the same language with a different name (with exception of patented parts of implementation which is less certain with Bilski).

Re:Apple's response?

[chartreuse]

This is more or less their philosophy. Look at their attempts to squash scripting languages, runtimes & browsers on iOS. There is absolutely zero technical reason for this, it's all to force developers to code to Apple's APIs.

I really doubt you are correct in this. Though the hardware resources available to iDevices are orders of magnitude greater than, say, the original Mac, it's still very easy to bring the CPU to its knees with an ill-chosen line or two of code, and the introduction of even limited multitasking just makes it easier.

I'm not saying there are "absolutely zero" politico-corporate reasons for Apple's decisions in this area, and I can empathize about disliking the tradeoffs in autonomy for iOS developers (the Mac is much less restrictive, and free once you have the hardware), but Apple's had to do a lot of software optimization to assure a reasonable user experience (responsiveness, battery life, etc), and "bare-metal" runtimes that don't work through the public APIs aren't likely to benefit.

You may well be right about Android. Otoh Apple will probably be happy just to skim most of the profits from the smartphone/tablet market as they do now. Both approaches are useful, pick the one that meets your needs.

Re:Apple's response?

[node 3]

It will be interesting to see if Apple respond to this and how. My feeling is that they might try and protect their assets and restrict developers' options.

They aren't going to do a damned thing. Not only is there nothing effective for them to do, they have no reason to. Slashdot's anti-Apple paranoia is not an actual reason.

I haven't really thught this through

Clearly.

but I just can't see Apple letting people develop apps for iPads and then recycling ostensibly the same code for some Sony gadget. It is not in their nature.

You do not understand Apple's nature. They want to control the quality of their own products. They generally don't give a shit about other's products and in fact host plenty of open source projects that help the competition.

Re:Apple's response?

[ChunderDownunder]

cloning cocoa is no different to haiku, mono, classpath, linux, reactos or wine. i.e. foss clean-room implementations give lawyers no ammo.
The spectre of patents is the elephant in the room but Jobs would watch the Larry vs the Android battle before attacking Sony.
The most likely action would be a clause in the iOS developer agreement that you target only Apple devices. Sounds pretty anticompetitive to me but i'm sure Sony would challenge that.

Re:Apple's response?

[benbean]

Hmm, got logged out there. I'll try that again:

6502 -> Mototola 68k -> PowerPC -> Intel.

Re:Apple's response?

[DrXym]

One technical reason for this is to make sure that everybody is on the same playing field when it comes to things like architecture changes.

That doesn't make any difference. Flash (for example) would still be coded over the top of whatever APIs iOS exposes. If architecture undert those APIs changes then you're talking about a recompile at most. But since iOS apps are compiled to LLVM byte code, the chances are it wouldn't even need that.

Re:Apple's response?

[Draek]

If that were the case they'd go the *other* way, include a solid scripting language or runtime by default and push the hell out of it over anything that compiles to an architecture-dependant binary.

You know, like Google does with Java on Android.

Re:Apple's response?

[sznupi]

Did we already forget how Apple tried to ban, this year, the use of languages not blessed by them and of middleware targeting also iOS?

Re:Apple's response?

[tyrione]

Apple also owns the rights to Obj-C

???? Obj-C was created by Brad Cox in the early 80s. Next licensed the trademark from StepStone. GCC has had an objective C compiler in it (as described by Cox) since the early 90s. As it is, the compiler used by Apple is the GCC compiler with some extra features such as properties (which have been released as gpl and are available for download from apples website). With the exception of trademarks and patents on an implementation, you can't own a language. Anyone can build a compiler for the same language with a different name (with exception of patented parts of implementation which is less certain with Bilski).

NeXT bought sole rights to all the IP for Objective-C in 1995. Apple acquired this ownership with the purchase of NeXT.

Re:Apple's response?

[codegen]

What IP? A particular implementation of a compiler and a trademark. You can't copyright a language, just like you can't copyright a recipe. If I take the language spec and independently implement a new compiler (like the gnu folks did) then there is no problem. In the US, you can patent some parts of an implementation, but any such patents on Objective C ran out a long time ago.

Re:Apple's response?

[benbean]

Then you would have performance issues, particularly for games.

Re:Apple's response?

[bonch]

Developing for the iPad requires using UIKit, which is built on the Cocoa foundations that GNUStep adheres to an older version of (OpenStep). You're not going to be able to simply copy over the code for a project.

Re:Apple's response?

[SteeldrivingJon]

"You're not going to be able to simply copy over the code for a project."

You'd be able to copy over non-UI code.

Another benefit, though, is that iPhone code and GNUStep code will follow similar design patterns and idioms, use similar collection classes, similar ways of storing user defaults, a similar notification model, etc.

Porting a game from iOS to GNUStep will thus be similar to porting from iOS to Mac OS X (CocoaTouch to Cocoa).

Re:Apple's response?

[Bill_the_Engineer]

Another poster already pointed out that NeXT purchased all the rights for ObjC in 1995.

While any IP on ObjC 1.0 has most certainly expired, Apple continues to support the language (and seems the main supporter). Apple did a language refresh with v. 2.0 last year.

Bill Cox did invent the language but, according to his bio, has moved on to using XML, Java, Ruby, and Perl as his primary languages.

Who does what?

[clickclickdrone]

The world continues to chase apple -- probably for the better

Or more accurately, One foreign company adopts a compiler.

For the better?

[Xest]

"The world continues to chase apple -- probably for the better."

lol, did someone really just say that in the context of Objective-C? For all the things Apple has done right and does well, clinging on to Objective-C is not one of them.

Re:For the better?

[WrongSizeGlass]

Indeed. I've worked with Objective-C on and off since the pre-OS X 'Rhapsody' days. It's almost like a cruel mix of coding, texting and writing documentation ... all that plus a touch of COBOL's verbosity with a syntax/grammar nazi in its heart. After a while you just want to look a blank screen.

Re:For the better?

[CODiNE]

I'm no expert on languages, but doesn't Objective-C deliver on what it's intended to be? A light-weight object oriented extension to C without all the extra stuff that makes C++ difficult to use?

Also doesn't it's dynamic runtime stuff allow certain things that C++ doesn't?

Re:For the better?

[thenextstevejobs]

For all the things Apple has done right and does well, clinging on to Objective-C is not one of them.

It'd be nice if you pointed out, you know, actual reasons rather than just make snide comments. I'm sure some knee-jerk Apple haters will vote you up though.

My issues with iOS development lie not with Objective-C, but with Apple's frameworks and libraries. It's frustrating to only have header files and not be able to check out what a method actually does when debugging. Fortunately, the documentation for their classes is top-notch. The objc runtime is also a pretty wild ride, but once you know your way around you can poke at it and find out where your messages are going at least. Can check out the source for the runtime here http://opensource.apple.com/source/objc4/

Another issue of course, is XCode. I've switched to writing most of my iOS code in vim, building my code with the xcodebuild command. I still rely on XCode to do things like add files to the xcodeproj and manage the build configurations. XCode has a mind of its own, wacky completions, a completely fucked up undo buffer, strange locations for settings, and more frustrating joys. Would love to do away with that.

Check out the cocoa.vim plugin, and also, while I'm at it, you can get your vim for your local environment pimped out in minutes with Vimlander 2: The quickening. Test driving my apps with Pivotal's Cedar framework.

Re:For the better?

[Anonymous Coward]

s/because of/in spite of/

Re:For the better?

[lurch_mojoff]

Some of the biggest NeXT clients were precisely from the military, intelligence, banking, financial services and science communities. And they chose NeXT precisely because of Objective-C and NeXTStep.

Re:For the better?

[nicholas22]

"The world continues to chase apple -- probably for the better." That's just flame bait, I wouldn't have glimpsed twice on this article had there been no such phrase... Yet, here I am now, reading the article, posting and trying to come up with something that will tease Apple fanbois, for the heck of it. This is why I come here every day ;)

Re:For the better?

[barzok]

Just because something is popular & widespread, doesn't mean it's high-quality.

And just because something is not widespread, does not mean that it isn't high-quality.

Re:For the better?

[teh kurisu]

Syntax and implementation. I willingly go the extra mile to avoid using Obj-C anywhere except for UI code.

Isn't syntax just a personal preference? I actually quite like ObjC's syntax. What don't you like about it?

Not in my experience, eg: All the documentation presumes the developer is using IB when no serious developer I know will touch it.

As long as you understand what Interface Builder is doing under the bonnet/hood, then it's really not that hard. And is there any particular reason why a serious developer wouldn't touch IB? I find it to be quite a useful tool, much better than the equivalent in Qt Creator.

XCode is such utter shit that it's not funny.

Agreed. Xcode 4 is available as a developer preview and I'm hoping that it solves a lot of the issues I have with the current version, but I haven't had a chance to play with it properly yet.

Re:For the better?

[Xest]

To be fair it's not that there's any inherent problem with Objective-C, that much is pretty well demonstrated by the countless great applications built on it for Apple's platforms. The real issue is really that it's like the neanderthal of languages- it evolved from C in parallel with languages like C++ and Java, but in doing so has ended up rather more ugly, and whilst it has some good bits, it also has bad bits like a lack of namespaces and operator overloading (although of course these issues aren't limited to Objective-C, Java lacks operator overloading too for example) but the combination of what is frankly a quite horrible syntax and these missing features means it's essentially just a poor man's C++. The obscurity of the syntax just builds an extra barrier that's really unnecessary in this day and age- every developer just about is comfortable with C++ style syntax so why waste time with a language syntax that's so obscure when you can just have one that people can jump straight into? This issue spills over into cross platform development somewhat in that it's much more of a headache to development multiple versions of a program when you're facing two very different sets of syntax more so than porting between programs with similar syntax.

So yeah, certainly it "works", but there's really just no point in it when other languages work just as well without the added headache of lack of things like namespaces and an obscure syntax. There are bigger issues with the development tools and libraries themselves, but really that's something else, my comment was really targetted at the language- effectively Objective-C is different without bringing anything worthwhile to the table- at least with some other languages that have more obscure syntax they also often have a redeeming feature, like say being a functional programming language for example.

Re:For the better?

[hobbit]

It used to be a lightweight extension to C, but ObjC-2.0 rather spoiled that with dot syntax for properties :(

Re:For the better?

[Viol8]

Yes , I agree about the syntax. Instead of creating a nice consistent extension to the C language as Bjarn did with C++ (albeit with some kludges) , Obj-C really looks like someone tossed a completely different language into C because it was easier than making an effort to actually extend C nicely, and then didn't even bother to stir the resulting dogs dinner.

Re:For the better?

[beelsebob]

Not in my experience, eg: All the documentation presumes the developer is using IB when no serious developer I know will touch it.

You've never met a serious developer.

I've worked in Mac and iPhone application development for several years in industry and never met any developer (including collegues, online friends, people on the cocoa mailing lists, people on the developer forums, people at conferences), serious or not, who does not use IB.

Re:For the better?

[Graff]

Also doesn't it's dynamic runtime stuff allow certain things that C++ doesn't?

Yeah, like built-in introspection and reflextion. Stuff like RPC (remote procedure calls) is simple and flexible under Objective-C but under C++ it has to be hard-coded in and can be very brittle.

Re:For the better?

[Anonymous Coward]

Isn't syntax just a personal preference? I actually quite like ObjC's syntax. What don't you like about it?

The bits that aren't C.

is there any particular reason why a serious developer wouldn't touch IB?

Load time of xib and the fact that for any non-trivial interface, you're going to end up hand-coding it anyway.

Agreed. Xcode 4 is available as a developer preview and I'm hoping that it solves a lot of the issues I have with the current version, but I haven't had a chance to play with it properly yet.

I forget, is this one of those things I agreed to an NDA on? If so would Apple kill me for telling you that despite a cleaner UI; XCode4 is just as useless?

Re:For the better?

[dyfet]

While your overall statement could be thought of as broadly correct and relevant, it does so by being a chimeric language where you have two completely different and unrelated syntactic forms (C and smalltalk) that are superimposed on each other. I personally feel this reduces overall legibility.

Another consideration is that since method calls are messages with signatures that are symbolically matched at runtime as each method is invoked, there is some runtime overhead in method calls that are very different than found in C++ methods, even in respect to C++ virtuals, and this may become very important depending on how methods are used. To me Objective-C tends to make you use smalltalk as the framework for "overall" application structure and then use pure C for the details, where C++ is better for applying object oriented methods even to low level details, and this is where execution speed often does matter.

Finally Objective-C's runtime library standardized threads and conditionals, which makes writing multi-threaded applications more consistent and even generically cross-platform. However, all the issues with using pure C functions and libraries that are not re-entrant do of course remain.

Re:For the better?

[teh kurisu]

I think the extent to which the syntax is a barrier to entry for new developers is exaggerated. Square brackets denote method calls - easy. It might take a wee while before typing out method declarations in the right order is second nature, but I think that's acceptable because you gain (forced) named parameters.

I like the fact that the syntax is different, because the chances of getting caught out are reduced. There are already too many languages with similar but subtly different syntaxes out there.

Re:For the better?

[t2t10]

Sure it delivers on that. And in 1985, that was a great thing; it was technically obsolete even then, but for underpowered personal computers, it was a decent compromise.

In 2010, it's just stupid. We don't need extensions to C of any form, we need C and its satanic spawn to die.

Re:For the better?

[CODiNE]

Nice link on Reflection, every now and then I wish I could do that but didn't know I could.

Re:For the better?

[Maury Markowitz]

Or perhaps more accurately, not updating it.

It still has some things I like, but there's many more things I like in other places now. Boxing for one...

Re:For the better?

[Xest]

I agree it's not a big barrier, it's just an unnecessary inconvenience, that's the problem. I think the inconvenience alone puts a lot of people off of it because there are so many other languages out there that don't have that inconvenience for them.

Re:For the better?

[Arker]

essentially just a poor man's C++.

Actually, it's the other way around, C++ is the poor mans objC. Unlike C++ it's a C superset, and way back with NeXT it was demonstrably leading to fewer bugs and less developer time on the same job. Apple has made some poor decisions in its role as de facto shepherd but the language is solid in its role.

Re:For the better?

[Graff]

Nice link on Reflection, every now and then I wish I could do that but didn't know I could.

There's a lot more to it if you dig deeper:
Objective-C Runtime Programming Guide

You can do some pretty neat stuff like dynamically creating a class and adding methods to it. Some of it should only be used as a last resort but it's nice having the tools at hand if you really need them. This kind of stuff is either extremely difficult or outright impossible in C++.

Yes, there are some performance penalties to a dynamic runtime but for most cases it is negligible. If you desire you can circumvent the dynamic aspect of Objective-C and "freeze" method calls in order to get around those penalties for performance-critical code. There's a great series of articles on this subject: The Optimizing Objective C Series

Re:For the better?

[muecksteiner]

You apparently do not really understand what Objective-C is about yet. Yeah, I know, "you don't know what you are talking about" is the classical ad hominem attack in any programming language flamewar. But in my opinion, it is hard to see how anyone who has actually taken the time to look at Objective-C closely could ever refer to it as being a "poor man's C++".

Now calling it a "poor man's Smalltalk", well, you might have a point there. But C++? ObjC and C++ are both in some way descended from C, but that is where the conceptual similarities end. The ObjC runtime is dynamic, which is IMHO a blessing, compared to the strict typing and template system of C++. But I'll grant you any day that Obj-C could do with some modernisation, in particular w/r to namespaces.

But even the other thing you mention, operator overloading... that is absent for a reason, simply because software design works differently in ObjC. You don't really need it in the same way that you do with C++. Same with multiple inheritance. You have protocols for that, amongst other things.

So please give ObjC another, more in-depth look, some time. You might be surprised in a positive way, once you look past the admittedly rather weird syntax.

A.

Re:For the better?

[onefriedrice]

Yes , I agree about the syntax. Instead of creating a nice consistent extension to the C language as Bjarn did with C++ (albeit with some kludges) , Obj-C really looks like someone tossed a completely different language into C because it was easier than making an effort to actually extend C nicely, and then didn't even bother to stir the resulting dogs dinner.

I laughed at this post, but then I realized you might not be trying to be funny. As a C++ programmer myself, I've never heard anyone referring to C++ in a serious way as a "nice consistent extension to the C language." C++ is an absolute monster. It's completely inconsistent in many ways and is riddled with so many "gotchas" that it takes years until you should be able to call yourself an expert. That's a long time in the context of learning a new way to describe what a computer should do.

I haven't programmed in Objective-C in years, but I do remember that it is far simpler to learn than C++. It adds comparatively little to the C language, as far as syntax goes; basically just the [] message-passing construct and the @ keywords. I think Objective-C "2.0" may have distinguished itself a little more, but I haven't looked into it.

Anyway, hopefully you're being funny. Otherwise, we have completely different opinions. Objective-C seems to have extended C in a way that is much nicer and cleaner than C++ IMO.

Re:For the better?

[beelsebob]

No, but it does tend to come up fairly regularly. It's a reoccuring theme in #iphonedev/#macdev that a new programmer will come in saying "I'd prefer not to use IB because xyz", and every experienced programmer tells them to use it and learn it. Two weeks later, and they've joined the chorus of people saying "use IB". Similar themes repeat on the mailing lists.

Re:For the better?

[UnknownSoldier]

You CAN do reflection in C++ as the code base for one game I saw ... the catch is you need a super-base object, templates, and macros to pull it all off ...

but yeah, there is no _native_ language support for it.

Re:For the better?

[Graff]

But I'll grant you any day that Obj-C could do with some modernisation, in particular w/r to namespaces.

In the end namespaces are very little more than appending more characters on a name. You can get most of what namespaces do just by adding a unique string to part of your class name. Yes, there is a possibility for clashes if someone chooses a string which is the same as yours but how often do people use outside classes other than the ones in the Cocoa frameworks?

At best there should be some sort of prefix directory where developers can register their class prefixes and make sure that they have a unique string. Apple already uses NS and CF so most developers know do avoid using them.

Here's some good reading on the topic:
Cocoa Style for Objective-C: Part I
ChooseYourOwnPrefix

Re:For the better?

[UnknownSoldier]

> In 2010, it's just stupid. We don't need extensions to C of any form, we need C and its satanic spawn to die.

Sounds like you have never actually shipped any games on modern consoles. C (and C++) isn't going anywhere, because there is nothing better* to replace them with.

Which means, in the mean time, we need extensions to solve Real World (TM) problems. Not to sound like an ass, but let me know when you understand restrict semantics.

* Better, in this context means a) fast to compile, b) fast to execute. D _might_ be a possibility, but at the moment, I don't know of any D compilers for PS3, XBox 360, or Wii.

Re:For the better?

[ToasterMonkey]

lol, did someone really just say that in the context of Objective-C? For all the things Apple has done right and does well, clinging on to Objective-C is not one of them.

Hey, I'll give you a chance for "Informative" points too.

Why?

Re:For the better?

[Xest]

But that's a completely different argument, his point is that C++ extends the C syntax and rules pretty consistently, whilst Objective-C does not, it changes them.

The complexity of C++ stems not from the syntax per-se, but simply because you can do that much more with it- not only have you got namespaces for better code organisation in large projects, not only have you got tools such as operator overloading, true multiple inheritance, but you also have options such as template meta-programming.

You found C++ harder simply because it has more features, and more complex features to learn, not because of it's syntax. C++'s complexity stems purely from it's power, Objective-C's complexity stems from it's obscure syntax- the former is the price you pay for extra features, the latter is just simply inexcusable difference for the sake of difference and/or poor language design.

C++'s syntax change complexity is purely down to the amount of syntax that is required to implement such a rich set of features. If you base your argument purely on syntax without any consideration of why that additional syntax is there and without any consideration of language changes then you might as well just argue Java trumps them both because it's much closer to C syntactically than either of them, but that would be ignorant of the fact Java offers a completely different featureset again.

Perhaps the most obvious test though is this, write an application that's not overly complex and uses the base set of shared features the languages provide using their preferred syntax (rather than the fact you can just use C for either) and which then more closely represents a C program syntactically? you really can't argue it's anything other than C++, which is precisely why the jump to C++ is much more natural than to Objective-C as per the GP's argument.

Re:For the better?

[wimmi]

Doom was written on a NextStep machine.

'Nuff Said!

Re:For the better?

[Anonymous Coward]

Obj-C really looks like someone tossed a completely different language into C

It's Smalltalk.

Brad Cox's inspiration for writing Objective-C came from the 1982 issue of Byte magazine that covered Smalltalk.

--lowell

Re:For the better?

[Anonymous Coward]

I think you have that backwards. Objective-C doesn't change any of the rules of C. On the other hand there's a lot of C syntax that is not valid C++.

Both C++ and Objective-C started off as object oriented extensions to C, and IMO Objective-C does a much better job. C++ tried to add everything and the kitchen sink, and ended up with horrible, bastardized syntax because it's still trying to achieve C compatibility, even though it hasn't been strictly compatible with C in over a decade.

It's even more noticeable if you look at what's considered "good" code in each language. The following is valid C, Obj-C and C++, but a C++ weenie will whine that it's not using std::cout.

#include <stdio.h> int main() { printf("Hello world!\n"); return 0; }

Re:For the better?

[Jorl17]

I don't agree with that. I much prefer C++ to Objective C. The latter disgusts me due to its insane syntax.
That is all -- my opinion.

Re:For the better?

[pmontra]

The are languages such as Ruby that don't require you to type () and even ; because the parser can figure out where an expression ends. Actually sometimes you need the () to disambiguate alternative interpretations of argument lists (e.g. nested method calls) but generally speaking, typing only one . with no () is so much better than the two [] or the two -> followed by (). And don't forget the ;. When I look at Java I can't understand why they designed a language that needs us to type the ;. When I look at Obj-C, well... it's just so ugly and apparently redundant.

Re:For the better?

[firewood]

The obscurity of the syntax just builds an extra barrier that's really unnecessary in this day and age

Objective C's form of punctuation abuse isn't any higher a barrier than C++'s forms of punctuation abuse. In fact, it has less total weird syntax. Reports are that Objective C stops looking obscure to most programmers after about 2 weeks of use, even if they were previously biased towards C++ or Java like syntax.

Re:For the better?

[Josef Meixner]

Now calling it a "poor man's Smalltalk", well, you might have a point there.

and

But even the other thing you mention, operator overloading... that is absent for a reason, simply because software design works differently in ObjC. You don't really need it in the same way that you do with C++.

In other words, you don't even know Smalltalk, but speculate about the similarity between ObjC and Smalltalk. For your information, Smalltalk has operator overloading (in the form of the unary and binary selectors) and uses it in the implementation for numbers. It works a bit differently (all binary operators have same precedence, so 5 + 4 * 3 = 17, but 4 * 3 + 5 = 32, I hope I didn't mix up the sequence, I am rather sure that binary selectors evaluated right to left), but it definitely has them. Also the big plus (and minus) for Smalltalk always was the integrated environment, you can literally change anything, if you want for example the compiler on the fly. It is similar to Lisp in that regard (though I think Lisp does it more elegantly). ObjC is a very, very distant cousin, basically only inheriting the compound selectors. And as I just found out, ObjC finally has inherited the BlockContexts, after only 20 years (or 30, I couldn't find out when they made it into ObjC exactly, Smalltalk had them fixed at least since 1980) that are a central part of Smalltalk. In Smalltalk there never was any kind of selection or looping statements, they were implemented as methods on objects taking blocks. E.g.:

|i| i := 0. i = 1 ifTrue: [^'It is 1'| ifFalse: [^'It is not 1'].

That defines a local variable i, assigns 0 to it and then tests if it is 1 and executes the first block returning a string if it is, else it returns the result of second block.

Re:For the better?

[Draek]

In the end namespaces are very little more than appending more characters on a name.

In languages with only token support for it, yeah. In languages that implement namespaces properly however, actually applying some common sense to it, no it really isn't. Having a namespace named "Ada.Numerics.Complex_Arrays" is a lot more readable than "CA", but I think we can all agree that typing "AdaNumericsComplexArrays_ComplexVector v = AdaNumericsComplexArrays_ComposeFromCartesian(arg1, arg2)" isn't what a sane man would find comfortable.

Yes, there is a possibility for clashes if someone chooses a string which is the same as yours but how often do people use outside classes other than the ones in the Cocoa frameworks?

Isn't that a bit chicken and egg? rather than "it's not a problem because people don't use it much", I'd argue that "people don't use it much because it's a problem". After all, using outside classes is very common in the Java and C# worlds, in spite of the fact that both languages come with very powerful frameworks out-of-the-box as well.

Re:For the better?

[sznupi]

Naughty Dog used their variant of Lisp in PS1 and PS2 era. Crash and Jack & Dexter were some of the nicest looking / best running / most polished games around.

IIRC they did switch to C/C++ with the onset of PS3 - but maybe that's not for strictly technical reasons? (in the practical realm - availability of tools, libraries and people, for example)

Re:For the better?

[TrancePhreak]

I find it far easier to manage pointers in C++ than in Objective C, but a lot of that is due to the libraries not the language. There are some things that call autorelease before passing back the pointer, some things do not. Some things you need to call retain, some things you do not. In order to figure any of this out, I'm constantly looking things up. In C++ I can just go and not worry about such things. It's always clear what I'm being given.

Re:For the better?

[TrancePhreak]

It might be because the PS3 compiler was pretty immature and you needed to manage the SPU's much more. On the PS2 they probably got enough performance out of it to not matter. In the future, the PS3 compiler might be able to handle the SPU's on its own.

Re:For the better?

[t2t10]

I made no common on the availability of languages, or the feasibility of choosing something else, I said that C and its derivatives are harming the industry and need to be replaced.

As it turns out, there are actually plenty of alternatives, there simply isn't a one-size-fits-all replacement.

Re:For the better?

[shutdown -p now]

C++ weenie will whine that it's not using std::cout.

A C++ weenie here. Actually, for starters, I'll whine that you didn't write #include <cstdio>.

On the other hand, a C weenie would whine about the completely unnecessary "int" and "return"...

~

Re:For the better?

[shutdown -p now]

I've never heard anyone referring to C++ in a serious way as a "nice consistent extension to the C language." C++ is an absolute monster. It's completely inconsistent in many ways and is riddled with so many "gotchas" that it takes years until you should be able to call yourself an expert.

I'd say that's perfectly consistent with C, then. I mean, mixed signed/unsigned arithmetic, or the declaration syntax, or tag namespaces in C are about just as fucked up as some of the darkest bits of C++.

But, anyway, I think GP was talking about syntax. As in, using "." and "->" and "()" for method calls, which is kinda consistent with C - since also it uses the first two for member access, and parentheses for function calls, and C++ just logically combines them together.

Re:For the better?

[shutdown -p now]

In the end namespaces are very little more than appending more characters on a name.

The point of having namespaces in the language is so that you can avoid spelling those characters over and over again (via "using", "import" etc), except when you actually hit a case where you have two clashing identifiers from different namespaces.

Re:For the better?

[shutdown -p now]

Obj-C and C++ are both in some way descended from C, but that is where the conceptual similarities end.

To make things really brief:

C++ is C with Simula-67 tackled on top (no, really - that's where "virtual" directly comes from).

Objective-C is C with Smalltalk tackled on top.

C++ is more subtle in that it changed Simula syntax so that it looks more like C from the first glance, with curly braces etc. Obj-C took the more blunt approach.

Re:For the better?

[shutdown -p now]

Doom was written on a NextStep machine.

You'd have a point if it was written in Objective-C.

Re:For the better?

[shutdown -p now]

It is required in ANSI C99, yes. 99% of C code out there is ANSI C89, though. A true C weenie would consider C99 heresy, anyway ("whut? VLA in my language??").

Re:For the better?

[Graff]

Having a namespace named "Ada.Numerics.Complex_Arrays" is a lot more readable than "CA", but I think we can all agree that typing "AdaNumericsComplexArrays_ComplexVector v = AdaNumericsComplexArrays_ComposeFromCartesian(arg1, arg2)" isn't what a sane man would find comfortable.

So you make the prefix "AdaNumericsComplexArrays" or something similar and gain most of the goodness of using a verbose prefix. There's also some techniques which use #define or @compatibility_alias to shorten the class name so that you don't have to type it every time, similar to the using keyword in Java.

Isn't that a bit chicken and egg? rather than "it's not a problem because people don't use it much", I'd argue that "people don't use it much because it's a problem". After all, using outside classes is very common in the Java and C# worlds, in spite of the fact that both languages come with very powerful frameworks out-of-the-box as well.

Yeah, kinda. My point is that even if you use some outside classes they are likely to be common ones that you already knew not to use the same prefix. You should also choose a prefix which is at least 4 characters, the chances of a clash are then minuscule - about 1 in 460,000 if you use all caps and 1 in 1.8 million if you use initial caps, mixed case middle, and final lower case. With odds like that you probably don't need to worry about clashes or complex namespaces.

Re:For the better?

[Graff]

You CAN do reflection in C++ as the code base for one game I saw ... the catch is you need a super-base object, templates, and macros to pull it all off ...

Sure, after all that's approximately how Objective-C originally worked, as a bunch of preprocessor macros on top of C. The point is that you'd have to basically be rolling your own implementation of a dynamic language on top of C++. If you're doing that then you're probably doing it wrong, you should either find a cleaner way to do what you want or switch to a dynamic language and start all over.

As the AC said above me, "When people say "can't", you can assume they mean "not natively supported"."

Re:For the better?

[SteeldrivingJon]

"Yes, that was true, but quite a while back."

True, but it shows that "real" apps can be developed using Objective-C and the NeXT-originated frameworks. Apps like trading systems at First National Bank of Chicago (now part of JP Morgan Chase), Bank of America, Swiss Bank Corp and UBS (now merged), Fannie Mae, etc.

" The world has moved on."

True, although I think many such customers in the mid-90s moved away from NeXT in order to reduce small-vendor risk (ie, not be caught out if NeXT went under). Especially when Java arrived. That was very seductive as an alternative, especially when per-seat deployment and development costs were considered.

What I don't know is how successful the projects were that ported NeXT-based systems to Java or C++ or otherwise, and how the development effort compared to the original NeXT projects. I suspect C++ would have been rather nastier in 1996 than it is now, assuming that template libraries, boost, etc have improved or come into existence.

Things might have turned out differently if NeXTSTEP were owned by a bigger, 'safer' company, and sold for less. If, say, Sun or IBM had owned the OS, and given away the OS and dev tools, making their profits on server hardware, it might have remained in use by corporations.

(As a point of reference, in my group at First Chicago/Bank One, in 2000 we had moved our trading app to OpenStep on NT, allowing it to run via Windows Terminal Server. That's about when I left, so I don't know where it went afterward. I think they may have tried moving it to WebObjects.)

Re:For the better?

[SuperKendall]

I find it far easier to manage pointers

In an OO language, why are you still worrying about pointers? That's what I hated about C++ in the many years I spent with it. Well that's one thing.

There are some things that call autorelease before passing back the pointer, some things do not. Some things you need to call retain, some things you do not. In order to figure any of this out, I'm constantly looking things up.

I never look that up, because there are very clear rules around that - init/new/copy gives you something retained, anything else does not. Anything that wants to store something long term (beyond the local call) will retain it and release it when done.

But that's on the iPhone; on the Mac desktop developers have not looked that up for a while because it has garbage collection and "retain" is a noop.

I'm constantly looking things up. In C++ I can just go and not worry about such things. It's always clear what I'm being given.

That's odd because I remember spending a lot of time with stuff like MemoryScape from Rogue Wave. I find Obj-C less error prone in regards to memory handling than C++.

You also have to worry less because Cocoa has better foundation classes than you get with the standard template library...

Re:For the better?

[bonch]

To be fair it's not that there's any inherent problem with Objective-C, that much is pretty well demonstrated by the countless great applications built on it for Apple's platforms. The real issue is really that it's like the neanderthal of languages- it evolved from C in parallel with languages like C++ and Java, but in doing so has ended up rather more ugly, and whilst it has some good bits, it also has bad bits like a lack of namespaces and operator overloading (although of course these issues aren't limited to Objective-C, Java lacks operator overloading too for example) but

That it lacks operator overloading is a huge positive, not a negative. You don't give a convincing example that Objective-C is a "neanderthal language," though that kind of hyperbole implies a pre-existing bias against it.

the combination of what is frankly a quite horrible syntax and these missing features means it's essentially just a poor man's C++. The obscurity of the syntax just builds an extra barrier that's really unnecessary in this day and age- every developer just about is comfortable with C++ style syntax so why waste time with a language syntax that's so obscure when you can just have one that people can jump straight into?

No offense, but this is really stupid, especially calling it "a poor man's C++." The big difference between C++ and Objective-C isn't syntax; syntax is a superficial barrier to entry that everyone gets over when learning a language. The difference is that C++ is a compile-time language, while Objective-C is a run-time language. It uses a dynamic dispatch, and there's nothing obscure about the syntax--your praise of C++ makes the statement even more bizarre since C++ is infamous for its insanely and obscure syntax! Objective-C's messages are just brackets. Arguments in the message are prefixed with labels. You get used to this after a day, if that long. Every new C programmer thought braces and semicolons were weird, too.

If your primary argument against Objective-C is that it doesn't look like C++, then that's a really bad argument, especially given how critical people have always been toward C++ for its ability to inadvertently hide unpredictable behavior.

So yeah, certainly it "works", but there's really just no point in it when other languages work just as well without the added headache of lack of things like namespaces and an obscure syntax.

You repeat the "obscure syntax" claim, which is, again, bullshit. Not only it not obscure, but it inherits Smalltalk's self-documenting, easy-to-read nature. Objective-C code is vastly less obscure and obfuscated than C++ code.

As for namespaces, this isn't ever an issue for Objective-C programmers in practice (and some consider namespaces an obfuscation of code anyway). It would be solving a non-problem. Adding namespaces to Objective-C would conflict with the dynamic nature of the language and its ability to, for example, add methods at run-time. Again, Objective-C is a dynamic dispatch language, and it intentionally does not enforce compile-time restrictions on methods. You can send messages to objects that don't even implement those messages, and all you'll get is a compiler warning. You can actually implement a method in your class to catch unrecognized selectors and forwards them elsewhere. Namespace support would require a total reworking of the run-time and would limit much of its dynamic nature.

Putting the word "works" in quotation marks is just trolling.

There are bigger issues with the development tools and libraries themselves

Such as? You're throwing out a lot of personal conclusions here without any evidence and getting modded up for it. Let's hear what you have to say about these frameworks and development tools, because so far, you've come off as judgmental and misinformed.

but really that's something else, my comment was really t

Re:For the better?

[master_p]

Actually, it's the other way around, C++ is the poor mans objC.

C++ has a lot more capabilities than ObjC. For any non-trivial software, C++'s capabilities are necessary.

The company I work for writes ObjC code for iPhone applications, and we have lots of memory problems, due to mismanaged reference counts, but we can't have smart pointers as in C++, due to lack of templates. On the other hand, we have written C++ applications with thousands of lines of code (120 kloc) without a single memory problem, thanks to smart pointers.

Unlike C++ it's a C superset

C++ is 99.9% compatible with C, whereas ObjC is 100% compatible with C. That's hardly a worth noting difference.

and way back with NeXT it was demonstrably leading to fewer bugs and less developer time on the same job.

C++ 2010 is different from C++ 1990. C++ didn't even have templates back then.

It's also a matter of design; for example, if you compare Qt with Cocoa, you'll find a similar level of quality.

Re:For the better?

[master_p]

You apparently do not really understand what Objective-C is about yet.

As if you understand what C++ is about.

But in my opinion, it is hard to see how anyone who has actually taken the time to look at Objective-C closely could ever refer to it as being a "poor man's C++".

Lack of templates and operator overloading means no smart pointers, which means no automated reference counting. This had led to quite a lot of bugs in iPhone applications.

The ObjC runtime is dynamic, which is IMHO a blessing, compared to the strict typing and template system of C++

It is a blessing and a curse, at the same time. There is a reason strict type systems have been developed.

You have protocols for that, amongst other things.

Protocols (or interfaces) are a poor man's multiple inheritance.

Re:For the better?

[master_p]

You some how make it rational to have to type a class prefix all the time, at each and every line of code...

Re:For the better?

[master_p]

Man, this thread is spread with more fud than ever...as if Slashdotters are no more technical people.

C++ can easily a dynamic runtime just like ObjC, if it was necessary, by using operator overloading and dynamic message maps, instead of vtables.

Re:For the better?

[master_p]

This kind of stuff is either extremely difficult or outright impossible in C++.

No, it is not. Please stop spreading FUD. You can do ObjC's slow message passing mechanism in C++, using operator overloading and dynamic message maps (even creating a class dynamically).

Re:For the better?

[master_p]

And they chose NeXT precisely because of Objective-C and NeXTStep.

SOME military, intelligence, banking, financial and science communities chose NeXT. NeXT was a commercial failure...so the client list was pretty small.

Secondly, I doubt they chose a whole operating system because of the programming language used. It's a silly argument, for obvious reasons. They chose NeXT because it could support their requirements, at a good price.

Re:For the better?

[BitZtream]

On the other hand there's a lot of C syntax that is not valid C++.

... uhm ... WTF are you talking about. I've been doing dev in C for 20 years and I've yet to see one thing in C that is invalid in C++. I fully admit to not reading the actual language specification, but I call bullshit and would say your problem is with a shitty compiler that either didn't detect the problem you had in C mode or doesn't compile C++ properly.

Re:For the better?

[BitZtream]

Did you seriously just say C++ wasn't a superset of C?

Re:For the better?

[BitZtream]

It's frustrating to only have header files and not be able to check out what a method actually does when debugging.

So I'm guessing you've never done professional development for a mainstream OS? If you're biggest issues with something is 'I cant see all the source' then you're a pretty shitty and inexperienced developer indeed.

Re:For the better?

[Arker]

You also have to worry less because Cocoa has better foundation classes than you get with the standard template library..

And bringing us right back to the topic... GnuStep.

The purpose of this project is to create a free and open version of the Cocoa (formerly known as NeXTSTEP/OpenStep) APIs and tools for as many platforms as possible.

It's great stuff, and I have been complaining for years that infinitely less-worthy work was getting the attention instead, so I was very happy to see this.

Re:For the better?

[Graff]

You some how make it rational to have to type a class prefix all the time, at each and every line of code...

You'll be doing the same thing with namespaces under C++. Let's say you have a namespace "Foo" which has a class "Bar". Every time you want to use the class you need to write "Foo::Bar". This is pretty close to using a class prefix like "NS" in Cocoa, such as in "NSString".

Now C++ does have the using keyword which lets you skip the namespace designation on a class so that you can do something like:

using namespace Foo;
Bar anObject = more code;

However, now you've just killed the point of having a namespace because you've essentially stripped off the unique name! Yes, it's up to the programmer to make sure that the code block that has the using keyword doesn't have two classes that have the same name but are defined differently elsewhere but the point is that it adds extra complexity and work to the matter.

You can also simulate namespaces and the keyword using under Objective-C so that you don't need to type the prefix every time. Just use #define and #undef around the code block. For example:

#define String NSString
String *bar = more code;
#undef String

It's a little bit more verbose but it's pretty close to using a namespace. Overall you can get most of the functionality of namespaces just by using a unique prefix for your class names. Yeah you have to type a few extra characters every once in a while but it's not onerous.

Re:For the better?

[Leynos]

I'm the other way round. I found ObjC a joy to learn, picked it up pretty quickly. C++ took several abortive attempts and had me pulling my hair out for a long time. Now that I'm relatively comfortable with both, I still find ObjC to be my path of least resistance (certainly when writing gui apps).

I'm not sure why that is exactly. I think the use of templates in C++ made it difficult for me to pick up. I know you can write C++ code without using templates, but a lot of libraries seem to make heavy use of them. The types of error messages produced by gcc when templates are involved tend to make finding out where you've gone wrong rather difficult at times.

I know though that I have a lot to learn in C++. Specifically, I have yet to write my own generic class or function. I'm sure I will at some point, but so far there hasn't been much call for them in the problem domain I tend to use C++ for.

Re:For the better?

[CptNerd]

And as a Smalltalk programmer from back then, I have to say I'm quite pleased that ObjC didn't die, although it probably came close there. I still have my copy of Brad Cox's book that I bought back when it came out, pre-NeXT days. I prefer the ObjC syntax because it didn't try to seamlessly integrate the object syntax into the original C syntax. I remember going to a technical conference where Andrew Koenig gave an example of a downside to C++ versus straight C.

In C, the statement

varC = varA + varB;

generates a small amount of easily-predicted binary code. In C++, there's no real way of predicting how much binary code is generated by the compiler, and so there's no good way of optimizing the source. Worse, there's no easy way of debugging this kind of statement in C++, given the kinds of things going on in the background. Even worse, the third C++ standard was coming out, and he gave an example of two ways of interpreting part of the standard, that produced very different binaries and thus programs that acted differently, but were both compliant with the standard, and thus "standard C++".

I wish I could have kept the notes, it was a fascinating talk, and reinforced my (mostly kept to myself) opinions about C++.

Re:For the better?

[Jorl17]

Yeah, I have a feeling that I am biased. C++ was the first language I really learned and I have loved it ever since. What makes GUI easier for me in C++ is Qt, which, by using moc, is more than "pure c++".

Re:For the better?

[SteeldrivingJon]

"Secondly, I doubt they chose a whole operating system because of the programming language used. It's a silly argument, for obvious reasons. They chose NeXT because it could support their requirements, at a good price"

They chose NeXT for the development environment's advantages. If they were selecting on price, they certainly wouldn't have chosen NeXT, given that in the early days you had to buy $4000 NeXT computers, and later the Intel version cost $795 for the OS and $4000 for the developer tools.

Just look at how NeXT's business evolved. They went from selling computers with an OS and dev tools, to selling an OS and dev tools, to selling the OpenStep development tools and a deployment environment on Windows, to selling the WebObjects environment for deployment on the web. They shed everything *but* the development environment, over time.

Re:For the better?

[benhattman]

In the end namespaces are very little more than appending more characters on a name.

In C++ perhaps, but languages like Java and C# provide levels of encapsulation within namespaces which can be very valuable. Also, it provides a language supported method for conveying to other developers that two classes are related.

Re:For the better?

[TrancePhreak]

I actually find the classes like NSArray/etc less useful. I develop software that requires fast code, and those libraries are not fast in comparison. STL's vector you could optimize down to an array access. Cocoa's is a function lookup + call.

Re:For the better?

[1729]

On the other hand there's a lot of C syntax that is not valid C++.

... uhm ... WTF are you talking about. I've been doing dev in C for 20 years and I've yet to see one thing in C that is invalid in C++. I fully admit to not reading the actual language specification, but I call bullshit and would say your problem is with a shitty compiler that either didn't detect the problem you had in C mode or doesn't compile C++ properly.

http://public.research.att.com/~bs/bs_faq.html#C-is-subset

Re:For the better?

[rsfinn]

It's almost like a cruel mix of coding, texting and writing documentation ...

Where I come from we call that "software engineering".

Re:For the better?

[badkarmadayaccount]

Meh, it's gonna take a long time to get a descent C OO extension.

Re:For the better?

[badkarmadayaccount]

Qt has a message passing system - much like ObjC.

Re:For the better?

[badkarmadayaccount]

Qt, anyone?

Re:For the better?

[badkarmadayaccount]

Both OCaml, Lisp, Haskell, Ada, and Eiffel match your requirements, I believe.

Re:For the better?

[Jorl17]

Yes, that's what I was talking about when I mentioned moc.

Re:For the better?

[badkarmadayaccount]

Oops. Sorry.

Summary is incorrect

[zr-rifle]

GNUstep's objective is to create a free and open source implementation of the Cocoa libraries, with some additional libraries. It does not target the OpenStep spec, which is antique and obsolete.

Please read the definition

Re:Summary is incorrect

[thenextstevejobs]

If Apple started using open source'd classes for things like strings and could focus their internal development on things that interact more directly with hardware (especially graphics), that would be a win for everyone.

Less money for them for common functionality, more ability for me to see what's causing a bug.

Re:Summary is incorrect

[gnasher719]

If Apple started using open source'd classes for things like strings and could focus their internal development on things that interact more directly with hardware (especially graphics), that would be a win for everyone.

1. Have a good look at all the open source stuff that you can download from Apple. You'll be surprised. Especially with string handling, Apple has always been one of the driving forces behind Unicode. 2. "Everyone" I think excludes Apples.

Re:Summary is incorrect

[beelsebob]

Apple do open source their implementation for things like strings... here it is:

http://opensource.apple.com/source/CF/CF-550.42/

Re:Summary is incorrect

[rxmd]

Apple has always been one of the driving forces behind Unicode.

For selected values of "always". Apple has supported Unicode well since OS X, that is since 2001 or so, or in other words, ten years after the Unicode standard was published. Even Windows was earlier - Unicode support in Windows NT 3.x was there on the API level, in NT 4 it would work well if your programmers had been halfway diligent, and in Windows 2000 it would work well out of the box. With Apple systems before 2001, it was a pain to get Unicode working properly on MacOS 9 - it was technically supported in 9.x, but it didn't really work all that well.

With OS X, Apple finally had the opportunity (that Plan 9 had had something like a decade earlier) to design a new API that used Unicode for all strings. Prior to OS X, the Apple device that supported Unicode best was the Newton, and even there you didn't have proper input methods and rather limited font support.

Re:Summary is incorrect

[mfwitten]

What is particulary humorous is that the Maintainer of GNUstep recently wrote a blog post titled GNUstep Is Not OpenStep...:

Hey guys. I thought I would make this blog post to make a point: GNUstep is not OpenStep. GNUstep is a Cocoa implementation and has been for quite some time.

Re:Bizarre choice

[sznupi]

Qt is LGPL, it's not "owned" by Nokia - certainly not in the way Apple controls Cocoa and GNUstep strives to keep up.

That said, as far as I am concerned GNUstep is at least the second best choice of the two / it's nice to see that their efforts might finally give something big.

Developer eligibility

[tepples]

If someone develops for a Sony gadget then it would be natural to port it over to Apple products which will increase their available apps.

Except by the time you are eligible to develop for Sony gadgets, you're expected to already have released an app for the iProducts. Plenty of existing Sony gadgets that run apps, such as PlayStation family products, appear to require all developers to be established companies, not individuals or small businesses.

Re:Global Competitors

[WrongSizeGlass]

Apple is so far ahead in competition compared to its competition.

I nominate this for November's Yogi Berra award.

Re:Bizarre choice

[K. S. Kyosuke]

As others have mentioned in the comments, Objective-C was one of Apple's poorer decisions

I suppose you have a significantly better (simpler and more flexible) compiled OO language suitable for system-level programming up your sleeve, when you talk like that.

Re:Bizarre choice

[beelsebob]

Actually, Objective-C's performance is very very good, and verbosity is absolutely a good thing. The problems I might raise with objective-c would involve it's highly dynamic nature, and lack of a decent type system, not it's implementation's speed or it's code clarity, which are both positive advantages for it!

Cocoa is also one of the absolute cleanest application development frameworks out there by far (CocoaTouch improves on it a chunk though purely by binning a lot of old cruft), so I'd say sony made a bloody good choice.

Discontinued

[Anonymous Coward]

Why is this pushed without mentioning that "SNAP Development is currently on hold" and the source code removed?

C/C++/Objective-C OOP

[mrnick]

I had a difficult time moving from C++ to Objective-C. I think it would have been easier going straight from C to Objective-C. Old habits are hard to break. I thought I new OOP but it was learning Objective-C that really let it sink in.

I learned it as part of my Master's project, an iPhone application, for my graduate studies in Computer Science. I have since setup a Linux box specifically to code in Objective-C.

It really comes down to personal preference. Code in what language you like. Currently I prefer Objective-C.

NP

Re:C/C++/Objective-C OOP

[t2t10]

Why not learn something decent instead, like Ruby or Python?

Re:C/C++/Objective-C OOP

[H0p313ss]

Why not learn something decent instead, like Ruby or Python?

That's funny, you should get that on T-shirts. You could make a bundle from project managers.

Re:C/C++/Objective-C OOP

[asvravi]

[quote] I thought I new OOP but it was learning Objective-C that really let it sink in. [/quote]

So I take it you didn't no OOP?

Re:C/C++/Objective-C OOP

[abigor]

Because he wants to write commercial software that runs on millions of devices? I love Python, but it's not the language one chooses for that sort of thing.

Re:C/C++/Objective-C OOP

[quacking duck]

I thought I gnu OOP but it was learning Objective-C that really let it sink in.

So I take it you didn't gno OOP?

Fixed that for both of you.

Re:C/C++/Objective-C OOP

[t2t10]

He was recommending "code in what language you like". Since Objective-C was his first exposure to dynamic OOP, I suggested broadening his horizons to languages that he might like more.

Ruby and Python both have been used a lot for commercial software. Think of them as better, faster versions of VisualBasic, including native, JVM, and .NET backends. You may be running some commercial Ruby or Python app without even knowing it.

The only reason Ruby and Python aren't choices on iOS is because Apple hates anything that threatens their control over the platform. If they allowed alternatives to their shitty Objective-C tools, there would soon be hardly any Objective-C software left.

Re:C/C++/Objective-C OOP

[bonch]

The moral here is that C++ will ruin your brain.

Re:closed.

[lurch_mojoff]

In what way GNUstep + GCC (+ presumably Linux) facilitate "systems [lock]down and ... prevent after-market modifications" more than "Android-esque / Java"?

Re:Bizarre choice

[onionman]

As others have mentioned in the comments, Objective-C was one of Apple's poorer decisions

I suppose you have a significantly better (simpler and more flexible) compiled OO language suitable for system-level programming up your sleeve, when you talk like that.

I like the D programming language. It's relatively new, but its well designed and multi-paradigm. It's suitable for system-level programming, but still supports higher-lever programming methods such as OO and functional programming.

The world continues to chase apple?

[Assmasher]

Insinuating that SONY making use of Apple inspired development tools/specs/practices/whatever is validation of Apple in some way seems quite strange.

SONY is famous for being absolutely crap and producing/choosing/using development tools.

SONY's picking a development tool set related to Apple's only clear benefit is to people who have had to develop for SONY products in the past - ANYTHING is better than software that came out of SONY.

They sure used to make great hardware though, and that's starting to return a bit.

But adopting Apple-like dev environment(s)...? Water to a man dying of thirst and all that...

Re:The world continues to chase apple?

[konohitowa]

How true. Have you had the displeasure of using their pathetic attempt at an iTunes interface for the Sony Reader? It's only become mildly usable in the most recent revisions. Not that iTunes is an example of awesomeness, but Sony couldn't even get the basics right. The only thing worse than their solution is the plethora of "free" solutions that were rolled for non-supported platforms.

Re:The world continues to chase apple?

[Assmasher]

Not personally.

The thing is, I don't dislike SONY despite the horrific crap they make you work with from a software point of view. So many of their things have this 'touch of genius' that I find myself excusing the most ridiculous things because I can say "but, omg that freakin' thing is FAST!" Then I find myself debugging something at 3AM thinking "I'd like to strangle the f***er that built the cell tool chain..."

Re:The world continues to chase apple?

[konohitowa]

I'm with you. I love my Sony Reader. For me, it's just the right form factor. The Kindle is too big for my tastes and I just don't need a keyboard on my reader. I suppose wireless might be nice, but I don't feel like I'm missing out on anything by not having it. It does the one thing I want -- lets me read books without a lot of eye strain -- and it does it well. I've finally gotten to the point that I'm comfortable with the bizarreness of the associated software, but I still occasionally contemplate rolling my own version.

So - PS3 development?

Re:The world continues to chase apple?

[Assmasher]

A looong time ago, in a galaxy uncomfortably close...

Re:closed.

[Verunks]

This makes total sense - Sony are very similar to Apple in that they lock their systems down and actively prevent after-market modifications. For these reasons, there was no way Sony were going to go down an Android-esque / Java route, so mimicking Apple was the logical choice.

did this just came out of your arse or what? do you think that using java instead objective-c/gnustep will prevent Sony or anyone from locking down the system, or even better do you think that using objective c like Apple will automagically lock down the system?
Oh and by the way Sony Ericsson use android for their phones, and there is some speculation that they will use android 3.0 for the playstation phone

Why not Cocotron?

[hobbit]

As far as I understand it, Cocotron is more concerned with implementing Cocoa rather than OpenStep (i.e. it would be more attractive to iOS developers), and I'd have thought its license (MIT) would be easier for Sony to ensure compliance with than the GPL.

Re:Why not Cocotron?

[hobbit]

I guess I should have searched before I posted, as I see that there's recently been a blog post on the former matter: http://heronsperch.blogspot.com/2010/11/gnustep-is-not-openstep.html
But the latter?

Err, why would you do system level programming...

[Viol8]

... with a language that does run time binding? It sounds like the ideal enviroment for all sorts of trojans , viruses and obscure faults and failures.

Looks like SNAP just shut down

[halfdan the black]

look at the homepage, http://snap.sonydeveloper.com/
it says SNAP development is currently on hold
Now, when I was checking out the site last night, it was all still there, now for some reason, some CEO type decides axe the project. Wonder if Microsoft got wind of this and forced them to shut it down and re-write in visual basic. Perhaps Microsoft threatened Sony by raising their OEM costs or something?

"The world continues to chase apple -- probably fo

[Charliemopps]

"The world continues to chase apple -- probably for the better."

When did Slashdot become a forum for apple fanboys?

GNUstep on Android?

[korpenkraxar]

So how does this fit in with SonyEricsson's current Android efforts?

Re:nice!

[MightyMartian]

I did, and then you came along.

Re:Bizarre choice

[forsey]

I think a lot of people who dislike Objective-C are those who just looked it over and haven't spent too much time with it. I used to feel the same way until I got most of the way through an iPhone app recently. I view it as an acquired taste. Watching the great WWDC videos that Apple provides on it's development site helped me to understand it a lot and learn why they do the things they do with it.

Re:Err, why would you do system level programming.

[abigor]

Can you give some concrete, real-world examples where these have plagued Objective-C applications/systems?

Re:"The world continues to chase apple -- probably

[hrimhari]

It has been a few years since it migrated from a Linux fanboy-only site to a more democratic one. Today, you'll find Linux fanboys, Apple fanboys and surprise! Even Microsoft fanboys! But more importantly, you'll also find people impartial enough to not be fanboy to anything.

Re:closed.

[larry bagina]

It is linux (specifically, Ubuntu 10.9)

Re:Bizarre choice

[marsu_k]

The proprietary "do-whatever-you-please-with-it"-license still exists for Qt. The license is on per developer/per year-basis. Note the absence of handsets in the previous sentence. A company can do anything with the toolkit and not release anything back to the community with the proprietary license. Not that I can think of any reason to do - Qt Quick/QML seems great, and one will be able to achieve a lot easily without modifying the toolkit - which is LGPL, so your $KILLER_APP can be very much proprietary.

Re:Err, why would you do system level programming.

[iluvcapra]

NSInputManagers, but all of that is behind us, or so we keep telling people. ;)

Re:Bizarre choice

[644bd346996]

Are any of those good enough compared to obj-c to overcome the advantage obj-c has of being familiar to far more programmers? From what I've heard, CL might be, but I don't know any of those languages enough to judge.

Also, do any of those languages make it as easy to use C and C++ libraries as Obj-C does?

Re:Bizarre choice

[marsu_k]

I'm sorry, I don't understand what you're getting at. Sony Ericsson (and many other handset vendors) use Android, without having to pay anything to Google. Similarly they could use Qt, and not pay Nokia a dime. Yes, many handset vendors build proprietary UIs on top of Android, but they do so without modifying the core platform. What's stopping them from doing the same with Qt? The framework itself is more than comprehensive for all kinds of things, and LPGL certainly doesn't preclude proprietary UIs.

Re:Global Competitors

[iluvcapra]

Pointing out redundancy is not in itself redundant.

Re:Bizarre choice

[quacking duck]

If you're *starting* a new project, D might be an option, but the GGP's assertion was that Objective-C was a mistake that Apple made.

According to Wikipedia, D first appeared in 1999, long after Apple acquired NeXT and its Objective-C based OS which was the foundation for Mac OS X. iOS is based on OSX, so it follows that they'd re-use the core parts rather than re-write it from scratch and have to maintain two distinct OS programming skillsets, if a different language didn't provide substantial benefits over staying with Obj-C.

Huge disadvantage for system programming

[SuperKendall]

Ada2005,Eiffel,Lisp (with CLOS for OO),OCaml

None of them can work with C code so directly as Objective-C, which is a very large advantage indeed for systems programming, and a decent advantage for other forms of programming too (like being able to use something like a blowfish library with almost no work).

Now that Objective-C has closures, I'm not sure I really see that great a benefit of any of those languages over the drawbacks.

If you like a LISP syntax, consider Nu which is an S-exp based variant of Objective-C and call compatible so it maintains the same benefits.

Re:Huge disadvantage for system programming

[Renegade88]

Ada was designed to work directly with C and other languages. This wasn't tacked on later, it a fundamental part of the language.

Do you even know anything about Ada, or are you just spewing? At least put in a caveat if you aren't familiar with a topic rather than lumping things together with topics you may know.

Re:Huge disadvantage for system programming

[SuperKendall]

I'll ignore the snark as I can understand how you get grumpy when someone criticizes a language you like when you have a deeper understanding of it.

By way of background, I have not programming anything in production with ADA but I have studied it to some extent.

AFAIK you have to generate bindings to work with C from ADA. There's zero extra work for Objective C to use C, and you also can easily mix any C you like right in the middle of Objective-C which (again, AFAIK) is not true of ADA.

Also why would projects like this exist if it were so easy to work with C in ADA?

If you can point to some specific examples showing use of a C library with ADA, I'd be happy to retract that from the list - but honestly, would you want to write a whole OS in ADA? It's in the list as a modern language and it does have some nice features, but to me ADA is just as verbose as Objective-C and I'm not sure it really provides any more ability for coding than Objective-C gives you otherwise. Objective-C is a powerful language, just as you note that I should note critique ADA without experience you should not claim Objective-C is less powerful than ADA without some experience.

Re:Huge disadvantage for system programming

[Renegade88]

It's Ada, not ADA. It's a first name like Sally or Jane.

So yes, you have to create procedures or functions to import C functions. These are often called bindings, and there's a thin and thick variety. There are numerous examples of Ada using C libraries. I've personally rewritten thick bindings for expat and zlib. The GNAT compiler has an in-built function to generate bindings given a C header or a C++ header, so the majority of the work is done for you.

As far as verbosity goes, I don't consider verbosity a detraction although I realize many people do. Yes, it's verbose, although the machine code it gets compiled to isn't much bigger than C.

Also I believe some embedded systems have already been written in Ada. Here's a link to the most secure OS in the world: Integrity RTOS. Green Hills is one the main commercial solutions for Ada, so it's likely most of RTOS is written in Ada or SPARK, although it doesn't say on the product page. There are other Ada OS projects out there, so the answer is yes, somebody wants to write an OS in Ada.

As you suggested, I won't comment on ObjC because I can't speak intelligently about it.

Netscape

[tepples]

Yes, there is a possibility for clashes if someone chooses a string which is the same as yours

Does NS stand for NeXT Software, or does it stand for Netscape?

Re:Netscape

[Anonymous Coward]

Yes, there is a possibility for clashes if someone chooses a string which is the same as yours

Does NS stand for NeXT Software, or does it stand for Netscape?

It refers to NeXTStep, from which OpenStep was derived.

Re:Netscape

[PhunkySchtuff]

Yes, there is a possibility for clashes if someone chooses a string which is the same as yours

Does NS stand for NeXT Software, or does it stand for Netscape?

Neither - it stands for NeXTSTEP

Re:Netscape

[ziggyzaggy]

gee I thought it was the Network Simulator http://sourceforge.net/projects/nsnam/files/allinone/ns-allinone-2.34/ ns-3 is still in development: http://www.nsnam.org/

Re:Netscape

[Leynos]

There was some speculation that it stood for NeXT / Sun (superseding the old NX prefix used before the OPENSTEP days).

Re:Netscape

[badkarmadayaccount]

NeXT Sun

UI Frameworks totally different and Obj-C open

[SuperKendall]

I have not had a chance to look at Sony code examples, but from the summary it's pretty obvious the UI is different - Sony states for instance part of it is based around the cross-media bar...

But realistically when you consider there is already OpenStep which replicates a lot of Cocoa functionality, Apple is not doing anything to anyone. And since all of Apple's improvements to Objective-C compilation (such as additions to GCC and LLVM) are all open source, where do you get the vibe that Apple would try to block other people from using Objective-C?

XNA uses C#, not C or C++

[tepples]

In 2010, it's just stupid. We don't need extensions to C of any form, we need C and its satanic spawn to die.

Sounds like you have never actually shipped any games on modern consoles.

That's a reasonable assumption, given that you have to be an established company with an office just to get a devkit that doesn't use C#.

Consider the IDE too, C# Silverlight is better

[danparker276]

Writing apps for a phone is a like writing 1/10 of a webpage display wise. Good coding / language doesn't matter that much. What really matters is how easy it is to get things done. I've used, C, C++, all sorts of Java, C# asp.net, but C# Silverlight is by far the best. The Visual Studio IDE is great, there is a ton of free forum support, and a lot of people are using it / (lots of sample code)

Re:Consider the IDE too, C# Silverlight is better

[RAMMS EIN]

``The Visual Studio IDE is great''

I hear people praise Visual Studio a lot, but, having used it on a few projects myself, I am not impressed by it. Granted, if you are coding for Microsoft platforms like .NET, it may be your best choice since there isn't a whole lot of competition there. But as development environments go, I wouldn't call it great. It's not horrible, either, but it does have enough bloat, bugs, and missing features to make me rather not work with it.

Add to that that, to use VS professionally, you actually need to pay - for VS and for Windows, and the combination of some things that work in newer versions not working in older versions, and vice versa, and my conclusion is that Visual Studio is a waste of money. You pay, but what you get is not better than what you could have gotten for free - unless you're locked into some Microsoft technology that isn't supported anywhere else.

All this in my opinion, of course, just like what you said is your opinion. If you continue to enjoy VS, that's great! I just wanted to throw this out there to point out that not everybody things Visual Studio is great.

Re:Consider the IDE too, C# Silverlight is better

[aristotle-dude]

Please. Visual Studio is not as great as you are making it out to be. If you took the vanilla VS.NET and tried using it without any third party addons like resharper, you would not be heaping praise on it.

IntelliJ IDEA has mainly of the features that you probably attribute to VS.NET without realizing that they are probably offered by the Resharper instead of built in functionality. The company that created resharper for VS.NET produces IntelliJ IDEA.

Re:Consider the IDE too, C# Silverlight is better

[TrancePhreak]

Visual Studio has come a long way. Sadly, XCode has not. See, things we take for granted like code completion actually work in Visual Studio. XCode you're lucky if it is telling you a function on the "class" you are using and not any of the other "classes". Another thing, Visual Studio has a large amount of things you can change in the settings, and it's pretty easy to use. XCode requires lots of kludging around in sparsely installed files, muddling with settings that are sometimes not documented.

Re:Consider the IDE too, C# Silverlight is better

[grouchomarxist]

That was true about earlier implementations of code completion in Xcode, but around Xcode 3.x it improved significantly.

Re:Consider the IDE too, C# Silverlight is better

[SuperKendall]

Code completion works pretty well in later versions of XCode, and is much better in the newer XCode they are moving to (can't really say much more about that because of NDA). On the fly error checking and all that good stuff too.

And the InterfaceBuilder approach to interface assembly beats code-behind any second of this eon. It's the only GUI development tool that didn't leave me scrambling for GUI assembly in code within seconds. I think in fact it might be the only approach to GUI development tools that makes any sense, after having tried a lot of different tools in Java desktop and Windows development.

Re:Consider the IDE too, C# Silverlight is better

[TrancePhreak]

I'm using 3.2.5 and it's still terrible. It suggests functions from objects other than the one I'm looking for calls on.

Re:Consider the IDE too, C# Silverlight is better

[grouchomarxist]

My guess is that you're running into a bug. Perhaps some index is corrupt. I suggest doing a very clean build and if that doesn't work try asking on some online forum oriented toward Xcode.

Re:closed.

[tepples]

Sony are very similar to Apple in that they lock their systems down

In what way GNUstep + GCC (+ presumably Linux) facilitate "systems [lock]down"

Sony hardware that includes Linux is open until Sony kills the Linux. This happened with the PlayStation 2 when Sony discontinued the Linux kit, and it happened with the PLAYSTATION 3 when Sony killed the ability to use Game OS and Other OS on the same console with a system software update. As of right now, it appears Sony has a policy like that of Nintendo: you have to be an established company or Sony won't sell you a devkit.

How to lock down a PSP phone

[tepples]

there is some speculation that they will use android 3.0 for the playstation phone

How much do you want to bet that Sony will lock down the PSP phone? Let me count some ways it could go down:

• Remove the option to install APKs from "unknown sources", as seen in AT&T branded Android phones such as Motorola Backflip and HTC Aria.
• Restrict GPU usage by APKs not digitally signed by Sony, as seen in the Tapwave Zodiac and the PS3 before system software 3.21.
• Require the presence of a SIM with a suitable voice and data plan, so that it doesn't compete with PSP and PSP Go for the Wi-Fi-only handheld game market.

Re:Bizarre choice

[Anonymous Coward]

To quote Carmack:

https://twitter.com/ID_AA_Carmack/status/28939697453

"A single use of an obj-C number formatter, and it actually shows up in profiles. Obj-C does not belong in high performance apps."

Re:"The world continues to chase apple -- probably

[sootman]

About ten years ago, when Taco got a TiBook and Mac OS went all UNIX-y. Where have you been?

Re:Bizarre choice

[Anonymous Coward]

The fact that a single, rarely-used class is somewhat slow is in no way an argument against a langauge.

Re:Bizarre choice

[HeronBlademaster]

Claiming Objective-C is "familiar to far more programmers" is a stretch at best. I'm a C/C++ programmer, and I've been working with Java for a long while now, but I still find Objective-C's "messaging" syntax and its idiotic class definition syntax to be unintuitive and nigh-unreadable, despite the language's C-like appearance much of the time.

Seriously, what idiot decided "+" and "-" are better choices for distinguishing between class methods and instance method than using C's existing "static" keyword for one and defaulting to the other?

I added the "chase Apple" zing to get accepted

[EMB Numbers]

I added the "chase Apple" zing in order to get the submission accepted by slashdot. There is a recipe. Deliberately omit important details from the summary, include something slightly inaccurate, and end with a zing.

It drives responses. People post to add the missing important detail. People post to correct or clarify the slight inacuracy. People post in response to the "zing." I have been doing this for years. Follow the recipe any your submissions will be accepted too.

Re:Bizarre choice

[Cinder6]

If Objective-C has the performance of a scripted language, then how is it that my Mac runs as fast or faster than my Windows machine?

Re:Bizarre choice

[644bd346996]

I was referring more to the fact that there are a great many programmers developing apps for Apple platforms, but Ada and Eiffel programmers are harder to find. CL and Ocaml are probably too abstract to catch on in a market where the average programmer can handle Java and some of C++'s capabilities.

foregt Java

[zakeria]

objective-c is long overdue in the Linux world... I've been a programmer some 25 years now and I have to say I nothing comes close to using objective-c, I just wish it looked better thats my only problem I have with it it's just hard to read.. We need more developers using O-C it would make Linux a better place.

Re:"The world continues to chase apple -- probably

[goosesensor]

a few years ago.

Re:"The world continues to chase apple -- probably

[ziggyzaggy]

now that's funny, what with Google-warez being the mega-Linux distro/app/service the whole fucking planet runs.

Objective-C in a nutshell

[Coward Anonymous]

These two quotes just about sum Objective-C:

"Objective-C is simple. It just takes a genius to understand its simplicity"

and:

"Those who don't understand Objective-C are condemned to reinvent it, poorly"

With apologies to Dennis Ritchie, Henry Spencer and Unix.

Re:Objective-C in a nutshell

[shutdown -p now]

I have a third one to add:

"Objective-C combines all the performance of Smalltalk with all the convenience of C".

Re:Bizarre choice

[TrancePhreak]

Or it could be that they used XCode and it gave them a function from another class that wasn't on the class they were using. The program then proceded to compile just fine and when they ran it, it didn't work but there were no clear indications why.

Re:Bizarre choice

[Durandal64]

Yes, because the "static" keyword hasn't been overloaded at all.

Re:Bizarre choice

[shutdown -p now]

As I'm not an Obj-C or Cocoa developer, I don't know what Carmack has meant by this quote, but it sure sounds like whatever is the Obj-C analog to printf("%d"). orrect me if I'm wrong. If I am not, then that's not a "rarely-used class".

Re:Bizarre choice

[grouchomarxist]

It isn't clear what Carmack exactly meant because that class can be used for both converting strings into numbers (ints or floats) or numbers into formatted strings, such as currency values. It has performance penalties, but it isn't the only way to do conversion. To do something like printf("%d", value) in objective-c you can just use printf("%d", value).

Re:Bizarre choice

[HeronBlademaster]

Fair enough, but it would still be a lot clearer than "+".

Target platforms?

[TeamSPAM]

Does anyone know what hardware this would run on? While I expect that using Objective-C and GNUStep may get some iPhone developers to try this platform. I wouldn't expect much a lot of code iOS to be portable. The UIKit framework is the core that runs iOS apps, which is something that GNUStep does not have at this point. Is Sony planning on have a touch interface or something more conventional?

ObjectiveC++

[bgspence]

The Objective-C language syntax was carefully designed to co-exist with C and C++. It may look a bit different than C or C++, but that is by design. It was designed to mix into both. It therefore required a syntax style which would be unambigious. It had to look different, or it would have just been sm odd flavor of C or C++.

Here is what Apple says about 'Using C++ With Objective-C': http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html

"Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file. This Objective-C/C++ language hybrid is called Objective-C++. With it you can make use of existing C++ libraries from your Objective-C applications.

"In Objective-C++, you can call methods from either language in C++ code and in Objective-C methods. Pointers to objects in either language are just pointers, and as such can be used anywhere. For example, you can include pointers to Objective-C objects as data members of C++ classes, and you can include pointers to C++ objects as instance variables of Objective-C classes."

If you want to use C or C++, go right ahead. The Objective-C language includes ALL the capabilities and drawbacks of both C and C++.

Re:"The world continues to chase apple -- probably

[Xylona]

Yeah, that can make it tough when you are staring at the computer all day.

Re:Bizarre choice

[bonch]

Objective-C is kind of blah these days. It has the performance of a scripting language with the verbosity of a compiled language (I'm exaggerating but not much). No thanks.

You're absolutely exaggerating. Objective-C is C with an object-oriented run-time, and so it has the performance of C. The overhead of sending messages through the run-time is little more than that of a function call.

Re:Bizarre choice

[bonch]

Your post is so misinformed. Objective-C is one of the reasons Cocoa is such a beloved and powerful framework, Steve Jobs had nothing to do with GNUStep, and you provide zero evidence or examples to back up your claim that "it's just obsolete and never worked that well to begin with."

In fact, you're another one of these suspicious, anonymous posters who seems to show up in every Apple article, bashing their technologies. It's getting way too predictable to be a coincidence.

Re:Bizarre choice

[SteeldrivingJon]

NSFormatters are usually attached to text fields or cells in a user interface, for things like formatting internationalized dates or numbers. With numbers it includes the sort of pretty-printing you see in spreadsheets (red for negative numbers, etc), maximum/minimum checking, etc. For dates I believe formatters will handle converting a string like "tomorrow" to the appropriate date.

If you just want to create a formatted string, you can use [NSString stringWithFormat:@"%d", anInt].

Or even printf.

Re:Bizarre choice

[master_p]

I suppose you have a significantly better (simpler and more flexible) compiled OO language suitable for system-level programming up your sleeve, when you talk like that.

Yes. It's called C++. Which is significantly better than ObjC, and almost as simple and flexible.

And before you say anything, consider the fact that BeOS was largely programmed in C++. If the most flexible, fastest and most responsive multimedia operating system ever produced is not a testament to C++'s power, I don't know what it is.

Re:Bizarre choice

[master_p]

The overhead of sending messages through the run-time is little more than that of a function call.

No, it is not. It has significant overhead. WTF, doesn't anybody here understand how message passing works? Each time an ObjC message is passed to an object, the run-time does a search in a map to find the implementation!!!! WTF, what is wrong with Slashdot!!!!! has it become so popular that we can't understand how searching in a map works vs a vtable indirection!!!!!!

Please excuse my tone, but I've read lots of comments about ObjC today, most of them either wrong or exaggerating. It's amazing that a site proud for its members being technically skilled with computers to be ignorant of such basic facts!!!

Re:Bizarre choice

[suy]

Qt is not fully owned by Nokia right now, and is moving to be a fully openly governed project. And Qt has now Qt Quick, which is a system for developing apps using a declarative language, and can be mixed with C++ very nicely. I've been playing with it lately, and is a great product.

C++ can be as flexible as ObjC...

[master_p]

For those who say C++ cannot be as flexible as ObjC, I wrote a little C++0x class and example that demonstrates how easy it is to have message passing in C++.

C++ is not a superset of C

[Arker]

That's exactly what I said, and it's true.

Re:Bizarre choice

[iluvcapra]

WTF, what is wrong with Slashdot!!!!! has it become so popular that we can't understand how searching in a map works vs a vtable indirection!!!!!!

All of the implementation addresses are cached when run for the first time, and it's usually inlined; after the first invocation a message usually is only a cycle or two slower than a vtable indirection, given the normal caveats. objc_msgSend is extremely optimized, it's the single most called function on the platform so it gets a lot of attention from optimizers.

Re:Bizarre choice

[murr]

Cocoa crucially depends on reflection features of the underlying language (obtaining classes, calling methods and manipulating data members by name). Lisp would obviously qualify for this (for sufficiently large values of "Lisp"), but standard Ada and Eiffel would be completely unsuited to the task, and I doubt OCaml would be suited.

I could see Ruby become an increasingly serious contender, though. Right now, the primary problem is that debugging is messier than in an Objective-C app, but otherwise, it's an excellent match.

Re:Bizarre choice

[iluvcapra]

Apple's implementation of Objective-C also offers vtable dispatching as an optimization since Mac OS X 10.6, and benchmarks indicate little chance that either approach gives you much improvement on modern hardware.

(Don't mean to keep posting but I did some more reading this morning and I found it interesting.)