CompuServe Messages

>the principles of OOP are language indepent, indeed. Indeed. >Of course, you will >need a much extended – and therefore slow one – BASIC interpreter to handle >capsuled stuctures 🙂 Yes, and herein lies part of the point of an OOL. It is not so much that you must have an OOL to do OOP, but it becomes so much more convenient and "natural" to do so. > Imnho, OOP or not OOP is a question which style one prefers for problem >analysis and solving. Exactly. > You may use a (preferably true) oo-language or not. For sure (obviously with some force fitting and twistings, but definitely possible). >Imnho, OOP just means to switch on your brain and let it warm-up before coding. Welllllll, I think that too generalized to be useful. I mean I can definitely warm-up and do my pre-stuff under a non-OO approach. >The other i would characterize as brain-storming. Both may lead to a reasonable >result. The bill comes with management of design errors and later with >servicing and upgrading/actualisation…:-) Actually, both may, or may even lead to the same result. Nonetheless, if the brain-storming is not merely hacking, hopefully there is some method to the madness, and an educated senior programmer who is concerned with product growth maintanence and other even disjoint subsequent products, can only be keep teethering through the same issues. Of course, there is always a line in the sand. I don't think I just want to brainstorm on a 10MLOC application. I want to do a lot more, including being aware that there will be design errors, including some beyond my control. We are often apt to say that because say a 500 LOC app is so small is to be consumable (or mostly so) by one human that it can be done a different way, but I believe the issue isn't as simple as that. For instance, if my 500 LOC is a one-day program just to obtain a rough answer of something, it might be validly argued that the upfront time and planning of say an OOP design would be too excessive in ratio to the lifetime of the app. Well, it's equally valid that the nonchalantness of the throw-away might be problematic. Also, with a design, one may have found reasonble prototype (starting?) points for the app based on this one. Etc. I'm not arguing for either side, just raising that the issues and goals and needs and tradeoffs and expenses need to be constantly evaluated.