Hacker News Reader

Comment by Touche | Hacker News Reader

> Objective-C isn't what you think it is

A language without namespaces, that's used almost exclusively for iOS apps and nothing else. Nope, that's exactly what I think it is.

View on HN

And, um, Mac OS X applications.

I know that may not seem like a big deal but many major applications people care about seem to have first appeared on Mac OS / Mac OS X (yes, these are two very different things).

BTW: namespaces?! Not exactly my go to checklist feature for languages.

> And, um, Mac OS X applications.

As little of it as possible. I dump everything I can into C++ both for portability and for sanity-of-code reasons.

Fine, they're different things. My point is that seemingly no one uses Objective C except to make proprietary Apple things. Which is fine, but I always find it annoying when people sing the praises of Objective C but avoid using it for web servers, cli applications... or anywhere else Objective C doesn't have an institutional advantage.

I think what people really like about Objective C is not Objective C but Cocoa.

It is called vendor lock-in. And yeah, it is not only Microsoft with their tecnologies that try/tried to do it.

It is called a vendor providing an API for a platform with useful features implemented, so that one can focus on building solutions to one's problems and not reinvent the wheel. Watch out, the way you said it makes you sound like a free software fanatic/proprietary system hater.

I would seriously consider Obj-C on non-OSX systems if it had a better library available (GNUstep doesn't cut it), but that's a chicken-and-egg problem.

It has nothing to do with lock-in. There's nothing stopping people from using Objective C to serve web apps, it's just that no one does it because Objective C is not a pleasant language to work in. People do choose to use Microsoft languages for things other than Windows apps.

Objective-C really is pleasant to use for GUIs. As I noted elsewhere in this thread, I offload everything I can into C++, but between Objective-C and IB, I really enjoy building GUIs in OS X.

Anything else, not so much, but, yeah.

"goto checklist feature?"

Does the language have goto? Check. Okay, now let's write a security library! :)

Just to be clear, I meant "go to" (and edited the post accordingly).

And MacOS applications. You know, the second bigger desktop platform.

But it's not like "where it's used" matters. That's mostly just a historical accident. If Microsoft had adopted it instead of C++ for example (which is not that outlandish), it would have been used a lot more. There was also NeXT that adopted ObjectiveC (it was developed before it), and OpenStep which also involed Sun and other players etc.

And compared to "being used for iOS apps" (e.g 1 million apps in the most lucrative mobile market", Lisp and Smalltalk are not used even 1/100 that. And Haskell even less (some "success story" here and there, eg an obscure bank, and that's mostly it). Does that make them bad languages?

And the fact that it doesn't have namespaces. Yeah, so like C. So that's important, because?

>Nope, that's exactly what I think it is.

Well, doesn't seem like you do. Or have any extended experience with the language. It's just empty snark to convey "oh, so obsolete".

The namespaces are inherent in the class name. It's actually a very nice solution.

Instead of this Foundation::Array we get NSArray. Way easier to type out, and looks a million times cleaner to me.

Until some other cool library you really want to use happens to also have a NSArray.

With proper namespaces/modules, such conflicts can be usually sorted out by renaming on import. With C and Objective-C, good luck.

If a cool library you want also has a class named NSArray, then you just refactor it by renaming on import like you just mentioned.

It's literally the exact same thing as what you're saying. Say I have one library in my project already - we'll call it BGAddressBook. And then I find another library that I really want to add that also happens to be named the exact same - BGAddressBook. So, I would refactor one of them (probably the one already in there to be BG1AddressBook or whatever). This is no different than having a library named BGAddressBook in ruby and wanting to use another library with the same namespace. You're going to have to change one or the other's namespace to work with both.

Properties don't matter and can collide with no problem. I can have a BGAddressBook with a name property and a BGSomethingElse with a name property. Doesn't matter. It'd be the same as BGAddressBook::Name and BGSomethingElse::Name.

How do you refactor third party libraries delivered as binary?

How would you refactor a third party library delivered as a binary in a language with namespaces?

By importing names from that namespace and aliasing them. Or by creating another namespace and importing them there.

You can't seriously argue that "NSArray" as a single string is the same thing as (hypothetical) "NS.Array", where both "NS" and "Array" and the thing at "NS.Array" are semantically different things. Don't get me wrong, I love Smalltalk and Erlang - both languages suffering from the same problem - but I can recognize a shortcoming when it bites my arm off.

I was genuinely asking in my question above. I'm all for it as long as it makes sense. I've never messed with aliasing or anything like that - I'm decently fluent in Objective-C but have only really dabbled in ruby/js.

After looking around halfway through writing this, this looks pretty nice:

http://stackoverflow.com/questions/11091740/is-it-possible-t...

I see what you're saying. Maybe it's Stockholm Syndrome, but I do like knowing associated files in 3rd party libraries easily too. I don't know, I'll experiment with this more in ruby and see how it feels.

Then there must be some other cool library you really want to use happens to also have the namespace "std" and a "vector" class inside...

    #include <coollib.h>

    namespace betterns = std;

The whole problem is that namespaces are open, and you can add to them from anywhere. This means a namespace alias is useless in this situation. There's no distinction between things put in namespace std by library A and things put there by library B - they are all equally valid members of namespace std.

All that has been accomplished by the namespace alias is that before, both libraries were accessible through "std", and now, both libraries are accessible through both "std" and "betterns".

Namespaces gives you the tools to make name clashes less likely, but they don't make them impossible. Generally to avoid clashes totally you need a central arbiter of name ownership like, say, the DNS registry, which is why naming your packages using inverted domain names was advocated by some people in the Java community.

I just gave a C++ example, because you asked for one.

There are lots of module systems to choose from, and Objective-C offers none.

I never asked for anything; perhaps you are confusing me with luikore.

Namespaces and modules do not prevent name clashes, at least in any language that I'm aware of. Even with a more sophisticated system like Haskell's, you're still out of luck if you have a package name clash. (And getting to the point where that's the limiting factor requires GHC extensions.)

What namespaces/modules buy you with respect to name clashes is just that they make it possible to stomach longer names that make those clashes less likely.

Are you aware of a programming language that does truly prevent name clashes through a namespace or module system? I'd be interested to hear of it.

Except that with a proper namespacing solution, you just declare that you want Foundation's Array in one spot, and in the rest of the file you just write Array. With NSArray, it's NSThis and NSThat and NSBlah and NSFoo and NSBar and NSNSNSNSNSNSNS everywhere.

That's an interesting point. I've never done that (only an amateur at ruby) with a class before besides #defines, which just feels like bad juju.

Another good thing about the Obj-C de facto way is that you can immediately tell what a class is vs seeing String string

Quadrupling the dot, that's what I think namespaces are.

How do namespaces come to be the feature to specifically call out? Is there something deeper to namespaces than a lexical (i.e. surface) convention around identifiers?

Yep. And the fact that Apple did absolutely nothing to evolve the language into something better shows that they just don't give a fuck about tools and most importantly about their developers! Maybe it's better than C++ or other alternative, maybe XCode is quite good, but this just show that since the days of NeXT (the 80s!), they just don't give a fuck!

...hate to say it, but nowadays the only big company that seems to care about developers and actually gives them cool tools and languages is Microsoft! C# with all its extensions, F# and the cool research they do in the languages area shows one thing: they care about us!

This really isn't true.

http://en.wikipedia.org/wiki/Objective_c#Objective-C_2.0 http://en.wikipedia.org/wiki/Objective_c#Automatic_Reference... http://en.wikipedia.org/wiki/Objective_c#Blocks

Objective-C also suffers from C interop considerations that make it more difficult to extend and evolve the language than something like C# or Java.

(None of this is to denigrate the wonderful work MS has done when it comes to language innovation.)

This is crazy talk. While I'm certainly not saying that Objective-C is perfect, or that Apple shouldn't do more, to say they've done absolutely nothing to evolve the language since the 80s is flat out incorrect. Look at blocks, ARC, object-literals, etc.

On revision 2.0 and later Apple has included a lot of modern stuff like: ARC, properties, literals, blocks, fast enumeration, etc.

No, you don't "hate to say it".

Reply on news.ycombinator.com