[ggm]

It's incredibly easy to learn how to hack, and not how to abstract good design in a problem.

Anyone who opened a 1980s PC mag could be shown how to implement basic FOR or WHILE or if/then/else expression logic in BASIC and achieve huge outcomes: playable games, interesting solutions.

Learning how to craft code so its "better" is really hard. Abstraction is a distinct skill.

The mathematical underpinnings of code lie in things like logic, and group theory, higher order functions, recursion, you name it. These are not things to acquire by asking your kid next door to show you how his mod-scene ASM works.

I studied CS over 40 years ago. I think I'm still deficient, at the end of my career. CS is hard.

Understanding the implications of code on memory, performance, critical paths, safety, provability, type-safe all come with rules of thumb (engineering) which can often be acquired by the kid-next-door path, and fundamentals in their theory which really cannot.

FP is at the extreme end of hard-to-acquire, especially if your entry was imperative hacking.

[hejdjdjdkkss]

> I studied CS over 40 years ago. I think I'm still deficient, at the end of my career. CS is hard.

Name one system you worked on in your career that was “abstracted well” and built to the quality uncle bob thinks is good. I bet you can’t. Because they don’t exist. Not in the framework that this industry now measures “abstract well” in.

It’s a square peg in a round hole. Writing software is more like composing music than it is an engineering or maths discipline no matter how much people really want it to be. (Hardware is a different story)

Come at me bro :)

[throwaway77770]

I don't think Bob's standards are preferable. Or, in the likeness of Yegge's Execution in the Kingdom of Nouns, I present:

void get_coffee() { /* ... */ }

void move_away_from_obstacles(auto what_to_move_away) { /* .... */ }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void sit() { place(butt, seat); }

void prepare_mind() { get_coffee(); sit(); }

void get_opinion(int on_whom) { /* .... */ if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

[frant-hartm]

Haha, this is really good, never seen it. But one piece of the uncle bob's advice says you should order your functions from higher level abstraction to lower level, then it reads like a book and you can stop at any time you get the understanding of the code. So your example reordered:

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

void prepare_mind() { get_coffee(); sit(); }

void get_opinion(int on_whom) { /* .... / if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

void get_coffee() { / ... / }

void sit() { place(butt, seat); }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void move_away_from_obstacles(auto what_to_move_away) { / .... */ }

[Zababa]

I've always found this advice confusing and contradicting. Higher level to lower level doesn't read like a book. To make it read like a book (or an essay), you have to "flatten the tree", do something like:

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

void prepare_mind() { get_coffee(); sit(); }

void get_coffee() { / ... / }

void sit() { place(butt, seat); }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void move_away_from_obstacles(auto what_to_move_away) { / .... / }

void get_opinion(int on_whom) { / .... / if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

[ggm]

No system I worked on in my career still exists and is abstracted well.

Music is a sub-arc of Maths. You know that, right?

[jmkr]

Any recommendations for getting more of the fundamental knowledge and not being the next store neighbor?

I feel like I'd be a much better programmer had I studied CS, but it's difficult to also self study when working so I'm trying to find some balance to learning. Like, easy reads that will show immediate improvement to keep me interested, instead of picking random dry textbooks.