STANDING OVATION

[kickaha]

Yes, I am an unabashed Apple whore. Have been for years.

But this column is Dead Fricking On. No other company in any other industry would ever get away with it. Annoying.

Comments

[kickaha.livejournal.com]

There are a couple of points I think you're trying to make here, and they are best considered as separate issues.

1) Language support for data structure safety
I'm not convinced that this is a long term solution. It is a *part* of the solution spectrum, but just as C can be written to be robust, Eiffel can be written to be full of holes. The language constructs can provide safe mechanisms such as guarded arrays for buffer use, but at the same time allow production of data structures that can, if improperly designed, result in utterly trashing said mechanisms by attempts to replace them. Silly? Sure. Possible? Absolutely. Probable? Have you *seen* some of the lousy code out there these days?

Essentially, language support for any idiom has to be an attempt to enforce policy to be worthwhile. (If it were merely a case of producing functionality, we'd still be using assembler - a Turing machine is a Turing machine is a Turing machine. If it's not functionality, and it's not policy, then it's just syntactic sugar.) For instance, object-oriented languages add one essential fragment above and beyond structs, file-based function gathering and static keywords: enforced memory allocation and data initialization as one atomic act. Otherwise it's just syntactic sugar that makes certain abstractions more clear. However, one can easily 'bypass' that policy enforcement by making a class with an empty constructor and an intended initializer method that the documentation states must be called before the object is used post-instantiation. Boom. You just lost any purpose for using an OO language.

Policy support to prevent programmer stupidity is problematic, and even adding direct language support in an attempt to enforce it is at best going to snag only a portion of the problem. It'll take care of the most common cases with developers making silly mistakes, but no language will ever truly be able to protect those who think they're uberl33t from themselves.

In a similar way, using libraries and frameworks to reduce potential problems is about on par with language support. Providing facilities in an API that are simple to use and ubiquitous performs the same general function as language support, and depending on the framework, can perform much of the same enforcement (abeit at runtime, not at compile time.) Of course, they can also be bypassed, so the question becomes "How well designed is the necessary support such that it is *so* easy to use and prevalent that no developer would seriously think about bypassing it except in extremely rare cases?"

Point being: language or library, proper support can be offered and utilized, or bypassed by a truly incompetent developer. The Cocoa frameworks offer some extremely nice idioms over the top of Obj-C that extend the security of data structures, and they are amazingly well thought out after going on 20 years of work on the core philosophies. Perfect? Nope. Better than everyone rolling their own C system? Yup. As good as direct language support? Debatable, depending on the language. (The Carbon API is less stellar in my opinion, but is being transitioned to layer over the same libraries Cocoa uses.)

(Holy crap, I have to send this in pieces. Cripes.)