Live data from Hacker News

The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

justinmath.com

31–40 of 74 posts

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#31

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 strong…

The 200% Problem. You have to understand the abstraction but then when it doesn’t work you have to understand the thing it abstracts too.

Which of course the author always does and so they don’t get what they’ve done to people.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#32
post #8

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.

have you tried Rosetta Code?

https://rosettacode.org/wiki/Rosetta_Code

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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#33
post #29

Earlier quoted context omitted.

Rule of 3s. Even more basic than this, never create an abstraction for a routine only used once.

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 Ru…

I blame bootcamp culture driven between 2010 and 2020.

Students learning DRY on day 1 and then applying it to the max before intuitively understanding the problems DRY solves.

I encounter people trying to establish standards and abstract patterns on the first pass of code...

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#34

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.

> 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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#35
post #29

Earlier quoted context omitted.

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 Ru…

I blame bootcamp culture driven between 2010 and 2020. Students learning DRY on day 1 and then applying it to the max before intuitively understanding the problems DRY solves. I encounter people trying to establish standards and abstract patterns on the first pass of code...

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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#36
> 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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#37
post #35

Earlier quoted context omitted.

I blame bootcamp culture driven between 2010 and 2020. Students learning DRY on day 1 and then applying it to the max before intuitively understanding the problems DRY solves. I encounter people trying to establish standards and abstract patterns on the first pass of code...

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…

> 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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#38
post #3

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 af…

Rule of 3s. Even more basic than this, never create an abstraction for a routine only used once.

'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.

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#39

Earlier quoted context omitted.

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 quantit…

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 str…

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. :-)

Re: The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

#40
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.
Post reply on HN