@unclebobmartin
Uncle Bob
Nothing here yet.
Nothing here yet.
No blogs yet.
"Class Categories" was Booch's original term for "Component". It was an play on Bertrand Russell's solution to the problem of.... Nevermind. The reason that I use the metrics at the level of a component is that the metrics are statistical. They tend to be accurate if the sample size is high enough. At the level of a class, the mathematics is subject to a lot of "error". I think DI frameworks are fine; but vastly overused. My advice is to use them to inject a relatively small number of Factories and Strategies; and to do that injection into Main. What I don't want to see is @autowired scattered everywhere through the code -- and especially not in the business objects.
I don't know what /r/programmers is. I am aware that there are folks who don't like my message for one reason or another. That's fine. I believe in the marketplace of ideas. If their ideas are better, their ideas will win. Some folks don't like the fact that I am a conservative, and a republican. Some folks don't like the fact that I voted for Donald Trump. That's fine. I believe in the marketplace of ideas. If my politics is wrong, then it will lose. Meanwhile, I've been a programmer for 48 years. That's something of a rarity. Very few people alive have been coding for 48 years straight. That sheer level of experience puts me in a position of some authority. I'm also a tolerably good writer, and that helps. Anyway, there's room for all of us here.
Every programmer should know many language. Dave Thomas and Andy Hunt once said (in "The Pragmatic Programmer): Learn a new language every year. This is good advice. Every programmer should know a C based language like C, Go, Java, C# or C++. Every programmer should know a functional language like Clojure, or F#. Every programmer should know a stack based language like Forth. Every programmer should know a logic language like prolog. Every programmer should know LISP. And that's just for starters.
I was never invited to be on the C++ standards committee. Had I been invited, I would have declined. I hate bureaucracies. I don't want to haggle over little tiny language features. I want to code. I know absolutely nothing about Rust. I may look into it one day; but there are so many other things to look into. Decisions, decisions.
Nothing deliberate. Nothing implied. What you see is what you get. I never got a degree. Never went to college. I started as a programmer in 1970 at the age of 18. I worked in COBOL, PL1, FORTRAN, and Assembler. I never looked back. Now, 48 years later, all those years of experience provide me with the means to make a very comfortable living. But in the early days I lived paycheck to paycheck. As my experience grew, so did my earnings, but then so did my family obligations. Keeping my head above financial water remained a challenge for over three decades. I started a business. Employed a lot of people for a time. Don't let anybody tell you that that's a good way to make a lot of money. It doesn't work that way most of the time. Eventually the business failed and left me with very significant debt. Now, late in life, I can relax a bit. But I don't want to. I love what I do, and I do it really well. I only hope that all of you can be as happy as I am, and as happy I have been throughout my life as a husband, father, and programmer.
No. Or at least not until we develop computer systems that have human-like intelligence. Why? Because of what programmers do, and who programmers are. Programmers are detail managers. We break problems down into the tiniest of little details. Much tinier than our bosses or customers or stakeholders believe is possible or necessary. And each one of those details requires a decision that only a human can make. Many folks have tried to build system that will make programmers obsolete. One of the first of these was COBOL. The goal of COBOL was to make programming so much like English that customers and stakeholders could write the functional specification, and then just execute it. That didn't work. The demand for COBOL programmers grew quickly, and so did their salaries. Since then folks have tried lots of other strategies. One of the latest was MDA (Model Driven Architecture). The idea was that customers, stakeholders, or business analysts could draw high level UML diagrams and execute them. That didn't work. The amount of detail necessary to adorn those diagrams with required real detail managers to step in. Real detail managers are programmers. So, no. AI will not replace programmers any times soon. Nor will AIs be driving cars through all our neighborhoods very soon; and for exactly the same reasons. Human judgement is required.