Forgot your password?
typodupeerror
GNUStep Programming Sony Apple

Sony Adopts Objective-C and GNUstep Frameworks 345

Posted by samzenpus
from the new-way-of-doing-things dept.
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."
This discussion has been archived. No new comments can be posted.

Sony Adopts Objective-C and GNUstep Frameworks

Comments Filter:
  • Re:How compatitble (Score:5, Informative)

    by TheRaven64 (641858) on Thursday November 25, 2010 @10:05AM (#34342292) Journal
    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.
  • Summary is incorrect (Score:5, Informative)

    by zr-rifle (677585) <zedr@@@zedr...com> on Thursday November 25, 2010 @10:12AM (#34342332) Homepage
    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 [gnustep.org]
  • Re:For the better? (Score:5, Informative)

    by lurch_mojoff (867210) on Thursday November 25, 2010 @10:58AM (#34342574)
    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? (Score:2, Informative)

    by nicholas22 (1945330) on Thursday November 25, 2010 @10:58AM (#34342578)
    "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? (Score:5, Informative)

    by Graff (532189) on Thursday November 25, 2010 @11:45AM (#34342912)

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

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

  • by t2t10 (1909766) on Thursday November 25, 2010 @12:10PM (#34343126)

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

  • by rxmd (205533) on Thursday November 25, 2010 @12:34PM (#34343324) Homepage

    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:For the better? (Score:4, Informative)

    by Graff (532189) on Thursday November 25, 2010 @12:46PM (#34343442)

    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 [apple.com]

    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 [mulle-kybernetik.com]

  • Re:For the better? (Score:4, Informative)

    by muecksteiner (102093) on Thursday November 25, 2010 @12:46PM (#34343448)

    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:Bizarre choice (Score:3, Informative)

    by marsu_k (701360) on Thursday November 25, 2010 @01:05PM (#34343586)
    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:For the better? (Score:4, Informative)

    by UnknownSoldier (67820) on Thursday November 25, 2010 @01:50PM (#34343844)

    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? (Score:4, Informative)

    by Graff (532189) on Thursday November 25, 2010 @01:50PM (#34343848)

    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 [cocoadevcentral.com]
    ChooseYourOwnPrefix [cocoadev.com]

  • Re:Bizarre choice (Score:3, Informative)

    by quacking duck (607555) on Thursday November 25, 2010 @02:10PM (#34343966)

    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.

  • by SuperKendall (25149) on Thursday November 25, 2010 @02:24PM (#34344078)

    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 [programming.nu] which is an S-exp based variant of Objective-C and call compatible so it maintains the same benefits.

  • Re:Apple's response? (Score:3, Informative)

    by codegen (103601) on Thursday November 25, 2010 @02:31PM (#34344140) Journal

    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:For the better? (Score:1, Informative)

    by Anonymous Coward on Thursday November 25, 2010 @03:05PM (#34344366)

    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:Netscape (Score:1, Informative)

    by Anonymous Coward on Thursday November 25, 2010 @04:54PM (#34345122)

    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 (Score:3, Informative)

    by PhunkySchtuff (208108) <kai&automatica,com,au> on Thursday November 25, 2010 @05:24PM (#34345302) Homepage

    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:How compatitble (Score:5, Informative)

    by HeronBlademaster (1079477) <heron@xnapid.com> on Thursday November 25, 2010 @05:45PM (#34345454) Homepage

    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

  • by goosesensor (1431303) on Thursday November 25, 2010 @05:54PM (#34345524)
    a few years ago.
  • Re:How compatitble (Score:3, Informative)

    by shutdown -p now (807394) on Thursday November 25, 2010 @09:51PM (#34346874) Journal

    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.

This screen intentionally left blank.

Working...