If you've never used an NSMutableURLRequest object before, but know how HttpRequests are made, you can figure out what's going on without having to dig into any documentation.
Many languages I've seen (C in particular) hide that explicitness. You call someFunction(arg1, arg2, arg3), but what do arg1, arg2, and arg3 do? Can you pass a 4th or 5th argument too? Unless you've memorized what someFunction() does, you have to dig into the docs, which makes the language harder to read. Obj-C method calls always list "every" available parameter, regardless if its used or not (e.g. nil).
------------------------------
Obj-C takes up a lot of horizontal screen space. It works best on high-resolution widescreen monitors, with a modern editor, and modern mouse, both supporting vertical AND horizontal scrolling. Limiting lines to 80 characters, or anything really, destroys its readability.
The most unreadable Obj-C code I've seen is usually formatted this way. Google's Obj-C code is a nightmare to read; they limit it to 80-characters (http://google-styleguide.googlecode.com/svn/trunk/objcguide....). Great for a 1980's terminal, not for modern 2560x1440 displays.
Frankly line-length should not be the job of the programmer writing the code, but of the IDE/Editor displaying it properly on-screen. When you say "all code must be 80 lines long", you've forced that upon every programmer regardless if it's a good decision or not.
It's like decoupling the Model and View. The Model is the actual code written, where the View is how it's displayed. Programmers should be able to customize how their View looks using their IDE/Editor. When you hard-code the View into the Model, you break decoupling, and force everyone to use the same View.
Most Editors/IDEs let you customize the view somewhat, like color-schemes and "wrap text". But I haven't seen a "complete" decoupling of the model (code) and view (how it's presented) yet, in any IDE/Editor. Someone please correct me if one exists. This is a feature I'd "LOVE" to see in all IDE/Editors and programming languages, as it will make verbose languages like Obj-C much easier to read based on the programmers preference.
This is more of a praise of Apple's naming conventions with the ios and Cocoa sdk's (which I agree are very good, as is auto-completion in XCode) than of Objective-C itself. Of course the quality of the framework is hugely important in how pleasant a language is to work with, but I wouldn't say that Objective C is an elegant language compared to everything else that's out there (IMO Python and Haskell are both very elegant, but there are a lot of languages I've never played with).
I agree about Google's styleguides... I used to code like that and line up all the :'s vertically, and i finally realized I was making my code harder to read.
So i refactored all my existing code to have every statement on one line. Yeah it's long, but my huge monitor and xcode in full screen remedies that.
Absolutely, I've been thinking this as well. But to make it really seamless, SVN/Git would have to work that way too, and they'd have to have knowledge of the language's syntax for that, which is not going to happen.
Many languages I've seen (C in particular) hide that explicitness. You call someFunction(arg1, arg2, arg3), but what do arg1, arg2, and arg3 do? Can you pass a 4th or 5th argument too? Unless you've memorized what someFunction() does, you have to dig into the docs, which makes the language harder to read. Obj-C method calls always list "every" available parameter, regardless if its used or not (e.g. nil).
------------------------------
Obj-C takes up a lot of horizontal screen space. It works best on high-resolution widescreen monitors, with a modern editor, and modern mouse, both supporting vertical AND horizontal scrolling. Limiting lines to 80 characters, or anything really, destroys its readability.
The most unreadable Obj-C code I've seen is usually formatted this way. Google's Obj-C code is a nightmare to read; they limit it to 80-characters (http://google-styleguide.googlecode.com/svn/trunk/objcguide....). Great for a 1980's terminal, not for modern 2560x1440 displays.
Frankly line-length should not be the job of the programmer writing the code, but of the IDE/Editor displaying it properly on-screen. When you say "all code must be 80 lines long", you've forced that upon every programmer regardless if it's a good decision or not.
It's like decoupling the Model and View. The Model is the actual code written, where the View is how it's displayed. Programmers should be able to customize how their View looks using their IDE/Editor. When you hard-code the View into the Model, you break decoupling, and force everyone to use the same View.
Most Editors/IDEs let you customize the view somewhat, like color-schemes and "wrap text". But I haven't seen a "complete" decoupling of the model (code) and view (how it's presented) yet, in any IDE/Editor. Someone please correct me if one exists. This is a feature I'd "LOVE" to see in all IDE/Editors and programming languages, as it will make verbose languages like Obj-C much easier to read based on the programmers preference.