I saw a talk where abstractions are analogized to telling a story. You will say "I was walking down the road and saw a deer", not "I put my left foot down, then my right foot down, then my left foot down, then turned my head by 70 degrees to the left and put an animal with big horns in the middle of my visual cortex".
A perfect example! Usually, when I want to present a good abstraction and encapsulation I talk about cars. You don't need to know how to engine works, you need just push a start button.
Great topic and no nonsense delivery of it. I’m also glad the “stop pretending all of this was done by me” concept has become more mainstream in tech. Successful software products are often too complex for one person to understand, let alone create/come up with. When I was at Netflix ~6 years ago, there were a couple talks my colleagues and I wrote/gave as a team… but giving one another credit was still pretty rare in Silicon Valley at the time.
any Tips for people from the other end of the spectrum? In coding, as well as in real life, i have a strong tendency to over abstract. The real life part isnt that bad, and i learned to live myself. But yeah, when you end up at unreasonable conclusions, usually some common sense instamce activates itself, adding a "HOLD ON, you went ahead of yourself" to the silent discussion. Problem is coding. For example, i have the "simple" task to make a "settings" window to display the values of attributes/parameters considered as setting. Normally you wont stop there, just displaying the "options", but thats way enough to get an idea where i go haywire. So i look at the stuff i need to display. So, that gonna be like 20 "LineEdit"s, some radio button groups, checkboxes, you name it. All in all not that much. But me is already thinking "NO we are not gonna make a 100 line spaghetti, i dont want to debug that, and i dont want to write that in the first place". This is, from what i gathered, still on track. Then i think to myself. "Hmmm, wouldnt it be good to have some kind of "settings infosystem" that would know all about the settings, their respective UI elements, some kind of priority maybe, their position, while we are at it relative as well as global, hierarchical connected nodes, along cardinality information, .... This is where i still see potential, but already get off track by quite a bit. And suddenly i catch myself scratching myhead over unforseen difficulties in creating a new datatype, to store some potential value where floating point accuracy wont cut it. But thats not one of the settings. To be precise, thats totally not on my task list. It is also not a neccessary step to achieve fulfilling my task list. Trying to get back on track, read a bit more on best practices. Next thing is me waking up over coding a simple database, since you know "gross i dont want to have a 100 line Method filled with literals and numbers, prone to change anomalies for its redundant parts" - "This could be a nice elegant clean method with just some loops and conditions, if the data would be provided" So if i ever get to the finish line with all the sidequests i tend to get involved, chances are i ended up with one or two cool frameworks i may use in further projects. Well i started with the good part. But also i used "chances are" and "may use". Yes it happened. Yes it even happened i was happy that past me designed the framework to be enhanceable from the start. But mosty I end up with a Moloch of like 10-15k lines of structured code that so ever elegantly creates those 100 lines of code i was too lazy to write myself. You guessed it, deadlines are a Problem as well a clutter. Even if the clutter is beatifully designed, works perfectly and you are proud of it. If it isnt in the focus of the development and not neccessary on the way, i better call it by its name CLUTTER.
"You can't switch on an enum class without casting it back to an int first". I don't know where you got that idea from - I switch on enum class values all the time.
It works if the input and case labels are all that enum class type; in the context of updating legacy code, perhaps retro-enforcing that won't always make sense
A module is probably the most important abstraction, at least in my current view. Or a namespace, if your language doesn't have modules. Because it is the most high-level abstraction available in code. Starting with a bird-eye view of things is how I like to decompose, going from the broader view, down to the most detailed view. If you don't modularize your code and instead start designing or worst, developing, from the detail level up, it becomes almost impossible to change your code and modularize later because of the growing coupling at the lower level and the missing well thought out interfaces.
Why would you move things into the build system when you have predefined ways to detect things inside the source code? That couples more your code with the build system actually.
This is how it's historically been done, and (amazingly) still often used in modern C++, and yes, its very coupled. The language is almost 50 years old now...
21:10 That's again seems like a C++ problem. You know what would help? Calling a function with "named arguments". Other languages have that (named parameters). (Not just calling a function whose arguments have names, that's a very basic requirement... that still some c libraries don't satisfy.) Like like : setName(firstName = "James", lastName = "Bond"); You can kinda do it in C with struct and designated initializes: typedef struct { int x, y, z; } point_t; void foo(point_t p) {} void test(void) { foo((point_t){ .x = 5 }); foo((point_t){ .y = 100 }); foo((point_t){ .x = 1, .y = 2 }); foo((point_t){ .x = 1, .z = 3 }); foo((point_t){ .y = 2, .x = 4 }); } In C++ you have to do a bit differently and with some limitation void testCpp(void) { foo({ .x = 5 }); foo({ .y = 111 }); foo({ .x = 1, .y = 2 }); foo({ .x = 1, .z = 3 }); //foo({ .y = 2, .x = 4 }); /// error: 'x': designators must appear in member declaration order } C also has this by the way : int a[6] = { [4] = 29, [2] = 15 }; and GCC has this: foo((point_t){ z:6, x:2 }); g++ foo({ x:2, z:6 }); and you can still have positional calling foo({ 1, 2 }); I like these better than spreading a one line call to 4+ lines. (If the names are long it might still spill over to the next line though.) It's better than, "OK, I'm setting up a struct..." then realizing "oh, I'm just using it for one function call". Maybe if function declarations would also create an implicit structure declaration and an inline function definition with that structure argument that calls the function with argument list, then we wouldn't have to set up the structure manually, and all functions could be called with initializer list with named argument assignment implicitly converted to structure: () is argument list call ({}) is for named argument call without manually naming structures that are only used as gateways to function calls. There might be a problem with overloaded functions, in that case automatic structure declarations could be disabled for those functions only where it would introduce ambiguity. Probably similar checks already exist to detect collision when overloaded functions have arguments with default values. And maybe relax the member declaration order restriction in C++.
Its actually amazing listening to this talk and working on my project simultaneously, adpoting some of the guidelines on the spot.
we are all doomed
Abstraction is everything in coding. Great talk. Not as obvious as some may think. We don't talk about that as often.
no wonder swdev is such a mess
I saw a talk where abstractions are analogized to telling a story. You will say "I was walking down the road and saw a deer", not "I put my left foot down, then my right foot down, then my left foot down, then turned my head by 70 degrees to the left and put an animal with big horns in the middle of my visual cortex".
A perfect example!
Usually, when I want to present a good abstraction and encapsulation I talk about cars.
You don't need to know how to engine works, you need just push a start button.
Great topic and no nonsense delivery of it.
I’m also glad the “stop pretending all of this was done by me” concept has become more mainstream in tech. Successful software products are often too complex for one person to understand, let alone create/come up with. When I was at Netflix ~6 years ago, there were a couple talks my colleagues and I wrote/gave as a team… but giving one another credit was still pretty rare in Silicon Valley at the time.
the myth of the lone coder is just that, a myth.
This is such an inspirational and motivating talk. So many small but relevant truths. Thank you!
any Tips for people from the other end of the spectrum?
In coding, as well as in real life, i have a strong tendency to over abstract. The real life part isnt that bad, and i learned to live myself. But yeah, when you end up at unreasonable conclusions, usually some common sense instamce activates itself, adding a "HOLD ON, you went ahead of yourself" to the silent discussion.
Problem is coding. For example, i have the "simple" task to make a "settings" window to display the values of attributes/parameters considered as setting. Normally you wont stop there, just displaying the "options", but thats way enough to get an idea where i go haywire.
So i look at the stuff i need to display. So, that gonna be like 20 "LineEdit"s, some radio button groups, checkboxes, you name it.
All in all not that much. But me is already thinking "NO we are not gonna make a 100 line spaghetti, i dont want to debug that, and i dont want to write that in the first place". This is, from what i gathered, still on track. Then i think to myself. "Hmmm, wouldnt it be good to have some kind of "settings infosystem" that would know all about the settings, their respective UI elements, some kind of priority maybe, their position, while we are at it relative as well as global, hierarchical connected nodes, along cardinality information, ....
This is where i still see potential, but already get off track by quite a bit.
And suddenly i catch myself scratching myhead over unforseen difficulties in creating a new datatype, to store some potential value where floating point accuracy wont cut it.
But thats not one of the settings. To be precise, thats totally not on my task list. It is also not a neccessary step to achieve fulfilling my task list. Trying to get back on track, read a bit more on best practices. Next thing is me waking up over coding a simple database, since you know "gross i dont want to have a 100 line Method filled with literals and numbers, prone to change anomalies for its redundant parts" - "This could be a nice elegant clean method with just some loops and conditions, if the data would be provided"
So if i ever get to the finish line with all the sidequests i tend to get involved, chances are i ended up with one or two cool frameworks i may use in further projects. Well i started with the good part. But also i used "chances are" and "may use". Yes it happened. Yes it even happened i was happy that past me designed the framework to be enhanceable from the start.
But mosty I end up with a Moloch of like 10-15k lines of structured code that so ever elegantly creates those 100 lines of code i was too lazy to write myself.
You guessed it, deadlines are a Problem as well a clutter.
Even if the clutter is beatifully designed, works perfectly and you are proud of it. If it isnt in the focus of the development and not neccessary on the way, i better call it by its name CLUTTER.
"You can't switch on an enum class without casting it back to an int first".
I don't know where you got that idea from - I switch on enum class values all the time.
Same, and if you skip using default, the compiler enforces that you always check every possible value of the enum.
It works if the input and case labels are all that enum class type; in the context of updating legacy code, perhaps retro-enforcing that won't always make sense
A module is probably the most important abstraction, at least in my current view. Or a namespace, if your language doesn't have modules. Because it is the most high-level abstraction available in code. Starting with a bird-eye view of things is how I like to decompose, going from the broader view, down to the most detailed view. If you don't modularize your code and instead start designing or worst, developing, from the detail level up, it becomes almost impossible to change your code and modularize later because of the growing coupling at the lower level and the missing well thought out interfaces.
Why would you move things into the build system when you have predefined ways to detect things inside the source code? That couples more your code with the build system actually.
This is how it's historically been done, and (amazingly) still often used in modern C++, and yes, its very coupled.
The language is almost 50 years old now...
@@ChrisAthanas yes, but it has been evolving :)
50 function calls can be a nice paragraph if all of them are named descriptively
21:10 That's again seems like a C++ problem.
You know what would help? Calling a function with "named arguments". Other languages have that (named parameters).
(Not just calling a function whose arguments have names, that's a very basic requirement... that still some c libraries don't satisfy.)
Like like : setName(firstName = "James", lastName = "Bond");
You can kinda do it in C with struct and designated initializes:
typedef struct { int x, y, z; } point_t;
void foo(point_t p) {}
void test(void) {
foo((point_t){ .x = 5 });
foo((point_t){ .y = 100 });
foo((point_t){ .x = 1, .y = 2 });
foo((point_t){ .x = 1, .z = 3 });
foo((point_t){ .y = 2, .x = 4 });
}
In C++ you have to do a bit differently and with some limitation
void testCpp(void) {
foo({ .x = 5 });
foo({ .y = 111 });
foo({ .x = 1, .y = 2 });
foo({ .x = 1, .z = 3 });
//foo({ .y = 2, .x = 4 }); /// error: 'x': designators must appear in member declaration order
}
C also has this by the way :
int a[6] = { [4] = 29, [2] = 15 };
and GCC has this:
foo((point_t){ z:6, x:2 });
g++
foo({ x:2, z:6 });
and you can still have positional calling
foo({ 1, 2 });
I like these better than spreading a one line call to 4+ lines. (If the names are long it might still spill over to the next line though.)
It's better than, "OK, I'm setting up a struct..." then realizing "oh, I'm just using it for one function call".
Maybe if function declarations would also create an implicit structure declaration and an inline function definition with that structure argument that calls the function with argument list, then we wouldn't have to set up the structure manually, and all functions could be called with initializer list with named argument assignment implicitly converted to structure:
() is argument list call
({}) is for named argument call
without manually naming structures that are only used as gateways to function calls.
There might be a problem with overloaded functions, in that case automatic structure declarations could be disabled for those functions only where it would introduce ambiguity. Probably similar checks already exist to detect collision when overloaded functions have arguments with default values.
And maybe relax the member declaration order restriction in C++.