3 ms·

Clearly you're in the "Features are good, use C++" camp It appears that since you didn't understand my criticism, you decided to substitute your own strawman t

Clearly you're in the "Features are good, use C++" camp It appears that since you didn't understand my criticism, you decided to substitute your own strawman that you could respond to. Your reference to C++ -- and my assumed preference for it -- is an odd choice, given that I did not actually mention the language. I think C++ is broken for reasons of poor language design. Simplicity is good in both implementation of a language and the use of it, the balance of that is complex and warrants significant consideration. I will provide an alternative summary, since I think "The ObjC runtime is insufficiently complicated." is both loaded, and incorrect: The ObjC runtime is poorly architected, shows its age, and is not sufficiently well designed to permit the implementation of features that would grossly simplify the use of the language. In support of this I mentioned a number of features that simply are non-implementable on the current runtime, including automatic handling of reference cycles. Your contrary (and unsupported) assertion is that GC is "for the most part" not efficient enough for use on 5W computer. Somebody should tell Microsoft and the MonoTouch guys. Even Android's GC is usable, and it's an fairly primitive mark-and-sweep collector.

caladri 14y ago
Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example. Is age an issue in its own right, or is it what informs what you perceive as a poor implementation that precludes the implementation of "modern" features? Also, I wonder if you perceive any possibility that progress might actually occur in the form not of accumulating more features on top of the modern fashionable designs but of starting from an earlier base and pursuing an alternate path of evolution to that of extant runtimes — do you? For example, is it possible that there is some innovation which could occur on top of C which would not be possible in the context of some modern language and its modern runtime which would make it a more desirable platform than the modern alternatives? As someone who works primarily in C (and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft!) I would say that's certainly the case, because there are already things that make C more appealing than C#, Java, etc. An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization. If it isn't that age precludes the possibility of progress, then what's the problem with age? Code rot is an illusion.
- flatline3 14y ago
  > Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example. I was referring to the particular C programming approaches of the 1990s, rather than any notion of bitrot. If you were to explore a more complex ANSI C application from 1990, you would be more likely than not to find all state managed through globals, possibly significant use of goto, a slew of poorly documented and difficult to trace implementation functions, and an over reliance on exposed structure definitions and simplistic data models that would be exceedingly difficult to iterate on without breaking the code base. Additionally, the code almost certainly wouldn't be re-entrant, much less thread-safe. You also wouldn't have found unit tests, although some people would include a commented out test () function in some of their sources. > ... and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft! My own position here is that we learned to write better C, not that we moved "up" to C++. > An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization It is very difficult to maintain pure backwards compatibility with C while adding any significant functionality. This is what Apple discovered with GC, and when implementing ARC, they had to go the route of outright restricting certain previously supported usage, eg: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.restrictions.records http://clang.llvm.org/docs/AutomaticReferenceCounting.html#o... If we pick your idea apart in more detail, how would you represent reference-counted entities in this C environment? You couldn't do so without defining higher-level structures (such as objects, or glib gobjects), at which point you very quickly find yourself heading away from C. This is effectively what Apple was forced to do to add blocks to C, and is also why it seems quite unlikely that blocks will ever see inclusion in the C specification.
drewcrawford 14y ago
> The ObjC runtime is poorly architected, shows its age, and is not sufficiently well designed to permit the implementation of features that would grossly simplify the use of the language. The first two points are not defined in a sufficient way that would allow us to have a meaningful conversation about them. What does it mean to be poorly-designed? What does it mean to be old, and why is old bad? We cannot make progress here without semantic introspection. On the third topic, however: > In support of this I mentioned a number of features that simply are non-implementable on the current runtime, including automatic handling of reference cycles I'd like to examine this particular assertion in substantial detail, because it is apparent to me I have not communicated clearly: 1) First of all, the statement "automatic handling of reference cycles is not possible to implement because of the Objective-C runtime" is false. It is false because it has in fact been implemented, in spite of the Objective-C runtime: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#//apple_ref/doc/uid/TP40008006-SW2 https://developer.apple.com/library/mac/#documentation/Cocoa... 2) I've made the general argument that many features are not useful on a 5w computer. Now I will make the specific argument that detecting retain cycles is not useful on a 5w computer: > We have no heap scans, no whole-app pauses, and no non-deterministic releases. We really think that a smooth, fluid interface is important to our customers, and that great battery life is also important. And with that, GC is deprecated. - Apple, WWDC 2012 session 406, about 34 minutes in Now extending this two-case line of reasoning to the general list of features: I do not believe (and you have provided no evidence to support) that the Objective-C runtime is the limiting factor for any feature you have listed. I also do not believe (and you have provided no evidence to support) that any feature is useful on a 5w computer. In this particular most-favored case, both of these problems apply, but I believe at least one problem applies to every feature you have listed. > Somebody should tell Microsoft and the MonoTouch guys. Even Android's GC is usable, and it's an fairly primitive mark-and-sweep collector. I think they already know: > The occurrence of this is non-deterministic, and may happen at inopportune times (e.g. in the middle of graphics rendering). If you see this message, you may want to perform an explicit collection elsewhere, or you may want to try to reduce the lifetime of peer objects. http://docs.xamarin.com/android/advanced_topics/garbage_collection http://docs.xamarin.com/android/advanced_topics/garbage_coll... As I understand it, MonoTouch's optional SGen does a better job, but still uses a stop-the-world algorithm for "large" objects. Given the memory constraints of most iOS devices, lots of things are large relative to the amount of memory you have available. For example, my real-world iPad currently has 90MB in the free pool, which means that a single layer that draws to screen is 10% of the immediately available memory in pure graphics buffer allocations. (It is possible to increase the available pool, and in fact iOS will instruct apps to dump what they can if more is requested, but this is slow and also not being a good memory citizen).

caladri 14y ago

Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example. Is age an issue in its own right, or is it what informs what you perceive as a poor implementation that precludes the implementation of "modern" features? Also, I wonder if you perceive any possibility that progress might actually occur in the form not of accumulating more features on top of the modern fashionable designs but of starting from an earlier base and pursuing an alternate path of evolution to that of extant runtimes — do you? For example, is it possible that there is some innovation which could occur on top of C which would not be possible in the context of some modern language and its modern runtime which would make it a more desirable platform than the modern alternatives? As someone who works primarily in C (and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft!) I would say that's certainly the case, because there are already things that make C more appealing than C#, Java, etc. An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization. If it isn't that age precludes the possibility of progress, then what's the problem with age? Code rot is an illusion.

flatline3 14y ago
> Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example. I was referring to the particular C programming approaches of the 1990s, rather than any notion of bitrot. If you were to explore a more complex ANSI C application from 1990, you would be more likely than not to find all state managed through globals, possibly significant use of goto, a slew of poorly documented and difficult to trace implementation functions, and an over reliance on exposed structure definitions and simplistic data models that would be exceedingly difficult to iterate on without breaking the code base. Additionally, the code almost certainly wouldn't be re-entrant, much less thread-safe. You also wouldn't have found unit tests, although some people would include a commented out test () function in some of their sources. > ... and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft! My own position here is that we learned to write better C, not that we moved "up" to C++. > An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization It is very difficult to maintain pure backwards compatibility with C while adding any significant functionality. This is what Apple discovered with GC, and when implementing ARC, they had to go the route of outright restricting certain previously supported usage, eg: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.restrictions.records http://clang.llvm.org/docs/AutomaticReferenceCounting.html#o... If we pick your idea apart in more detail, how would you represent reference-counted entities in this C environment? You couldn't do so without defining higher-level structures (such as objects, or glib gobjects), at which point you very quickly find yourself heading away from C. This is effectively what Apple was forced to do to add blocks to C, and is also why it seems quite unlikely that blocks will ever see inclusion in the C specification.

drewcrawford 14y ago

> The ObjC runtime is poorly architected, shows its age, and is not sufficiently well designed to permit the implementation of features that would grossly simplify the use of the language. The first two points are not defined in a sufficient way that would allow us to have a meaningful conversation about them. What does it mean to be poorly-designed? What does it mean to be old, and why is old bad? We cannot make progress here without semantic introspection. On the third topic, however: > In support of this I mentioned a number of features that simply are non-implementable on the current runtime, including automatic handling of reference cycles I'd like to examine this particular assertion in substantial detail, because it is apparent to me I have not communicated clearly: 1) First of all, the statement "automatic handling of reference cycles is not possible to implement because of the Objective-C runtime" is false. It is false because it has in fact been implemented, in spite of the Objective-C runtime: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#//apple_ref/doc/uid/TP40008006-SW2 https://developer.apple.com/library/mac/#documentation/Cocoa... 2) I've made the general argument that many features are not useful on a 5w computer. Now I will make the specific argument that detecting retain cycles is not useful on a 5w computer: > We have no heap scans, no whole-app pauses, and no non-deterministic releases. We really think that a smooth, fluid interface is important to our customers, and that great battery life is also important. And with that, GC is deprecated. - Apple, WWDC 2012 session 406, about 34 minutes in Now extending this two-case line of reasoning to the general list of features: I do not believe (and you have provided no evidence to support) that the Objective-C runtime is the limiting factor for any feature you have listed. I also do not believe (and you have provided no evidence to support) that any feature is useful on a 5w computer. In this particular most-favored case, both of these problems apply, but I believe at least one problem applies to every feature you have listed. > Somebody should tell Microsoft and the MonoTouch guys. Even Android's GC is usable, and it's an fairly primitive mark-and-sweep collector. I think they already know: > The occurrence of this is non-deterministic, and may happen at inopportune times (e.g. in the middle of graphics rendering). If you see this message, you may want to perform an explicit collection elsewhere, or you may want to try to reduce the lifetime of peer objects. http://docs.xamarin.com/android/advanced_topics/garbage_collection http://docs.xamarin.com/android/advanced_topics/garbage_coll... As I understand it, MonoTouch's optional SGen does a better job, but still uses a stop-the-world algorithm for "large" objects. Given the memory constraints of most iOS devices, lots of things are large relative to the amount of memory you have available. For example, my real-world iPad currently has 90MB in the free pool, which means that a single layer that draws to screen is 10% of the immediately available memory in pure graphics buffer allocations. (It is possible to increase the available pool, and in fact iOS will instruct apps to dump what they can if more is requested, but this is slow and also not being a good memory citizen).