Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
What, again?What, again?Posted May 1, 2007 22:45 UTC (Tue) by ncm (subscriber, #165)In reply to: What, again? by dark Parent article: The Rise of Functional Languages (Linux Journal)
"Stone Age" refers to the impossibility of encapsulating management of the resource in the languages under discussion. One is left manually calling "close" functions, or (as in dcoutts's toy example above) trying to match resource lifetime to program control flow. "Imperative" (vs., presumably, "declarative") does not make a meaningful distinction. Any language that lacks destructors leaves the programmer needing to explicitly "open and close the database connection", or the mutex, or the socket, or what-have-you.
Traditionally Python has avoided this problem by supporting the equivalent of destructors in C-coded language extensions.
(Log in to post comments)
What, again? Posted May 2, 2007 0:00 UTC (Wed) by dcoutts (subscriber, #5387) [Link] And how do destructors work? They're either block scoped, if you allocate an object on the stack or if you allocate on the heap then you have to manually free the object (which then calls the destructor). So how was this better? You have to explicitly open and close the database connection, via explicitly allocating and freeing the object.
What, again? Posted May 2, 2007 1:58 UTC (Wed) by njs (subscriber, #40338) [Link] C++ actually does rather better than this (if used correctly) -- it's easy to use block scoping for most resource management (because, well, most resources of all kinds actually have lexical extent, at least in most programs when written well), and when a resource has dynamic extent, you use a smart pointer, which has explicit semantics about when it will be freed (i.e., exactly when the last reference disappears). Or you can do other fancier and situation-specific things if you want, of course, like pooled allocation.
There's no reason that other languages couldn't do this, but most GC languages are so hasty to ensure that the programmer does not *have* to worry about memory management that they remove the guarantees that the programmer needs in case they ever *want* to worry about memory management. So, in particular, most GC languages have either poor or no support for finalizers (cf. the weird interactions between Python's __del__ and the cycle collector, or the minimal guarantees Java makes about the environment in which a finalizer will be run), and make no promptness guarantees about collection. C++ is very very far from a perfect language, but it does get this part right -- you can always tell from code inspection exactly when each resource will be acquired and released.
What, again? Posted May 12, 2007 6:55 UTC (Sat) by jwalden (guest, #41159) [Link]
That's all well and good for simple data, but it falls flat on its face with cyclic data. If your data is cyclic, you have to explicitly break it somehow, perhaps via As for the rest of your comment, it's true that having the ability to perform prompt finalization is useful, in some circumstances; it enables idioms like RAII. I do have to disagree with "you can always tell from code inspection exactly when each resource will be acquired and released", however, because determining variable lifetime (particularly effective lifetime, i.e. how long the value of a variable can influence future execution -- GC provides no solution to that problem) for values on the heap can be reduced to the halting problem.
|
|||||||||||