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 :)

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?

[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?

[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?

[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?

[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?

[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?

[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: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.

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?

"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?

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: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:"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: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.

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: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

[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: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:How compatitble

[Anonymous Coward]

your post just proves you never done anything in really productive languages like C#, python, ruby, ... objC is simply miles behind those

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

[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

[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: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.