For me the problem isn't Obj-C. It's cocoa. (Unless things have changed,) if everything was consistent in cocoa from a language perspective i.e. every library / framework is accessible with Obj-C from the start as opposed to being only C. If I remember correctly the Addressbook portion is one of the culprits.
In defence of Objective-C
101–110 of 122 posts
Re: In defence of Objective-C
#102As someone who likes Objective-C a lot, I have to say this is a pretty bad defense of it. No offense, clearly we are both fans of the language, I just don't think this will convince anyone on the other side. In fact, I find very little defense of it at all in this post. It seems his fundamental argument is "its a matter of taste", which while true, in no way conveys the many "whys" of the choices made in this languag…
I stopped reading at: "Things like factories, adapters, and other design patterns are all thankfully not there." Huh? Design patterns are "thankfully not there"? What does that even mean?
It means that you type stuff like
NSArray* array = [NSArray new];
CollectionFactory colFactory = new CollectionFactory();
ICollection array = colFactory.getArrayOptimizedFor(100);
Re: In defence of Objective-C
#103The only argument I'm buying into is this one... [someInstance doSomethingWithObject:a andAnotherParam:b]; It just reads beautifully. Otherwise working with Objective-C was like pulling teeth at times. It had been a long time since I had to write so much code to get such simple things done.
Exactly. I once worked with a very smart Obj-C guy. I asked him if he could document all the method calls so I knew what they did.
He said: there is no need. In Obj-C the selectors should document themselves.
Re: In defence of Objective-C
#104Earlier quoted context omitted.
On #4: personally, I believe it is a mistake to attempt to abstract memory management from developers unless you can abstract all resource management (as there is no fundamental difference between memory mappings, file handles, database connections, or minimum-wage bicycle messengers), and in the attempt to fully abstract memory management (as in, with garbage collection) it usually becomes impossible to abstract arb…
Why don't you expand upon this and your other comments into a full-blown defense of objective C? for the record: My preference for Smalltalk-style messaging over Simula-style objects is largely historical (having been exposed to the former first)
I'm curious why you ascribe that preference to historical reasons. My exposure was in reverse order to yours but we have the same preference.
Re: In defence of Objective-C
#105I don't think these are the real problems with Objective-C. To quickly address this issues, before discussing the real problems: "Ugly" - get over it, "Verbose" - get over it, "Memory Management" - Obj-C memory management is in fact super simple as long as you follow some really simple rules, especially with ARC. Now the real problems I have: 1. Lots of unnecessary code. With the old runtime, you had to modify your c…
Apple still plans to make synthesize the default behavior in the future, but they encountered problems of C ambiguity that prevented it from shipping for Lion.
I don't think how old the language is matters, especially since it has seen several major updates in recent years.
Re: In defence of Objective-C
#106For example, to filter an array is lovely: filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; A four-word name for filter and filtering for equality by using a string formatting DSL are not really on my list of lovely things. I'm sure Objective-C does something well but this guy is not pointing it out.
It's four words because Objective-C methods are self-documenting. From that method name, I know it returns a new, autoreleased array that has been filtered using the provided NSPredicate.
Re: In defence of Objective-C
#107I dislike the NextStep libraries (and all of Apple's subsequent creations) far more than Objective-C itself. The completely unnecessary verboseness is what drives me up the wall. If the libraries were designed more like C++'s (say what you will about STL, but at least set is called set ), I'd probably have no issues whatsoever.
You may dislike the verbosity, but it's hardly "completely unnecessary." A typical Objective-C program is inherently self-documenting. It's nice knowing what a group of arguments is used for without having to look up the method prototype.
Re: In defence of Objective-C
#108Earlier quoted context omitted.
The Android phones appeared a year or so later. Memory prices weren't the same. And GC is always less efficient than no GC, even with more memory.
> And GC is always less efficient than no GC, even with more memory. No, it's not. GC allows for more efficiency in many scenarios. Imagine creating and destroying many small objects. With traditional memory management, every malloc incurs a cost to allocate a chunk of memory from the free store. This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for lat…
> This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc.
This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior.
> in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested.
Sure, but by "less efficient" I'm not only referring to allocation speed, but also to memory usage. That nursery pool is auto-managed, and not program specific (with the exception of some smart gc guesses).
Re: In defence of Objective-C
#109I don't think these are the real problems with Objective-C. To quickly address this issues, before discussing the real problems: "Ugly" - get over it, "Verbose" - get over it, "Memory Management" - Obj-C memory management is in fact super simple as long as you follow some really simple rules, especially with ARC. Now the real problems I have: 1. Lots of unnecessary code. With the old runtime, you had to modify your c…
7. `[X new]` works.
Re: In defence of Objective-C
#110Earlier quoted context omitted.
> 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,…
The way the do notation syntax (used by most people for describing monads) in Haskell translates to function application allows you to do some fairly interesting things with syntax abuse. As for strings, it is very seldom that you find interesting alternative implementations: the only one I can think of is a rope. Interestingly, C++11 now allows you to override string literals, so you can actually do this.
Objective-C actually allows you to choose which string class you use as well using the compiler flag "-fconstant-string-class=class-name"
http://gcc.gnu.org/onlinedocs/gcc/Constant-string-objects.ht...