On Aug 17, 1:19 pm, Standish P <stnd...@gmail.com> wrote: > On Aug 17, 12:32 pm, John Passaniti <john.passan...@gmail.com> wrote: > > > > > > > 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. > > 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, > > 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
program a universe simulator using a turing machine. -- http://mail.python.org/mailman/listinfo/python-list
