Slashdot Mirror
Objective-C Comes of Age
New submitter IdleThoughts writes "Sometimes it takes a long time to spark a revolution. Long the ugly duckling of programming languages, iOS' Objective-C passed C# in the 'TIOBE Programming Community Index this month and seems on a trajectory to overtake C++ in the next few. It was invented in the early 1980s by Brad Cox and Tom Love, with the idea of creating 'Software Integrated Circuits' and heavily influenced by Smalltalk — yet another legacy from Xerox PARC, along with desktop GUIs, ethernet and laser printers. It was adopted early on by Steve Jobs' NeXTStep, the grand-daddy of all that is now OS X. It had to wait, however, for the mobile device revolution to have its day, being ideally suited to the limited resources on portable devices. It's still being actively developed by Apple and others, sporting the new automatic reference counting and static analysis in the Clang compiler. It turns out it has supported dynamic patching of code in applications all along. What more surprises does this venerable language have up its sleeve?"
Clang recently added literal syntax for collections and boxed numbers:
NSArray *array = [NSArray arrayWithObjects:@"one", @"two", @"three", nil];
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:
@"bar", @"foo",
@"post", @"first",
nil];
NSNumber *num = [NSNumber numberWithInteger:42];
NSArray *array = @[ @"one", @"two", @"three" ];
NSDictionary *dict = @{
@"foo" : @"bar",
@"first": @"post"
};
NSNumber *num = @42;
Properties will also be synthesized by default, so you won't have to write @synthesize statements anymore, and corresponding ivars will be synthesized with an underscore prefixed name.
Objective-C is interesting to follow because it's a language that was once considered totally niche and almost completely irrelevant, but the frameworks were beloved by developers, and the language's keepers kept at it long enough for the world to see how useful the language is. It also has historical significance as the tools used for creation of the original WorldWideWeb program as well as the development of Doom and Quake. John Romero wrote about he and Carmack simultaneously editing the same map in DoomEd thanks to distributed objects.
It's still verbose and Smalltalk-ish, but the language as a whole has improved drastically since the transition to Clang. According to the mailing list, Apple has more engineers allocated to the language than ever before, and a lot of it has to do with the move away from GCC.
I hear that GCC is working toward being easier to modify, so the competition from Clang has been good for everybody, and it's all open source.
By my figuring it was legal in the mid-to-late 2000s.
I'm the real Vorokrytin P. Winterbuttocks.
Its recent success has obviously been tied to one gigantic hit platform, for which it is the only natively supported PL.
TIOBE Again??
Fine language in many ways but I call 'Boo' on the method syntax.
Look, I understand that people who use their tools daily want to advertise them and it's a goosd thing if you like what you're using, but let's face it: Objective-C is just another unsafe, hopelessly outdated extension of C as C++. It's great to get things done and sucks less than C++, but it's not in any way a modern language nor is it based on a great language design.
Before people start flaming me, please consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself. There is no doubt that Objective-C has its place and is useful, just don't try to sell it as the latest great new thingy. Even Apple's own old Dylan was a more interesting and innovative as a language than Objective-C.
My 2 cents. Now let the language flamewars commence.
This trend is interesting because it kind of dovetails with the fact that fewer and fewer developers are choosing GNU-based/FOSS licenses for their work -- this and the fact that iOS is attracting developers in droves away from pure FOSS pursuits. While Linux and FOSS are interesting and while I do use quite a bit of it, at least iOS is not balkanized. Walled-in garden, whatever. It just works the vast majority of the time and Sally Secretary could give a damn about software license politics -- and that's what they are. The four freedoms are nice, but in the real world, no one but the zealots cares. And even if you do care, if you're not a coder with mad skills, you cannot do anything anyway. That's like saying "yeah, you can buy this Ferrari -- if you have the $250,000 it takes."
I've been in IT now for 15 years and there have been maybe two times where the license issue matered and that was simply because I needed to install a single piece of software on about 30 machines. I chose a FOSS solution because of fiscal concerns.
iOS, Objective-C and Clang are now the interesting bets.
Seems like every few weeks someone writes another story about the amazing "trends" in the TIOBE Index. As far as I can see, the real trend is: Languages go up in popularity, they go down, they move around, one month it's the First! Time! Ever! that a language has made the list, the next month it's gone again, and C, C++, and Java are always at the top (in varying order). Such variable results suggest that TIOBE's sampling method isn't all that reliable or accurate to begin with, but I think we all have a pretty good idea what languages people are really using and for what.
Breakfast served all day!
And I mean extreme barfing! A terrible language with terrible syntax, semantics, and protocols.
What a waste of time for programmers everywhere!
Don't you mean the "daddy" of OS X? I thought OS X *is* the Next OS but overlaid with the Mac desktop.
Also why is it called iOS Objective C? Is objective-C only available through Apple?
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
Where's XCode for non-Mac? Not everyone wants to get $500 in redundant hardware to run software.
You save $500 on hardware but spend $500 on Microsoft Visual Studio Pro. So its a wash. However when you consider that the hardware lets you dual boot Mac OS X or Microsoft Windows the Mac seems like a win. Especially when you consider Mac OS X offers you a really nice Unix environment if one is so inclined.
Look, I understand that people who use their tools daily want to advertise them and it's a good thing if you like what you're using, but let's face it: C is just another unsafe, hopelessly outdated extension of assembly. It's great to get things done and sucks less than fortran, but it's not in any way a modern language nor is it based on a great language design.
Microsoft's previous pronunciations on the future of windows programming (all HTML 5, no place for .Net) has driven people away from C#. Look at the graph details and they match with the initial platform announcements on Windows 8. Uncanny.
Messaging has never been their strong suit.
What the fuck does this have to do with Apple?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
You are delusional. You see shills everywhere. You accuse everyone who says anything good about Apple or Microsoft of being a shill. You have called Mac/iPhone developers Microsoft shills when they fairly point out something Microsoft did right.
You are just a cyber-stalker with a hard on for a couple of posters. You are not a crusader. You are just a silly spammer with a weird hobby. Get over yourself.
Objective-C is just another unsafe, hopelessly outdated extension of C as C++.
Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure - mostly you are never using C arrays or the like. Just because they are there does not make the language inherently "unsafe" if that's not how real people use the language.
consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself.
Objective-C currently has some of the most advanced libraries for any platform. It already had great string support and other strong frameworks even before iOS, but with iOS and the Mac taking off the framework support for really advanced animations, database work, networking, etc. as good as or better than any other platform. I came from a Java world and am missing nothing for libraries... not to mention a really good set of open source libraries that offer other abilities in addition to the core frameworks.
In fact, I would go so far as to say the range and quality of design of the frameworks are THE reason to use Objective-C.
People like you just look at when Objective-C was developed and think because of its age it cannot be "modern". What you don't realize is that Objective-C was developing over all that time, just in a fairly parallel path to other languages - I like to refer to it as a "Steampunk" language. It is modern but just not quite the same as other things you are used to, coming from an alternate reality.
You're going to have to come up with real reasons for Objective-C not being "modern", most of which are probably quite out of date by now. Before we can flame you, there need to be specifics which we can skewer...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I dev in ObjC on iOS almost every day, and the language sucks. I think it sucks less than C++, but I'm not sure that says much. The Xcode IDE (which also sucks) and the bolted-on features help, but overall the language hasn't aged as well as plain old C - i.e. while coding in it, you are constantly reminded that it is not a modern programming language. Anytime a language gets in your way, it's a bad thing, and that happens an awful lot with ObjC.
(And before the flames start: yes, I fully recognize that nobody is forcing me to dev for the iOS platform, it's a choice I've made because I make gobs of money off of it. But that doesn't make ObjC suck any less, it just makes me willing to tolerate the suck and grumble about it on /.)
His writing sounds like it came straight out of a USA Today puff piece. I guess he hasn't yet learned to change the tone of his writing when posting informally online. (See http://www.paulgraham.com/submarine.html)
What more surprises does this venerable language have up its sleeve?
Theres only one way to find out, and it involves wading through extraordinarily long, unintuitive, and overly verbose object, property, and method names until, Surprise!, you find yet another feature of limited utility.
https://www.eff.org/https-everywhere
OSX is NOT the NeXT OS with the Mac GUI. That would be much better.
In fact it can be claimed to be a lineal descendent of NeXT, but it's been greatly modified, and the new UI is a regression from either the Mac or NeXT GUIs.
Also iOS - Obj C is obviously referring to the proprietary dialect of ObjC used in Apple mobie devices. (Nothing to do with Cisco iOS either, why cant they think of their own names for this stuff?) There are other dialects, notably the GCC version, which is much more widely applicable.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
When I evaluate a language the first thing I do is look at a random block of code and say to myself is this what I really want to be writing?
When I look at lisp all I see is endless streams of ()()())))) and my brain instantly reboots in a violent seizure.
jquery would be a decent system if only I could get over the rediculous hackish syntax needed to workaround underlying JS environment.
ASP and close neighbors were always a turnoff due to the weird escape sequences you needed to plaster absoultely everywhere more recently razor cleaned that up somewhat.
Objective c has too many perlish @ symbols and a rediculous number of [] [][][ ][][][] [] contraptions all over the place. I know this sounds and is shallow but when I look at code I really need to see the code not have to look under layers of syntatic nonsense existing only for convenience or compatibility/interop purposes.
Give me a capable clean language not hacks upon hacks.
Given enough time any language can be made useful... this does not mean I would ever willingly choose to use it. I'm instantly wary of languages with only one killer app (iphone) unless it is heavily domain specific.
Of course not, it's just a programming language. Sort of like C. Actually, it is C, well sort of, with some things added but down there you have C, even the parts that C++ removed from it.
Not entirely limited to Apple:
http://www.gnustep.org/
The asterisk next to his name means he's a subscriber, dumbass. Subscribers see articles before non-subscribers. You can write a reply in the box and submit it when the story goes live.
Objective-C is not exclusive to Apple platforms, they just happen to be one of it's most prominent supporters. As a matter of fact the GNU project has actually for long time been a supporter of the language due to its use in GCC and through the Gnustep project.
Its recent success has obviously been tied to one gigantic hit platform, for which it is the only natively supported PL.
To be clear, objective-c is only required for iOS user interface code. An iOS developer is free to use c/c++ elsewhere, free to use posix rather than iOS for many operating system services, etc.
I mean, that's the simple explanation. If Apple wasn't having a resurgence, would anyone be paying attention to Ojective-C?
Please do not read this sig. Thank you.
Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure - mostly you are never using C arrays or the like. Just because they are there does not make the language inherently "unsafe" if that's not how real people use the language.
There is a common consensus in the CS community that pointers as opposed to references, pointer arithmetics, direct type conversion ("memory overlays") etc. are unsafe, and a language that makes it easy to use them is "inherently unsafe". (That doesn't have anything to do with actual programming practise. Obviously, you can write "safe" programs in any language, even in machine code, as long as you're very careful.) As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.
As for "modern": Perhaps you haven't seen any modern programming languages yet? Because otherwise you should know what I mean. Relatively modern features are e.g. automatic type inference, automatic parallelism, contracts, a concurrent garbage collector -- things like that.
What is the percentage of software projects being developed for Mac OS X? iOS, on the other hand, currently dominates the smarthphone market and development on this platform is mainly done in Objective-C, which explains the statistics. But it's a "dynamic" situation, as we are all aware.
>>>the new UI is a regression from either the Mac or NeXT GUIs.
So you're saying OS X GUI is actually inferior to the Classic OS 9, or the old NeXT computer's GUI? Interesting. I jumped from OS 8 to OS 10.2 and didn't really notice any major differences in the desktop (except the new tab bar at the bottom). Maybe I just didn't use it enough. Why do you think OS 10 is inferior?
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
Why do you claim it is "unsafe"?
He may be using unsafe in the same way as Microsoft. See this.
From that page:
... code that makes low-level API calls, uses pointer arithmetic, or carries out some other unsavory operation, has to be placed inside blocks marked with the unsafe keyword.
Heh, "unsavory". Personally, I think pointer arithmetic is delicious!
Tiobe's data is an indicator of how active internet based discussions on each programming language. Even Tiobe says it themselves:
"What programming languages are hot in the Internet discussions? "
and
" Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written." (http://www.tiobe.com/content/paperinfo/tpci/index.html)
All the graph on that link above shows is there's been an increase in the amount of discussion on Objective C. You can say it's due to an increase in adoption, or you could say it's due to people being absolutely fitful with learning it. There's no way to tell what the data means. You may as well google " sucks" and count the results.
I think the author/submitter is being very hopeful in the way they have construed the data.
Join the Slashcott! Feb 10 thru Feb 17!
If you want a cleaner slasdot, free from shills, mod this astroturfing account down.
No, if YOU want a cleaner slashdot, then stop posting as AC.
There is a common consensus in the CS community that pointers as opposed to references, pointer arithmetics, direct type conversion ("memory overlays") etc. are unsafe
In ObjectiveC we are really using objects more as references than as pointers.
Basically you come off here as just being afraid of something because you've been told it's scary, not because you've seen real issues.
As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.
Exactly my point, As I said, I was a Java programmer (for almost a decade) - Objective-C is not really less safe at this point in practice. I say that in terms of stability and in terms of memory use (since you still do not say what you mean by "safe" and the world offers many perils).
As for "modern": Perhaps you haven't seen any modern programming languages yet?
Snark alert. As I said, I used Java for a LONG time. Before that I knew better languages still, Scheme and other things... Perhaps you have not worked with enough different languages to know what is really "safe" and what is not.
Because otherwise you should know what I mean.
I don't automatically agree with snobs.
Relatively modern features are e.g. automatic type inference, automatic parallelism, contracts, a concurrent garbage collector -- things like that.
You're still using a garbage collector? Do you watch that operate while gnawing on woolly mammoth bones or what? ARC is a far superior approach as it involves no overhead.
As for contracts... you really don't know Objective-C at all, do you?
You just come off as some ancient CS grad-school twat totally removed from real world programming. I've worked on large systems for multi-national corporations, and now on mobile applications used by millions of people. I don't automatically assume anything anymore, as experience I have found teaches you a lot more than mere theory or some summary of a language you have read on a blog.
Don't judge any language until you've tried to solve real problems with it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Hi bonch
Nice to see that this time you didn't forget to logout from one of your sockpuppet accounts, like you did when you burned your StarcraftWin account.
http://search.slashdot.org/comments.pl?sid=2844371&cid=39970917
Absolutely!
Back a few years ago when OSX was new, Tog posted a good, though brief and certainly incomplete, article about the regressions from OS9. You can read that here: http://www.asktog.com/columns/061PantherReview.html
I dont know off the top of my head of a good comparison of the same type versus NeXT but one could certainly be done and it would look no better in comparison. The NeXT dock or the old Apple menu were both excellent designs, the OSX version of each is an obvious regression, confusing, inconsistent... even the windows widget layouts degraded badly. Classic Mac OS has three widgets, two on the right that have non-destructive functions, and a single button on the left with the destructive (close) function far away from the nondestructive controls. NeXT refined that a bit, with only two buttons, on opposite sides of the window, still keeping the destructive function far from the other one (and adding some 'hidden' functions for power users in a convenient spot where they wouldnt interfere with those who don use such things.) In both cases, the buttons themselves are also distinguished visually with simple, contrasting geometric shapes.
But on OSX, you have 2 nondestructive and one destructive control bunched together in one tight group without separation, "glowing gumballs" without distinctive shapes. It's unquestionably a massive regression, whether you measure from OS 9 or from NeXT.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
The thing about bonch's (likely the parent AC) trolling/shilling is that they're so damn obvious -- they all fit the same pattern. Early (usually first, within the first minute or two that the article shows up) post, longish posts that would have been impossible to compose in less than a few minutes, immediately modded to +5 by all the high-UID sockpuppets, frequently with offtopic crap about Google (especially when it's a positive article about Google -- he always derails the conversation to bash them in some way).
There really aren't that many shills on the site -- it's mainly fanbois. I thought bonch was just a sad fanboi for quite a while as well, but the posting pattern of all of his sockpuppets matches his main account so well that there's just no way it can be coincidence.
--Jeremy
Jesus was a liberal
And just like iOS, it's impossible to do an Android app without using Java.
Really? Not that I would suggest it but the documentation and sample applications named "native-x" seem to say otherwise!
http://developer.android.com/sdk/ndk/index.html
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
What you are saying is that you don't really know anything about Obj-C. Its pointers really are references, and unless you decide to embed C code, you will never do casts or pointer arithmetic. Using your same logic that the availability of these in the language make it inherently unsafe, you could make the case that javah/jni makes Java an unsafe language.
Objective-C has a concurrent GC, along with Automatic Reference Counting which is far more efficient and would probably fit in as "modern feature" that no other language currently has. It also has managed queues for easy and efficient parallelism and supports DbC as good or better than any language that has any significant market share.
What does that leave out of your list... type inference. Oh boy, I certainly can't live without that!
I think there's a helicopter outside your house.
It had to wait, however, for the mobile device revolution to have its day, being ideally suited to the limited resources on portable devices
WTF? New iOS devices are more powerful than NeXTStep and original OS X machines.
The reason it became popular is because the iPhone & iPad are very popular in the mobile space. They aren't popular because of Obj-C, but rather a combination of user experience and marketing. Not only that, but if you want to develop on iOS, you have the choice of... Obj-C.
On the Desktop computer side of things, "Visual studio" is probably the most popular development environment, in part because Windows is the most popular platform, but even then there's still a choice of lanuages: VB, C++, C#.
Not only that, but if you want to develop on iOS, you have the choice of... Obj-C.
That is not at all true, you can use C#, Ruby, Javascript, and other languages also...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In the mid 1980s ObjectiveC was product supported by a software company while C++ an open-source hobby. I was a NeXT developer then. I can see why Steve would have wanted to go with something a little more solid. But it was that C++ was more open and FREE that made more attractive to the university crowd and hackers. So it leapfrogged over ObjectiveC for a long while.
If so, he's still wrong - we don't do anything that would be meant to go inside an "unsafe" block in normal Obj-C programming.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Objective c has too many perlish @ symbols and a rediculous number of [] [][][ ][][][] [] contraptions all over the place.
It has a handful of @ symbol constructs, and with the use of properties now most code does not have a ton of [] the way Lisp like languages do...
Good Objective-C code is really clear because of the named parameters, with a good IDE verbosity in method names does not hurt you.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
LOL, you deduced that from a couple of lines of code hurriedly typed into a web form?
Combined with your list of things that were, as he said, already fixed, along with this line of code:
NSString *title;
You have a property, why are you making a class var? Those are just the kinds of things that make people who have been working with ObjC a long time think of developers new to the language, or at least not spending any time keeping up... not to mention the complaint about delayed selectors, they are often abused by people who don't really understand why something doesn't work and just pushes the code out to a delayed call.
Your whole post was valid perhaps two years ago, but there are not many items you are complaining about that are real issues anymore, and the remaining ones are mostly subjective (naming conventions, I prefer the long names in ObjC to other languages).
Also, I do exactly the thing you mentioned (a common base class that is reused between iPhone/iPad instances of those classes) and have not found that to be a problem. What do you feel is limiting in that regard?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Objective C, at least as used on iOS, is not a safe language. I don't see how anyone with serious programming experience could believe that.
Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone). Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities. Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.
Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application. It's actually a "defined" operation in the sense that it's defined to return garbage or another nil. Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application, unless (worse) you have some "clever" programmer who decided to rely on this obscure behavior. The nonsense of accessing NULL is why it is defined to result in an application crash on any sane platform - you want to stop the app at that point to avoid possible data corruption. But Objective C apps will happily continue their merry way, overwriting internal state with garbage or more nils until it auto-saves your now hopelessly corrupted data to disk.
This is a specific instance of a more general problem with Objective-C, which is that despite being based on C it turns a lot of failures that would be compile failures in any modern language into runtime failures or heuristically driven compiler warnings. Most research into programming languages for the last 10-15 years has been about how to catch more errors earlier, mostly through better type systems (a lot of functional research is in this direction). Objective-C takes a massive step backwards in this regard, converting errors even C++ compilers can catch ahead of time into issues you may not even notice unless you have extremely thorough testing plans. Example: typos in method names.
Thirdly, Objective-C does not have any kind of real namespacing support. The Cocoa libraries use the convention of an API prefix, but there's no language support for it, meaning "namespaces" such as they are tend to be very short or non-existant. Combined with the way symbols can mishmash together in the same binary can lead to awkward to solve linking issues.
There are a lot of problems with Objective-C that make it difficult to consistently write correct code and flatly contradict how modern languages are designed (no surprise, as it's not modern).
Actually, there are accusations that you're the shill, and that your name is Rui Maciel from Portugal: http://tech.slashdot.org/comments.pl?sid=2844659&cid=39972515
Care to respond?
Early (usually first, within the first minute or two that the article shows up) post, longish posts that would have been impossible to compose in less than a few minutes
Subscribers see posts about 30 minutes before everyone else. They show up in red at the top of the front page (for example, an Oracle article will go public about 20 minutes after this post). It's kind of surprising how many posters don't seem to know this.
immediately modded to +5 by all the high-UID sockpuppets
There's no way to know who moderates a post unless you're a Slashdot admin.
All of this is off-topic crap and should be modded accordingly.
If writing informative posts that give relevant information about the topic at hand is corporate propaganda, then Slashdot needs more shills posting.
I can't even remember the last time someone used a code tag in a Slashdot post. It's almost like this place is a forum for technical discussion again.
Vala (http://en.wikipedia.org/wiki/Vala_(programming_language)) actually has ARC as well and is worth a look.
Let me summarize. You chose to ignore almost everything of what I've said
That summarizes your position. I corrected almost all of your points. You responded to only one of mine, and there not even a point on the language but a meta issue of languages and platforms that any third rate philosophy student could offer up as a supposedly "informed" opinion on computing.
have personally insulted me (makes you wonder who's the real snob?) made all kinds of presumptions about my background...
I only responded in kind. You started out insulting me first (and assuming I knew nothing about higher level languages even when I first stated I knew Java in my original post), giving me free range to question anything and everything about you.
The responses I type are a mirror on those who I am responding to. You came off as an arrogant elitist ivory-tower prick with little in the way of practical experience (that last item mostly based on the few concrete items you offered).
Furthermore you never even said what you DO know anything about, a very curious omission indeed! You can claim I got "everything wrong" all day long, while never revealing even a portion of what you do know while at the same time complaining we are guessing at it.
Perhaps you should try a different writing style if you would like more pleasant responses. Perhaps if you don't want people to get your background wrong you should provide some instead of poorly thought out complaints that illuminate only your area of ignorance and not your field of understanding.
The main disadvantage of Objective-C in practice is, of course, that you have to write the whole fucking program again if you want to have it run on Android or any other non-Apple platform.
In the end to have the best application for any platform you have to tailor it specifically for that platform; in REAL LIFE very little code can be reused even if the platforms share a similar language. The code itself matters so little compared to the conceptual model of how the program fits together.... and the parts of the code that really matter, in specific UI interactions have to be totally customized to a different platform anyway.
But I guess if you are OK with simply dumping bad applications out that annoy users I suppose I could see where you would have the opposite feelings and write drek that will run "anywhere".
In the end, it sounds like you are a typical ivory tower prick as I had you pegged at the start. You have only reenforced that vision with your later writings, abrasive and rude and pretending you know everything while illustrating how little real world understanding you have.
I'll let you have the last response, since you have nothing real to write but simply further fling insults while claiming you are above me. The readers know the truth, know how much you really know and exactly the tone of responses you drew out. I have already unmasked you, so my work with you is done.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
He asked me if I had any experience with Smalltalk. I said "no". He said "Good, because if you did, I wouldn't hire you. Smalltalk requires a very bizarre way of thinking, and I wouldn't want anyone who thinks that way on my team."
Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure - mostly you are never using C arrays or the like. Just because they are there does not make the language inherently "unsafe" if that's not how real people use the language.
Obj-C was unsafe before they introduced ARC - back then you could over-release an object and then use it. ARC is a fairly recent addition, and many people haven't caught on yet.
Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone). Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities. Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.
Obj-C is not manual memory managed since the introduction of automatic reference counting, which is technically a form of GC. One thing it certainly does is preventing memory corruption - you can't end up with a dangling reference anymore (unless you specifically try). Memory leaks are irrelevant, since they also exist in managed languages with tracing GCs like Java - all it takes is forgetting to null out a reference.
Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application. It's actually a "defined" operation in the sense that it's defined to return garbage or another nil. Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application, unless (worse) you have some "clever" programmer who decided to rely on this obscure behavior. The nonsense of accessing NULL is why it is defined to result in an application crash on any sane platform - you want to stop the app at that point to avoid possible data corruption. But Objective C apps will happily continue their merry way, overwriting internal state with garbage or more nils until it auto-saves your now hopelessly corrupted data to disk.
I happen to agree that it's a bad design decision, but it's most certainly not "obscure behavior" in Obj-C - in fact, it's quite idiomatic to rely on this fact when doing chained method calls or property accesses without interleaving null checks.
Also, the reason why accessing NULL results in an application crash is not because they wanted to stop an app, but because C and C++ were designed to run with as few checks as possible, and reading from a null pointer causes a segfault on most platforms (but not all: e.g. DOS wouldn't segfault, nor would most other platforms with no memory protection; that's why C++ standard says that it's "undefined behavior" to dereference null).
Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application. It's actually a "defined" operation in the sense that it's defined to return garbage or another nil. Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application, unless (worse) you have some "clever" programmer who decided to rely on this obscure behavior.
At that point anyone who actually uses Objective-C agrees that you are talking out of your arse. Standard C free () and realloc (), C++ delete operator - they all work just fine with null objects. And there's a reason for that.
Sending messages to nil is not "defined" in some obscure sense, it's defined. It's part of the language. It's not "clever" to rely on it, it is bloody stupid and ignorant to not rely on it.
Objective C, at least as used on iOS, is not a safe language. I don't see how anyone with serious programming experience could believe that.
Some people with experience know better.
Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone).
No, it uses ARC, which is superior, since there is no run time overhead.
Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities.
Even under the old regime memory management was mostly automatic. You simply signaled when you wanted an object, and then when you were no longer interested. That is a strike against Objective-C many raise but I just never found to be an issue in practice.
Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.
You clearly are not keeping up on year old iPhone development practices.
Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application
I thought you just said you disliked memory corruption.
Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application,
if ( myString > 0 )
Nope, not a bug, and very useful compared to:
if ( myString != nil && myString > 0)
That alone, if you have done any Java programming, would make it all worthwhile. Basically it safeguards against all kinds of horrible bugs if sending a message to nil means nothing. Would you prefer shouting into the void rip off your arms? Why would you prefer that an accidental sending to an obviously un-initialized space break the program? Madness!
despite being based on C it turns a lot of failures that would be compile failures in any modern language
Poor Objective-C, choosing a different path. DIFFERENT IS TEH EVILS!
They have made different choices but they are not bad ones. They are along the age old lines of deciding where they sat on the sliders of things like dynamic vs. static, and then making the best of where they landed.
Most research into programming languages for the last 10-15 years has been about how to catch more errors earlier,
Meet CLANG. Objective-C development is NOT hurting for early warnings you have problems, and in fact is probably ahead of just about any other language right now. "modern" or otherwise.
Example: typos in method names.
You have got to be kidding me, there were compiler warnings about that as far back as I remember. Just because you CAN send any message to an object does not render you doing so any less an error a compiler can easily flag, just as mis-typing a function name would raise an error.
Thirdly, Objective-C does not have any kind of real namespacing support.
That is very annoying at first coming from other languages. That is the one thing I would like them to resolve, as you say it can raise overlap issues. But in the end it's really a minor thing as the naming convention (mostly a class prefix), works OK. The main problem with it though is not the one you raise - overlap with other classes in fact raises a linker error, so it's not like that really happens for whole classes. No, the problem with lack of namespaces is the inability to easily include a large number of header files at once by simply declaring you want to use a namespace.
There are a lot of problems with Objective-C that make it difficult to consistently write correct code and flatly contradict how modern languages are designed (no surprise, as it's not modern).
Funny how Objective-C has now leapfrogged ahead of other "modern" languages in terms of library support and language features like ARC. I programmed Java for over a decade and would b
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Which one is easier to read?
To my mind the ObjC code is easier to read because it is clearer.
string.strip is harder to read generally speaking, because it's so small it can get lost in other code, and it pre-supposes a great big pile of understanding the history behind the terse word "strip". For a new programmer coming in, the Objective-C code is far clearer.
When browsing through a large volume of code either would take the same time to skim over since you knew what they were doing (though as noted the shorter example is easier to accidentally miss).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Obj-C was unsafe before they introduced ARC. back then you could over-release an object and then use it.
Actually even that's not really the case. Note that what would actually happen in that case would be that something would try to send a message to that object, at which point the runtime system would throw an exception noting the object did not respond to that message. It's not unsafe in the classic sense, since you are going through the runtime to send messages to objects.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.
Yea Java is really safe.
.. if we can use the latest and greatest features, which is often not the case
Sometimes. The hugest jump in improvement, by far, was ARC - and that support goes back to iOS 4 even though they introduced it with iOS 5. You can easily use that today, and have been able to really for a while now as there are very few iOS 3 devices around anymore.
I think a lot of it comes from the inability to have any sort of mixin class.
What about categories!!!! Especially with the newer ability to also create variables local to them (which there have been means to do for awhile in different ways).
Thanks for the very thoughtful response.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I swear that at times Slashdot feels like a bunch of stuffy comp-sci folks stuck in the 80's. You'll argue day and night about minor technical details, but it's none of those details/minutia that really make a product take off. Sure, flaws will kill a product, but beyond a very simple point, they are just a tool to get a job done. Steve Jobs understood that, maybe we should too and stop the language circle-jerks.
Skip your meds today, did you?
Where did you get the bizarre idea that companies like Apple or Microsoft would bother with hiring shills to post on /.? All the people who have ever read this site are barely a rounding error compared to the number of customers they have. They don't need to win hearts & minds, because developers who support their platforms can make money doing so.
Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure
Objective-C is a superset of C, right?
so you can write to arbitrary memory locations, call arbitrary (non-NX) code locations?
unsafe.
"Modern" languages (and i'm thinking Ada, here) don't allow such things, or make it trivial to disallow them (java's JNI, c#'s 'unsafe', etc...)
Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)
Parameter names in method calls are /always/ named. You can't just say obj.someMethod(x,y). It's always [obj someMethodForX:x y:y].
The above combine to make even the most basic operations tedious. Want to trim leading/trailing whitespace off a string? Enjoy [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]
I consider this an advantage. All those folks who talk about self-documenting method names finally have a place to hang their hats.
Immutable arrays, dictionaries, sets, strings. I get it, it can be useful for performance to know something is immutable (maybe, I'm not that convinced). But the common use case is most certainly mutable, so /that/ should be the default, e.g. NSArray should be mutable and then if needed there can exist some NSImmutableArray or something. But no, they did it the other way around.
Immutability is about more than just performance. Java and C# both have immutable strings. Good programming practice often recommends immutability as a way of enforcing contracts and avoiding unintended side effects. Some languages avoid mutability for any object.
There is a common consensus in the CS community that pointers as opposed to references, pointer arithmetics, direct type conversion ("memory overlays") etc. are unsafe, and a language that makes it easy to use them is "inherently unsafe". (That doesn't have anything to do with actual programming practise. Obviously, you can write "safe" programs in any language, even in machine code, as long as you're very careful.) As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.
As for "modern": Perhaps you haven't seen any modern programming languages yet? Because otherwise you should know what I mean. Relatively modern features are e.g. automatic type inference, automatic parallelism, contracts, a concurrent garbage collector -- things like that.
Java is a slow pig and the rest of your examples have little real-world usage for desktop/handheld applications, at least client-side. There's lots of unoptimized wonderfully safe academic languages lacking decent libraries for people to create applications that integrate well with the rest of the system. LISP is awesome but I wouldn't want to try to write a modern game or productivity app in a reasonable amount of time with it.
Obj-C at least gives you a lot more options as far as libraries with a lot less reinventing of the wheel than any of your examples.
The actual programming language matters very little to an experienced developer, who sees the code not in terms of the programming language it is programmed in but as a set of abstract algorithms and syntax trees.
That is hardly an article about regressions from OS9. It's a complaint about the sizes of some windows (mostly irrelevant now we have high-DPI screens), some GUI features that are deprecated as far as I know (drawers), and quite a lot that's complimentary about the OS. The only thing you really have to complain about is the window widgets. I agree that it's not as immediately clear to the new user (although RED is a pretty global idiom for STOP) and almost all apps would throw up a warning dialog before throwing away data. Those that don't (e.g. Safari) have a history function anyway. Calling it a "massive regression" is ridiculous. There are many things that are better, a few that are arguably worse, as with any OS update.
Yeah I noticed after posting that is a later article. You can find the earlier one I meant to link easy enough with google.
Even this later, much more complimentary article links to the "why the dock still sucks", and it mentions quite a few of the problems. The areal density issues are NOT irrelvant now, not at all. High DPI screens do nothing about areal density issues, on that you are confused.
Colours take much longer to process than simple geometric shapes here, as Apples own research proved a few decades back. Slowing the user down with a confirmation screen afterwards is no substitute for making controls that are not so error-prone to begin with.
The dock and the apple menu bar are the biggest problems, so bad that he split them out from the main article. The NeXT Dock was a thing of beauty and the OSX version one of the ugliest designs ever made. It has improved somewhat, over many years, in response to a lot of criticism. It's still pretty darn ugly, even if time and natural interests (Tog is and will presumably always be an Apple man) eventually lead him to tone his criticisms down more than is warranted.
And yes it's true that with newer releases some criticisms were eventually listened to. Some, not all. Not anywhere near all.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Code resuse...FAIL
Nonetheless, its survival predicated alone on its modularity was and is the weapon SteveJobs used to ' rev.' past the competition and while on a line count basis the language reuse fails.
The same can't be said for ' Obj-C' reuse-ability which enabled Apple to repurpose its software systems on innovative hardware implementations. WIN-WIN
Certainly a userspace app can't write to arbitrary memory locations (and not even access them), not on sane hosted platforms (OSes) anyway. It can try for sure, and yes, it'll probably crash very quickly. It's not like apps written in "safer" languages can't crash because of an uncaught exceptions. (Or is it not crashing if you could've caught it? ...)
No, the AC is right; you are a cyber-stalker with a weird hobby. I've been watching these idiotic posts for quite a while now (years probably) and all you manage to do is embarass yourself with how ... focused ... you are to inform the rest of us about shills. I'd add you to the tiny list of people I actually let the site outright block from me but you're too much of a coward to step out from the AC cloak, presumably because you'd lose your "audience."