3 ms·

Perhaps a matter of taste, but it seems everything you dislike about the Obj-C runtime are the things I enjoy: > It is effectively an extremely simple dynamic

Perhaps a matter of taste, but it seems everything you dislike about the Obj-C runtime are the things I enjoy: > It is effectively an extremely simple dynamic dispatch runtime Yup! Just the way I like it. It's practically lisp-like in its minimalism. Just the minimum you'd need to get the job done. > reliant on the OS memory management This, actually, is one of my favorite points. Letting the JVM grab a giant allocation at startup is fine if all you're going to do with your machine is run JVM programs (i.e. a server), but it sucks when you've got multiple apps all trying to play nice together. The OS has a memory management system for a reason. I'd much prefer my runtime use the existing system, than re-invent the wheel (as it were). > with reference counting Right, well...I did mention that the lack of a GC kinda sucks. I suppose it's a trade-off that one must make if you are going to rely on the OS to manage memory. Still, I can't help but feel that some sort of opt-in system could be made to work at runtime. > zero support for any complex runtime state inspection (say, to support breaking reference cycles) Of course, the flip-side to this is that runtime performance is more predictable, since the runtime isn't attempting to do anything overly complex. I can see how you might argue this either way: more runtime introspection eases the burden on language implementors, but it also is a sunk cost whether you want it or not. > The class registration system has hardly changed in 20 years "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" > has no support for namespaces I'm not completely convinced this is a problem domain that I want my runtime solving for me. The addition of two-level namespacing to Mach-O addresses the only time I can think that I definitely want runtime managed namespacing. If I want namespacing to be part of my object model, let me determine how it should work. (It's always mildly annoyed me that Java's reverse-DNS-style bleeds into almost every JVM-based language.) > the type encodings available at runtime are complex-to-decode-strings The type encodings are simple C strings! > the whole thing is, quite honestly, the kind of rickety design you'd expect to emerge from C hackers in the late 80s early 90s If by that you mean that the central message dispatch routine is hand-optimized assembly for each platform the runtime is available on... I'll have some more of that, please! Edit: Oh, and about the "like" part...I was being mildly facetious. There are aspects of all 3 languages that I enjoy, but I doubt they'd have become as popular as they have on their merits alone. (Well, ok, given the landscape at the time, Java's popularity could be said to be fairly won...)

flatline3 14y ago
> This, actually, is one of my favorite points. Letting the JVM grab a giant allocation at startup is fine if all you're going to do with your machine is run JVM programs (i.e. a server), but it sucks when you've got multiple apps all trying to play nice together. The OS has a memory management system for a reason. I'd much prefer my runtime use the existing system, than re-invent the wheel (as it were). The OS memory management system is as general-purpose as possible. At the kernel/process interaction level, the APIs are thin abstractions on the underlying VM page mapping system. Below that, at the malloc level, malloc is designed to be as general purpose allocator as possible, without introducing complexity unsupportable in C, such as migrating allocations across generations. The JVM's lack of ability to rededicate pages to the OS is a failing of Sun's particular implementation, and is not strictly inherent in the design of generational collectors. Your argument dismantles Sun's architectural choice when used on mobile hardware, but does not address the relative merits of alternative allocation/collection schemes. > In regards to the class registration system: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" That response has little substance. It's not perfect, or even great, it's merely functional. I would be enthralled if Mach-O two-level namespacing worked with ObjC classes, but it can not. > The type encodings are simple C strings! They're C strings, not particularly simple. Try decoding (with lackluster documentation) a complex structure return value. Modern runtimes use much more cleanly structured, cross-referenced data here. > If by that you mean that the central message dispatch routine is hand-optimized assembly for each platform the runtime is available on... I'll have some more of that, please! No, that's not what I mean. You'd find just as much complex hand-optimized assembly code in other runtimes, likely more. I'm referring to design choices such as the use of unnecessarily complex data structures with minimal if not outright missing API to access them, poorly abstracted implementation details (such as exposing C string type signatures as the highest-level representation of a type encoding), minimal/missing/poorly-defined metadata. An example is the failure to encode type data in blockrefs in the first public release of blocks for ObjC, which made it impossible to implement imp_implementationWithBlock(), due to the need to differentiation between stret vs non-stret return types and select the appropriate trampoline. This required changes to both the compiler and the runtime, and meant that prior to those changes' introduction by Apple, it would have been impossible for an external entity to implement similar functionality. This sort of hackish minimalism is the polar opposite of the careful considered and long-term focused design that Microsoft (and even Sun) applied to the core of their platform. Compare the completeness (and longevity) of the JVM Virtual Machine specification to the ObjC runtime. Over roughly the same amount of time, Apple has had to introduce complete ABI-breaking fundamental changes of to their runtime to implement extremely basic language enhancements. In contract, the JVM specification has not, to my recollection, been broken once over the course of 20 years. Additions have always been forward-compatible. An example of the above would be the addition of non-fragile base classes through the use of minimal ivar access indirection. This required a wholesale breakage of the entire language, and thus could only be introduced on 64-bit Mac OS X and on iOS. Apple's language and runtime design is hackish at best.

flatline3 14y ago

> This, actually, is one of my favorite points. Letting the JVM grab a giant allocation at startup is fine if all you're going to do with your machine is run JVM programs (i.e. a server), but it sucks when you've got multiple apps all trying to play nice together. The OS has a memory management system for a reason. I'd much prefer my runtime use the existing system, than re-invent the wheel (as it were). The OS memory management system is as general-purpose as possible. At the kernel/process interaction level, the APIs are thin abstractions on the underlying VM page mapping system. Below that, at the malloc level, malloc is designed to be as general purpose allocator as possible, without introducing complexity unsupportable in C, such as migrating allocations across generations. The JVM's lack of ability to rededicate pages to the OS is a failing of Sun's particular implementation, and is not strictly inherent in the design of generational collectors. Your argument dismantles Sun's architectural choice when used on mobile hardware, but does not address the relative merits of alternative allocation/collection schemes. > In regards to the class registration system: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" That response has little substance. It's not perfect, or even great, it's merely functional. I would be enthralled if Mach-O two-level namespacing worked with ObjC classes, but it can not. > The type encodings are simple C strings! They're C strings, not particularly simple. Try decoding (with lackluster documentation) a complex structure return value. Modern runtimes use much more cleanly structured, cross-referenced data here. > If by that you mean that the central message dispatch routine is hand-optimized assembly for each platform the runtime is available on... I'll have some more of that, please! No, that's not what I mean. You'd find just as much complex hand-optimized assembly code in other runtimes, likely more. I'm referring to design choices such as the use of unnecessarily complex data structures with minimal if not outright missing API to access them, poorly abstracted implementation details (such as exposing C string type signatures as the highest-level representation of a type encoding), minimal/missing/poorly-defined metadata. An example is the failure to encode type data in blockrefs in the first public release of blocks for ObjC, which made it impossible to implement imp_implementationWithBlock(), due to the need to differentiation between stret vs non-stret return types and select the appropriate trampoline. This required changes to both the compiler and the runtime, and meant that prior to those changes' introduction by Apple, it would have been impossible for an external entity to implement similar functionality. This sort of hackish minimalism is the polar opposite of the careful considered and long-term focused design that Microsoft (and even Sun) applied to the core of their platform. Compare the completeness (and longevity) of the JVM Virtual Machine specification to the ObjC runtime. Over roughly the same amount of time, Apple has had to introduce complete ABI-breaking fundamental changes of to their runtime to implement extremely basic language enhancements. In contract, the JVM specification has not, to my recollection, been broken once over the course of 20 years. Additions have always been forward-compatible. An example of the above would be the addition of non-fragile base classes through the use of minimal ivar access indirection. This required a wholesale breakage of the entire language, and thus could only be introduced on 64-bit Mac OS X and on iOS. Apple's language and runtime design is hackish at best.