|
|
Re: Math Wars Philosophizing in the NY Times
Posted:
Jun 22, 2013 8:08 PM
|
|
|
|
On Fri, Jun 21, 2013 at 7:38 PM, GS Chandy <gs_chandy@yahoo.com> wrote:
> Sorry about that. Let me see if I can make the point in future without
> the shouting - however, I do notice that:
>
> i) none of them has ever taken back any of that and they had been shouting
> their slogans out for quite a few years, I believe (long before I ever
> arrived on the scene).
>
That is not remarkable given the tenor of this list, which is defined by
opposing camps with conflicting agendas. This is one of those lists where
the so-called "math wars" get fought / debated / hashed out / shared. The
rhetoric is what it is.
>
> ii) But yet, I do observe that there are a few less fulminations being
> expressed at Math-teach these days against the 'Education Mafia' and the
> 'Schools of Education'.
>
I would not be rushing to attribute much if any significance to such
stats. The fog of war is dense.
>
> This is really the heart of the matter in any societal system. GST did
> not quite provide that.
>
>
GST is not over yet. An ongoing meme.
With me, like with Kenneth Boulding, it became more critical of and/or
independent of Economics, while describing the same turf. The Henry George
school in Economics (a school of thought, somewhat obscure) seems closer to
my brand of GST in crediting sun energy for a steady flow of income, grant
income in our books.
Humans revector solar income (includes organic produce) into channels of
their own making (water wheels turning mills and so on, the water cycle
being powered by sun energy and gravity). My website pages on GST have all
these little diagrams with the sun pointing at the Earth and captions like
"current == currency".
> While GST is indeed where several of Warfield's contributions to 'systems
> science' arose from, I believe the crucial insight was absent there. For
> one thing, GST was not a 'science' - it was a 'general theory'. The other
> crucial insight, namely that we do need to enable people to work on and
> resolve their own problems, at their own levels, was also (generally)
> absent in GST.
>
> The crucial insight was certainly absent that, in systems, what we (as
> individuals and as groups) really do need to do is simply to look at and
> understand just how the factors in the respective systems may be
> inter-related to the others (and to the purpose[s] of the system).
>
Another author I write about and share the teachings of is this R.
Buckminster Fuller, who references GST while picking up on the task of
needing better integration among the disciplines.
He pioneers a new humanities language (readable as prose) that's so laced
with rather precise uses of STEM terms, in ways consistent with the grain
of current usage (e.g. "frequency"), as to gather momentum across a number
of universities, starting in North Carolina. His kind of thinking also
permeated the US military, with the hexapent dome in the Pentagon garden
(1940s).
Both assets (a) and (c) below cover these topics from different angles:
(a) Divided Spheres (STEM primer, geometric, Popko)
(b) Digital Mathematics (STEM textbook, Litvin & Litvin)
(c) King of Infinite Space (a bio, Siobhan)
http://www.nytimes.com/2013/05/13/arts/design/Richard-Buckminster-Fuller-a-Gentle-Revolutionist.html?pagewanted=all&_r=0
> For adequate 'understanding of the system', the specific and crucial
> relationship simply has to be "CONTRIBUTES TO" (its 'negative', "HINDERS"
> is also relevant).
>
> The'CPM scheduling' people had since the 1950s I believe been promoting
> "PRECEDES" as the relationship to look at, clearly not realising that in
> any unknown system, we simply cannot come to understand the precedence of
> Events and Milestones in the system till we gather some prior needed
> understanding about it - and this is available to us by trying to find out
> how things may "CONTRIBUTE TO" each other.
>
> (Of course, CPM scheduling did not actually look at 'systems' explicitly,
> though the systems are indeed, I believe, implicit there. The CPM people
> clearly needed exposure to GST, which seems to have been absent in their
> considerations. Robert Hansen is an instance of a person who got himself
> seriously 'hung up' on "PRECEDES").
>
>
A lot of this thinking has since been superseded by those designing
algorithms for parallel processors. The need to think precisely about
concurrency in various walks of life has fed back into GST, as it has into
other disciplines.
http://youtu.be/OhBgsJKLGLc (a talk I attended, not my video however)
> Warfield also perceived (right to begin with) that the specific
> relationship that we need to look at in systems is "CONTRIBUTES TO". When
> we come to understand the "CONTRIBUTIONS" of various system factors to each
> other (and to the purpose[s] of the system, we may then begin to understand
> the system - and with some understanding we may be able to work effectively
> in and on it.
> >
> >One of these systems is TDD (test driven
> > development) a branch of Agile. You let one group write tests for the
> other and then switch.
> >
> I've seen Agile and TDD. (Though I'm not an expert, by any means).
> Useful approach; I want to do something with Agile. However, I believe
> the understanding that THE crucial relationship in systems is
> "CONTRIBUTION" is absent (or, at least, it's not handled explicitly
> enough). In any case, I don't believe either Agile or TDD will enable
> anyone, at any level, to identify an issue or problem and work on it
> starting with their currently available ideas. Both are clearly approaches
> for specialists and 'experts' - but we need an approach that enables
> non-specialists, 'non-experts' to work effectively on resolving issues and
> problems.
> >
>
You're still a proponent of the all-uppercase keyword I see
("CONTRIBUTION"). I'm more from the e.e. cummings side of the fence, the
unix world, with everything lowercase, almost.
Management and software engineering go hand in hand. Developing a STEM
curriculum without serious consideration of the cyber tools and toys just
leaves a lot of serious choices to others.
I encourage school faculties to advocate for their own schools, as a place
to develop their own unique approaches.
Polytechnical schools should manage their own servers at some level,
because it's what they teach, what they profess to know, just as ag schools
should grow some of their own food.
Anyway, the CONTRIBUTION of the sun, a nearby star, to the planetary
economy, is not to be overlooked and text books which do commit this
omission are a curious genre, a layer in intellectual archeology coincident
with a dark age in human thought.
>
> Well, yes, I recall from my very early 'Boy Scout' days, the very useful
> character traits and skills (including the need for cooperation between
> individuals along with 'some' competition) that the movement seeks to build
> - in many ways quite successfully. (Of course, the 'scout movement' in
> India must have developed rather differently from how it did in its nation
> of origin [Britain] and I imagine it must have developed quite differently
> in the US as well. I'm not adequately aware about any of this to comment -
> except that I would believe that the underlying philosophy is indeed most
> useful for all individuals in society.
> >
>
Boy Scout movements were amenable to hosting "nationalism", which is
already ritualistic, so you get a lot of flag stuff in US scouting. At the
recent Eagle Scout honoring ceremony I attended, the US national flag was
presented as a gift to both boys receiving the status of Eagle, a top rank,
along with a copy of 'The Peoples History' by Howard Zinn, an interesting
synergy, perhaps symptomatic of a new synthesis within the dialectic -- a
process in the Zeitgeist.
> > Software engineering is helping managers with many
> > difficult tasks. The
> > importance of version control with formal branching
> > and merging is being
> > recognized by the legal profession and I think before
> > long the
> > Congressional Record might find itself on Github or
> > one of those (probably
> > something more customized for legislation).
> >
> It is, indeed (helping managers with extremely difficult tasks). However
> 'software engineering' as it stands is, I believe, somewhat deficient in
> that it does not adequately inculcate a 'problem-solving approach' in its
> practitioners. I confronted this problem when I tried to initiate
> development of the OPMS software. The software people just were not able
> to understand how to create and develop the software. As I'm not a
> software engineer myself, we faced some difficulties - till we all learned
> that it had to be handled as a problem outside 'software engineering' (to
> begin with, at least).
>
Management finally embraced the coding world when it realized it was
wrestling with the wrong stereotype: they saw geeks as socially inept
solitary types who retreated into windowless basements to pursue their
asocial activities, sometimes returning to the surface with miracle "killer
apps" that could be great sources of pure profit.
Then the light dawned: coding is often an intensely social activity with
input from others coming in through chat windows, version control sites,
emails, live streaming. You also sit on couches and code together. You
geek out in smallish pods. The donuts and pizza are real, as is the beer.
But you need to stay sharp so it may be more coffee or... (back to
stereotypes) Jolt Cola and Red Bull.
The light came on with the advent of Linux, which took the world by storm
-- clearly not a solo project. Apparently those geeks weren't being
asocial in those basements, they were sharing the Internet.
Many spectators following the "dot com bomb" assumed that was a blip in the
1980s and 1990s, as if Linux had since gone away. But what happened
instead is a more mature management stopped thinking in terms of
get-rich-quick stupid pet trick schemes (though these still abound) and
embraced the technology more for what it was, here to stay.
The discipline of TDD helped many companies invest in a style of code
growth that permitted continuous testing with immediate notice of breakage
when developing new features, a style less prone to bottleneck compared
with some guy in the back room, the only one who "understands" a vast code
pile.
> (However, what IS interesting is that, at that point when ILW shut up
> shop, it happened to be at the very bottom of the 'dot-com bust' - but yet
> ALL the members of the ILW software team were able to land themselves
> excellent jobs - because, by this time, they had indeed become "very
> effective s/w engineers"!! (That was their original Mission - and it served
> them well).
> >
>
It's a joy to managers to come upon a subculture that has already trained
itself in working together. The GNU project was what was behind Linux:
the set of tools needed to write an operating system: emacs, gcc etc..
A challenge though was these geeks also had developed loyalties and didn't
want to buy into an older design for intellectual property that would be at
the cost of collaborative sharing. A system of "copylefts" (a form of
copyrighting) was invented to keep the older set of reflexes at bay.
This strategy of "world domination" (retaining access to one's tools,
retaining mastery) has paid off handsomely. Instead of trying to "beat"
Linux, IBM jumped on board. Shared public knowledge, like mathematics and
science itself, means shared skills and shared literacy, and therefore
collaborative capability.
If you lock away the tools for a tiny group of elite select or
pre-ordained, you create intolerable bottle-necks for yourself while
everyone else works around you, leaving you in the dust.
>
> Of course. Software engineering (and developments from it) has been
> responsible for a huge transformation in a great many aspects of our lives.
> However, as we have realised in India, that is not enough at all: just
> now, major parts of North India have been suffering from a 'Himalayan
> tsunami' so to speak - for which we were ENTIRELY unprepared in ALL
> respects. It's clear that the need for effective 'problem solving' is
> somewhat more fundamental (arises from a more fundamental human need) than
> 'software engineering'. It really is a 'habit of mind', I claim - and we
> do not have enough of that at all in societies anywhere.
>
> GSC
>
Whereas I'm claiming that geek cultures growing up around the evolution of
the Internet have pioneered new collaboration skills that spill over,
outside just the activity of writing code.
These same people participate in self government and on standards
committees. They engage in peer review. They blend in and through
academia. They are helping us redesign STEM education to include more of
these 'lessons learned'.
True, we need to continue evolving and maturing our management practices.
I'm not saying we have reached some kind of pinnacle or final apex.
I'm just suggesting that GST is alive and well and continues to morph with
each generation of contribution.
Kirby
|
|
