On 10/10/2022 16.19, avi.e.gr...@gmail.com wrote:
I won't reply to everything Dave says and especially not the parts I fully
agree with.
I think in many situations in life there is no ONE way to do things so most
advice is heuristic at best and many exceptions may exist depending on your
chosen approach. As such, I do not really think in PYTHON when writing code but
an amalgam of many languages with all kinds of ways of doing things and then
zoom in on how to do it in the current language be it Python or R or JavaScript
and so on. Yes, I am in some sense focused but also open, just as in Human
languages I may mostly be thinking in English but also sometimes see words and
phrases pop into my mind from other languages that mean about the same thing
and then filter it out to focus on whichever language I am supposed to be using
at the time.
Given that we can both remember programming last-century, this
surprised. (or may have misunderstood!)
If we think, in German, of some parting words for an older friend
departing on a long trip, and translate word-for-word into English we
might come out with: "May God pickle you".
There is a second step, which is to examine the 'solution' in terms of
its expression (how the communication will be received), and thus the
more-correct English expression would be: "May God preserve you"!
The two p-words are sufficiently-similar in meaning to appear
synonymous, when examined in-isolation. However, that first expression
would at least bemuse an (only) English-speaker, and quite possibly confuse!
One of the problems which 'appeared' when programmers were first given
direct-access to the computer, eg time-sharing mini-computers; and which
persists to this day, is "the rush to code". Indeed there are (still)
some 'managers' who think that unless a programmer is writing code (s)he
isn't 'working' - but we're only interested in our own behavior.
Accordingly, "design" and "development".
Back-when, some lecturers insisted that we first create a flow-chart or
a pseudo-code solution for an assignment - BEFORE we coded in COBOL,
FORTRAN, or whatever. In many ways, because we were learning the
programming-language, most felt it very difficult to draw a flow-chart
that didn't merely look like FORTRAN.
(to make that worse (for ourselves) I suspect many of us performed the
latter first, and then ...) Many of us will have felt this some sort of
academic-exercise or even 'a nuisance', but there was 'method in their
madness'!
Relating back to the comment (above): when *designing* a
solution/flow-charting/pseudo-code, an "amalgam" of programming
constructs and human-language expressions will indeed add richness,
opportunity, and alternatives. All serving to amplify analytic and
design skill.
Conversely, when *coding*, the skill comes from employing the (specific,
programming) language to best advantage. At which time, one's
JS-knowledge is almost irrelevant, because the task is to convert a
design outline or planned-solution, into Python.
(idiomatic, pythonic, efficient, readable, ...)
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
