Item — HN Reader

I find myself wondering how many Swift converts actually wrote Objective-C like it was supposed to.

I’ve run into a lot of programmers that worked with ObjC as they would Java or C++, that is, using very small and fine grained objects to divide up the problem.

It’s the standard way in Java. It’s also the opposite of how ObjC is supposed to be, which is ”a few big classes” that uses message passing as glue.

How many former ObjC programmers actually heard of ”Software IC”?

Using ObjC like Java/C++, the language quickly becomes unwieldy and verbose. If you do that, then obviously Swift feels like a huge improvement.

On the other hand, if you essentially write C and let ObjC be your reusability layer, then Swift might feel like you’re back to working inefficiently in Java / C++ with objects all over the place.

1 comments

I definitely agree with you.

The way that I write Objective-C is to use 'id' for everything and have as few classes as possible, mostly I just add methods to the existing classes mainly NSString, NSArray, and NSDictionary.

Objects are interchangeable as long as they can respond to certain messages. For example, any object can be an array as long as it responds to objectAtIndex: and count. There was a whole discussion above about how Objective-C doesn't have generics, but this completely misses the point because Objective-C doesn't even need generics. "Modern" languages are not necessarily an improvement, software generally does not get better over time, it reaches a peak then it declines.

Objective-C is one of the best languages I have ever used, but the vast majority do not understand it, even the ones who say that they used to write Objective-C for X amount of years but now love Swift. The truth is, they never understood the beauty of Objective-C.

I consider Swift to be a language for large teams of average programmers, reading Lattner's response to Swift's criticisms tells me that he is a compiler guy, but that expertise does not carry over at all to programming languages.

I don't really like the direction they were taking Objective-C anyway, so in the end it doesn't matter. I'm against things like dot notation for accessing properties and ARC, I don't use either when I program in Objective-C. Those recent changes end up making the compiler more strict and a pain to deal with.

Interestingly generics seem to drive the addition of type inference in order to avoid having to write too complex types, losing the self documenting nature of the static type, but still not avoiding the problem entirely.

Consider the types of some template generated pointers, or just something like std::unique_ptr<std::vector<std::shared_ptr<Foo>>> (which isn’t a very far-fetched example).

This is ”the generics problem”, where it actually starts having an obscuring effect.

ObjC is immune to the problem since it lacks any need to do do the specialization. Unlike Java where you needed a lot of manually inserted casts without generics, ObjC doesn’t need them at all.

Like you say, dot notation, ARC, stricter resolution of dynamic messages etc were weakening the strong points of the language and would push the programmer towards a Java-like object model - which is very far away from how the language ideally should be used.