Going back to malloc/free is clearly insane. Garbage collection is handy, and works well for lots of purposes. But, gc isn't perfect: my job as a programmer is to understand and control the computer's operation; garbage collection makes memory management opaque and nondeterministic. (The usual place this bites you is when trying to optimize for memory usage - it's still possible with gc, and tools can help, but it's harder and the result more fragile.)
So there's room to explore more structured systems for memory management, that let you precisely define object lifetime when possible/convenient, or fall back on gc in a controlled way. Well-written modern C++ -- with its stack allocation and multiple flavors of smart pointers -- often looks something like this, but too many people still just use new/delete and "real gc" isn't one of the available flavors. But C++ is the only game in town for this kind of thing, because everyone else just bakes gc into their runtime as The Way Memory Works. It'd be wonderful to have a better language than C++ with a better memory management system than pure gc.
Posted Dec 6, 2008 10:38 UTC (Sat) by liljencrantz (subscriber, #28458)
[Link]
That I can agree with. The op expressed the opinion that a langauge that includes garbage collection are instafail, which I belive to be a silly argument that has been disproven time and time again in the last 10 years. But it's not a silver bullet, no. And there are definitely situations where the coder could do a lot better than even the best automatic collectors with very little effort.
New system programming language
Posted Dec 6, 2008 18:18 UTC (Sat) by drag (subscriber, #31333)
[Link]
There are module writing languages for python.. I am aware mainly of cython/pyrex. (pyrex being more serious, cython more open to add-ons)
The old story for python performance is:
1. write program
2. profile program
3. optimize and redesign in pure python as much as possible
4. if more performance is needed then move the relevant portions of the program out to C and bring it back in as a module. (Cython/Pyrex are trying to make it easier without all the boilerplate.)
This way you get the app rapidly prototyped and written and identify areas were performance and optimization work is actually necessary rather then trying to guess ahead of time.
I don't know particularly how successful this approach is, but it's what is mentioned in the literature and seems to make sense to me.
This way you get to use GC and then also do the manual memory stuff were it matters. Have your cake and eat it, too.
New system programming language
Posted Dec 7, 2008 0:24 UTC (Sun) by njs (subscriber, #40338)
[Link]
Pyrex/Cython are indeed *fantastic*. But they don't really create the kind of system I'm talking about here, because 1) they're usually used to define little self-contained computational cores and simple wrappers around foreign code, so their interaction with overall memory management is minimal (except that they let you temporarily avoid the constant heap allocations that tend to bottleneck pure Python code), 2) they don't provide any tools beyond malloc/free anyway.