Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

justinmath.com

Post reply on HN
Print view View original

21–30 of 74 posts

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

#21

Post by QuadmasterXLII »

pitched wrote: post #15
erikerikson wrote: post #14

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.

Not sure I’m following here. Happen to have a concrete example of when abstracting first is more helpful?

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.

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

#22

Post by flyingcircus3 »

huijzer wrote: post #7

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.

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

#23

Post by [deleted] »

awongh wrote: 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.

[deleted]

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

#24

Post by ww520 »

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.

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

#25

Post by seeknotfind »

praptak wrote: 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.

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

#26

Post by seeknotfind »

erikerikson wrote: post #19
pitched wrote: post #15

Earlier quoted context omitted.

Not sure I’m following here. Happen to have a concrete example of when abstracting first is more helpful?

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

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

#28

Post by aeim »

awongh wrote: 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.

+1

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

#29

Post by hinkley »

seeknotfind wrote: post #25
praptak wrote: 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.

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.

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

#30

Post by erikerikson »

seeknotfind wrote: post #26
erikerikson wrote: post #19

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…

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.

Post reply on HN