[Edu-sig] As We May Think: What will we automate?

[kirby urner]

On Mon, Mar 23, 2009 at 12:42 AM, Edward Cherlin <echerlin at gmail.com> wrote:

<< SNIP >>

>>> = Edward
>> = Kirby
>   = Edward
     = Kirby

>>> There are several programming languages popular among non-professional
>>> programmers. These languages get no respect in the professional
>>> community, and neither do their users. But think what a
>>> non-professional programmer is. He or she is typically a specialist in
>>> some other domain who needs custom programming. A statistician, a
>>> scientist, an engineer, a computer musician...I know people in each of
>>> those fields, and others, creating their own software to do their
>>> jobs.
>>
>> An example or two might be helpful.  I spontaneously think of Excel,
>> SPSS and Mathematica, all of which get respect, although not so much
>> as "general purpose languages" -- which has specific meaning.
>> Mathematica is general purpose in the sense of "comprehensive in what
>> it covers" but I don't see it as a replacement for SQL or Javascript.
>
> Most of my examples are from APL.
>

OK, but I think we agree APL is a professional language that gets
plenty of respect from the professional community.

> Stanley Jordan is a jazz guitarist who graduated from the Princeton
> Computer Music program. He writes APL programs to write music.
>
> My father was an actuary. He calculated insurance rate books in APL.
>

I have a lot of respect for APL / J.  I also cite Iverson a lot, think
he supplies ammo in the CP4E department, especially in support of
using an executable notation to learn math concepts.  I cite him in my
Python for Teachers handout on this very topic:
http://www.4dsolutions.net/presentations/p4t_notes.pdf

Apropos of that, the Jsoftware.com web site is one of the best in
terms of walking that talk, using J to look at 'Concrete Mathematics'
in particular, related territory.  I'm tickled every time I think how
converting a permutation to cyclic notation is a builtin primitive in
J.

I also enjoy writing it in Python, at which point it becomes
importable as a name in a namespace.

>> <rant>
>>
>> This is what I most disagreed with in Keith's remarks.  I don't think
>> all those centuries upon centuries of encoding our thinking in lexical
>> constructs, grammars, is suddenly on the verge of evaporating in to
>> some drag and drop cartoon-like haze.
>>
>> Rushing to shield children from the supposedly harmful effects of
>> lexical coding, while on the other hand stressing reading books and
>> imagining while so doing (i.e. not needing those pictures "as a
>> crutch"), is to work at cross purposes in a self defeating pattern.
>
> I assume that this rant is directed at my Turtle Art proposal. It is
> not in any way opposed to lexical coding, which is essential for
> managing programs of even half a page in length. My proposal is to
> introduce tree-structured thinking first, and then show how to
> represent trees in lexical constructs, whether literally in LISP, or
> by punctuation, indentation, and other devices in other languages. The
> idea is to teach what is common to almost all programming languages,
> and make it much easier to switch from one syntax to another, as one
> has to do now that nobody can program exclusively in COBOL for 40
> years.
>

Not really directed at Turtle Art proposal no.

I think it's more I get this feeling when in the Squeak and Smalltalk
world, that there's a backlash against lexical coding as that means
typing (as in typewriter, keyboard) and little children aren't so good
at that, ergo need like affirmative action where we use eye candy
approaches, "friendly" peripherals, and let them conceptualize these
"like programs" in a dream-like Disney-esque environment.

I skeptical of this tendency to over-romanticize the "child prodigy
programmer" as if we should be spending big GNP on overcoming any need
for a keyboard, so Johnny Neutron can just "program in his mind's
eye".  Similar to my rant against chip implants, trying to bypass eyes
and fingers even when these are working OK.  Even though this
technology is still somewhat far off (in terms of the Hollywood
versions) I think it sends the wrong message to even hype them as
desirable, as if we'd all be happier if this were Wall*e world
(everyone on their backs with a big gulp, thinking in Smalltalk).

You're not in that camp, or at least not with this project, is what I
hear you saying.  But that that brings up the question of what age
range you're aiming at and do they know how to type.

So again, I'm not a detractor w/r to Turtle Art, hope you won't think
of me that way.  If you're getting across tree structures, that's all
to the better I'm thinking, because of the DOM and XML more generally.
 XML is a tree structure, in terms of nodes having children and not
having more than one direct parent.

In the old days, when we'd teach grammar, including Latin grammar
(because it's hard, consistent, and detailed -- was the theory, this
is before my time), students would visualize parsing, these parts of
speech.

We're kidding ourselves if we don't think those kinds of concentration
and analysis were irrelevant to later computer language formation --
they go part and parcel.

Nowadays, though, we want to extend "grammar" to include more of a
sense of the DOM, XHTML and CSS, how these inter-related, including
with template languages like Jinja2.  That's more what IB Engish
should be like.

>> We're not anti-lexical, aren't trying to kill off the "left brain".
>> Needing to type lots of characters in order to get things to happen is
>> not a terrible thing.  Wiggling fingers, instead of just lying in bed
>> and programming through "chip implants" is also not a high crime.  I'm
>> all for prosthetics where necessary, but why as elective surgery?  We
>> have better ways to spend our R&D budgets, than on gratuitous
>> peripherals for those with already functional biological equipment.
>>
>> </rant>
>>

>>>> = Keith, a well respected engineer in these parts, inventor of "Lofstrom Loop"

>>>> Working with "text code" will probably be considered
>>>> "fundamental" and "connected with our roots", like animal-powered
>>>> agriculture is now....
>
> Bizarre.

<< SNIP >>

>> I sense countervailing temperaments at work.  Some people just feel
>> better when there's this sense of a unified substrate, a primitive
>> simple beginning.  Others are less monotheistic in their proclivities
>> and don't mind a more heterogeneous "toolbox" model.  You get down to
>> a bunch of very different things, working in complement.  But there
>> you have it:  "everything is a thing" in basic English (a useful
>> design pattern, even though ridiculously misleading).
>
> There are quite other motives at work. One set is that some people are
> willing to take on a greater memory load than others.
>

I share your interest in using memory efficiently.  It's just that I
like where Python "begins" which is "in the middle" with hash table,
array / list, class itself (a kind of data struct w/ behavior),
already built, ready to rumba.  Problem I have with Scheme, as a
starter language, is you either need to import, or code from scratch,
these kinds of data structures that aren't primitive, but can easily
be built (again and again, seemingly endlessly).

I just get impatient with low level languages I think.  I've usually
had the luxury of high level objects, even as primitives.  Call me
spoiled in that way.

When it comes to teaching mathematics with Python, the high level
works in my favor.  I don't necessarily want to spend much time
talking about chip internals, registers.  This isn't computer science
or electrical engineering.  We want to spend most our time thinking
about Polyhedra, Vectors etc.

Yes, these are expressed as Python objects, but no, we don't feel
we're learning to become "professional programmers" as our goal here
is to get clear on these Polyhedra and Vectors.  That might be for
theater work, plus something about airplanes.

>>> "I invented Object-Oriented Programming, and C++ is not what I had in
>>> mind."--Alan Kay
>>>
>>
>> Yet we want to recruit talent willing to learn and work with C++.
>> I've put quite a bit of work into thinking how we might recruit future
>> M programmers (suMerian meme), copying humanities disciplines focused
>> on ancient cultures (linguistics, archeology, history, warcraft...
>> poetics).  They tell me UC Davis is still a hotbed of MUMPS
>> scholarship.
>
> I know the OpenVistA people. It's worldwide.
>
>> This isn't easy work for me though, because in other contexts,
>> hospitals clinging to "dead language" systems like MUMPS is biting
>> into my take home pay.  I want elegant FOSS solutions to replace
>> creaky, unmaintainable, unscalable systems, but bureaucrats fight me,
>> because people like using what they already know.
>
> You now face a dilemma. OpenVistA _is_ FOSS.
>

Thanks for reminding me about this, I'd plumb forgot!

So I'm just going to stay biased and say not all FOSS projects have
the same half life for a reason, and I think MUMPS is on the way out,
simply because the LAMP stack or a variant will do the same things and
is better understood i.e. why forgo real SQL in this day and age.  We
should use more Django, in hospitals, not just on-line newspapers.

At least that's what I'm seeing with one major client.  Everything
they're doing is the same kind of SQL stuff you'd do with PostgreSQL
plus the interface is butt ugly, plus no one on staff knows any MUMPS
so they're completely at the mercy of external vendor coders in that
language, hardly prevalent compared to say Python or Perl or one of
those.  They pay top dollar for a DOA offering.

Yes, M has a niche market in health care (where it started, where it
dies), but from what I've seen up close, the health care sector is
paying a high price for keeping MUMPS alive well past its prime.
There's maybe a difference between a "dead language" (e.g. FORTRAN,
still the basis for lotsa libraries) and a "zombie langauge" (e.g. M).

>From interviews I've done, and from source code I've eyeballed, I'd
say M seems a crazy-making language, not at all a pleasure to use, and
in the hospital where I've seen it at work, it actually breaks in
serious ways, the equivalent of a primary key getting corrupted.  The
product built around it is unwieldy and deficient.

Fortunately, this is research data, not legal medical records.

Unfortunately (until rescued), it's highly valuable, lots of the
earliest heart valve procedures.  I consider rescuing it from MUMPS a
high priority, but in a headless bureaucracy you just "go with the
flow" a lot.  Inertia is a compelling force, as Newton well taught us.

Anyway, from my point of view, the health care sector would benefit if
it stopped investing in M, no matter how "free".

Along similar lines, I get frustrated with how SQL isn't really that
hard, in a simple workaday sense, where you just want some simple
joins, maybe based on views.  Yet Microsoft Access layers it with eye
candy while making the SQL itself rather thorny, hard to eyeball.

That's sort of the same thing I worry about with trying to give kids
what appear to be training wheels on training wheels on training
wheels -- these Dr. Seuss contraptions all designed to make up for the
fact that maybe they're too young to be worrying about programming?

When you're still in a little body, the priority is maybe to get
outside doing some real activities, not virtual ones.  A lot of that
empathetic conceptualization you'll want to draw on later, isn't
developed just sitting in front of a computer all day.

Let's just say I'm leery of "contraptions" which insulate the "end
user" from writing any code, and yet under the surface write reams and
reams of the stuff, which at some point everyone ceases to fully
understand...  that's the opposite of "open source" in a way, as
you're really just hiding the internals, keeping "end users" from
really seeing behind the scenes...

Bottom line, I guess I worry about using electronics to pander to the
imagination in ways that undervalue developing physical coordination
skills.  I see how television has done this.  The younger they are,
the more I want to add to the motor component (gross and fine motor
skills).

Again, this isn't directed against any of your projects.  I'm just
investigating my own biases for the record, keying off the fact that
MUMPS is oppressive, and that too many of my coworkers have atrophied
and/or undeveloped SQL and/or database skills because the so-called
"computer professionals" have taken a "spoil the end user" approach,
which I regard as antithetical to FOSS.

Also, on a more positive note, I think cartoon-like approaches
designed to be instructive around particular concepts, are quite
suitable for *adults* as well as kids.  In other words, once you *can*
do lexical programming and *do* have lots of physical coordination,
*then* it's a good time to get a next level of training, with surreal
cartoons (like manga) your imaginary friend (good way to learn some
computer science).

It's a lot about *sequence* (the way topics get ordered).  Some of the
stuff we aim at children we might do better adapting for adults.  Lets
have more Wii in senior centers, along with more FOSS (as we learned
at the last OSCON, using FOSS to bridge grandchildren and grandparents
is a good way to go).**

Kirby

** http://worldgame.blogspot.com/2008/07/women-and-foss.html