[HN Gopher] The Need to Grind Concrete Examples Before Jumping U...
___________________________________________________________________
The Need to Grind Concrete Examples Before Jumping Up a Level of
Abstraction
Author : JustinSkycak
Score : 137 points
Date : 2024-12-08 15:29 UTC (7 hours ago)
(HTM) web link (www.justinmath.com)
(TXT) w3m dump (www.justinmath.com)
| billyp-rva wrote:
| Relatedly: struggling is learning [0].
|
| [0] https://news.stanford.edu/stories/2019/09/embrace-
| struggle-e...
| achatham wrote:
| 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.
| praptak wrote:
| 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.
| seeknotfind wrote:
| Rule of 3s. Even more basic than this, never create an
| abstraction for a routine only used once.
| hinkley wrote:
| 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.
| GenerocUsername wrote:
| 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...
| hinkley wrote:
| 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.
| KineticLensman wrote:
| > 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.
| hinkley wrote:
| Definitely true, but probably easier to get nerds to
| rewatch Ted Lasso than Full Metal Jacket.
| cjfd wrote:
| '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.
| vacuity wrote:
| 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.
| coldtea wrote:
| > _' 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.
| skobes wrote:
| Ironically, this post would benefit from showing some examples.
| dr_dshiv wrote:
| 100%.
|
| 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
| Handprint4469 wrote:
| 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.
|
| [0]: https://byorgey.wordpress.com/2009/01/12/abstraction-
| intuiti...
| huijzer wrote:
| 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).
| flyingcircus3 wrote:
| 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.
| awongh wrote:
| 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.
| aeim wrote:
| +1
| kevindamm wrote:
| 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.
| awongh wrote:
| 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.
| aqme28 wrote:
| 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.
| danielmarkbruce wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| joshdavham wrote:
| 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.
| bick_nyers wrote:
| 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.
| sleazebreeze wrote:
| 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.
| mmastrac wrote:
| 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.
| hinkley wrote:
| 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.
| erikerikson wrote:
| 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.
| pitched wrote:
| Not sure I'm following here. Happen to have a concrete example
| of when abstracting first is more helpful?
| SilasX wrote:
| Not disagreeing, and I'm not sure if your comment was
| intended as a joke, but it's kind of funny what just happened
| here, if anyone missed it:
|
| "They say you have to use concrete examples, but not everyone
| needs that."
|
| 'Can you give a concrete example of that?'
| erikerikson wrote:
| Indeed, and both a reasonable desire and one of my systemic
| communication failures. :)
| erikerikson wrote:
| 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.
| seeknotfind wrote:
| 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.
| erikerikson wrote:
| 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.
| ndriscoll wrote:
| 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. :-)
| QuadmasterXLII wrote:
| 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.
| vacuity wrote:
| 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.
| penguin_booze wrote:
| > 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.
| dr_kiszonka wrote:
| I find that people often _think_ they understand an
| abstraction, but examples either expose that they don 't or
| add deeper insight.
| ww520 wrote:
| 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.
| k__ wrote:
| I need to grind concrete examples before jumping to theory.
|
| Don't know how I finished my CS degree, because most of the
| theory I just understood years after leaving university and doing
| some hands on work...
| xg15 wrote:
| > _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.
| tom_ wrote:
| 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.
| schneems wrote:
| 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.
| xg15 wrote:
| 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.
| nhlx2 wrote:
| Similar to grinding scales on a music instrument.
| klysm wrote:
| 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
___________________________________________________________________
(page generated 2024-12-08 23:00 UTC)