[kragen]

Writing a small program takes much less effort per line than writing a large program, especially if it doesn't have to be maintainable and extensible, especially by other people. http://canonical.org/~kragen/sw/dev3/circlegrid.html only took me three hours of JS hacking, and it's like 200 lines of code. The simplified version of the basic COCOMO model in David A. Wheeler's "SLOCCount" is Person-Months = 2.4 * (KSLOC1.05), which suggests a budget of 0.44 person-months for this code, about two weeks, which is clearly too high; we've all written and debugged a few hundred lines of code in a day on some occasion after getting out of the larval stage. This probably would have been faster if I hadn't been so out of practice with DHTML.

Another thing, though, is that some things are easier than other things. Usually in a programming job you have to do the easy things and also the hard things. This brings down the average. If you're writing a bunch of blog posts for fun, though, you can just publish the ones where good visualizations came out pretty quickly and discard the others that are much more effort for less return.

I feel like visualizations using d3.js are still pretty "hand-written".

[chubot]

That's true, and like everything I'm sure writing JS visualizations gets faster with practice, and you become more familiar with the tools.

Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness. I can't in any universe imagine it taking less than a week of full-time work. If you told me it took a month of full-time work I wouldn't be surprised at all.

----

I liked this concept of "interpretive labor" and that's what I'm really getting at:

https://distill.pub/2017/research-debt/

There’s a tradeoff between the energy put into explaining an idea, and the energy needed to understand it. On one extreme, the explainer can painstakingly craft a beautiful explanation, leading their audience to understanding without even realizing it could have been difficult. On the other extreme, the explainer can do the absolute minimum and abandon their audience to struggle.

I've been writing for public consumption for about 3 years and really feel that tradeoff. When I put effort into some writing or explanation, the result is better. People tell me it clicked, etc.

And I would say you can go a lot further than you think in bridging the gap. This article is evidence of that! Lots of people here are saying they wished they had this in high school, etc.

3Blue1Brown's videos are another example of that. I was fairly good at math in high school but if those videos existed then, I would have probably gotten a lot further.

----

This ties in nicely to your Dercuano notes which I have had open in my browser for awhile! There are many interesting topics there. But I also feel like you went to the other extreme and there's a lot of interpretive labor involved in reading them :)

Why did you decide to polish and publish the "memory models" post? I'd like to see more posts like that. (I could send you the notes that jumped out at me if interested.) Whenever I've taken the time to polish some writing, I've never regretted it. For some reason it feels annoying to start (probably because I have to clear my brain of other things), but when I'm doing it it's fun, and when I'm done, it's worthwhile.

[kragen]

> Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness

I think the author probably had to try a lot of things before hitting on such a well-balanced set of visualizations: not too much detail, not too little, not too many degrees of freedom, not too few, usable on hand computers, usable on laptops. But I think that if you gave someone the web page to look at and asked them to make similar visualizations, it would probably take them a day or two.

> I would say you can go a lot further than you think in bridging the gap.

You might be right, but I'm kind of cynical about it. I think it's easy for people to fool themselves into thinking they understand things after seeing a good explanation. Nova on PBS resulted not in rapidly advancing physics from the generation of kids who grew up watching it, but instead Deepak Chopra and The Secret — the fruit of the illusion of fluency without the corresponding skill.

Worse, the educational system is in many ways optimized to promote the illusion of fluency. You have textbooks of the variety Feynman complained about, with the wakalixes. You have semester-long self-contained courses, discouraging spaced learning. You have pre-announced big-bang exam dates for those courses, so students game the system by cramming to get better grades. In many cases you have multiple-choice tests to make grading easier, so guessing the teacher's password is the highest-return gaming strategy, even if often insufficient by itself. The whole educational experience is compressed into a degree program of four years or thereabouts, further discouraging spaced learning. Students rarely attend any classes they aren't getting credit for, even though this is technically permitted at most universities I've visited. It's a commonplace observation that students forget almost everything they "learn" within a few years. So the idea students get of learning is very different from what learning is; schooling systematically distorts their ability to evaluate whether they are learning or not. (Paul Graham has explored this theme from a different angle in http://www.paulgraham.com/lesson.html as well.)

How would we distinguish a universe in which this beautiful post on gears successfully transmitted learning to its readers from a universe in which it only transmitted the illusion of learning to them? In both universes the post is popular. In both universes people say things like "I wish I had this in high school!" But in one universe people are able to do things they couldn't do before; perhaps design gear trains for 3-D printing that show up in Hackaday projects, or perhaps laser-cut unusual gear-tooth profiles with different pressure angles or different depthing/ripple tradeoffs or something. But that could take a while, and it might be really hard to trace back. Is there a lower-latency indicator we could observe, even if it's something hackable like school exams?

I don't want to sound like I'm above all this. I feel like I have new gear knowledge from reading this post, despite having read hundreds of pages about gears and watched hours of gears videos previously; it happens to be something I can state, namely that the pressure angle always needs to point at the point of tangency of the pitch circles. But I'm not yet sure if that's really true or what happens if it's false (you can definitely design gears for which it is false). I'd need to struggle with the problem for a while in order to really understand it.

(A different learning effect would be that people learn that posts like this are very popular and make more of them, having been inspired by this one. I'm pretty sure that will happen whether or not people learned things about gears from this post.)

> This ties in nicely to your Dercuano notes which I have had open in my browser for awhile! There are many interesting topics there. But I also feel like you went to the other extreme and there's a lot of interpretive labor involved in reading them :)

Thanks, that's flattering! I'm glad you're enjoying it. Are you using the HTML version or reading the raw Markdown?

> Why did you decide to polish and publish the "memory models" post?

I don't know. I think it was just random chance. I enjoy doing that kind of thing but I don't do it very often. Even memory-models is pretty unfinished and has some parts that are pretty raggedy.

> I could send you the notes that jumped out at me if interested.

Sure, that would be wonderful! If you wanted to commit to commenting on further drafts within some timeframe, that would probably help motivate me to work further on them.

----

I want to be careful to disclaim a particular interpretation here. In "Real Programmers Don't Program in Pascal" it says, "If it was hard to write, it should be hard to read." I don't believe that. I don't believe that if something was hard to discover, it should be hard to learn. I think we should make learning as easy as possible, and I agree with the post you linked that this benefits from improved explanations, and that improving those explanations takes a great deal of work.

But I have been burned many times even by my own illusion of understanding, let alone those of Freud and Chopra, to the point that I am wary of it. It is well that we remember, as Euclides said, that there is no royal road to geometry; a good tutor can save a student from remaining in error and from failing to notice the importance of something they could learn, but ultimately the student is the one that must do the hard work of constructing the knowledge within their own mind.

[chubot]

I'm with you that there can be an illusion of fluency, but I don't think that casts any doubt on the value of the article.

Most people will read it and say "fun" (including me, since I don't work with gears) and maybe 5-10% will go on to do something else with it, but that's working as intended.

I agree you can't really say you know something without testing the knowledge. You need to do more work to test whether you know it or not, but having the concepts and words at hand is a prerequisite for that. I'm certain if I were to actually work with gears I would come back to this article. (I would probably also learn where it falls short in practice, but I would learn that about any resource AFAICT.)

-----

Testing your knowledge is one reason my brain flipped from math to programming over 20 years. Math is hard to test but programming is easy to test.

However, one thing I found surprising is that publishing tests your knowledge, but writing does not. I would categorize Dercuano as writing but not publishing at the moment.

It tests it in exactly this way:

https://news.ycombinator.com/item?id=22033792

Blogging is a public act. Anyone can read this. When I write a blog post, I imagine my supervisor, a respected colleague, or a future employer reading my explanation. These imagined readers force me to ask myself honestly if I understand what I am writing.

I found the same thing while writing my posts on https://www.oilshell.org. If someone digs this up in 5 years, is it going to look dumb? And of course simply not knowing something is not dumb, but pretending you know something you don't is dumb (likewise with promising something you can't deliver, which I've been careful not to do).

I can see there are a lot of great ideas in your notes, but I have 100% certainty that polishing those ideas will lead to a better understanding, more ideas, and forcing a focus. The writing alone alone doesn't cut it. (I know because I also have 3382 personal wiki pages with notes and URLs accumulated over 15+ years with overlapping research!)

I would definitely comment on drafts. I was paid to review the second edition of Effective Python last year, and am also reviewing a book for a friend currently, so I have some experience with that. I'm most interested in the posts on parsing, automata, languages, compilers, and (parallel) algorithms -- I have less experience with graphics. I didn't know you were working on HAMMER -- that line of research is also in my wiki pages and I have several thoughts about it. I'll send you a mail with the ones that jumped out at me.

[kragen]

I've responded to your email! Let me know if it got spam-filtered.