Kdtyjb

Objective-C was by all accounts a nightmare to work with

I loved it. Loved it.

Some background: in the 90s I worked for a developer here in Toronto with a Mac and Win app. I wanted to work on the dev side but I had no formal training, and I found the barrier to entry to be too high for my interest level. To do anything useful, you had to learn the OS, the IDE, the language and the library, each of which was some level of dismal. For instance, the text editor widget on the Mac couldn't handle 32k, and the various libraries just called it. If you wanted to edit more text, well, have fun!

In 1998 Apple sent me a copy of OpenStep, or as they called it, Rhapsody Preview. After some install issues (lack of drivers, had to replace the CDROM drive with one it knew) I had my first real program running in a day. Real program.

Because unlike the Mac or Win of that era, the OS was the library, and the library was f'ng amazing. Text editor? How about one that fully supported Unicode, was limited only to 32-bit int in length, automatically paged data as needed (because that how the whole system worked), did complex layout like columns and flowed around graphics and such, and had a built-in spell checker. The entire library was like this, the base objects were super-powerful out of the box and tightly integrated with each other and the entire OS as a whole. I hate to use this word, but it had synergy that had to be used to understand.

Contrast with, say, Win + MFC... gebus. It was like Lisp Machine vs. PDP-8. .Net helped, and C# is better than Obj-C (I'd say it's my favorite language), but it was decades before .Net got close to OpenStep of the 90s, and even today its base objects still suck - why can't the get an array type right after 20 f'in years?! Every time I use it I end up wondering why some totally base object is missing some totally obvious feature, or why they have five objects to do the same thing, each with their own set of dumbness.

Obj-C was no worse than other languages, except perhaps in syntax (perhaps). It had two super-amazing advantages though. Extensions let you add code to existing compiled objects, so you could add spell checking to someone else's text editor for instance, and the handling of nil was wonderful.

Swift... well I like some things and don't like others. The whole class/struct thing they boast about is, to me, a crock. Yes, I know it's more efficient etc, but it really is much less flexible than just declaring a class and using it. I also hate hate hate putting the type after the declare, int c=0 is simply easier to read than var c:Int=0, and int doSomething() is lightyears better than func doSomething() -> Int. Bah! Swift also lost the wonderful nil handling, and I can't for the life of me see an upside - everyone just puts ! on everything.

Overall, yes, Swift is an improvement. But Obj-C was pretty great too. At least in the 90s. It collected a LOT of cruft when it moved to Mac/iOS, and much of that was ugly and just totally bolted-on. So early Obj-C and Swift were pretty similar in ease-of-use IMHO, while late Obj-C was indeed getting to be a real downer.

Swift was introduced only in mid-2014 so I think perhaps some of those people's beards have greyed out very rapidly! That aside, Objective-C attempts to fuse two different languages: Smalltalk and C. So it's a compiled language, like C, that for object types also supports dynamic dispatch and introspection, like Smalltalk.

It's actually a strict superset of C: all standard C libraries are directly callable from Objective-C, and many of the very central parts of Apple's libraries are written directly in C.

Object types are dynamic enough that you can look up available methods and their types, and declared properties, and their types, and at runtime access either by name if desired. This functionality is central to Apple's UI libraries: e.g. to tell a button which action to perform when pressed you tell it the identity of the object it should call plus the name of the method, and the runtime does the necessary method routing. So things like the UI designer don't generate any code. There's no hidden mapping file full of comments that it was automatically generated and please don't edit.

There's at least one problem that stopped being a problem a long time ago: into the OS X era, memory was managed manually — you were responsible for remembering to take a small number of idiomatic steps to ensure proper memory allocation and deallocation. But they were so idiomatic that no thought was really required, and indeed that the compiler was able to assume responsibility for them circa 2010.

There were also problems of style: object syntax is almost LISP-esque in requiring matched pairs of outer brackets. Square brackets rather than round but it still used to mean a lot of hopping back and forth on a line. This also improved a lot towards the end of Objective-C's primacy as Apple started using Clang itself directly for in-IDE code processing, including predicting where automatically to insert this opening brackets.

But the main problem was this: at runtime, Objective-C provides duck typing. That is, you're free to pass any object type to any method of any other object type and things will just work if the code has been written to expect it. So e.g. there's only one array type, which can hold any mixed list of objects.

When the first versions of the framework were built for NextStep machines with low quantities of megabytes of RAM, that was a huge bonus for many of the complicated data types: e.g. there's also just one version of a dictionary, so having it be entirely typeless means having only one set of code in memory for all applications. Compare and contrast with a generics-based language like C++: each instance of a std::map has distinct code generated at compile time that is specific to the types of the keys and values. Which is faster and safer but a greater burden on memory footprint.

There are 'lightweight generics' now in Objective-C that declare an intended type for each collection variable so that the compiler can look to provide probable misuse warnings, but they're post-Swift and, honestly, primarily for its benefit — they help at the boundaries between the languages because the newer prefers the safety of types.

Trying to draw this ramble back to a concrete point: I'd say that no, Objective-C was never much of a hindrance. It offers all of C plus a bunch of reflection that is useful for UI programming. There's also empirical evidence to back this up: officially-supported languages for building OS X languages from day one were Objective-C and Java. The latter was deprecated only a few years later after market forces selected the former.

I think the language's major crime is oddball syntax; it is also unfortunate that some of the problems that being typeless solved are no longer problems, making it undesirable as an axiomatic feature.

A nightmare? Seriously?

I never worked for Apple, and I don't know what kind of attitude those people have, but I wrote desktop application software for NeXTStep. I recall Objective-C and the NeXTStep development tools to be a quite reasonable and easy-to-use. As far as I can remember, none of my co-workers had any complaints.

Sounds like somebody was just p***ed off about being asked to do something new and different.

Did objective-C hamper software development for Apple software or is this just the random experiences of someone on the internet?

Do you really expect an objective answer here? Languages are a matter of heart and opinion, not really anything factual. Even more so when asking about the truth of an opinion like the one mentioned.

A short comparsion might be useful

The main difference is for what goal C got extended. Both (C++/Objective C) are meant to speed up execution compared with prior, more 'pure' OOP languages by using the rather simple static compile structure of C. And extending it with OOP features.

• Objective C focuses on being a language extension by implementing ways for dynamic object and code handling (reflection) while keeping it a compiled language with a minimum runtime. It's generally geared toward making run time decision about linkage and message parsing.




• C++ replaces C by moving toward the use of standard classes. C++ target is a complete static code, all decisions about linkage and message parsing is made at compile time. Metaprogramming with Templates tries to overcome this to some point.

It can be said that Objective C is a a more basic and thought thru attempt on the language side, while C++ adds many features in less than coherent ways, inviting feature creep thru the standard library in often incompatible manner.

In general Objective C may be preferable for larger and more dynamic projects. especially if they are in use over a long time and many instances. C++ got it's merits when its about closed projects and a small footprint.

So what about the 'hampering'?

Not really. C++ allows for much code mangling to get along with prior C knowledge plus acceptance some aspects as helpful, whereas Objective C requires to truely switch for a more clean OOP design.

Preferences may come down to willingness of programmers to learn new ways or jsut mangle thru - the later are of course less expensive to hire and more ready available.

It's a very subjective matter. Programming languages and programmers need to pair up: some programming languages are more suited to the way a programmer is thinking than others. So if a developer is working with a language that seems to get in their way, they surely do not like it.

I for one liked Objective-C when I started working with it back in 2007 (already had almost 20 years of programming experience in various languages at that time). Still like it. Even back then, it had a lot of nice features and pretty consistent APIs but it's syntax is unusual in the C family of languages.

It was a hindrance insofar that Objective-C is almost solely used for iOS and macOS development, so you are unlikely to come across it when working with other OSs. This limits the people that have experience with it and thus the available resources like documentation and source code when compared to, say, Java which is available everywhere. At the same time this also leads to the advantage of providing a consistent experience for all developers who worked with Objective-C.

Almost equally important are the available APIs (building blocks) provided to the programming language. The ones provided by Apple were pretty consistent even back than (with a few dark, dirty corners here and there) and have (mostly) improved; the need to coexist with Swift has helped in this regard. And like the programming language itself, if an API gets in the way of what a programmer is doing they don't enjoy it. The APIs provided by Apple a very verbose, some names can become very long. Some people love it, some people hate that.

It should be fairly evident that Objective-C has not hindered the growth of software in Apple's "ecosystem". For this, you only need to look at the success of the App Store.

Recall that iOS (originally, just OS X for the iPhone) started off as a closed development environment. The only official apps for iPhone were those internally developed by Apple. Of course, they were developed using the Cocoa Framework and Objective-C language brought over from OS X. A full year after the iPhone release, the App Store opened a floodgate of new developers adopting Cocoa and Objective-C. From Wikipedia:

The App Store was opened on July 10, 2008, with an initial 500 applications available. As of 2017, the store features over 2.1 million apps.

So, regardless of any developers personal feelings on whether it is a nice development experience, or whether the language has serious shortcomings, the objective evidence proves that software was produced on a grand scale using this platform.

Seems like a very opinion oriented question, but as someone that's programmed in a lot of different environments (including Objective-C)... IMO, Objective-C could indeed qualify as a nightmare when compared to well, virtually anything else. Personally it's like the worst parts of C and the worst parts of LISP combined and I truly wish that they had gone with something else, really anything else... :-)

It's an excellent and extremely powerful language. The syntax needs a bit of time to get used to, but after a week or so you should have no problems whatsoever.

Named arguments are the best innovation of Objective-C. Lots of things that are bad in C++ because a function call is not self-documenting go away in Objective-C. There are observers built into the language. Any property can be observed, that is arbitrary code can say "I want to be notified when this property changes" - great for having the weakest possible coupling between code. There are interfaces, so you are not restricted to subclassing. There are closures. There are class extension - if you ever wished you could extend std::string (add methods to it, not subclass), you can do that in Objective-C.

It's an excellent language. Swift is better - after a non-trivial learning curve, but that's with 20-30 years more experience.

I've been programming professionally for 30 years and have worked with plenty of languages, and I hated, HATED, HATED Objective-C. It never made any sense to me. I tried to figure it out, but whenever I thought I had it, I didn't. Finally I gave up and moved on to something else. So, was Objective-C really a hindrance to Apple software development? Yes, it was. It certainly was for me.

A hindrance is not necessarily a barrier, however. The availability of other tools for doing ios development, particularly with C++, has made learning Objective-C unnecessary. But I do believe that plenty of developers were scared off by Objective-C and never even investigated alternatives.