Live data from Hacker News

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

justinmath.com

41–50 of 74 posts

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

#41

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.

True. I feel, this is why sometimes, the notation

  a_0 + a_1 + ... + a_n
is easier to understand than the shorter

  sum(i = 0 to n) a_i
.

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.

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

#42

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…

I find that people often think they understand an abstraction, but examples either expose that they don't or add deeper insight.

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

#44
post #43

Similar to grinding scales on a music instrument.

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

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

#45

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.

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

#46
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?

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.

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

#47
post #38

Earlier quoted context omitted.

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…

I like to think of it as two intertwined rules:

  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.

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

#48
post #38

Earlier quoted context omitted.

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…

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

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

#49
post #35

Earlier quoted context omitted.

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

Definitely true, but probably easier to get nerds to rewatch Ted Lasso than Full Metal Jacket.

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

#50
post #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 blackb…

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