begin quoting Christopher Smith as of Sun, Apr 10, 2005 at 07:11:04PM -0700: > Andrew Lentvorski wrote: [snip] > >No argument there. People overuse OOP. > > Nah. People overdo architectures and abstractions. It's a phenominon you > can find with almost any language, but it tends to be more common with > the higher level languages. I think it's 'cause programmers have too > much free time on their hands. ;-)
Here's a shiny new hammer. Odd how suddenly how everything looks like it needs a good solid whack. "Overdo" is an endemic disease among the technical crowd. You get a new concept in your head, and your subconcious keeps an eye out for places to use it. Most recently, I've seen this with "Design Patterns" -- I think that design patterns are _wonderful_, and that every programmer ought to read at least the GoF book. But a common disease in the pattern community is "pattern happiness". Instead of looking for a pattern to fit a thorny problem, a lot of people look for places to apply a design pattern or three. (I really think that the 'liability' and 'tradeoff' aspects of a pattern should be emphasized a lot more than they are for just this reason.) (This is how I explain the vehemence of some of the Lisp-is-great crowd.) However. When you _learn_ a new concept, it's probably _best_ to catch this disease for a little while (but avoid making any significant decisions while so infected), just to make sure the concept sticks. A lot of people learn OOP, dutifully recite "objects are data plus behavior", and then revert to their old (often procedural) habits in a couple of months. It's amazing how C-like old C programmer's Java code can look, especially if they're in a rush and haven't ever pushed themselves to look at everything with the rose-colored OOP spectacles. But you'll want to recover, eventually, so you can use the other tools in your toolbox. [snip] > >Classes, packages, namespaces, files, etc. are grouping features for > >managing engineering complexity--nothing more. They are not "new > >paradigms of programming"--they are simply housekeeping. Very > >*useful* housekeeping sometimes--but housekeeping nonetheless. > > I agree that they are techniques for organizing code and managing > engineering complexity. We had "all programming is just book-keeping on some level" on the whiteboard for awhile. Replace 'book' with 'house' and the sentiment remains... programming seems to fall into picking good names and keeping track of things. > However, I'd argue that if anything is a > different "paradigm of programming", it would have to be something that > changes how you organize code and manage engineering complexity, no? I We're throwing around "paradigm" here an awful lot... I may have to go read Kuhn again to make sure my definitions haven't become blurred by the hype. > would agree that the "new" is silly vis-a-vis OOP or even functional > programming, as they've been around for so long relative to procedural > programming... well, it seems silly to call them "new". Indeed. -Stewart -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
