I'm a dinosaur and I'm about to go extinct!

Posts: 64
Joined: 2005.06
Post: #1
I can see the writing on the wall; the improvements made to Objective-C and the Cocoa frameworks over the last year and a half are driving me to irrelevance, because I'm a dinosaur and I can't adapt to the coming age of mammals.

[Fair warning, this is in Languages & Scripting because it's directly related to Objective-C, but this post is really about dealing with a changing language]

[I have grown lungs and crawled from the ocean] I started programming as a preteen using REALbasic back in MacOS 8 and advanced to C and Objective-C with the release of MacOS X. This can be entirely attributed to MacOS X coming packaged with a developer CD with the entire development environment on it. Never before had everything I needed to program in a compiled language been so accessible to me.

C and Objective-C were my first compiled languages because I had little choice in the matter; I'm grateful they were, because if C++ had been my first foray into C-based languages, I may have learned to hate programming instead of embracing it. I learned Objective-C and C because I had to, I continue to use them because I can.

[I walk the land and I'm top of the food chain] From then to now, I've learned a myriad of both compiled and interpreted languages. Java, C++, Fortran (in its many variants), Lua, SAC (Seismic Analysis Code; the executable is its own script interpreter)*, and a number of others I can't be bothered to list.

Though I have a wide range of tools at my disposal, C and Objective-C remain my tools of choice whenever I'm working on my own personal projects. This isn't a decision that's made for performance reasons or even because the languages play nicely with the available frameworks. The decision is made because I like the flow of the languages; I like having manual and explicit control over anything I create. Though it may sound contradictory, I also like the sugar--I'm all for anything that can legitimately simplify the language without sacrificing functionality.

Despite the lack of adequate support for Objective-C on other platforms until very recently (new (nearly) Apple compatible runtime with GCC 4.6 last year and now Windows compatible Clang and LLVM), I've been a happy camper. For the longest time, any valid Objective-C I wrote for one platform would be valid for any other platform (from a language standpoint, not from an available framework standpoint). This changed with Objective-C 2.0.

[Impact, and not lucky enough to burn away in the fire] Ignoring the fact that for a time the language itself was not the same on all platforms, I didn't know what to think of the new 2.0 features. I didn't like the new features and I still don't, but I don't dislike them either. They aren't my style; as previously mentioned I like to have full control over what's going on and synthesized properties and dot-notation rub me the wrong way. I don't like how they hide the mechanicals behind the scene, but I also recognize why they exist and why others use them. It's an attempt to ease the transition of programmers migrating from other languages.

Then Clang (and LLVM) became the standard for Apple. GCC is not bad by any means and frankly it still produces superior binaries in comparison to Clang, but when it comes to features, Clang knocks GCC out like it had a glass jaw.

ARC, garbage collection, the new literals, and the variety of other minor improvements that don't get quite their fair share of the spotlight: all of these are great things. Except it scares me that convention and Apple's frameworks (primarily Foundation) are being hardcoded into what is essentially the future of the language.

ARC relies on naming conventions such as new, copy, etc.; by all means you should follow these naming conventions to a 'T' as they exist for a reason, but I'd be lying if I said I didn't have misgivings about them becoming ingrained in something most now consider a critical part of the language. I'm really weird in that I actually like manual reference counting--enough so that I'm willing to give up the performance benefits for using it, so ARC isn't for me, but it is the thing for most people, so what it dictates for all intents and purposes, goes.

The new literals I actually like and would love to use. They even let you use subscripting on any object that implements the needed methods. My problem with it is that the rest of the literals are hardcoded to be Foundation classes, with no flags or other obvious means to change them. Again, I understand that this is meant to be a compiler extension and that the majority of people have no problem with it being tied to Foundation classes, but this runs headlong into the same problem as ARC: defining a defacto standard on something that shouldn't be a standard. Compiled languages aren't meant to have system dependent frameworks as part of their core functionality (I fully understand you can compile Foundation yourself for other platforms, but that pretty much defines the opposite of a standard).

As much as I want to be aboard the gravy boat with all this syntactic sugar and goodness, I can't help but feel that somewhere along the way the boat began to drift off course, and now we're heading for the rocks, despite the captain constantly telling us not to worry; everything is alright; we can trust him to steer us safely.

[The sun is behind ash and there is no food left] So there it is, I'm a dinosaur. As much as I'd like it to be so, I am not and cannot be a mammal. I cannot adapt. I will strive on for as long as I can carry myself, avoiding the changes that I'm unable to adapt to, but my time is coming to a close, and one day I'll only be so much hydrocarbons.

[So what is all this? This I'm afraid is my realization that my favorite language is changing, and changing in a way that I'm not willing to follow it. It's the realization that while I may be able to keep doing things as I have done, I'll be unable to share my code or work with others, as other proponents of the language will be using all the new features and eschew my lack of them. It's the realization that one day I may need to legitimately fall back on plain C code only, or god help me C++†. For once I want OSC to come in here and rip my post apart and tell me in fine detail how I'm wrong about every point. This is one time where I don't want to be right.]

[Why dinosaurs? Because you're probably bored stiff as it is. Nobody would make it through this post if I didn't add a little something.]

* What can I say, I'm a geologist; I wasn't a comp-sci major. All this programming stuff is for fun and profit.

** I had to rewrite this thing in its entirety, because Safari doesn't even support undo in forms.

Not really; I will give up cross-platform compatibility altogether and use C# before I ever consider that wreck of a language (C++) for a serious project.
Quote this message in a reply
Posts: 1,563
Joined: 2003.10
Post: #2
I share a lot of your sentiments. Much to the chagrin of some members of the community, I've always refused to use new language features until they're a few OS revisions old. I care much more about cross-platform development now than I used to, and I just use C for everything with a thin layer of Objective-C on the Mac to get things bootstrapped. C is my favorite language by far and seems like it'll pretty much last forever, so this works out quite well.
Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #3
Wow, Justin Brimm, I am shocked. I cannot find a single thing to disagree with in all of that! Not a single thing. At least not from my point of view. Apparently I am a dinosaur too.
Quote this message in a reply
⌘-R in Chief
Posts: 1,277
Joined: 2002.05
Post: #4
* SethWillits hurls a giant asteroid at you all.
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #5
You are of course entitled to your opinion, even if it's wrong Wink

Here's some thoughts:

1) Objective C has never been independent of Foundation, at least as far back as I can remember @"..." has created an NSConstantString object. Note that knowledge of this class has been embedded in the compiler (it creates it in the data segment) and the framework (the class responds to retain, release, autorelease, copy, and all the primitive string methods that the rest of the NSString cluster is built on).

2) The notion of a language without a library is absurd. I can't think of a single (serious -- BF doesn't count!) language that lacks a standard library. Why should ObjC be different? Yet it traditionally has been.

3) Manual reference counting is an entirely automatable design pattern. There are strict rules about the "logical retain count" of objects in ivars and globals (+1), objects returned from most methods (+0), objects returned from specific methods such as -init*, -copy*, +new* (+1) and objects passed into methods as arguments (+0). Any time something is completely automatable, it would be crazy not to automate it and save humans from doing the work.

4) Automating this means moving the language/library line a little. Now rather than being Foundation conventions, -retain, -release, -autorelease, -dealloc, NSAutoreleasePool and some naming conventions must be part of the language. This isn't any different from any other language with memory management features, e.g. -finalize in Java or destructors in C++ being part of the language.

5) Handwaving a little more, syntactic sugar is a part of most languages (C++ and Ruby have operator overloading, Python and Lua turn operators into method calls like __add__, etc.) and syntax for common data structures is a part of most languages (Perl and Ruby have regex literals, almost all the scripting languages have array and dictionary literals, etc). C++11 adds the ability for initializer lists to be "a literal for" any custom class. So yes, indexing operators, and array/dictionary/number literals for ObjC push the language/library line a little further, but not into untrodden or even uncommon territory.

6) Realistically, ObjC without Foundation has never been sane or sensible. Even if you were writing ObjC for another platform, you've always used one of the open-source Foundation libraries anyway. Pushing NSNumber, NSArray, NSDictionary and NSString down to join NSConstantString is not actually going to impact anyone's life.

So in conclusion, it feels kind of hypocritical to me to pick on ObjC for becoming less like a thin set of syntactic extensions and more like a language, given it's now MORE like any other language than it was before (and a lot easier and nicer to program with to boot).

As ObjC becomes more popular, I imagine the quality of the open-source runtimes and Foundations will improve too, since it will benefit more people to care. But you're right, for now, if you want to be super cross-platform, ObjC isn't the best choice. Then again, it never was.
Quote this message in a reply
Posts: 461
Joined: 2002.09
Post: #6
I used to feel similarly when new C++ features were added. But my codebase doesn't use most of them, and it turns out it doesn't matter. (How many people who use C++ daily actually know every detail of the language? Almost none, I'll wager.)

I'm also using C# lot at work. Most of our code is using 2.0 features. Microsoft has added some nice stuff, and also some bloat, in versions 3.0 and 4.0, but our existing code still works and we've selectively used a few new features when it is convenient to do so.

I think some of your discomfort is just going from knowing 90+% of a language to suddenly finding yourself below 50%. It's dismaying, and feels like a step back. But the 50% you know is mostly still valid. And you may even find that knowing the underpinnings that the modern features are built on will give you an advantage in some cases over people who only know the syntactic sugar.

Or as a coworker used to say: "They're all Turing-equivalent." :-)

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Posts: 1,487
Joined: 2002.09
Post: #7
I for one rather like the syntatic sugar they've added. I like being able to do things like object.property += x without wanting to shoot myself in the face. I know exactly how they work, and I know they save me from tying a lot of crap I don't want to. It's not taking away control, only repetitive junk I don't care about. (I also look forward to literals and indexers for the same reason.) Stuff like that has turned Objective-C from a language that I don't mind into one that I rather enjoy. Life is too short to waste time on things the language should be doing for me. Wink

Like OSC said, it's a little crazy to expect to find a language without some standard types or minimal functionality. Even really minimal languages like Scheme or Lua let you use whatever string type you want. You use the one the language was designed to use. Anyway, you weren't *really* planning on writing Obj-C code without using Foundation were you?

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Posts: 625
Joined: 2007.09
Post: #8
Another REALbasic alumni, woot!
Having used Objective-C, C#, Python, and a weird JS/ActionScript hybrid, Objective-C remains my all-time favorite language. Unfortunately, it seems as though the reasons I love it (the verbosity, naming all your arguments, square brackets) are also the reasons a lot of other people think it's ugly. And vice-versa(don't care for dot-syntax honestly). I have no opinion on ARC - I'm just happy there's no garbage collection.

I think I'm more of the grouchy old man in the basement with a shotgun and can of beans than the dinosaur though. Rasp

As pertains to C# - the Mono runtimes(Mono, MonoTouch, Mono for Mac, Mono for Android) allow you to write some pretty cross-platform C# code — not to mention the cross-platforminess when you use C# with Unity.

- Lincoln Green
Quote this message in a reply
Posts: 35
Joined: 2010.01
Post: #9
I like properties because you don't have to write as much code. I don't like dot-syntax though. I think if I have to switch between []'s and .'s I may as well just use []'s and I don't think .'s are easier to read anyway.

A couple of additions being used in the API's that I find kind of necessary are for each loops and blocks. Nobody likes NSEnumerator's.

I'm looking forward to new literals, but I can't say the same for object subscripting which looks evil and ugly. Also, some language features (eg, new literals) have backwards compatibility so that's good.

I only use new features that I think are worthwhile.
Quote this message in a reply
⌘-R in Chief
Posts: 1,277
Joined: 2002.05
Post: #10
Dot syntax is great. New literals are great. I have a negative gut reaction to subscripting, though I imagine after a bit of wincing, I will like that too. Having more succinct syntax for the trivial and common things in code is a good thing.

obj.property += x;

[obj setProperty:[obj property] + x];

The benefit is pretty obvious to me even in a simple example like this. In longer uglier code with square bracket soup, the benefits of are even clearer. I dig the separation of action vs data. It makes gleaning the important methods in code flower quicker and easier.

The only reason to not like it is view.frame.origin.x += d; does not work. I'm actually annoyed they didn't go that step further to make it work. It seems like a no-brainer to me.

Blocks are also a welcomed addition. Massively useful. Especially when combined with GCD. Blocks make a few existing APIs in Cocoa much more sane. ie, NSPredicate and all of [blah doSomething:delegate:selector:context:] methods.

Ditto on OSC's and Skorche's comments.

Keep up the good work, Apple.

PS: I for one don't depend at all on cross platformness of my code (which is clearly important to you), but if I did, I wouldn't use Obj-C because GNUStep and the tools are always behind what Apple has, and to me it makes more sense to use something fully and equally supported on all platforms than fight with all of the differences.
Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #11
From my experience, this is better than both of those:
int newValue = [obj property] + x;
[obj setProperty:newValue];

It is easier to debug, it better describes what is being done, it is easier to read, and it only cost one extra line.
Quote this message in a reply
Posts: 104
Joined: 2002.04
Post: #12
To me, all the new stuff simply ups the readability of the code and reduces the boilerplate code one needs to write.

It's full of win.
Quote this message in a reply
Post Reply