151–160 of 220 posts
I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind: What have they ever built? Reading code from popular opensource projects…
I don't know what Uncle Bob uses but the motherboard in my PC has exactly one CPU socket. And at $600 I wouldn't say it's cheap.
I'm not sure how can I add another CPU to my laptop and my mobile phone.
Also not all software is multithreaded.
Earlier quoted context omitted.
Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.
Since this gets repeated so often, it is probably worth reproducing a little more of Knuth's quote. "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We shoul…
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs
I don’t think this is widely true today (outside e.g. game development anyway). If it were, we’d probably have lots of fast software that’s very hard to read! But computers were a lot slower then, compilers weren’t as advanced, and it would make a lot of sense if performance was top of mind for most programmers at the time.
I really do not understand why this is a discussion, why a video had to be made about it and why we now need an interview about this. Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of…
Make it run.
Make it clean. (and if need be,)
Make it fast.
It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…
Now I try to use OOP the least I can, I try to use the less abstractions I can and I try to make the CPU use the least number of instructions.
I am using a part procedural and part functional approach, keep data separate from functions that process the data, try to use immutable data where possible and minimize state changes.
I am trying to use a data oriented approach and I am more happier and productive than if I hade to apply clean code principles and software patterns on top of software patterns.
I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind: What have they ever built? Reading code from popular opensource projects…
Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.
This confusion is easily resolved - just remove "science"
Now let me wave a dead chicken over those server logs...
Earlier quoted context omitted.
So many times I've seen a more readable, simpler code turned out to be more efficient as well. In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around. The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appe…
The whole C64 scene are shaking their head in disbelief. The CPU couldn't care less about "easy readability" (whatever that even means) of your code. Ever heard of self-writing / self-modifying code? Probably an extreme example, and it can be used both ways - for performance reasons (unroll those loops!) or for abstraction (macros are your friend!).