Interesting Links for 18-09-2024

[andrewducker]

1. The centrality of stupidity in mathematics (and coding, and IMHO numerous other topics)

(tags:stupidity learning Education academia mathematics )

2. Abortion safe zones coming into force on 31 October in England and Wales. (24th September in Scotland)

(tags:UK abortion law )

Comments

[lilysea]

Abortion safe zones coming into force on 31 October in England and Wales. (24th September in Scotland)

about damn time!

[simont]

#1:

[...] the new idea feels obvious. And more, you are so changed by the new perspective that you can’t even understand your own prior lack of understanding.

My most vivid memory of that happening to me is the day I lost my fear of git. The inability to express what I'd previously been confused about was so striking, and so sudden, that I actually bothered to introspect to see if I could work out what had happened.

I'd read several articles on the web describing git's object data model: immutable commit objects linked in a dag, each linking to a tree object, each linking to blob objects for files or further trees for subdirectories, and branch heads as (mutable) references to a specific commit. Somehow, these articles didn't cause me to be less confused. And then one day I ran git fast-export to dump out the whole of a test git repository, and looked at the dump file to see if I could understand it. Then suddenly the blockage cleared from my mind and I felt I understood git. But all that was in the dump file were the same commits, blobs and trees that I'd already read about: with hindsight I could see that those articles had told me nothing but the truth. But somehow looking at it "for real" conferred an understanding that the articles hadn't.

It took me months of pondering to figure out exactly what had become clear to me that day, which somehow hadn't been clear before. But eventually I decided the thing I hadn't taken in from the articles (maybe they hadn't said it, or maybe I missed it, I never went back to check which) is: there's nothing else. If you have a collection of commits, blobs, and trees, and you know which commit each branch head points at, that's enough to construct an equivalent git repo of your own (which is exactly what git fast-import will do when it reloads the same dump file). No further types of metadata exist in the repository that I hadn't known about¹.

Once I was sure of that, I wasn't afraid of complicated operations like git merge or git rebase, because I could work out for myself what they basically had to be doing internally: given that data model, there's only one option. Whereas when I still had a 10% worry that there was some extra metadata lying around (e.g. machine-readably marking cherry-picks of the same commit as equivalent, or explicitly marking that a file was renamed in a commit), there were more possibilities in my head as to how the thing might work.

"If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." – Rob Pike

¹ (of course, there are edge-case weirdnesses like the git-replace and git-notes ref namespaces, and no end of extra nonsense that can exist locally to a particular git checkout, but for the core understanding, I was interested only in the common case, and only in the data shared between repositories by pushes and pulls. Everything else I was confident I could learn later as and when it impinged on me.)

[fub]

I had the same thing with the Apocalypse World Engine, a ruleset for roleplaying games. I just could not wrap my head around it. And then I had one sessions with a couple of friends, and it clicked. And, like you, I went back to the texts that I could not wrap my head around before, and indeed: it was all there from the start. But I needed that 'seed' of that first session to make it all fit together, like how a crystal grows around a speck of dust.

[andrewducker]

Agreed - I need something for it to all grow around.

[andrewducker]

Oh yes. I need to have enough practical experience for me to be able to understand the concepts, and then I can come from the conceptual side and really nail things down. But without both I find myself blocked.

With Git it was reading Git from the Bottom Up that really made things click to me. But I had to actually use it a few times and see what it did before that article made any sense.

And now git is really really simple to me. (The data structures - the commands are still a clusterfuck.)

[jducoeur]

My equivalent to this was basically The Curse of Lady Monadgreen (from Gilad Bracha):

Once you understand monads, you immediately become incapable of explaining them to anyone else.

Which is why, once I finally figured it out (after something like eight years of Scala programming), I immediately (in a small enough epsilon of "immediately", it appears) began to teach it, because it was clear from the outset that only right then, right when I had just learned it, would I be able to reconstruct how I learned it.

(Which was essentially in reverse. Most people start by trying to explain what a Monad is, and that's usually a lose -- you wind up bogged down in category theory and/or laws. I instead teach how you use it in Scala programming, with lots of examples, which tends to get the intuition across -- generally the most important part -- and then work outward from there to explain how it works.)

[andrewducker]

Yeah. I once managed to find an explanation of what things, when put together, cause something to be a Monad. But not to understand why this was an important thing.

[jducoeur]

Yeah, my "inside-out" explanation goes something like:

• This is a nested for comprehension over Lists. (I have several examples I choose from, each of which involves several nested functions that take something and return a list of results.) You see what this is doing, right?
• This is a nested for comprehension over Option. (Usually some sort of validation example, with several nested functions that return a value if it succeeds, and the next function has to validate that.)
• This is a nested for comprehension over Future. (Some sort of async example, where each function returns a value that you pass into the next DB or API call.)
• If you can use a data structure in this way, it's a Monad. (More or less -- people argue about Future, but it's good enough for most purposes.)
• And then I break the previous examples down, reducing the syntax sugar of the for comprehensions into the underlying map and flatMap functions, and show how it's all just function calls. If the data structure implements a well-behaved map and flatMap, it's a Monad.
• If I have time, I show some examples of higher-order functions that work on any Monad (which you can do in Scala, but not in every language), to motivate why this is useful for reducing boilerplate and code duplication. (Testing can be a great way to illustrate this -- showing how you can replace an async Monad with a synchronous one, to be able to test async code single-threaded.)

[andrewducker]

Were I to be working in Scala I can definitely see this approach working for me!

[sobriquet9]

1. The linked article contradicts the article it links to.

The linked linked article says "doing well in courses means getting the right answers on tests. If you know those answers, you do well and get to feel smart."

The linked article says "There’s something fundamental in the nature of mathematics that makes it easy once you get it, and impossible before." That means it's not enough to memorize the right answers.

The problem here is that we conflate rote memorization to pass the tests with actually learning the subject.

[channelpenguin]

Yes. Exactly. Almost everything needs some of both. Some insights might also only come when other information is instantly recallable AND well-practiced.