My feeling is these paradigms, SOLID and SIMPLE, boil down to basically: small objects, connected minimally, though interfaces.
SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
> ... composition of functions operating on immutable data structures is just the right way to go
Yeah. No. Maybe. The cost of immutability can be high. Immutability can be very elegant when it's right, but mutability can be clearer other times. As another respondent said, there's no silver bullet. There's no 'right way to go'; as ever it depends.
Please note that the article merely encourages the application of some of the best practices introduced by functional programming - strong typing and more mindfulness around mutability and side effects - into all forms of programming.
Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.
>I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
> Error: ENOENT, no such file or directory '~/foorc'
I can’t count how many times I’ve seen error messages that look like this, often with no context at all, in JavaScript apps, even widely used ones like npm and webpack. Proper error handling is never easy, but the JS community seems particularly given to avoiding it.
Complexity is combinatorial. If you compose your code of overly complex components the end result will have much more emergent behavior.
If everything at the bottom is straightforward, then people will spot more overarching concerns, instead of bogging down in minor details.
I’d really love to see some cognitive science applied directly to UX and code quality concepts. Surely some of the things we espouse but don’t enforce are spot on, and others are cargo culting. Refining that list might make it harder to ignore.
Write a docstring for a function before you write the body of that function. Keep it short. Don't overthink it. At this point, it doesn't even have to be syntactically correct.
If, in a brief sentence, written in plain English (or any other language of your choice), you can't explain the idea, you need to "go back to the drawing board." Resist the urge writing it in a programming language before you can explain it in English.
When you're done writing the function, go back to the docstring, revise it; in some cases, you can even remove it.
The purpose of a docstring is to help humans to quickly scan the code and discern the meaning, the idea of the function without having to read its source. Like a trailer for a movie - it should give you the general idea, but not give away the implementation details.
Think about docstrings as "type annotations" for humans. We use types and type hints "to help the compiler understand our code better" because computers do not understand plain English, but very often, we have no empathy for fellow programmers.
"Keep the story going. Sign up for an extra free read.
You've completed your member preview for this month, but when you sign up for a free Medium account, you get one more story."
taberiand|6 years ago
SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
tobr|6 years ago
tempguy9999|6 years ago
Yeah. No. Maybe. The cost of immutability can be high. Immutability can be very elegant when it's right, but mutability can be clearer other times. As another respondent said, there's no silver bullet. There's no 'right way to go'; as ever it depends.
kevingoslar|6 years ago
Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.
pytester|6 years ago
It can provide an incremental improvement but it is https://en.wikipedia.org/wiki/No_Silver_Bullet
thinkpad20|6 years ago
I can’t count how many times I’ve seen error messages that look like this, often with no context at all, in JavaScript apps, even widely used ones like npm and webpack. Proper error handling is never easy, but the JS community seems particularly given to avoiding it.
hinkley|6 years ago
If everything at the bottom is straightforward, then people will spot more overarching concerns, instead of bogging down in minor details.
I’d really love to see some cognitive science applied directly to UX and code quality concepts. Surely some of the things we espouse but don’t enforce are spot on, and others are cargo culting. Refining that list might make it harder to ignore.
orenkt|6 years ago
it would be also very educational to see decision and design process of an app build with those rules.
lostgame|6 years ago
Also; keep it clean. Don’t over-comment, but comment.
dplgk|6 years ago
iLemming|6 years ago
If, in a brief sentence, written in plain English (or any other language of your choice), you can't explain the idea, you need to "go back to the drawing board." Resist the urge writing it in a programming language before you can explain it in English.
When you're done writing the function, go back to the docstring, revise it; in some cases, you can even remove it.
The purpose of a docstring is to help humans to quickly scan the code and discern the meaning, the idea of the function without having to read its source. Like a trailer for a movie - it should give you the general idea, but not give away the implementation details.
Think about docstrings as "type annotations" for humans. We use types and type hints "to help the compiler understand our code better" because computers do not understand plain English, but very often, we have no empathy for fellow programmers.
sys_64738|6 years ago
tchaffee|6 years ago
kyberias|6 years ago
dplgk|6 years ago
dang|6 years ago
avmich|6 years ago
Sorry, can't read behind paywall.
kevingoslar|6 years ago