> And the fact that Apple’s methods were designed for autocomplete means that the language is practically unusable in environments without it, which in practice means substantial lock-in to Apple’s proprietary dev tools since no one else invests as much.
This may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.
This may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.