> What a lot of math learners fail to understand is that grinding through concrete examples imbues you with intuition that you will not get if you jump directly to studying the most abstract ideas.
I feel that's more a lesson for a lot of math teachers to understand. I remember some frustrating linear algebra, calculus and computational complexity courses where the lector basically threw some formulas onto the blackboard, went line-by-line through a formal proof of their correctness and then called it a day. Giving actual examples of the application of the formula was an afterthought left to the student aides. Giving examples that could explain the derivation of the formula was not even considered as an idea.
It always reminded me of someone teaching an "introduction to vi" course but then just scrolling through vi's source code without any further explanation - and in the end expecting the students to be able to fluently use vi.
> > What a lot of math learners fail to understand is that grinding through concrete examples imbues you with intuition that you will not get if you jump directly to studying the most abstract ideas.
> I feel that's more a lesson for a lot of math teachers to understand.
That's certainly true, but the teachers who teach that way were probably once students who tried to learn that way (I was one on both counts, though I got better), and it'll be better for them as teachers if they learn the lesson as students.
Adding, not disagreeing, but at some point, those abstract concepts like dot products become concrete on their own when you get into things like SIMD programming.
Yeah, but to arrive at that point, you'd have to have understood dot products already.
It's one thing to take two float arrays, multiply them componentwise and sum the results. It's another thing to understand why this operation constitutes the dot product in R^n vector spaces.
You also have to understand that a^T b is a popular way of writing the dot product. <a,b> is for dumb high schoolers.
Then there is the fun part in German that the dot product and inner product are both called Skalarprodukt. There are many inner products of which the dot product is only one.
Does it matter whether the professor or the teaching assistant is the one giving the examples?
The professor is in an awkward position, because the professor at the front of of the large-group lecture hall doesn't have anything to do to add value. Watch videos, read book, work exercise, and then go to recitation or office hourse for interactive tutoring.
Yeah. It's kind of ironic given how unhappy the author sounds about people being unable to figure out what's going on after seeing the same thing over and over again.
That's the same principle which makes it wise to first do some copy pasting before you abstract stuff into a common library. Gathering some (more than two) concrete use cases before you factor out the common functionality makes much better library functions.
A common sign of prematurely deduplicated code is a common function with lots of boolean flags and other knobs to tweak its behaviour for every use case added after it was written.
You owe it to yourself to type out your copied code again. So easy to lose track of context when you’re moving fast. Variables have the wrong name, conditionals can’t be false, etc. Copy, yes, but don’t paste. Do it the hard way.
The ideal heuristic is to only deduplicate towards more orthogonality.
Suppose you started from first principles and navigated down the ontology tree taking one of the shortest paths (well, shortest-ish since it's a hard problem that'll burn up too much time otherwise.) Would you encounter your deduplicated function on the way? If not, it's making it worse.
I was on a team rewriting a UI from native to web, so we were moving fast on copying existing features instead of inventing new ones. About four times in 18 months we had triplets of features in the backlog and tried to generalize the implementation on the second occurrence, only to have to do expensive rework on the third. The code and the tests just wouldn’t bend the right way. We had mostly agreed to follow the Rule of 3 but someone kept thinking this time would be different and it never was. The last story was always the slowest and extra time spent on the middle one was wasted.
Sports are good at distinguishing drills from practice. Practice is meant to look almost like real play. Drills are something you do so practice goes better, and to narrow your window of harm in practice.
I put, for instance, TDD in the drills category. I don’t think you should live in TDD. nor do I think you should avoid TDD because someone said they thought it wasn’t a viable lifestyle choice. You should do it for a while every six months or a year to knock the cobwebs off and remind you what sort of tests you’re going to need and write code that complements good tests, rather than fighting them.
DRY is a bit more complex. I think DRY in unit and integration tests is a slow death. Tests should be DAMP because requirements change, and so do languages, frameworks and libraries. DAMP avoids the sunk cost fallacy which I’ve seen nerd snipe too many people. Test isn’t useful anymore? Just delete it. Or replace it. Boom, done.
> Sports are good at distinguishing drills from practice
The military also. Individuals learn 'part task' drills (e.g. firing a tank gun), then practice them in a team environment (e.g. the different crew roles working together in a single tank) and then finally (in something fairly unique to the military) exercising collectively: multiple teams working together to achieve a common task. E.g. several tanks coordinating an attack, then adding in infantry, etc.
'rule of 3s' is way too simplistic. It is on the beginner level. 3 is an arbitrary number anyway. It can be any other number depending on the situation. And creating an abstraction from only one use can be valid. In particular this happens if something gets a bit big while talking to too many other things. E.g., a function receives RPC while also doing something with a piece of hardware, and both of these things are a bit non-trivial. These two things should then not be mixed even when it is the only function doing these two things. I will say though, that creating an abstraction from one example one should expect that some future improvements to the abstraction will most likely be necessary.
a concrete problem ___domain has an ideal solution with ideal abstractions for its purposes
seek to understand your problem ___domain to a reasonable extent before writing hard-to-change code
Of course, we don't understand the problem ___domain perfectly from the start, and neither do we write perfect programs from the start. It's an iterative process of optimization, where you alternatively work on a specific understanding or work on the understanding. Everyone has to figure out that balance for themselves.
>'rule of 3s' is way too simplistic. It is on the beginner level. 3 is an arbitrary number anyway.
That's precisely why it's useful.
"On your discretion" would just lead to endless bikeshedding - as having a useful discretion requires that you are already advanced enough to not need such advice.
It's not that new devs really understand three to be some special number either: just a useful heuristic, which can be 2 or 4 or 5 if needed.
This is presumably about math problems, but I always approach programming problems this way.
One issue I have with math problems is that sometimes I wish I could immediately go down one level of abstraction and see something like a physics or programming problem that applies that specific or related problem I'm working on. I haven't found a resource like this yet.
Not a guide, per se, but it has many implementations of a wide variety of math and programming concepts, implemented in a large number of different programming languages.
This is cool. It's pretty close to what I meant, but each task is completely siloed without any meta information, so it's good if you wanted to look for something very specific but not good if you are thinking about or exploring a problem space.... For example, on the page for factorial it might be nice if they linked to other kinds of combinatorial problems.
Although I bet that ChatGPT might already know a lot of this kind of thing. I haven't had the chance to use LLMs in this specific context yet.
And why is it so hard to have math education based on good concrete contextualized examples, vs just rules and problem sets? Understanding the “why” behind the math is often lacking… and math doesn’t always need to be applied, that’s ok— but if it can be, it is so much easier to understand
This was something that really lacked in my statistics degree. We were always learning different distributions, proofs and estimation methods but very rarely applied them to actual problems. I feel like you can kinda get away with this type of thing in math more, but in statistics, it makes things super hard to learn.
I kinda wish you could just take a course on a specific distribution. Like, here's the Poisson class where you learn all of its interesting properties and apply it to e.g. queuing problems.
I took a lot of stats and probability courses in university, but never developed any intuition related to it. This would have been very helpful to me back then and now even.
I’m adopting an Example Driven Development approach in my latest project. The project is a library/framework with a public interface. EDD is great in this case. To explore and experiment new features, I turn the use cases into runnable examples and use those to drive the internal implementation. This combines feature implementation, documentation, examples, and testing in one shot.
Yes, exactly. See [0] for a concrete example of an abstraction that can't be grokked without grinding concrete examples, and how people who have already grokked it forget this fact.
A concept I learned about in Knowledge Based AI (gatech ONSCS) is called “version spaces” where instead of starting at specific examples and moving to be more general or the other way around you do both as a kind of knowledge bidirectional search. I feel humans work that way too. We need both specific examples and generic models to help us converge to a deeper understanding of topics.
But on the other hand, 2 or 3 elements of the sum are usually enough, i.e. you probably wouldn't improve understanding by writing out the first 10 elements or so.
FYI that article is an interview with Jo Boaler, the main architect of removing middle school Algebra in SF and California (attempted). Her views are pretty controversial among those promoting math excellence.
That's not to say there isn't anything worthwhile in the article, but figured people would want that context.
This applies to code as well. I worked on an internal PostgreSQL protocol driver for work and I've been focusing on understanding the binary message format inside and out, then the server state machine and query behaviour, and only then building a driver.
Don't underestimate the value of time spent grinding the low levels for code that is fundamentally important to what you are doing. You come away with a much stronger understanding than if you just hack a solution, cargo culting some existing code and just shipping it.
The author is generalizing their preference here to say it's "right". Some brains need this, others need the abstraction before the examples provide the most benefit.
As noted by others this preference influences how one learns code effectively too. It's a pretty basic trait.
The author's stated preference is most common but it is not the only one.
This question seems to bring a frame that implies there is an example that would apply to everyone. I'm claiming such an example doesn't exist but I will try (please note these are overly simplified).
Consider addition...
"We're going to learn addition today"
One approach: "it is combining two quantities into one. For example, 1 + 1 = 2, 2 + 2 = 4"
Another: "1 + 1 = 2, 2 + 2 = 4, you see, we are combining the quantities"
For some of us, getting the abstraction first gives us the mental framing that allows the examples to teach us the most and the alternative feels like noise.
For others, they're not sure what we're going on about until we have given them enough examples so that they can understand the abstraction. They want to generalize off of the examples they've seen.
Neither is inherently right but they have trade offs and we have preferences on this dimension that end up being strong and usually outside of our awareness. Frequently it can not matter if we jump back and forth between concreteness and abstraction.
I don't think this is the distinction being made here. Abstractions may be useful framing, but the author contrasts, after hearing what addition is, are you going to start studying multiplication, or are you going to look at examples of addition. We'd never think about teaching a child multiplication before they know their addition tables. However, in higher level math, and I saw this in uni, it's common to study structures without knowing many examples of them. You can do proofs about groups without connecting any of these proofs to actual examples that show their utility.
Ironically properties of groups were one of the first things to come to mind where working on an abstract level makes sense. You can convince yourself groups are an interesting interface/definition (both with a couple concrete examples plus a fuzzy argument that anything you want to call "symmetries" ought to be a group), but then if you want to understand something like commutators and abelianization, I don't really see any insight from working with concrete groups. The point is more abstract: [G,G] is normal (easy to show), so you can mod it out, and doing so gives you "G but everything commutes" (because you quotiented away all the commutators).
Similarly I'm not sure there's a lot of understanding to be gained from writing down cosets (as in the actual list of set members). It's still necessary to know how to calculate, but the understanding of what you're trying to do comes from the fundamental theorem on homomorphisms/first isomorphism theorem. You'll never get it from looking at cosets, and in some way it's actually a bit of a distraction IMO. They're often kind of just there to prove quotients exist.
Tensor products feel similar I think: actually constructing the tensor product is not terribly interesting and mostly just demonstrates that it exists. Focusing on the concrete definition makes it easy to miss the forest for the trees.
Maybe having given a couple examples, we can extend it to the abstract idea that universal properties are usually more interesting than the associated concrete constructions. :-)
In fact, I taught my child multiplication and negative numbers without running him through a lot examples. He publicly demonstrated the ability to multiply (by multiplying numbers during conversations) before his school ever taught it via drilling (in their case the Singapore method).
I agree about the shift in university. I really enjoyed what felt like a removal of the noise. Of course, the interconnection of the pieces and learning to instantiate the concepts into concrete are expected work of students. That all said, abstraction (or models) are lossy compressions and noticing their failures is essential to avoid becoming detached and/or delusional.
Famously, literacy pedagogy briefly swung towards “memorize lots of english words, and then once you’ve ground on that task for a while introduce the abstract rules of phonics” with disastrous results.
If anything, phonics isn't really abstract, and memorizing probably feels abstract to a young child. It's from the perspective of the learner whether there is a clear, concrete thing to learn or something abstract and general. A child likely isn't just approaching memorizing words as a task for memorization, but rather trying to find out the rules behind the pronunciations and failing. Phonics is what those rules are.
The abstraction can clarify the boundaries and scope.
For example:
I'm thinking of a *number* between 1 and 10, for example, 3 or 7.
Is 1 allowed? Is 10 allowed? non-integers? Irrationals?
A definition and theorems can seem trivial, if you latch onto the first trivial example and treat it as the canonical situation. This is very common difficulty when learning intro abstract math.
> others need the abstraction before the examples provide the most benefit
Would anyone need examples if they understand the abstraction? They can stamp out their own examples, can't they?
Needing examples after you've a grasp at the abstraction would be like saying 'I need help coming down this zip line', where as discovering or arriving at the abstraction is the result of working through and distilling n number of examples. To relate to the analogy, that's like climbing the hill in the first place.
Yes, that was my gist--that, examples introducing examples gives you a feel of the landscape, and assists you to arrive at the abstraction yourself. The abstraction feels like your own rather than something forced upon you.
Yes. I think I did well in math/physics classes in college and grad school just because I found the most effective way to study, for me, was to grind out as many problems as possible. Go through the old homework, old exams, books, anywhere you can find relevant problems with solutions to check against.
It's not just for you. It's the most effective way. I know several people who all crushed college etc and only later realized maybe they aren't so smart, maybe they just stumbled into the right way(by an order of magnitude) to study... hell, I'd redo problems and find depth or nuance in the same problem that I didn't see the first time.
I think a lot of people do college too young: if you can find a reasonable “real” job, a gap year or two will give you some life experience and a chance to mature a bit, which puts you in a much better place for actually learning.
Makes sense. I always intuitively understood that going from for example electronic engineering to computer science is probably easier than the other way around, but this article makes a great point. Without some low-level knowledge, you do not fully understand the higher level. Then you can only parrot the higher level (I’m also looking at you here LLM).
I'll go you one further. Many Electrical Engineers who learn about the progression of transistors, logic gates, flip-flops, registers, arithmetic logic units, central processing units, instructions, and so on, have such a profound epiphany about how all complex systems are merely collections of less complex systems working in concert, that they can't help but to see the rest of the world through that same lens, at all times.
It depends. Some people most certainly grasp things better if they are concrete, grounded in their perception of reality. For others, they see each 'example' as a mere partial projection at best that completely fails to capture the true essence of the abstraction.
That said, in sloppy engineering we often see the reverse. 'Here's a meta-model I cooked up overnight. Now if you spend the next 3 years gathering all the ___domain knowledge and expressing it in my nifty notation, you can have the outline of a potential candidate for your question. I'll write up a journal paper tomorrow about how I solved your problem'. There was a lot of that around when I was in academia.
With history classes in high school I wish they bumped up the abstraction level a little sooner. All those dates and names of important figures, almost completely useless information imho.
> All those dates and names of important figures, almost completely useless information imho.
As someone with an amateur's interest in history, I suspect that it's useless in the same way that learning words from a dictionary, or memorising multiplication tables, is useless. Learning words from a dictionary gives you no facility with a language, but you can't build much facility with a language if you don't know its words. Similarly, multiplication tables are useless for doing mathematics, but I think that it is good, both for the practice of math and in the real world, to have some basic number sense. (This is perhaps more contentious. My opinion is certainly shaped by the fact that I was among probably one of the last generations to be taught this skill, and am glad that I have it, but don't really know what it's like to grow up in a world where the skill is regarded as completely irrelevant.)
That's not to say that history classes don't lean too much on the names-and-dates approach. After all, it's easier for the teacher, both for preparing lessons and for evaluations—it's a lot easier to decide unambiguously whether a student has a date correct than if, say, that student has correctly understood the historical significance of some important event.
That feels different to me. Grinding scales helps with muscle memory and technique. There’s certainly aspects of that with math, especially with algebraic manipulations. Doing math problems can yield a deeper understanding of the underlying concepts and how they behave. Thinking you understand doesn’t cut it
I feel that's more a lesson for a lot of math teachers to understand. I remember some frustrating linear algebra, calculus and computational complexity courses where the lector basically threw some formulas onto the blackboard, went line-by-line through a formal proof of their correctness and then called it a day. Giving actual examples of the application of the formula was an afterthought left to the student aides. Giving examples that could explain the derivation of the formula was not even considered as an idea.
It always reminded me of someone teaching an "introduction to vi" course but then just scrolling through vi's source code without any further explanation - and in the end expecting the students to be able to fluently use vi.