I don't know if this is going off on too much of a
tangent, so feel free to redirect this to a different
thread.
I think Mark has raised a very important issue about
teaching introductory programming to STEM researchers.
Specifically, for some (arguably many) STEM researchers
who are new to programming, the difference between
what a particular sequence of symbols means in
mathematics, vs what that same sequence of symbols
means in programming, can be highly counterintuitive.
Explanation:
STEM researchers often have strong and longstanding
experience with mathematics.
Which is great, but can make learning programming
counterintuitive for new programmers.
Something I've seen many times is a STEM researcher
who misinterprets the programming language as
simply a different set of symbols for expressing
their equations.
This leads to problems like the researcher assuming
that, if they express their equations properly, then
they'll get the right answer.
Which can be a disaster, for example, if they don't
properly initialize their variables (and if the
compiler/interpreter doesn't do so by default).
I teach a Programming for Non-Majors course most
semesters, and most of those students are STEM majors.
Early on, I tell them that a program is a description of:
(a) a collection of data,
and
(b) a sequence of actions on that data.
The goal of characterizing a program this way is to
get them thinking about programming as qualitatively
different from doing mathematics.
I do that because programming *looks* deceptively
like math, and especially looks like a set of equations
-- which is on purpose, from the perspective of
experienced programmers, but can be very confusing for
new programmers.
For example, consider assignment statements -- which,
in the programming language I teach (C), look almost
exactly like equations:
x = y + z;
(In the supercomputing world, this is even worse,
because many supercomputing applications are written
in Fortran, which typically doesn't have a statement
terminator like C's semicolon.)
When I teach assignments, I repeatedly reinforce that,
although this looks like an equation, it's actually
an action:
(1) evaluate the expression on the right hand side of
the [single] equals sign,
and then
(2) put the result into the variable on the left hand
side of the [single] equals sign.
A bit later on, we look at this:
x = x + z;
We talk about how this can't be an equation: for the
kinds of numbers they know about -- integers, reals,
maybe complex -- no value would satisfy x.
And I remind them, repeatedly, that it's an action,
not an equation.
Also, I explicitly say "single equals sign," even before
I introduce relational operators.
I do this because the C equality operator is the
double equals sign, and the difference between
"set equal to" vs "check whether they're already equal"
is confusing for some (many?) new programmers.
That's particularly because they have prior experience
with math, where that distinction isn't an issue,
and therefore is rarely if ever stated explicitly.
But most of them don't have prior experience with
programming, where that distinction is incredibly
important, and getting it wrong can be very difficult
for a new programmer to debug:
if (a = b) {
x = y + 1;
}
else {
x = y - 1;
}
---
Henry Neeman ([email protected])
Assistant VP, Information Technology - Research Strategy Advisor
Director, OU Supercomputing Center for Education & Research (OSCER)
Associate Professor, Gallogly College of Engineering
Adjunct Associate Professor, School of Computer Science
The University of Oklahoma
3200 Marshall Avenue Suite 130, Norman OK 73019
405-325-5386 (office), 405-325-5486 (fax), 405-245-3823 (cell),
[email protected] (to e-mail me a text message)
http://www.oscer.ou.edu/
----------
On Thu, 13 Dec 2018, Laufersweiler, Mark J. wrote:
>Kunal,
>
>I have done it informally with data and software
>carpentries, especially when learners are coming from
>all across campus and from different domains.
>
>Turns out that it helps with the mental models that
>the learners have may have around their understanding
>of a term. An example was when we got to functions and
>the learner was thinking of a formal math f of x,
>f(x) = and was having an issues when the code for a
>function was longer than one line.
>
>A colleague and I did jargon busting as a formal
>portion of a webinar on HPC for Librarians and it was
>very well received. As I work across campus and at
>times find myself working with different groups/domains,
>I find it a good place to start to have an ask and
>answer around terminology which makes discussion much
>easier when people are not spending time trying to
>figure out "what did they mean by that word?".
>
>Greg Wilson's recent post on 12% of a plain
>(https://goo.gl/EEA8ea) even has a section in this
>lesson development plan that includes a section on
>terms and builds glossary as one of the deliverables
>to learners. This may be something that we would want
>to start building into carpentry lessons. Even
>instructors are not immune to not understanding the
>jargon.
>
>-Mark
>
>Dr. Mark J. Laufersweiler
>Research Data Specialist
>University of Oklahoma Libraries
>ORCID: http://orcid.org/0000-0001-5544-0976
>E: [email protected] W: (405) 325-3710
>Cal: http://libcal.ou.edu/appointment/9321
>
>Those who give up essential liberties for temporary safety deserve
>neither liberty nor safety.
>- Benjamin Franklin
>
>----------
>
>On Dec 13, at 1:58 AM,
>Kunal Marwaha <[email protected]> wrote:
>
>I was reviewing the Library Carpentry lessons and came
>across this section on jargon busting:
>
>https://librarycarpentry.org/lc-data-intro/02-jargon-busting/index.html
>
>I'd love to try out this technique in other settings
>(including Software Carpentry workshop) but wanted
>some feedback from others.
>
>For those who have used the "Jargon Busting" technique
>(in any Carpentry setting), how did it go? What were
>common words that arose? Did any learners get off track
>or (alternately) get intimidated?
>
>I imagine this is a neat icebreaker to have early in
>a workshop (or, right after a break) to encourage
>"meeting your neighbors". (This is useful if learners
>develop trust in each other -- when stuck, they can
>first turn to each other, reducing load on helpers or
>instructors.)
>
>Similarly, this can help instructors sense "what does
>my classroom care about?" but with full classroom
>participation (are they R-focused? what's their
>experience level? things the pre-workshop survey would
>answer if everyone filled it out...)
>
>Thanks in advance,
>Kunal
>
>The Carpentries / discuss /
>see discussions + participants + delivery
>options Permalink
------------------------------------------
The Carpentries: discuss
Permalink:
https://carpentries.topicbox.com/groups/discuss/T081a5f608875cb79-M53dfb4db13ac55df9223febe
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
