3 ms·

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thu

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

jcelerier 2y ago
At no point in my life my code has been made worse because I've used an existing sort function instead of writing a buggy one
- SleepyMyroslav 2y ago
  If we ignore 'buggy' part I think you projecting current good state back into not so good old times. I am pretty sure you will not replace radix sort that uses domain knowledge of reduced value range with qsort circa C++98. Things became much better after relatively recent improvements in generalist sorting libraries: when pattern defeating quick sort variants became norm, when mostly sorted cases got covered ... Tbh I do have a case from 2013-16 when I regret not doing it for one AAA project on ps4.
xtracto 2y ago
I am wondering where the "generalize code after doing it for the 3rd time" rule of thumb comes from? I also subscribe to it, and read it somewhere 15/20 years ago. Was it the Mythical Man Month book Maybe?
- laserlight 2y ago
  See the C2 Wiki article: https://wiki.c2.com/?ThreeStrikesAndYouRefactor https://wiki.c2.com/?ThreeStrikesAndYouRefactor
0x696C6961 2y ago
The rule of three should obviously not be applied to well known data structures and algorithms ...
- II2II 2y ago
  Well known data structures and algorithms are well know because they have been used more than three times. That said: if you are dealing with a situation where you have to implement them yourself, you may want to consider whether the rule of three applies. (Clearly this depends upon the situation.)
- bluGill 2y ago
  If the well known data structures and algorithms are not provide by your language get a better language. There are exceptions. If you are implementing the language it is your job to write them. It is useful as a student to implement the basics from scratch. Your language may decide something is not allowed and thus not implement it (a doubly linked list is almost always a bad idea in the real world. Likewise you don't need to provide all the sorting algorithms)
chthonicdaemon 2y ago
Tell that to Richard Hamming: "Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class." [1] I have seen this "premature abstraction" warning creep through our discourse lately, but I don't clearly understand it. I feel like I'm making calls all the time about when to introduce functions or classes that will save you time or effort in the future without forcing yourself to see the repetition before you do. Not only that but Hamming's advice has rung true in my career. Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too. [1] https://jamesclear.com/great-speeches/you-and-your-research-by-richard-hamming https://jamesclear.com/great-speeches/you-and-your-research-...
- malfist 2y ago
  To your point, we use abstractions all the damn time. They're everywhere. Even programming languages are an abstraction (especially high level ones). You and I, and everybody else here doesn't pick a cylinder and a block to write to and tell the hard drive to move it's arm into place and record the magnetic data, no we all talk about inserting a row into the DB. Abstractions are essential to productivity or you'll never get out of the "make it from scratch" trap
  - sgarland 2y ago
    Yes, but there is a line to be drawn somewhere. Filesystems are sufficiently advanced such that there’s no meaningful gains to be had from manually allocating CHS for data, and they provide housekeeping. C abstracts a lot of architecture-specific information away, but still requires that you understand a modicum of memory management; if you understand it (and cache line access) well, you can get even more performance. Python abstracts that away as well, and gives you a huge standard library to accomplish many common tasks with ease. You can quickly make a prototype in Python, but it won’t be as performant as C. You can spend time profiling it and moving computationally-heavy parts into C extensions (I do this for fun and learning), but you’ll likely spend more time and get worse results than if you just rewrote it. Docker is an abstraction over already-existing technology like cgroups. It provides an easy-to-understand model, and a common language. This is quite valuable, but it does allow one to not know about what it’s hiding, which is problematic when troubleshooting – for example, naïvely assuming that querying /proc in a container shows the CPU resources allocated to the container, rather than the host. That’s how I view abstractions. They can be incredibly useful, but they usually have trade-offs, and those should always be considered. Most importantly, you should at a minimum be aware of what you’re giving up by using them, even if you don’t fully understand it.
nyrikki 2y ago
Protecting yourself from technologies, vendors, etc... are all very very worth making abstractions for. The silly "only after # Times" type rules stolen from the DRY for DRY reasons is part of the problem and far from the solution. "Abstraction" could be anything from keeping code in different but adjacent files to an entire anti-corruption layer etc.... The costs are different, as are the benefits. It is horses for courses, not 'one rule that the government doesn't want you to know about'
tines 2y ago
It's interesting when people say "No. Just no." and then go on to explain. Wasn't the response supposed to be "just" a no?

jcelerier 2y ago

At no point in my life my code has been made worse because I've used an existing sort function instead of writing a buggy one

SleepyMyroslav 2y ago
If we ignore 'buggy' part I think you projecting current good state back into not so good old times. I am pretty sure you will not replace radix sort that uses domain knowledge of reduced value range with qsort circa C++98. Things became much better after relatively recent improvements in generalist sorting libraries: when pattern defeating quick sort variants became norm, when mostly sorted cases got covered ... Tbh I do have a case from 2013-16 when I regret not doing it for one AAA project on ps4.

xtracto 2y ago

I am wondering where the "generalize code after doing it for the 3rd time" rule of thumb comes from? I also subscribe to it, and read it somewhere 15/20 years ago. Was it the Mythical Man Month book Maybe?

laserlight 2y ago
See the C2 Wiki article: https://wiki.c2.com/?ThreeStrikesAndYouRefactor https://wiki.c2.com/?ThreeStrikesAndYouRefactor

0x696C6961 2y ago

The rule of three should obviously not be applied to well known data structures and algorithms ...

II2II 2y ago
Well known data structures and algorithms are well know because they have been used more than three times. That said: if you are dealing with a situation where you have to implement them yourself, you may want to consider whether the rule of three applies. (Clearly this depends upon the situation.)
bluGill 2y ago
If the well known data structures and algorithms are not provide by your language get a better language. There are exceptions. If you are implementing the language it is your job to write them. It is useful as a student to implement the basics from scratch. Your language may decide something is not allowed and thus not implement it (a doubly linked list is almost always a bad idea in the real world. Likewise you don't need to provide all the sorting algorithms)

chthonicdaemon 2y ago

Tell that to Richard Hamming: "Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class." [1] I have seen this "premature abstraction" warning creep through our discourse lately, but I don't clearly understand it. I feel like I'm making calls all the time about when to introduce functions or classes that will save you time or effort in the future without forcing yourself to see the repetition before you do. Not only that but Hamming's advice has rung true in my career. Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too. [1] https://jamesclear.com/great-speeches/you-and-your-research-by-richard-hamming https://jamesclear.com/great-speeches/you-and-your-research-...

malfist 2y ago
To your point, we use abstractions all the damn time. They're everywhere. Even programming languages are an abstraction (especially high level ones). You and I, and everybody else here doesn't pick a cylinder and a block to write to and tell the hard drive to move it's arm into place and record the magnetic data, no we all talk about inserting a row into the DB. Abstractions are essential to productivity or you'll never get out of the "make it from scratch" trap
- sgarland 2y ago
  Yes, but there is a line to be drawn somewhere. Filesystems are sufficiently advanced such that there’s no meaningful gains to be had from manually allocating CHS for data, and they provide housekeeping. C abstracts a lot of architecture-specific information away, but still requires that you understand a modicum of memory management; if you understand it (and cache line access) well, you can get even more performance. Python abstracts that away as well, and gives you a huge standard library to accomplish many common tasks with ease. You can quickly make a prototype in Python, but it won’t be as performant as C. You can spend time profiling it and moving computationally-heavy parts into C extensions (I do this for fun and learning), but you’ll likely spend more time and get worse results than if you just rewrote it. Docker is an abstraction over already-existing technology like cgroups. It provides an easy-to-understand model, and a common language. This is quite valuable, but it does allow one to not know about what it’s hiding, which is problematic when troubleshooting – for example, naïvely assuming that querying /proc in a container shows the CPU resources allocated to the container, rather than the host. That’s how I view abstractions. They can be incredibly useful, but they usually have trade-offs, and those should always be considered. Most importantly, you should at a minimum be aware of what you’re giving up by using them, even if you don’t fully understand it.

nyrikki 2y ago

Protecting yourself from technologies, vendors, etc... are all very very worth making abstractions for. The silly "only after # Times" type rules stolen from the DRY for DRY reasons is part of the problem and far from the solution. "Abstraction" could be anything from keeping code in different but adjacent files to an entire anti-corruption layer etc.... The costs are different, as are the benefits. It is horses for courses, not 'one rule that the government doesn't want you to know about'

tines 2y ago

It's interesting when people say "No. Just no." and then go on to explain. Wasn't the response supposed to be "just" a no?