On Aug 17, 2:53 pm, Standish P <stnd...@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. No. > 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. > 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. Here's a better idea: Become familiar with the languages you've cited, and more. I would recommend Forth, Lisp, Smalltalk or Ruby, Lua or JavaScript. Learn each and then come back and tell us if you 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. -- http://mail.python.org/mailman/listinfo/python-list
