In defence of Objective-C

I believe my key mistake was using the term "real programming languages" as the alternative to "scripting languages": the word "real" is quite harsh; I have softened the statement slightly by changing "we look at" to "some look at".

I will also, though, point out that I write almost as much (if not more) Python as I do Objective-C++ these days: I therefore can be said to certainly not consider Python to be for "stupid people", without including myself in that set. ;P

I love Obj-C message send syntax and I miss it dearly when using any other language. I love that a method implicitly documents itself at the call site, and that the delimiters occur between calls rather than in the middle of them.

And it works great with code completion. You just type '[' and the editor immediately knows what you are doing. Choose a method and the parameters are right in front of you. No documentation required, unless you actually need in-depth information.

> The first major point (which is found at the end of this post) in any "defense of Obj-C" should be that this is a very pragmatic language.

"Pragmatic", much like "practical", is utterly worthless for programming language discussions. It means something different to everybody, and it's basically the tool you'll reach for when you have absolutely nothing good to say about the language you're trying to "defend".

Both "pragmatic" and "practical" should be the godwin points of PL discussion. They're complete bull.

> The point is to understand why we have brackets, because they allow for named arguments without colliding with existing C syntax.

Just because there are reasons it's done that way does not mean it's any less ugly, does it?

> Additionally, they make it clear to the user that what is about to happen is not a traditional method call, it is a message send.

For pretty much all OO PL languages, the distinction is just cutesy, the end result is that you're synchronously calling a method on an object, whether you call it "message" or "method" has little relevance.

> This is because you can do both in Obj-C

Do you mean that in a "function pointer in a struct" sense? This would use the `->` sigil would it not? And obj-c 2.0 managed to include dotted property names, so that could have been used (obviously, it wasn't because obj-c merges Smalltalk syntax into C and Smalltalk's message-send syntax does conflict with C if unbracketed)

> It's possible to take Obj-C without Cocoa, and write a framework that is just as non-verbose as Python

Not quite, Obj-C has structural deficiencies (in part inherited from C) which mean it has boilerplate you can't do without, such as the duplications between header and implementation files.

For much of its history, it also lacked any form of "blocks" (and those added in obj-c 2 are pretty verbose), meaning your Obj-C code would have a harder time with scoped resources than the equivalent Python code.

Other intrinsic verbosity issues of obj-c: iterations pre-Obj-C-2 (and fast iterators), type annotations, retain/release calls (we'll see how ARC fares), ...

I would say embracing Cocoa's chosen verbosity (although I sometimes find it misplaced) is a much better strategy than claiming Obj-C can be as terse as Python.

> And it works great with code completion. You just type '[' and the editor immediately knows what you are doing.

Whereas in other languages you'd have to write... "."?

> Choose a method and the parameters are right in front of you. No documentation required, unless you actually need in-depth information.

Pretty much every somewhat advanced IDE does that, especially for mostly-statically-analyzable languages.

> Languages with macros and (often) monads allow developers to redefine the syntax and types to accomplish these goals.

You can't redefine haskell's syntax unless you're using Template Haskell (which is a language extension, not part of Haskell itself). It also has nothing to do with monads. Likewise with most MLs, or with Erlang. All of them have a literal list syntax.

And if containers have no reason to be special, why would strings be special? They're just sequences of unicode codepoints after all.

Continuing your argument into absurdity, why have literal syntax for most datatype at all really? You could just shove a bag of bytes into a constructor when you want integers or floats as well. Now you've got one literal syntax (which isn't even for a datatype): bunch of bytes.