Popular conceit about learning programming languages

[Bengt Richter]

On Sat, 23 Nov 2002 19:22:10 -0800, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

>Bengt Richter fed this fish to the penguins on Saturday 23 November 
>2002 10:08 am:
>
>> 
>> Fortran has abstractions too, but, e.g., no idea of dictionary per se
>> binding a particular set of names to a particular set of objects.
>
>        No, but then again, "dictionary" is just a name for an implementation. 
Sure, that's why I immediately focused on the abstract aspect of name->object,
and mentioned that you could get the same abstraction from elsewhere.

>For example, a Python dictionary and a REXX "stem variable" are both 
>forms of an abstract construct I know under the term "associative 
>array" (and REXX has a minor advantage too, as you can initialize stems 
>in a way in which a default value applies to all "undefined" keys). 
>REXX stem variables are variables in which the name contains a "."
>Python d["key"] is equal to REXX d."key" (yes, you can quote the part 
>of the variable that follows the "."). FORTRAN does not have 
>associative arrays, but that doesn't stop me from thinking in that 
>concept, leaving the implementation to later... True, for FORTRAN that
OTOH, if you were a programming newbie and had just learned Fortran, Fortran
would not help in making the associative array concept occur to you, whereas
a language with dictionaries or map objects etc would.
>implementation will require coding a bit of a library of routines, 
>but...
I've coded recursive algorithms using 1970's fortran, where all storage was
statically allocated as far as the language and its implementation
at the time was concerned. Fortran didn't give me the recursive concept to work
with (nor to learn, if I had been ignorant of the concept). It didn't stop me,
but no reasonably workable programming language can *stop* you, in theory at least.
Drudgery is a real and practical obstacle though ;-)
>
>        As for where the concept of associative arrays came from... I learned 
>of them NOT from Python or REXX, or from any other language. I learned 
>of them from courses on database internals, language design, etc.
>
I think you are reinforcing my point that the abstractions are the important things.
Python is certainly not an exclusive source of useful abstractions to think with,
but it makes them unusually accessible and fun to use concretely, and that makes it more
likely that a programming newbie will learn them early on.

>> Learning python gives you the abstract notion of name->thing
>> relationships to think with. You can get this notion from in Lisp as
>> well, but in Fortran name->thing relationships are narrowly contrained
>> (for useful purposes) and don't give you the general abstract notion.
>> OTOH, arrays also have abstract counterparts, and Fortran and
>> associated libraries gives you some useful things there.
>>
>        PostScript (yes, that /is/ a programming language) introduces one to 
>similar concerns. "Making" a substring doesn't copy part of the 
I in no way meant to imply that Python was an exclusive source of useful abstract
concepts ;-)

>original string, it just associates the name with part of the original.
>Changing the contents of the substring changes it AND the original 
>string. I learned that one years ago, on my Amiga. I've never had a 
>PostScript printer -- but my favorite Amiga wordprocessors only 
>produced NLQ output by using PostScript (the alternative was "screen 
>dump -- magnifying a 12 pixel character to fill a 24dot printer cell... 
>very ugly rectangular blocks). So I used so-called PostScript 
>compatible interpreter programs to render the pages. Turns out both 
>programs I used (one was discontinued and I had to buy a replacement) 
>did NOT implement the proper substringing behavior. I had to modify the 
>wordprocessor PostScript preamble files to work around that improper 
>behavior by doing string copies rather than subscript assignments.
>
you are presumably referring to getinterval, which operates on arrays or strings?
That's defined to share with the original, AFAIK. Are you saying the program you
fixed made the wrong assumption, or are you saying PostScript should make copies?
That's a change, if that's so now, I think. Is there another operator name that
does that (I wouldn't think they'd want to break backward compatibility with old
level 1 printers)?

>> So I would say "thinking in" a language is thinking in the abstract,
>> but restricting oneself to the abstractions that map easily to
>> representatons in the syntax of the language. The more powerful the
>> language, the less the restriction.
>>
>        Whereas I tend to do the thinking without taking any language into 
>account, using concepts picked up from anywhere if they assist in the 
>analysis of the problem space.
>
That's the pleasant part of having broad experience. But if you totally ignore the
constraints of the language you are about to be forced by circumstance to use,
you may get into expensive work against the grain (not to mention your gag reflex ;-).

If you then reconsider, and think using the subset of abstractions easily implementable
or already available in the language to be used, then I would call this pragmatically
restricted thinking "thinking in" the particular language. Of course languages overlap,
so some common denominator stuff may not suggest that thinking with it is "in" any
particular language.

Also, if you restrict yourself down to the bare minimum common to most languages, you
are probably effectively thinking "in" a poorer language than would actually be available
to you if you read more of the docs for the one you're using.

Regards,
Bengt Richter