While I agree with the OP in that there are certainly improvements that could be made to Objective-C I find myself disagreeing with a lot of the ideas in the post, especially this paragraph:
>We think we know what we want from an Objective C replacement. We want Garbage Collection, we want better concurrency, we don’t want pointers. We want better networking, better data base, better syncing functionality. We want a better, real runtime. We don’t want header files or import statements.
We don't want Garbage Collection to the contrary we want reference counting. Reference counting is the best compromise between handling memory manually and using GC ala Java. I would argue that the mental strain for the programmer is equal for reference counting(at least with ARC) to that of GC. However Reference Counting is extremely lightweight.
Regarding concurrency it should be mentioned that I don't have a huge amount of experience with different languages. I've done concurrency in Erlang, Java/JR, C++ and Objective-C. I'd say that GDC from Objective-C and possibly Erlang were the easiest to use.
Why wouldn't we want pointers? Most modern languages use pointers under the surface, there are significant benefits in not obscuring and hiding this as is done in Java.
We do want header files and imports because they provide a bunch of benefits namely separation of interface and implementation, distribution of compiled implementations with interfaces in header files. With the @import option compile time is significantly faster as well.
I'll deliberately skip the last points, suffice to say I don't feel strongly about them. I do agree on the data base point though.
My own revised list of things that Objective-C needs are. Proper static typing(no id), templates and namespaces.
EDIT: The point about requiring a programer to change a color is interesting, all though I would argue that the same holds true for web. I have rarely worked with designers who are proficient enough in git and css to make such changes. In the case that the designer is proficient enough to handle git, a css like json file can be used to specify the look of the app and thus changing colour would only involve editing a json file which is comparable to editing a css file
> We don't want Garbage Collection to the contrary we want reference counting. Reference counting is the best compromise between handling memory manually and using GC ala Java. I would argue that the mental strain for the programmer is equal for reference counting(at least with ARC) to that of GC. However Reference Counting is extremely lightweight.
I used to think that, until I started to spend more time on modern GC platforms like Java and .NET. It's impressive how performant a good generational garbage collector can be. For many business applications (i.e., not the kinds of workloads you'll see being simulated by popular benchmarks) a good generational GC can even improve performance thanks to improved locality of reference. I think a lot of us don't fully appreciate the cost of a cache miss.
Speaking of, I'm not sure a lot of us fully appreciate the cost of synchronization, either. It's one big reason why I'm not convinced that reference counting is particularly well-suited to concurrent programming, since it turns a really commonplace operation (retaining a reference to an object) into a synchronization point in the program. There's a non-trivial cost associated with that. You could avoid repeatedly stalling the CPU by being very careful about not sharing objects among threads, but I don't think most developers can reasonably be expected to make a habit of that in practice.
> Speaking of, I'm not sure a lot of us fully appreciate the cost of synchronization, either. It's one big reason why I'm not convinced that reference counting is particularly well-suited to concurrent programming, since it turns a really commonplace operation (retaining a reference to an object) into a synchronization point in the program. There's a non-trivial cost associated with that.
This is actually a problem for both. Simple implementations of AGC have to stop the world to scan at least the roots, and probably even a bit more than that, because there are significant ABA problems. There are ways around this, but as far as I know the only environment to use any of the really good ones is the JVM, because it's hellishly complex. I don't know that there is anything that doesn't stop the world for at least a couple of ns, though.
There are also solutions to it for reference counting. They involve using thread local reference counts and briefly stopping the world to reconcile the counts. I believe [1] describes this algorithm.
And once you get there, and start dealing with cycle detection, the difference between the two approaches starts to look a lot smaller. There's a paper on this too. [2]
I disagree with ridding ourselves of C compatibility to make the syntax terse. Being able to wrap C libraries and have a reasonably high level runtime a huge strong point of objective-c.
I am confused. Where did you get the impression that I was in favour of removing C compatibility? For the record I agree on your point. Any language which has compatibility with C is favourable.
>We think we know what we want from an Objective C replacement. We want Garbage Collection, we want better concurrency, we don’t want pointers. We want better networking, better data base, better syncing functionality. We want a better, real runtime. We don’t want header files or import statements.
We don't want Garbage Collection to the contrary we want reference counting. Reference counting is the best compromise between handling memory manually and using GC ala Java. I would argue that the mental strain for the programmer is equal for reference counting(at least with ARC) to that of GC. However Reference Counting is extremely lightweight.
Regarding concurrency it should be mentioned that I don't have a huge amount of experience with different languages. I've done concurrency in Erlang, Java/JR, C++ and Objective-C. I'd say that GDC from Objective-C and possibly Erlang were the easiest to use.
Why wouldn't we want pointers? Most modern languages use pointers under the surface, there are significant benefits in not obscuring and hiding this as is done in Java.
We do want header files and imports because they provide a bunch of benefits namely separation of interface and implementation, distribution of compiled implementations with interfaces in header files. With the @import option compile time is significantly faster as well.
I'll deliberately skip the last points, suffice to say I don't feel strongly about them. I do agree on the data base point though.
My own revised list of things that Objective-C needs are. Proper static typing(no id), templates and namespaces.
EDIT: The point about requiring a programer to change a color is interesting, all though I would argue that the same holds true for web. I have rarely worked with designers who are proficient enough in git and css to make such changes. In the case that the designer is proficient enough to handle git, a css like json file can be used to specify the look of the app and thus changing colour would only involve editing a json file which is comparable to editing a css file