[Tutor] Tungsten teaching method

[dn]

This is a quarky/quirky conversation.
(hah!)


On 15/07/2023 06.09, ThreeBlindQuarks via Tutor wrote:
> I have been wondering about some of the newer python learners in terms of how they approach learning. This is not really about just python but all kinds of languages.

Actually, the idea of "language" embodies an assumption. There are major 
differences between the abstractions of Romance languages, and the 
'click-based' Khoisan and similar - even Romance cf Chinese and Japanese.

Over here, Te Reo Maori was a spoken language (pre-white man and 
'civilisation') and 'writing' had quite a different meaning (and limited 
application*) when compared to English (of the period (!) ). Yet there 
are permanent 'records'.


> Do you start with the basics as in the kinds of constructs many earlier programming languages have. I mean define basic types like integer, floating point and character/text. Teach how to do simple assignment statements, then IF statements (or even weirder GOTO) and loop constructs like WHILE or FOR or whatever, then learn how to create functions, perhaps make simple objects and maybe eventually how to treat functions as first class objects.

A program[me] can be considered in two modes: control-flow and 
data-flow. Those of us who started back in the ?good, old, days were 
taught (lectured at) both FORTRAN-II/IV and COBOL-68. We quickly noticed 
similarities, eg both allowed one to add two values. Equally, it was 
starkly obvious that the languages had quite different approaches and 
philosophies - FORTRAN diving into its formulae/s, but COBOL requiring 
one to build a DATA DIVISION's worth of data-structures before even 
(linearly) reaching the PROCEDURE DIVISION.

Recently, I've been taking opportunities to ask various groups of 
pythonista about the data-structures they use, and gain some idea of the 
frequency with which they reach 'beyond the basics'. A surprising (to 
me!) number rarely go beyond the basic built-ins (strings, lists, dicts 
- notice the omission of sets and tuples) and (perhaps) the Collections 
Library. Thus, many prefer not to utilise custom-class(es), 
dataclass(es), even named-tuples - and many have never even read about 
enums.

Why? The most rational explanation is 'I can do it with what I've got'. 
In other words, the pain which may be incurred by having to 
manually-code functionality is seen as 'lesser', than the cognitive 
effort of indulging curiosity ("there must be a better way") and reading-up.

NB a recent addition/quirk to this was someone who enthusiastically 
revealed his version: having the curiosity, but then asking ChatGPT to 
suggest the 'better way'. Good one!
Question: has he added to his cognition, or is it more likely that 
ChatGPT gave some immediate cut-and-paste which formed a 
cognitive-bypass (in other words: the problem was 'solved', but no 
learning took place. Thus, the next time a similar problem arises ...)


> In other words, do you teach loosely simple parts of procedural programming then perhaps introduce object oriented and functional and perhaps other methodologies, including teaching about assorted libraries/packages/modules that extend the language?

There are two competing 'tensions' in traditional teaching: creating a 
basic foundational knowledge, and maintaining motivation. Remember the 
term (above) "lectured at" - were both present, or were 'we' required to 
maintain one - in the face of the other?

I'll leave you to decide if 'modern students' are any more/less capable...


> I think some here have learned vaguely along these lines and some quite differently. Some skip learning much and just look at snippets of code, perhaps in internet searches and try to figure things out. Some would prefer to search for pre-built software, as in publicly shared modules, that already do 90% of what they want.

Which by indulging the motivation side, can lead to 'holes' in the 
foundations - unless part of a structured curriculum.

That said, I prefer the approach of showing working examples BEFORE 
sourcing 'the facts' - somewhat the opposite of sitting through a 
lecture and then being given an assignment to 'prove' learning.
(I followed this technique at last Wednesday's PUG-meeting: "Properties 
and Descriptors", and am 'famous' for introductions (for often nervous 
adults/slightly-fearful folk) in first sessions of both HTML5 and SQL/RDBMS)

Again, there is a danger: SODD (StackOverflow-Driven Development) tempts 
cognitive-bypass, ie the learning you (convince yourself you) are doing 
without doing any actual learning.
(there's a yawning chasm between reading something and thinking one 
understands the material, and actual learning - the observation which 
underlies the advice we all give: WRITE CODE to learn!

Coming back to the "tension". There is a terrible temptation to hoodwink 
oneself into believing that 'progress has been made', when it hasn't. 
This is why external 'testing' is better than anything we come-up with 
by ourselves...


> So I decided to learn another language called WOLFRAM. I am not suggesting anyone here do so. I just am using it to illustrate some points. In a sense, this language is a successor to Mathematica and is a very high-level language that is hard to characterize. It comes with at least 6,000 functions built-in as in not needing to be imported. It is by Stephen Wolfram, hence the name that means Tungsten which is why the chemical symbol is W. The book is from 2015 and is called An Elementary Introduction to the Wolfram Language.

The implicit comparison is between Python and Wolfram, and is 
inappropriate (?unfair). Wolfram is unashamedly a Domain-Specific 
Language - would one use it for a typical COBOL-based record processing 
over-night batch job? (equally: would you use COBOL for 3D matrix 
processing?)

The virtue of DSLs is two-fold, and these illustrate your points 
beautifully:

1 domain: they (can) presume that the user is also a 'member' of the 
domain. In 'W' it is a mathematical background. This was also presumed 
(to a lesser extent) in FORTRAN - which name, for others' benefit, was a 
contraction of FORmula TRANslation; where the purpose and even the 
expression of functions was 'taken as read'. Books often stated "just as 
in mathematics" or "mathematical proofs"!

Key to any domain, is language. A word for a specialised (sub-set) 
language is "jargon". W assumes this for mathematics - indeed even as an 
applied mathematician (statistics) there are whole swathes of W 
functionality which zip over the top of my head. This also exists in 
Python, eg 'normal school kids' (in as much as I) talk of "whole 
numbers", "real numbers", and "letters"; whereas Python 'demands' we 
think of "integers", "floats", and "strings" (albeit wider than letters 
- and might be longer than one) - and we haven't even started to write 
code, yet!

2 implementation of concepts: the purpose of jargon is to enable rapid 
communication of (foundational and advanced) concepts rapidly - more 
rapidly than 'plain English'. (Sadly) it's effect (on someone from 
outside the domain, particularly a Python-Apprentice, is to present a 
'wall of incomprehensibility'. What, eh?

If a language can be presented to someone who has been 'admitted into 
the priesthood', ie knows the jargon; then it can communicate at such a 
higher-level, as does W!

* (as promised, I return to the concept of 'writing') The Maori people 
did record the legacies of their ancestors. Various forms of carving 
communicated history and performed particular functions when the carving 
was part of specific structures 
(https://www.newzealand.com/int/maori-carving/) - North Americans may 
think of similarities with "monumental poles" (when I was at school, the 
term was "totem poles" - not sure how PC these days). Such carving says 
less to me than W! However, the imagery 'sparks' recitations (and 
education/training) from adult 'story-tellers' who thereby pass-on an 
oral history to their younger generations. (for example) In this 
situation, my phrasing of "a priesthood" to a domain, might be a literal 
description!


The 'problem' comes when considering the 'specificity'. As before, W is 
little/no use outside its (narrow) domain.

(reminds me of my early days 'learning' German - being presented with a 
(virus laden) PC running MS-Windows. It rapidly improved my vocabulary 
because I quickly noticed that there was a "Hilfe" sub-menu where 
(normally) there would be a "Help" menu (on my (English-language) 
version). However, this knowledge was of little use when I went out to 
buy dinner from the supermarket...)


> What got me is that for an ELEMENTARY text, it skips all the elementary parts. It seems to practically jump into functional programming from the start and only about 2/3 of the way through the book is there a mention of a kind of IF statement. No real mention of loops as everything sort of had loops built-in one way or another. I still have not seen examples on how to setup a variable and assign to it or create a function other than an immediate inline (anonymous) function let alone how to create an object. I know it all has to be THERE but you can apparently do an amazing amount in this language by simply calling one of the many built-in functions appropriately, often in a nested fashion.

Once again, we are comparing an apparently "functional" DSL with what 
started as a general-purpose language - and has since been extended in a 
variety of directions to suit proponents in (at times) wildly different 
fields. Narrow and powerful, cf wide and flexible!
(see also (active and regular/periodic) discussions about what should be 
'in' and what excised or added, to the Python Standard Library (PSL))


Dispute: what got you there was a combination of the text, your 
pre-existing mathematics knowledge, and your experience of other 
programming languages. You were NOT a raw-beginner/blank-slate!
NB the latter achievement may sometimes also contribute negative factors!

It seems that you have quickly absorbed W and have enjoyed a rapid rate 
of 'success'. See elsewhere "intrinsic motivation" - and my mantra when 
it comes to training approaches: "nothing succeeds like success"!

Conversely, (and matching your thesis) the more (apparent) road-blocks 
placed in the path/way of a trainee, the less likely (s)he will persevere...

Also, those of us who have been 'around' for some time have had to adapt 
from (perhaps0 'spaghetti coding' practices, to "Modular Programming", 
thence "Structured Programming", thereafter we had to consider 
"Object-Oriented Programming". Lately, we've been exposed to "Functional 
Programming". With such history - or even a part thereof, it easy to 
assume that each is an improvement on the previous, perhaps some newer 
generation of programming techniques. Such is not true. Accordingly, 
Functional Programming is something that can be practised immediately 
and without any need to have gone-through, or even to know about all 
those others.

Accordingly, the "jump into" is not as big a deal as (perhaps) the words 
(above) may make it seem. In fact, we could take a Python newcomer and 
introduce lists of numbers, and jump straight into min(), max(), even 
map() - am not sure why a non-math programmer would find that 
advantageous, but it could be done...


> So, no, not suggesting it as a first language.

Dispute (although unlikely): why not use it as a 'first-language' (for 
mathematicians).

Although not my first, at uni we were introduced to a matrix processing 
language (think SPSS or a higher-level numpy/pandas) which served as a 
'first language' for many of my colleagues. All our stats-assignments 
had to be completed using it - even when I asked about using FORTRAN!


I suspect though, your point is: "not suggesting it as a first 
language", means: not using it as a spring-board into learning (the 
likes of) Python.

Although...


> The point here is that we often have little idea about the person asking a question and their background. There can be a temptation to simply give them an answer, sometimes an elegant answer using advanced features. Several of us recently tried coaching someone to fix their code and work through learning how to solve a problem. Someone else just supplied working code. Now if someone asked Wolfram how to say determine if a number is prime, rather than suggesting some technique using an algorithm, they would just suggest using PrimeQ[number] and voila! (In that language, you use square brackets in function calls.) If they were then asked how to check a whole list of numbers that way, do you think they would show any visible loops? Nope. I will spare the details but in effect they would apply a function to a list returning the list of results. If you want just the ones that are prime, you can use a sort of embedded if statement. One-liners seem to be the norm. And perhaps odder, the language is merely a part of a larger entity that includes a gigantic knowledge base on the internet that it automatically taps into so your program can literally ask in plain English for things like the populations of countries embedded in a request to make some complex plot displaying them.

Ah, now you've got me furiously riding my 'hobby horse' through the 
wilds of Cognitive Psychology. (Health warning = TLDR;)

Despite being involved in virtual training initiatives for many more 
years than COVID-19 has entered the common lexicon*, I've long regretted 
the lesser-quality of "communication" when compared with in-person 
interaction.

* as we, 'admitted to the priesthood', say, instead of "parlance"


The process of "learning" involves the formation of "mental models". One 
might liken these to a skeleton of bones. One 'hangs' new-knowledge from 
the bones, and extending/covering the skeleton of existing-knowledge. 
For example, lists and 'primitives' - the former being a "collection" or 
"sequence" of the latter (and the latter not being part of the Python 
jargon - yet you understand the term, immediately!).

If one's mental-model of how Python works is congruent to the (actual) 
way Python works, then we have (a degree of) success. If however it is 
not, then when the person comes to apply his/her knowledge, exceptions 
and errors ensue (plus, possibly, weeping, wailing, and gnashing of 
teeth - or in extreme cases, even sociopathy: "the computer made a 
mistake").
- cue perennial list-question revealing puzzlement over the binary 
representation of floating-point numbers...

Thus, when it comes to the "questions" discussed here, a first reaction 
should not be 'what is the answer?', but more: 'why is the person asking 
THIS question' and perhaps: 'in this way?'. In other words, establishing 
WHY the person's mental model is causing the query in the first place. 
For example, why is 4 / 3 "1.333 (etc)" and not "1" - after all, both 
"4" and "3" are integers? Both the person and Python are 'correct'. 
However, the person's logic, whilst eminently reasonable, does not match 
Python's - and Python 'wins'/the person is confused.

Thus, (as you...) the short answer is "float[ing-point] result". The 
longer answer is to discuss floats and integers, division and (integer) 
floor-division, number-types, etc, etc.


Dispute: yes, one can "ask in plain English for..." but although 
(apparently) plain language, once-again these words are in-fact 
specialised, skewed, and domain-specific, ie jargon. You are asking "how 
many" type questions about populations, eg "how many people in France 
speak German?". Thus, it is more data concerned with 'the numbers', 
rather than anything to do with France, or German-speakers.

For you (with your background, experience, and expertise) it might seem 
like "plain English". This assessment is skewed by your bias! (how's 
that for talking-math? BTW: no 'judgement'!) However, for many it is 
'hidden knowledge' which resides within a particular 'domain', ie they 
would not know where to start, even when asking that question in their 
minds (again: no 'judgement').


> Python though is actually many paradigms in one. You can actually do quite a bit similar to what I described if you focus on a combination of functional programming and some object-oriented programming and are a bit more verbose. But if you want to learn how computers work on a basic level and then get into higher abstractions, it is very good. Some of what I describe is in there if you know where to look. You can use plain loops, then as syntactic sugar you can use comprehensions or perhaps generators and of course you can use functional programming, including the kinds of tools you can get in the itertools module that automate lots of stuff for you.

Agreed.

Again, a 'tension'. When asked about these, usually in the context of 
'readability' (whatever that is!); my response involves assessing 'the 
team'. Thus, if 'we' are all perfectly capable of writing comprehensions 
and generators, then 'we' (all) consider them 'readable'. However, if 
'we' includes folk who are still Python-Apprentices, perhaps we should 
consider such abstractions 'less readable' and take-the-long-way-home?

OR... should we make a point of upgrading our colleagues' mental-models 
to include such powerful features, improve their (personal) skills, and 
move the team to some 'higher plane'?

(worthy consideration: what would such a move, properly implemented, do 
for group-cohesion, etc?)

Perhaps some of the observations (above) are applicable because it only 
needs to apply to an individual. The 'rules' change when consideration 
of the team is paramount.


Let's return to 'training', and the phenomenon often visualised as a 
"Learning Curve", and specifically the issues of "cognitive over-load" 
(trying to absorb too much information and/or too many concepts over a 
short space of time).

This is a BIG problem - and not just in Python or Computer Programming! 
Which is why Curriculum Design is not a trivial matter. I'm observing 
the side-project of one of our recent PUG-speakers called "The When of 
Python" (https://whenof.python.nz/blog/) wherein the idea is to try to 
identify which Python-constructs one needs to learn, at various stages 
in one's Python-career.

Similarly, this problem is revealed in the many approaches taken by the 
authors of 'intro to Python' books. Which one is correct?

I fear that the answer is both 'all' and 'none'! Certainly, an 
individual learner may (think to) prefer one over another, and an 
individual trainer similarly. However, (and one of your points) there is 
not one-size-fits-all (ie no 'silver bullet').
NB don't get me started on the pop-psy fallacies implicit in the idea of 
different types of 'learner'...

Coming back to 'mental models'. The key to scraping the 'rough corners' 
forming errors in an individual's model is saying/seeing/trying the same 
thing in a different manner.


> In this forum, I suspect that unless asked otherwise, we ought to remain in the lower levels. And I don’t mean the meaning of Elementary of someone like Stephen Wolfram! LOL!

Yes.

But...

We have different types of enquirer. All SHOULD be made to feel welcome, 
per the aphorism "I came for the language. I stayed for the community".

- the homeworker: yes, many simply want an answer and consider 'us' to 
be Stack-Overflow or ChatGPT, and the path to a (rapidly) completed 
assignment (see also "essay mills"). Yes, that attitude is wrong. No, I 
don't like it. We often respond with 'won't do your homework for you' 
and whilst this seems uncooperative (even rude or cruel?), the reason is 
'cognitive bypass', ie the 'homework' was given to promote learning and 
NOT to produce a (correct, numeric or whatever) answer.

- the baffled: the person doesn't understand why something happened, 
because his/her mental-model is incompatible with Python. This is 
difficult to detect because the person seldom realises where the 
divergence occurs/occurred. Such necessitates responding to a question 
with a question - often regarded as rude/impolite in many cultures. 
However, it is the 'correct' approach (but only seen to be so) in the 
long-run.

- the learner: such a person appreciates that (s)he doesn't know 'the 
topic' and is providing (some) background information in order to 
establish sufficient context. This person will be very happy to be given 
some web-references (or similar), and left to continue on his/her 
learning-journey. Sometimes it is just-as-easy to explain the concept. 
In this case, correcting 4 / 3 to 4 // 3 doesn't actually ANSWER the 
question - because the question is about the concept not the syntax.

- others?


It is a fact of life that contributors here don't have the same 
motivations (or "domain") as I/we/the rest of us. Accordingly, differ in 
the opinion of how a question should be answered - indeed whether an 
answer is 'satisfactory'. There have been criticisms (overt or implicit) 
in response to the 'won't do your homework' response - evidence that 
different motivations (of both question-er and answer-er) have been 
interpreted by 'reading between the lines'.

All of which is quite another essay, and is rooted in the issues and 
short-comings of written communication (email in this case) and the 
ability of each of us to 'communicate'...
(mea culpa!)

-- 
Regards,
=dn