4 ms·
In particular when defining and/or implementing the semantics for an imperative language, eventually store (memory) management comes up and everything gets much
by ced 10y ago
In particular when defining and/or implementing the semantics for an imperative language, eventually store (memory) management comes up and everything gets much more complicated instantly.
Why? Isn't C-like "call malloc" simpler than the GC which is required for most (all?) functional languages?
- kd0amg 10y agoIt's not really being functional that calls for GC -- if you have data structures (whether they're closures, records, or whatever) escaping up from the scope in which they were created, you have a tricky lifetime question to deal with. In both the imperative and functional cases, you could require explicit allocation and deallocation (like malloc/free), and you could make it automatic (garbage collection). Functional programming tends to use GC because passing/returning closures is a common thing to do. These days, I would say imperative programmers also tend to use GC.