How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
stndshp at gmail.com
Tue Aug 17 22:19:23 CEST 2010
On Aug 17, 12:32 pm, John Passaniti <john.passan... at gmail.com> wrote:
> On Aug 17, 2:53 pm, Standish P <stnd... at gmail.com> wrote:
> > Another way to pose my question, as occurred to me presently is
> > to ask if a stack is a good abstraction for programming ?
> > Certainly, it is the main abstraction in Forth and Postscript
> > and implementable readily in C,C++ and I assume python.
> A stack is a fine abstraction for some kinds of programming. It fails
> for others. In languages where functions are first-class entities
> that can be stored and passed around like any other kind of data,
> stacks can be problematic because a function can out-live the stack
> frame they were created in.
> > It is true that the other languages such as F/PS also have borrowed
> > lists from lisp in the name of nested-dictionaries and mathematica
> > calls them nested-tables as its fundamental data structure.
you are contradicting an earlier poster from forth who admitted the
part on dicts.
> > The whole case of OOP is the clustering of thought, ie book-keeping,
> > in the mind of the programmer around fewer objects than ten or twenty
> > fold functions.
> That's one view of OOP. It's not the only one.
and what can you add to enlighten the readers on the other view ?
> > so the name of the game is the same, ie to help the programmer keep
> > track of things for writing fault free code without chasing every
> > case, easy visualization, easy recall and communication with fellow
> > programmers of abstract concepts in terms of real world objects and
> > easy modification and code reuse.
> You, like probably everyone else who has thought about how to
> "simplify" languages will eventually end up at the same place-- you'll
> have a model that meets your objectives, but with some programmers
> will find is unnecessarily limiting. More importantly, you'll run
> into some classes of problems for which your simple model makes things
> inordinately complicated relative to what other languages and
> paradigms offer.
The objective is to discuss those cases via specific examples (not
generalities), and talk ABOUT them, not AROUND them.
> Here's a better idea:
Its a very fine wild goose chase project statement.
> Become familiar with the languages you've
> cited, and more. I would recommend Forth, Lisp, Smalltalk or Ruby,
> think limiting the programmer to objects with stack-ordered lifetimes
> is enough. Oh, and while you're at it, dip your toes into a problem
> domain you don't normally do any work in. If you're an embedded
> systems guy, then spend some time writing a non-trivial web
> application. Go outside your comfort zone and find a problem domain
> where cherished idioms and tools no longer apply. I think it will
> open your eyes.
More information about the Python-list