Comments in code are great in at least one situation: when something is first done in the obvious way and then there's a subtle bug or other roadblock why it can't be done the obvious way, a comment explaining why it was done in a weird way is good so nobody goes and "fixes" it before checking if the problem still exists.
Prime not understanding how codebases can get needlessly complex quickly tells me that he's never worked with my co-workers. "Clever programmers" who overengineer features and add useless abstraction layers for things that could possibly be problems in the future (but never will because they don't realize they're not working for Facebook or Google) are the bane of my existence. It truly is a constant battle to keep the code simple and doing only what it needs to do, not what some lunatic with delusions of grandeur thinks it might possibly do maybe someday in the far-off future once we reach billions of daily users.
I work in a big Python shop and enforcing type hinting is the single best thing we've done to improve code quality.
I really agree with you on your take about programming coming before writing code because as a new programmer i absolutely have no idea what to plan for. I cannot even conceptualize it. Its not until i actually start writing code that the idea comes together and i do the necessary research because i actually know the problems that need answers.
"It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away." -Antoine de Saint Exupéry
If I'm not wrong, seems like Prime has worked mostly on growing companies (Twitch, Netflix, etc.) so it seems like the work he does is to grow new components and add features to a growing codebase, but for companies that are already very large, needless complexity and the need for commented code on tests (to see exactly what was meant to happen before changes cause failures) is essential for going back and making sure that your code is still functional for the right reasons.
Prime you 100% need to watch the Rich Hickey talk on complexity. You’ve had this tangent too many times
Rich Hickey is underrated. He discusses the difference in complexity and difficulty. They measure different things, and one is objective, the other is subjective (and relative).
Simple != easy. The statement is made for the solution, not the process for achieving it. If you added indirection (interface usage) for it to be testable, and testability is a desired quality of your system, then this complexity is part of the solution you need, and it will still be between the acceptable/expected boundaries. It isn't that you simplify your problem (unless you really are able to), you simplify your solution so it doesn't have any extra added complexity besides what is required. In regards to software, we have to deal with the complexity inherent to the problem we are trying to solve (higher level problem), plus the complexities added because of the technical constraints we have deal with (although we try to minimize those, as much as we can, by having a well put architecture), both are part of the problem itself. Maybe your solution will still be (inherently) an incredible complex monster, but at least it will be smaller than the one you would get if you didn't put the effort at all
I'll give the author the benefit of the doubt on the "most programming should be done before writing a single line of code". It's true that you have to develop a rough concept of the solution before implementing it. I have solved a few hard problems I had just lying in my bed. So if that's what he means, I can buy it.
Phoenix LiveView has singlehandedly reignited my love for frontend development
Back in architecture school, the discussion/debate was always “complex v complicated” and not “simple v complex”. I think it is a much more interesting and fruitful conversation for honing creativity and problem solving. A system (simple or not) becomes more complicated as its design, language, and implementation lose clarity. If it becomes less clear why or how a project is doing something and that matters to you, then you really care more about language and expressivity more than complexity.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction." - E.F. Schumacher Something simple means in your mind something like "I can create Git, nothing difficult". But somehow only Torvalds was able to get rid of Mercurial, TFS, etc.
"Elegance" is the word you should be using for something that is complex, but operates simly
One thing i've been trying to do is work to figure out how to make UML and the Code are updated in parallel. It takes more time, but as the scale grows the necessity of documentation, and requirements tracking and compliance, becomes a larger portion of the workload. Doubly important when handing off tasks between different people, without having to make assumptions of what they would or would not know getting into it.
Structs are about memory layout. Type definition are term definitions and type annotations are propositions. Implementation is proof for the given type proposition. Also known as “propositions as Types” or “Curry-Howard correspondence”.
How does one start adding more complexity? Prime? Don't follow a set architecture..everything from project file structure..to the way you name your classes..to how you access your data Use confusing names. Create classes 5k lines + Duplicate your code across multiple files Use 3 different backend frameworks for one api. Have a lot of redundant error prone code that can be easily abstracted away by a good library Never refactor and improve the design of existing code. Don't remove dead code Don't follow best practices So many ways so many ways
I used to be the code equivalent of “Hemingway has never used a word that might send someone to the dictionary” Now I’m more “poor Faulkner, does he really think big emotions from big words?”
one comment on comments: an underrated use case in comments I find is when you are writing a function or script that in theory could be found with different names someone might search to try and find that code, you can use some of the keywords that are possible your team would look up in a comment so when they search they find it faster.
@k98killer