Sony Adopts Objective-C and GNUstep Frameworks 345
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."
Apple's response? (Score:3, Interesting)
Re:Apple's response? (Score:2)
Re:Apple's response? (Score:3, Interesting)
Re:Apple's response? (Score:3, Informative)
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? (Score:2)
Re:Apple's response? (Score:2)
Re:Apple's response? (Score:2)
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? (Score:3, Interesting)
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? (Score:2)
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...
Developer eligibility (Score:2)
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:Apple's response? (Score:3, Insightful)
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? (Score:4, Insightful)
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.
Who does what? (Score:5, Insightful)
Or more accurately, One foreign company adopts a compiler.
For the better? (Score:2, Insightful)
"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? (Score:3, Insightful)
Re:For the better? (Score:2)
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? (Score:4, Insightful)
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? (Score:3, Interesting)
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? (Score:5, Insightful)
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? (Score:5, Insightful)
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? (Score:4, Interesting)
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? (Score:4, Insightful)
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? (Score:2)
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? (Score:4, Insightful)
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.
Comment removed (Score:4, Informative)
Re:For the better? (Score:4, Informative)
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]
Netscape (Score:3, Insightful)
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 (Score:3, Informative)
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:For the better? (Score:5, Informative)
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.
Re:For the better? (Score:2)
Nice link on Reflection, every now and then I wish I could do that but didn't know I could.
Re:For the better? (Score:4, Informative)
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)
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:3, Insightful)
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? (Score:2)
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? (Score:2)
> 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? (Score:5, Interesting)
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/ [apple.com]
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 [vim.org], 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 [github.com]. Test driving my apps with Pivotal's Cedar [github.com] framework.
Re:For the better? (Score:5, Informative)
Re:For the better? (Score:3, Insightful)
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? (Score:2)
Isn't syntax just a personal preference? I actually quite like ObjC's syntax. What don't you like about 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.
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? (Score:2)
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? (Score:2)
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? (Score:2, Informative)
Re:For the better? (Score:2)
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? (Score:2)
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?
Summary is incorrect (Score:5, Informative)
Please read the definition [gnustep.org]
Re:Summary is incorrect (Score:2)
Less money for them for common functionality, more ability for me to see what's causing a bug.
Re:Summary is incorrect (Score:2)
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 (Score:3, Informative)
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 (Score:2)
Apple do open source their implementation for things like strings... here it is:
http://opensource.apple.com/source/CF/CF-550.42/ [apple.com]
C/C++/Objective-C OOP (Score:3, Interesting)
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 (Score:2, Informative)
Why not learn something decent instead, like Ruby or Python?
Re:C/C++/Objective-C OOP (Score:2)
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 (Score:2)
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 (Score:3, Funny)
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.
The world continues to chase apple? (Score:4, Interesting)
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...
"The world continues to chase apple -- probably fo (Score:3, Insightful)
When did Slashdot become a forum for apple fanboys?
Re:"The world continues to chase apple -- probably (Score:4, Insightful)
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.
Objective-C in a nutshell (Score:4, Funny)
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:How compatitble (Score:5, Informative)
Re:How compatitble (Score:2, Interesting)
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 (Score:2)
Give me good old C++ any day of the week.
ROFL... yeah... nothing more to be said, really...
Re:How compatitble (Score:4, Insightful)
Re:How compatitble (Score:2)
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 (Score:3, Funny)
Re:How compatitble (Score:3, Funny)
Fingers are overrated.
I typed this faster than you did.
Re:How compatitble (Score:5, Insightful)
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 (Score:3, Interesting)
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 (Score:4, Interesting)
Re:How compatitble (Score:2)
Re:How compatitble (Score:2)
Well, Apple's customer service policies and support agreement would stop it, for any commercial development anyways, but nothing "technically."
Re:How compatitble (Score:4, Interesting)
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 (Score:3, Funny)
So, I take it one would need two code bases?
Objective-C: All your code bases are belong to us
Re:How compatitble (Score:3, Funny)
Idjit! That won't compile. Try:
[codeBases allYourAreWithBelongToUs:YES];
Re:How compatitble (Score:3, Insightful)
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 (Score:3, Interesting)
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 (Score:5, Informative)
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 (Score:3, Informative)
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 (Score:3, Insightful)
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 (Score:3, Interesting)
Re:How compatitble (Score:2)
The summary is (surprise!) wrong. GNUstep has been following Cocoa for a while. So says this guy [blogspot.com].
Re:Bizarre choice (Score:5, Insightful)
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 (Score:3, Informative)
Re:Bizarre choice (Score:2)
Re:Bizarre choice (Score:5, Insightful)
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.
Re:Bizarre choice (Score:3, Insightful)
The fact that a single, rarely-used class is somewhat slow is in no way an argument against a langauge.
Re:Bizarre choice (Score:4, Insightful)
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 (Score:3, Interesting)
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.
Re:Bizarre choice (Score:3, Informative)
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.
Err, why would you do system level programming... (Score:2)
... 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.
Re:Err, why would you do system level programming. (Score:2)
Can you give some concrete, real-world examples where these have plagued Objective-C applications/systems?
Re:Err, why would you do system level programming. (Score:2)
Re:Bizarre choice (Score:4, Interesting)
Re:Bizarre choice (Score:3, Insightful)
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.
Huge disadvantage for system programming (Score:3, Informative)
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:Bizarre choice (Score:3, Interesting)
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?
Re:Global Competitors (Score:2, Redundant)
Apple is so far ahead in competition compared to its competition.
I nominate this for November's Yogi Berra award.
Re:Global Competitors (Score:2)
Re:closed. (Score:2)
Re:closed. (Score:2)
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
Re:nice! (Score:3, Funny)
I did, and then you came along.