Imperative programming and math pedagogy: TLDR; converting an algorithm or concept from a research paper into imperative code is often seen as tedious, but I think the process helps with learning and clarifying understanding. This is an underrated advantage of imperative code. Thoughts? Do you agree or disagree? How can this idea of "reification" of algorithms be extended to other paradigms? The long version: I am a big fan of Coding Adventures by Sebastian Lague. He just release a new video: He skims over the details (the videos are more edutainment than true in depth education), but a strategy he seems to follow is to look at the top research papers on a subject, take the key equations, and implement those equations as shaders in Unity with HLSL i.e. a C derivative language. This is a technique I'm very familiar with. I assume many people here are familiar with it as well. It can be tedious work to do this kind of translation, but it's hugely useful. I find that after doing a translation like that, I often have a much stronger understanding of the concept. The way I truly understood integrals and summations was through implementing them as for loops. I didn't understand monads and combinators until I implemented a parser combinator in an imperative language. In PHP no less. I was young and naive 😛. Many people in this community are fans of functional programming; there have been quite a few threads about ways to encode algorithms more effectively or "true to their mathematical form:" everything from APL to natural language to category theory. This is a counterpoint against always looking for the "most efficient way" to encode an algorithm. There is something about taking something "functional" and reifying it into a series of imperative steps that helps understanding a concept, at least for my personal learning style. I have very little experience with visual programming, but things like Factorio (mentioned recently), make me think that reification as learning tool can be just as effective in the visual paradigm. How can this idea of "reification" of algorithms be extended to other paradigms, or taken into account more generally?

I'll rewrite your statement slightly: "Implementing an algorithm or concept from a research paper as code that you have written from scratch is a process that helps with learning and clarifying understanding." No need to restrict this to imperative code. One trick I use to understand a difficult research paper is to write out the concepts in my own language (in English, I mean).

Yeah, I agree with Doug. While my personal experience agrees with Ray's, I have to conclude after looking around that the phrase "personal learning style" is key. There's some overlap between this thread and my pet pedagogical approach of learning things bottom up. I found it easier to learn Haskell by ignoring layout rules and infix operators, and explicitly specifying the bounds of each function call.

These are all great points. You are right to emphasize "personal learning style". (Maybe I should have emphasized that more.) The more I contemplate, the more I think that the important part is reification; making a concrete "thing".

FWIW, I watched this coding adventure yesterday; I'm a big fan of his and always wonder how he puts together such great videos - he seems to bend Unity to his will for the teaching parts as well as the rendering parts. I have coincidentally implemented the same approach in the paper he used, as part of a game prototype I was playing with (some eye candy enclosed - must revisit this project at some point!) My approach is probably slightly different though. I'm more of an 'implementer' than a scientist/academic, and I often struggle with hard math. My approach is typically to iterate towards a goal in very small steps without getting bogged down in the detail; and it can take several days to get through the technical challenge. I'm in awe of anyone who can read a paper full of Integrals and translate it to code. That would be highly efficient! I rely on following my nose and looking at sample code far more than the math. Part of the reason I'm always messing with visualization tools and visual programming is that they are the only chance I have to understand. "The way I truly understood integrals and summations was through implementing them as for loops." This + 1000, basically 😉 And Monads.... I've read a few articles, but until I actually get to use one in a program I won't understand them. Perhaps Sebastien is just really smart (I'm sure he is), but what intrigues me is, has he got to that place by building a set of tools and technologies around himself, such that he can break any problem up into pieces he understands? i.e. The fact that he can plot and interact with graphs while building his code gives him a deeper/quicker understanding of each step? Just more validation of Bret Victor's approach, I guess....

Quoting Donald Knuth (source: http://www.jstor.org/stable/2318994): "It has often been said that a person does not really understand something until he teaches it to someone else. Actually a person does not really understand something until he can teach it to a computer, i.e. express it as an algorithm. The attempt to formalize things as algorithms leads to a much deeper understanding than if we simply try to comprehend things in the traditional way."

Re: personal style, I find mathematical concepts to be much more naturally expressed using functional programming rather than imperative, but no matter one's preferred style it seems clear to me that programming is a better vehicle for teaching mathematics than the standard mathematical pedagogy. Likewise, I'm in strong agreement with Sussman that traditional mathematical notation is strictly inferior to writing everything down in an unambiguous machine executable notation.

I used to agree with Sussman, but I have changed my mind a bit: unambiguous, yes, but not necessarily executable. Much of what you write down in mathematics and mathematically formulated science is specifications. For example differential equations such as Newton's. You really want to be able to write such specifications without necessarily doing something specific with them.

In the 1950's, Kenneth Iverson was a math professor at Harvard. He designed APL as an unambigous, expressive mathematical notation, for teaching math to undergrads, and for his personal use solving research problems and writing books and research papers. Iverson joined IBM as a mathematician, where he used his notation to formalize and specify the instruction sets of the 7090 and 360 computers. Only after that, the project at IBM to implement APL as a programming language. APL doesn't usually get much credit for its influence on modern programming systems (although Mathematica, NumPy and TensorFlow are APL dialects), and it isn't usually credited as an early functional language, even though it was the first such language (to my knowledge) to have map/reduce primitives (although under different names). APL now seems to be remembered for its syntax. Finally, my point. Re: Sussman, APL is a much better mathematical notation than Scheme.

Historical note: NumPy started out with a focus on implementing much of APL as a Python library. The function names in Numerical Python (as NumPy was originally called) are the names of APL operators. Later on, there was a movement to make NumPy more Matlab-like to win over Matlab users, so the APL heritage is no longer as clear as it used to be. As for APL vs. Scheme: that really depends on what aspect of mathematical notation you focus. Sussman comes from a symbolic computation background, with an application focus on calculus (check his "Structure and Interpretation of Classical Mechanics" as the prime example). APL has a focus on numerics and algebra. The only decent attempt I know to unify both perspectives is Mathematica.

I have fond feelings for APL. It was the language in which I was taught a range of numerical methods by one of my favorite professors (here's his one-line APL solution to the N-Queens problem), and I agree completely that it is under-appreciated for its place in CS history. However, I find the syntax leaves a good deal to be desired for work outside of its original niche, whereas the vector nature it embodies can quite naturally be expressed in any other functional programming language. It is for this reason that I prefer "APL-as-library", "PROLOG-as-library", &c. Regarding the history of Mathematica, it was inspired almost entirely by Wolfram's extensive use of Macsyma and written in C rather than Lisp only because Rob Pike convinced Wolfram that C was "the language of the future" while they were both at Caltech. Wolfram was aware of APL, but to call Mathematica an APL dialect is in no sense correct. Re: APL v Scheme as notation, I will say first that we disagree and second that even though we've only (virtually) known each other for a few weeks, your habit of expressing your subjective aesthetic opinions about Lisp family languages as if they were objective truths is already quite tiresome.

papers alone are not great, is not a matter of functional vs imperative, it is a matter of completeness. 99% of the papers are missing implementation details that could be incredible hard to provide by the uninitiated. Papers with artifacts are great. Start from a running template, play with the parameters, see what happens.. if you really want to start from scratch, you can, but you can always go back to an actual working artifact for reference.

Good paper covering a lot of recent CS edu research in this area: https://scholarship.tricolib.brynmawr.edu/bitstream/handle/10066/22621/2020LowensteinS.pdf

@Emmanuel Oga My thoughts were more in regards to pedagogy than reproducibility, but there is probably overlap here (it's difficult to reproduce what you don't understand). My thesis is that you gain a deeper understanding by building your own model up from scratch. I learn far more by building from scratch than I do from just "playing with parameters." That being said, reproducibility is an important goal in itself. I applaud any efforts to improve that area!

At least for my personal style, reproducing is often the first step to understanding or learning. Hot take: reproducibility matters more for teaching than research.

Reproducibility matters for learning, which is the common aspect of teaching and research. Learning is attaching new knowledge to an ever-growing edifice of solidly acquired knowledge. Reproducibility is about the solidity of that edifice. You have to be able to question your old knowledge and check if it is as solid as you thought it was, in the light of new knowledge. And that is true as much at the individual level (what we usually call "learning") as at the collective level (research, which is learning at the level of society).

This seems to describe making conceptions and discovering misconceptions. Pedagogically, reproducibility would concretely imply using approaches that minimize the appearance or lifespan of misconceptions and minimize time to build conceptions? Research-wise, that would mean cataloging conceptions and misconceptions and measuring their presence over time across large groups? Then, we could compare different pedagogies?

I agree that implementing something helps understanding/feeling it better. And in fact it is the idea from Seymour Papert with the idea of microworld. Creating microworlds helps understanding some concepts. In the case of LOGO programming the turtle helps children feel (if not understand) concepts like angles. And I am convinced that this implementing-microworld idea can extend to adults to help them understand better some science, even without great programming knowledge. And as fan of visual programming, I think tools like Scracth are perfect for this: you can implement dynamic/interactive visualisation or microworld to help you grasp some concept. One example. During a two days workshop where I was teaching Scratch to some teachers (middle school), one wanted to use Scratch to create a small interactive animation to explain some plate tectonics concept. She has never used programming before, but at the end of the workshop she was able to ask her students to implement this concept with Scratch.

I think my comment on "reproducibility" needs to be clarified a bit with some definitions. There is the denotative, dictionary definition of "reproducibility": The ability "reproduce" something (note, this is generic, it can be anything, not just a research paper); to build a copy or simulacrum that exhibits the same behavior or results as the original. From what I see in the thread, we all basically agree that this is a good and useful thing, particularly for learning and understanding. But there is a connotative definition of "reproducibility" often associated with scientific research. This definition has more specific context associated with it. In this sense, "reproducibility" is the ability to make a copy or simulacrum that exhibits the same behavior or results of a research paper specifically for the purpose of peer review and validation. This definition often implies that the reproduction should be created completely independently from original result using only the information found in the paper (and associated references and domain knowledge), but no contact with the original authors. This second definition is what I believe @Emmanuel Oga was referring to, based on the context of his post and associated links. My response to that post was an attempt to separate the two concepts. I think I did a bad job initially, and hopefully this is more clear.

Yeah. Even if 99% of papers have reproducibility problems, I suspect the graphics papers that the (excellent!) demo link up top uses don't have that problem. Perhaps we need a separate thread on the academic notion of reproducibility.

@Ray Imber The terminology around this topic is a mess. There's people who have written articles just on what should be called what, and of course they disagree. That's life. One initiative worth mentioning in this context is https://reproducible-builds.org/. It's about making (Linux) executables reproducible from source code, so that you can be sure you are actually running the program whose source code you are reading. It's an answer to Ken Thompsons Turing Award speech "Reflections on trusting trust" (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf).

fwiw I was thinking reproducible more as in "reproducible builds" than as "replicable experiment". The idea is that papers should come with their artifacts: a "one click" implementation that process some provided example inputs and produces some example outputs, as described in the paper. This is maybe independent of the conversation of whether the learner should build their own version from scratch or not (personally I do think "building from scratch" is the best way to learn). Even when building from scratch, comparing against a reference implementation is incredible useful as a learning tool.