On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
Of course it was sold at WWDC as "ARC is better than GC" and
not as "ARC is better than the crappy GC implementation we have
done".
I have never seen a single instance of a GC based system doing
anything smooth in the realm of audio/visual real time
performance without being backed by a non-GC engine.
You can get decent performance from GC backed languages on the
higher level constructs on top of a low level engine. IMHO the
same goes for ARC. ARC is a bit more predictable than GC. GC is a
bit more convenient and less predictable.
I think D has something to learn from this:
1. Support for manual memory management is important for low
level engines.
2. Support for automatic memory management is important for high
level code on top of that.
The D community is torn because there is some idea that libraries
should assume point 2 above and then be retrofitted to point 1. I
am not sure if that will work out.
Maybe it is better to just say that structs are bound to manual
memory management and classes are bound to automatic memory
management.
Use structs for low level stuff with manual memory management.
Use classes for high level stuff with automatic memory management.
Then add language support for "union-based inheritance" in
structs with a special construct for programmer-specified subtype
identification.
That is at least conceptually easy to grasp and the type system
can more easily safeguard code than in a mixed model.
Most successful frameworks that allow high-level programming have
two layers:
- Python/heavy duty c libraries
- Javascript/browser engine
- Objective-C/C and Cocoa / Core Foundation
- ActionScript / c engine
etc
I personally favour the more integrated approach that D appears
to be aiming for, but I am somehow starting to feel that for most
programmers that model is going to be difficult to grasp in real
projects, conceptually. Because they don't really want the low
level stuff. And they don't want to have their high level code
bastardized by low level requirements.
As far as I am concerned D could just focus on the structs and
the low level stuff, and then later try to work in the high level
stuff. There is no efficient GC in sight and the language has not
been designed for it either.
ARC with whole-program optimization fits better into the
low-level paradigm than GC. So if you start from low-level
programming and work your way up to high-level programming then
ARC is a better fit.
Ola.
