On Tue, Dec 6, 2011 at 10:02 PM, Joe Niederberger <email@example.com> wrote: > "I checked the link. That idea each object should manage its own > secret, privately / independently manipulable, is still a powerful > influence I'd say, in some schools of thought (object oriented). > Others distrust that vocabulary (the more functional schools, which > claim to avoid both variables and state). > Kirby" > > Well there you go - you can't really understand Parnas much if you insist on "translating" what he is saying into "objects" or "classes" (as however *you* may use the terms.) Because his ideas just are on a bit different level (that of design and specification, not implementation) albeit with some overlap and borrowing (mostly from Parnas to "OO".) That was actually the point of the paper -- to revisit the original ideas freed from the "OO" blur. >
Even before implementation, we OO guys are prone to see the world in terms of objects. Don't need to touch a computer. That's just the mental lense. We get flak from feminists (some of us are girls -- Python Ladies for example) for "objectifying" all the time, but as a matter of fact that's our professional responsibility. 
More I was checking the conclusions section of that Parnas paper and finding the use of the word "secret" of interest, as languages have these different relationships to that concept. In Smalltalk, you couldn't / can't get to state variables directly, whereas Python leaves everything open, though you have optional cladding. Different levels of privacy pertain.
But then I sensed a subtle link between "secret" and "independent variable" (as in "parameter that my be isolated and altered, perhaps with side effects") and found that curious. I should go back and read more.
I've been in high level meetings (over about a 3 day period) with Guido (Python inventor) and Alan Kay (Smalltalk inventor), so will brag being connected at a high level in the OO world.
We also had Scheme people at this meeting though (OO wasn't the only focus), whom I would characterize as being more in the functional school (LISP, Haskell... its a category of language, with lots of hybrids, such as J, including aspects of the purer archetypes).
We've been discussing the imperative / functional split over on mathfuture quite a bit, with Cherlin and others, as it does impact how we teach Digital Math somewhat. Various teachers are experimenting with different techniques and comparing notes (as one would hope).
> But, on the main point, separating the "what" from the "how" - I take it you are just not that into it. The notion of "database lookup procedure" won't help anyone appreciate the utility of that distinction. You would have to let some purely abstract notions into your world to get or make the point. For example, in Parnas' language, an (abstract) "interface" is a (system developer's) "set of assumptions". Its not a concrete computing artifact at all. Your reference to "functional schools" seems to me to be on the computing artifact level, not on the system design and documentation level at which Parnas' work is aimed. I think his design philosophy is relevant regardless of the underlying computer language. Its perhaps hard to appreciate in the context of simple programs and classroom sized projects. > > Joe N
I freely admit to being no instant expert on Parnas and his thinking, but from my point of view, to focus on that paper is to suddenly veer off road and go trundling over the high Oregon desert. The point of this thread, I thought, was the unification of
(a) high school level Dolciani type functions (a set of related topics), most of which are rule driven in practice (e.g. boolean expressions), and
(b) the "how things work" vocabulary of the ecosystem / economy, which includes a lot of technology (this is STEM, where T matters as much as M does).
Since we're already talking about SQL and related tables, it's convenient to map domain, range tuples to key, value pairs -- concepts we're already yakking about in the context of SQL / noSQL.
There need be no rule (algorithm, computable path) for matching this key to that value. This is the pure idea of (x, y) pairs, with the added stipulation that no x is paired with multiple y's (that would be a relation, which has its own charms). That's already part of the Dolciani presentation, has been for decades.
Now of course most high schools are still in the thrall of Washington DC's hegemony and are forbidden to teach anything like "how things work" under the heading of "math".
Math has its own function in those 1900s-designed holdovers. It was more about weeding and feeding using somewhat arbitrary content (as long as the teachers were better at it, was the main thing), and getting the most compliant / fastest problem solvers better fit for service in industry as obedient doobies.
That function is broken as well however, or is at least easy to compete with. I advise friendly Silicon Forest bosses to harvest their grads from my ranks over theirs (talking about teachers too).
Schools that smash down the wall between "algebra" and "programming" are just going to develop in more interesting ways, so that's where we need to do our watering. "Water the hybrids" is my battle cry.
Anyway, if you haven't figured out some way to blend math and computer topics in a more synergetic brew by now, then maybe play it safe and stay with Washington DC (a LoserVille) and continue slogging along with a deficient, sub par, laughably obsolete textbook.
We're seeking advice and funding from other corners when it comes to Digital Math.
The USG is welcome to play, but *not* call all the shots (look where that leads -- not making *that* silly mistake yet again).
'Concrete Mathematics' was another inspirational title. But that was so many years ago by now.
 We also laugh sarcastically in Harvard's direction and ask when it's gonna grow "frontal Loebs" -- just a stupid play on words and besides it's insider / occupy talk that only a few academics, probably in the literature department, will have idea ability to decode (Arthur Loeb was a Renaissance Man who taught at Harvard and MIT a lot, long story).