Re: else ladders practice

On 20/11/2024 21:17, Bart wrote:

On 20/11/2024 16:15, David Brown wrote:

On 20/11/2024 02:33, Bart wrote:

 

It's funny how nobody seems to care about the speed of compilers (which can vary by 100:1), but for the generated programs, the 2:1 speedup you might get by optimising it is vital!

>
To understand this, you need to understand the benefits of a program running quickly.

 As I said, people are preoccupied with that for programs in general. But when it comes to compilers, it doesn't apply! Clearly, you are implying that those benefits don't matter when the program is a compiler.

No - you are still stuck with your preconceived ideas, rather than ever bothering reading and thinking.
As I have said many times, people will always be happier if their compiler runs faster - as long as that does not happen at the cost of the functionality and features.
Thus I expect that whoever compiles the gcc binaries that I use (occasionally that is myself, but like every other programmer I usually use pre-built compilers), uses a good compiler with solid optimisation enabled when building the compiler.  And I expect that the gcc (and clang/llvm) developers put effort into making their tools fast - but that they prioritise correctness first, then features, and only then look at the speed of the tools and their memory usage.  (And I don't expect disk space to be of the remotest concern to them.)

 

  Let's look at the main ones:

 <snip>
 OK. I guess you missed the bits here and in another post, where I suggested that enabling optimisation is fine for production builds.
 

I saw it.  But maybe you missed the bit when the discussion was about serious software developers.  Waldek explained, and I've covered it countless times in the past, but since you didn't pay attention then, there is little point in repeating it now.

For the routines ones that I do 100s of times a day, where test runs are generally very short, then I don't want to hang about waiting for a compiler that is taking 30 times longer than necessary for no good reason.
 

Your development process sounds bad in so many ways it is hard to know where to start.  I think perhaps the foundation is that you taught yourself a bit of programming in the 1970's, convinced yourself at the time that you were better at software development than anyone else, and have been stuck in that mode and the same methodology for the last 50 years without ever considering that you could learn something new from other people.

 

There is usually a point where a program is "fast enough" - going faster makes no difference.  No one is ever going to care if a compilation takes 1 second or 0.1 seconds, for example.

 If you look at all the interactions people have with technology, with GUI apps, even with mechanical things, a 1 second latency is generally disastrous.
 A one-second delay between pressing a key and seeing a character appear on a display or any other feedback, would drive most people up to wall. But 0.1 is perfectly fine.
 

As I said, no one is ever going to care if a compilation takes 1 second or 0.1 seconds.

 

It doesn't take much thought to realise that for most developers, the speed of their compiler is not actually a major concern in comparison to the speed of other programs.

 Most developers are stuck with what there is. Naturally they will make the best of it. Usually by finding 100 ways or 100 reasons to avoid running the compiler.
 

So your advice is that developers should be stuck with what they have - the imaginary compilers from your nightmares that take hours to run - and that they should make a point of always running them as often as possible?  And presumably you also advise doing so on a bargain basement single-core computer from at least 15 years ago?
People who do software development seriously are like anyone else who does something seriously - they want the best tools for the job, within budget.  And if they are being paid for the task, their employer will expect efficiency in return for the budget.
Which do you think an employer (or amateur programmer) would prefer?
a) A compiler that runs in 0.1 seconds with little static checking
b) A compiler that runs in 10 seconds but spots errors saving 6 hours debugging time
Developers don't want to waste time unnecessarily.  Good build tools means you get all the benefits of good compilers, without wasting time re-doing the same compilations when nothing has changed.
I can't understand why you think that's a bad thing - what is the point of re-doing a build step when nothing has changed?  And a build tool file is also the place to hold the details of how to do the build - compiler versions, flags, list of sources, varieties of output files, additional pre- or post-processing actions, and so on.  I couldn't imagine working with anything beyond a "hello, world" without a build tool.

While writing code, and testing and debugging it, a given build might only be run a few times, and compile speed is a bit more relevant. Generally, however, most programs are run far more often, and for far longer, than their compilation time.

 Developing code is the critical bit.
 

Yes.
I might spend an hour or two writing code (including planing, organising, reading references, etc.) and then 5 seconds building it. Then there might be anything from a few minutes to a few hours testing or debugging.  How could that process be improved by a faster compile? Even for the most intense code-compile-debug cycles, building rarely takes longer than stretching my fingers or taking a mouthful of coffee.
But using a good compiler saves a substantial amount of developer time because I can write better code with a better structure, I can rely on the optimisation it does (instead of "hand-optimising" code to get the efficiency I need), and good static checking and good diagnostic messages help me fix mistakes before test and debug cycles.

Even when a test run takes a bit longer as you need to set things up, when you do need to change something and run it again, you don't want any pointless delay.
 Neither do you want to waste /your/ time pandering to a compiler's slowness by writing makefiles and defining dependencies.

That is not what "make" is for.  Speed is a convenient by-product of good project management and build tools.

Or even splitting things up into tiny modules.

Speed is not the reason people write modular, structured code.

I don't want to care about that at all. Here's my bunch of source files, just build the damn thing, and do it now!
 

You apparently don't want to care about anything much.
<snip the rest to save time>