Edit: Provide pointers to where others can learn about those concepts
Anything that is “premature” is per definition incorrect. So there is no information in that sentence.
Having said that, a lack of architectural abstractions leads to badly designed code with a WTF count reaching the heavens. Have you ever seen UI code directly relying on a specific flavour of SQL implementation and database? That’s an example of how a lack of architectural abstractions leads to spaghetti code. Or how about the domain logic directly relying on a specific UI framework? Another example where an early architectural abstractions would have saved years of maintenance work. Again something I see all the time in the wild.
leaky abstractions create more trouble than is worth it. If your abstraction does not fit the problem neatly do not abstract it.
Could you please elaborate on that? I'm not sure to understand.
Write the simplest abstraction first, then as the system develops combine similar use cases into useful abstractions for clarity
Start out to broad and wind up wasting resources that could be put to better use.
Start out to narrow focus without knowing where need/$$ to keep going is and wind up wasting resources. Idealy, the narrower focus permits getting to the 'wasting resources' point faster.
Hiding the details via abstraction when details are still in development/need to be viewable & readily available defeats the purpose of abstraction making things simpiler/easier.
Instead of :
If foo then
bar
Else
baz
Endif
If foo then
bar
return
Endif
baz
I try to make each method/function to have a single entry and a single exit.
Cond, case, pattern maching in function heads, decision tables, and syntactic sugar in some PLs, allow you to flatten the nested code / branchinbg / conditionals.
Procedural is fine and simple and it works. You can refactor later if you have the time and money.
Related listening/watching: Jonathan Blow.
I have seen a lot of videos of Jonathan Blow. IIRC he created his own programming language to code in. That could be interpreted as pretty "nerdically sound" and "perfectionist" by many.
My point is, I agree with what you said in spirit, but the way you phrased it could be used to justify spaguetti code, too much technical debt and, ironically, fashion-based decisions (we need to just make it work, lets choose x).
The gist of it: you program procedurally without thinking too much about the code and only add "compressions" when the need for them arises. The compressions can take various forms like encapsulating data types within objects, behaviour within functions, extracting often-repeated operations into separate libraries and then loading and referencing them when needed, etc.
Typed arguments as strong pre requirements to intent, and the cost/benefit of typechecks.
What do I actually do? Boring imperative python3.
I wish I'd learned LISP as my first language. It was literally a left door right door choice to do Fortran on cards, and then Pascal. Two people teaching the induction classes. I went through the Fortran->Pascal door.
If I'd turned left, I would have entered the other cohort who started with LISP.
Thinking of the stupidest way we can get it done and then ruthlessly refactoring until the resulting algorithm / system is as simple as possible.
Edit: point 1 comes from A Philosophy of Software Design. One of my fave programming books of all time.
This is a profound insight. It totally changed how I think about the nature of multithreaded and multiprocessor based programming.
Also from Kevlin - Refactoring to immutability[2], which showed me exactly why you would want immutable "variables"
2. linters like eslint forces best practices and readability in my code
3. security is learnable from online sources like latacora blog and owasp cheatsheets
4. reading latest docs and github issues helps a lot in debugging.
5. reading readme file and getting started guides is more reliable than watching video tutorials.
6. videos however are good at getting comparisons and seeig presentations of ideal use cases of particular tool software or database or framework
I now think much more about immutable, append-only data stores as a result.
Technically 2 concepts but they’re highly related.
Basically, allow the consumer of a component to pass in something, rather than the component needing to contain that logic.
It’s great for front end systems, but also apples to backend and general systems programming… an invaluable concept
Basically, it boils down to this: F(A . B) = F(A) + F(B)
(F,A,B, ., +) could be anything which you found suitable.