iTranslated by AI
On the Necessity of Transcribing Code in Programming Learning
This is the material I prepared for a discussion on YouTube Live about the necessity of "Shakyo" (transcribing code).
It was written in a hurry, so it's quite rough.
I might add more after the discussion is over.
Points of Contention
Is there any meaning to transcribing code (Shakyo) in programming? Or is there not?
If there is, what is that meaning?
If not, why is it meaningless?
Also, from a slightly different perspective—especially in the field of school education—is there any meaning in making subjects with low motivation perform Shakyo?
What will not be discussed
- The suitability of Shakyo for individual languages
- The pros and cons of specific tools
- Details about individual libraries
- N=1 cases that cannot be generalized
Definition of Programming Shakyo
(Points likely to be agreed upon)
I am not calling the act of typing from top to bottom while completely suspending thought and not understanding the meaning "Shakyo." Therefore, I want to distance this from the Buddhist sense of sutra copying or chanting, or the manuscript copying of the Bible in European monasteries (though they are not entirely unrelated).
Shakyo (sutra copying) refers to the act of transcribing Buddhist scriptures or the transcribed scriptures themselves.
Shakyo was performed to spread the Buddhist teachings in an era when printing technology was not yet developed. Additionally, it was necessary for multiple monks to transcribe sutras for training, lectures, and research. Later [when?], it began to be said that there is merit (kudoku) in the act of transcribing sutras.
Some might argue that even original Shakyo is meaningless if you stop thinking, but that is not the point of contention here. Just for the record.
mizchi's Personal Opinion on Shakyo
First, as a premise, since each individual's brain development is different, I can only say it depends on the person. There are two variables: individual aptitude and the stage of learning. I do not believe that Shakyo is always necessary for everyone.
As for learning policies in general, I believe there are people who are good at deriving theories from an accumulation of experience, those who improve the accuracy of a theory by repeatedly practicing based on a consistent theory, and those who fall somewhere in between.
The reason I recognize the effectiveness of Shakyo is that I believe the following experiences can be gained while transcribing code into a local editor:
- Syntax highlighting appears when you input meaningful keywords.
- It becomes clear at what point and how the editor's completion works.
- You see what triggers error messages and where they disappear once you've finished writing.
- Acquisition of the co-occurrence probability of keywords. What is the difference between
export async functionandfunction(){}? - As an application, once you understand a small executable block during transcription, try running it at that stage.
I think there is value in experiencing this series of steps. When doing this, you should type character by character, as if engraving it into your brain.
Note: This may assume an IDE environment. I am of the school of thought that one should use an IDE for statically typed languages specifically to receive small bits of feedback.
I have a hypothesis that this is particularly effective for people who derive knowledge from experience.
In a podcast I listen to occasionally called "misreading chat" (pardon me if I'm remembering this vaguely), the acquisition of concepts was compared to derivatives in deep learning as "recognizing the delta within one's own experience," which really clicked for me.
Cases where the effectiveness of Shakyo weakens
However, this is only really effective in the early stages of learning, and I don't think you need to do the same thing once you have systematically acquired programming semantics. Once a framework is established, the benefits gained from programming transcription begin to diminish.
Conversely, as long as you acquire the correct concepts, you don't need to memorize the syntax of a programming language. This is why learning a second or subsequent programming language becomes faster. Even with TypeScript, which I use every day, my knowledge of how to write a switch statement is actually a bit fuzzy, but it has never caused me any trouble.
With video media so prevalent today, there are materials that allow you to prioritize conceptual acquisition without going through transcription. For example, while I don't fully understand ChatGPT's Transformer, I feel like I understand it after watching the following video.
However, even if you feel like you understand something through apt metaphors or videos, it's common for your hands to stop moving when it comes to actual practice. This problem is solved (or should be) through transcription and practice.
In reality, practice and theory are two sides of the same coin, and I think the limit of generalization is that the effectiveness of Shakyo is determined by the stage of learning and individual aptitude.
Other Examples Prioritizing Theory
When I worked with a Haskell programmer, they told me that since side effects are described as monads in the type signatures in this language, there is, in extreme terms, no need to look at any documentation other than the types. And as far as I could see from their coding process, it was true that they rarely looked at anything except Hackage (documentation auto-generated from code).
I felt a similar tendency with Rust programmers. When I did pair programming with koba789, I felt like they were essentially only looking at the IDE's type information and docs.rs.
YouTubeのvideoIDが不正です
In my experience, the effectiveness of Shakyo is low for people who have acquired such a systematic theory, or those who can acquire it quickly. These kinds of people do not need to experience samples and derive concepts from them. If they learn the answers themselves and the accuracy is sufficient, it is completed within their internal mental emulator.
My Opinion: Shakyo is not a must, but it has good cost-performance in the early stages
Treating Shakyo as an absolute feels like saying "learn by watching" because one cannot explain the system they have acquired.
I was good at Japanese history, and my learning method was to watch historical novels (such as Saka no Ue no Kumo) or dramas (Taiga dramas) to form a visual image, then read the textbook and reorganize it into my own notes (which is a form of Shakyo). After that, I would do Q&A exercises during my commute to manage the forgetting curve.
My Recommended Learning Method: Fail fast with REPL
I am in the camp that believes you should use an interactive environment like a REPL since it's available.
For example, you can get results immediately just by pressing F12 in Chrome to open DevTools and writing JavaScript in the Console tab.
> 1
1
> 1+2
3
> let x = 3;
undefined
> x += 1
4
> function add1(x) { return x + 1 }
undefined
> add1(2)
3
However, it is difficult to learn structured programming in a REPL environment. You can basically only learn things within the scope of what can be written as one-liners.
While Shakyo has specified execution units, a REPL allows you to get fast feedback on the smallest building blocks of programming, so I believe it offers the best cost-performance. In my case, it's no exaggeration to say that I learned programming through the Python REPL.
However, using a REPL requires constant inference of "What is the smallest unit in this given code that can be evaluated?" You need to be aware that this is being required of you.
I've heard that this is a common problem for people who only program in a REPL or Jupyter—someone once consulted me because they were so used to scribbling in Jupyter that they couldn't create functions in reusable units. I thought that certainly seemed plausible.
Other, more meta perspectives
- The futility of Shakyo from a compiler's perspective
- Writing code top-down, regardless of the evaluation strategy of execution semantics
- Author's perspective
- Being forced to write calls to functions that have not been declared yet, due to the need to compress line counts or for the sake of page space and abstraction
Discussion