[HN Gopher] The square roots of all evil
___________________________________________________________________
The square roots of all evil
Author : thunderbong
Score : 31 points
Date : 2024-12-06 19:00 UTC (4 hours ago)
(HTM) web link (neilmadden.blog)
(TXT) w3m dump (neilmadden.blog)
| btilly wrote:
| Rule of thumb. Don't try to generalize until you have at least 3
| distinct examples.
|
| This does a lot to find pragmatic tradeoffs between performance
| and abstraction. It also pushes you away from the over-
| abstraction that leads to the Second System Effect, as coined by
| _The Mythical Man-Month_.
| pjz wrote:
| This is an off-by-one interpretation of the zero-one-infinity
| rule :)
| dr_dshiv wrote:
| The Dao created the One
|
| The One created the Two
|
| The Two created the Three
|
| The Three created the Ten Thousand Things
|
| _Chapter 42 of the Daodejing_
| klik99 wrote:
| I call this WET, Write Everything Twice, as opposed to DRY,
| Don't Repeat Yourself.
|
| If you need to repeat yourself, first copy and paste. If you
| need to a third time, then you can pull it into a function to
| generalize.
|
| But like nearly everything with programming, hard and fast
| rules are bad, but it's a good rule of thumb
| reshlo wrote:
| In most places I've worked, there's a big problem with this
| approach.
|
| If you have three distinct examples, and you need to do
| something that requires a fourth, you won't be able to justify
| spending time writing an abstraction. You should just copy it
| again. The three existing examples don't use an abstraction,
| and they work just fine, so there's clearly no need for an
| abstraction... or so the argument goes. In the unlikely event
| that you're allowed to write the abstraction, you definitely
| won't be allowed to reimplement the existing examples to use it
| now, because those modules are not in scope and we don't have
| the budget to test them again.
|
| If you don't create the abstraction up front, you've lost the
| chance to have an abstraction.
| vunderba wrote:
| The point about building the perfect ontology is something I
| think we all struggle with. I feel like the long lived Cyc
| project is a classic example.
|
| https://en.wikipedia.org/wiki/Cyc
|
| I'm also surprised that they didn't clarify that the true square
| root of all evil is 25.8069758011.
| revskill wrote:
| You're misunderstanding "thinking before you code" vs premature
| blahblah.
|
| It shares the same mindset as the saying: Fail to prepare is
| prepare to fail !
|
| The challenges and the evils is in the details of the process of
| optimization, not that premature optimization is evil.
| FrankWilhoit wrote:
| We have seen generalization too late -- rather, we have seen the
| need for it, but by definition, if it is left too late, it is
| impossible.
|
| I personally have not seen premature optimization, but I may have
| led a charmed life.
| doug_durham wrote:
| Truth! Many developers believe the coming up with abstractions is
| the pinnacle of sw engineering. The amount of time and money
| wasted on arguing about the right abstractions, following by
| massive refactoring needed when you discover that reality doesn't
| match your abstractions is immense. I have had engineers abstract
| all of the way down to Turning machines in an effort to find a
| model that would fit all of their use cases.
| dragontamer wrote:
| Donald Knuth wrote 4 textbooks in assembly language with advice
| about why decrement then jump saves 1 assembly instruction per
| loop iteration.
|
| The fact that everyone uses his premature optimization is the
| root of evil remark is hilarious to me. The level of optimization
| in Knuths writing makes it evident that upfront efficiency effort
| is worthwhile. Just don't overdo it.
|
| But don't trust me on that quote. Just open book 3 (chapter 5 and
| 6, sorting and searching) and go read the tape drive simulations
| of merge sort yourself. You can't miss the printouts, they're
| huge.
| baronvonsp wrote:
| Those sound to me like the very definition of optimizations
| that are not premature though. His goal was to teach
| foundational elements of running programs on computers. Loops
| and sorts are used all over the place and improvements scale
| with inputs. I see a pretty big difference between solving for
| a problem you don't yet understand (the way I've always
| mentally framed "premature optimization") and establishing
| reasons for implementing primitives in optimal ways.
| dr_dshiv wrote:
| Donald Knuth: "premature optimization is the root of all evil"
|
| The article suggests that premature specialization and premature
| generalization might, instead, be the root of all evil. Really!
|
| Well-written.
| PaulHoule wrote:
| Wonder what he'd think about my very lispy chess engine I'm
| writing in Python. A player like that might look like
| opener(ender(mcts(ender(ply1(pieces+squares,temperature=25))
|
| the goal is minimum code not through code golf but by design by
| composition.
| dade_ wrote:
| The team that wrote the Windows 11 file explorer are clearly
| scared to death of any optimization whatsoever.
| pron wrote:
| I agree that premature generalisation is a problem, but to tell
| whether anything is premature, you must have all the information
| as the person who decided to generalise or optimise. Put simply,
| these are rules best applied to your _own_ projects, not to
| others '.
|
| Often I see people criticise some project for being overly
| generalised or "over-engineered" simply because they don't have
| as full a picture as the project's maintainers.
___________________________________________________________________
(page generated 2024-12-06 23:00 UTC)