3
$\begingroup$

People have different modalities in their imaginings. Some imagine things visually, some spatially, some by touch, some by smell, and some other ways.

What if a student claims to not have the ability to imagine things visually or spacial?

The student is fresh, just starting on their journey into programming.

What abstractions can I use to help such a student to develop good cognitive abilities in formulating their intent before they write code?

As clarification: I consider this question pretty agnostic regarding any imperative programming language (although, student has to learn C++, PHP, Java)

$\endgroup$
3
  • $\begingroup$ Hi Grzegorz, what language are you using? $\endgroup$
    – srattigan
    Commented Sep 6, 2020 at 22:29
  • $\begingroup$ Good point, question is about imperative programming languages. Student has to learn C++, PHP, Java. $\endgroup$ Commented Sep 7, 2020 at 19:50
  • $\begingroup$ The lack of ability to visualize things internally is actually a condition that affects ~1% of the population - it's called Aphantasia, and it's real. I don't see this impacting programming, though. $\endgroup$ Commented Nov 19, 2020 at 20:23

4 Answers 4

3
$\begingroup$

I introduce concepts by their shapes when it makes sense. An array is a line, a loop is a coil (and coils have ends), an infinite loop is a circle.

There is no real evidence to support the notion of visual learners, kinesthetic learners, etc. It helps to conceive of these concepts as shapes, and so we can teach them along with these shapes. Whatever the student believes or doesn't believe about their own visual sense, they can navigate their room in the dark because of a visuo-spacial awareness, and they navigate this without being aware of what thought-process they are using. It is up to us to help them utilize the appropriate senses for the concept in question.

$\endgroup$
3
  • $\begingroup$ TL;DR- shapes does not work here + it's also about communication between us. ||| Verbose: Thank you. In general input is interesting. However, As I wrote in question, person does not have visual/photographic nor spacial imagination. Therefore I need different abstractions. $\endgroup$ Commented Sep 7, 2020 at 16:24
  • 1
    $\begingroup$ @GrzegorzWierzowiecki I guess what I'm suggesting is that that may be the student's perception, but that it is almost certainly false, and the evidence is that they can navigate through doors, open boxes, discern different units of currency, distinguish people's faces from large rivers, etc, etc, etc. I am also quite sure that they can draw and describe something like a line, something resembling a circle, a rectangle, an arrow, and something resembling the letter Y, which are all of the shapes that you need in order to visualize the inner workings of code. $\endgroup$
    – Ben I.
    Commented Sep 7, 2020 at 20:47
  • 1
    $\begingroup$ @GrzegorzWierzowiecki (cont) I suspect this is a combination of learned helplessness and misinformation about how the brain works and how we navigate our way through the world. (Now, if the student has true shape blindness, of the sort that Oliver Sacks would be interested in, then you have something much more interesting on your hands, and I would bet that they can't code at all, and would have great, great difficulty reading text.) $\endgroup$
    – Ben I.
    Commented Sep 7, 2020 at 20:49
4
$\begingroup$

This may sidestep the question a bit, but perhaps you can have the student make physical drafts of what they want their program to do at first, kind of like making multiple drafts of essays.

As an undergraduate, I sometimes joked that I used an awful lot of paper for a computer science student. I found that dumping everything from my head or even the problem statement onto pieces of paper (more portable) or a very large whiteboard helped me to organize my thoughts and eventually figure out what I wanted to do for my harder programming assignments as well as the problem sets in my algorithms class. I also did this when I was just starting out in CS and programming, just on a smaller scale and not for very long. This was especially helpful when I was learning about recursion.

I also found this helpful for helping students when I was a TA for the CS department's discrete mathematics course, which was taught in two different styles: paper and pencil, and with a theorem prover language (Lean) (a lot of students felt like it was programming). It especially helped for the latter style, as students sometimes knew what they wanted to do in a proof but couldn't figure out how to express the proof in Lean because they didn't understand how they were supposed to understand the syntax. Based on what some of those students said, I think drawing everything out for them helped them to eventually visualize on their own.

If the student is just starting out with programming, the drafts shouldn't be too complex yet, so hopefully they won't be too taxing and they can be a stepping stone to eventually being able to getting mental images of program structures.

$\endgroup$
3
$\begingroup$

For visualising a program in advance of coding, and as a tool to aid in clear development, perhaps the "classic" flowchart may be useful? You can also "see" blocks that may later become functions, and the concept of modularisation.

Simple Flowchart

A useful tool to "see" code during execution may be the visualizer as this will let you "see" it in action using a range of languages.

Multi-language visualizer

You can step through the code and the learner can clearly "see" the flow of execution, all of the variables, their values and type/class and so on.

I have also used this on occasion to debug pieces of code where there would be something unexpected happening- it is very useful.

Step through code and see it execute visually

Of course the languages supported are limited, but include some of the more popular choices.

$\endgroup$
2
  • $\begingroup$ Thank you! Yes, indeed it's helpful for such person. Still does not help in imagining program before writing it or talking about program together. $\endgroup$ Commented Sep 7, 2020 at 16:25
  • $\begingroup$ I've added the flowchart element. Regardless of their preferred thinking mode, programming is primarily about logical thought- structuring a problem into a set of steps to find a solution. Some creativity is an advantage as there are always many solutions that are possible, but these can vary in efficiency and effectiveness. I don't know if UML Use Case diagrams are part of your course but these are more likely appropriate for an OOP approach. I'm not sure if there are many other options available in terms of structuring and visualising :) $\endgroup$
    – srattigan
    Commented Sep 8, 2020 at 22:27
2
$\begingroup$

This brings to mind what Christopher Alexander (an architect, and the inventor of pattern languages).

Architecture is traditionally a visual discipline. However Alexander says that in the first stages of a design, when we are exploring user need. We should use linear language (spoken, written, even sign-language e.g. BSL ).

However we need to keep ideas simple.

Therefore

  • Consider what a function/procedure/variable does, before considering how it will do it (or whether it will be a function, procedure or variable).
  • Decide how you will test it before you write it.
  • Write only as much code that is needed to make the test pass.
  • Write only as much test that is needed to make the test fail.
  • Keep each function/procedure/variable simple: ensure it does one thing, and consequently short.
  • Name functions/procedures/variables well: give them names that make sense at the point of use.

I have the same problem.

I sometimes work with people that are brilliant. They create code that is so complex that even they don't always understand it. I can not do this. My code is simple. My code has very few bugs. My code has higher functionality. But I just can't write complex code.

I can't debug complex code. However I have found that I can guess where the code will break (without really understanding it), and am very good at finding some of the bugs (no one can find them all in overly complex code, not even brilliant people).

I think it is this inability that has led me to investigate and discovering methods to writing software, that have a high probability of producing bug free, easy to maintain code.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.