From: bc@freeuk.com   
      
   On 29/10/2025 16:12, David Brown wrote:   
   > On 29/10/2025 00:14, bart wrote:   
   >> On 28/10/2025 21:59, Keith Thompson wrote:   
   >>> bart  writes:   
   >>>> On 28/10/2025 02:35, Janis Papanagnou wrote:   
   >>>>> On 27.10.2025 16:11, bart wrote:   
   >>> [...]   
   >>>>>> If speed wasn't an issue then we'd all be using easy dynamic   
   >>>>>> languages   
   >>>>> Huh? - Certainly not.   
   >>>>   
   >>>> *I* would! That's why I made my scripting languages as fast and   
   >>>>   capable as possible, so they could be used for more tasks.   
   >>>>   
   >>>> However, if I dare to suggest that even one other person in the world   
   >>>> might also have the same desire, you'd say that I can't possibly know   
   >>>> that.   
   >>>>   
   >>>> And yet here you are: you say 'certainly not'. Obviously *you* know   
   >>>> everyone else's mindset!   
   >>>   
   >>> I'll give this one more try.   
   >>>   
   >>> This kind of thing makes it difficult to communicate with you.   
   >>   
   >> You're talking to the wrong guy. It's JP who's difficult to talk to.   
   >>   
   >> He (I assume) always dismisses every single one of my arguments out of   
   >> hand:   
   >>   
   >> Build speed is never a problem - ever. The speed of any language   
   >> implemention is never a concern either.   
   >>   
   >   
   > Bart, I think this all comes down to some basic logic that you get wrong   
   > regularly :   
   >   
   > The opposite of "X is always true" is /not/ "X is always false" or that   
   > "(not X) is always true".  It is that "X is /sometimes/ false", or that   
   > "(not X) is /sometimes/ true".   
   >   
   > You get this wrong repeatedly when you and I are in disagreement, and I   
   > see it again and again with other people - such as with both Janis and   
   > Keith.   
   >   
   > No one, in any of the posts I have read in c.l.c. in countless years,   
   > has ever claimed that "build speed is /never/ a problem".  People have   
   > regularly said that it /often/ is not a problem, or it is not a problem   
   > in their own work, or that slow compile times can often be dealt with in   
   > various ways so that it is not a problem.  People don't disagree that   
   > build speed can be an issue - they disagree with your claims that it   
   > is /always/ an issue (except when using /your/ tools, or perhaps tcc).   
      
   It was certainly an issue here: the 'make' part of building CDECL and   
   A68G, I considered slow for the scale of the task given that the apps   
   are 68 and 78Kloc (static total of .c and .h files).   
      
   A68G I know takes 90 seconds to build (since I've just tried it again;   
   it took long enough that I had an ice-cream while waiting, so that's   
   something).   
      
   That's under 1Kloc per second; not great.   
      
   But at least all the optimising would have produced a super-fast   
   executable? Well, that's disappointing too; no-one can say that A68G is   
   fast.   
      
   I said that my equivalent product was 1000 times faster to build (don't   
   forget the configure nonsense) and it ran 10 times faster on the same test.   
      
   That is a quite remarkable difference. VERY remarkable. Only some of it   
   is due to my product being smaller (but it's not 1000 times smaller!).   
      
   This was stated to demonstrate how different my world was.   
      
   My view is that there is something very wrong with the build systems   
   everyone here uses. But I can understand that no one wants to admit that   
   they're that bad.   
      
   You find ways around it, you get inured to it, but you just have to use   
   much more powerful machines than mine, but I would go round the bend if   
   I had to work with something so unresponsive.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)