From: bc@freeuk.com   
      
   On 28/10/2025 02:35, Janis Papanagnou wrote:   
   > On 27.10.2025 16:11, bart wrote:   
      
   > That's meaningless, but if you're interested to know...   
   > Mostly (including my professional work) I've probably used C++.   
   > But also other languages, depending on either projects' requirements   
   > or, where there was a choice, what appeared to be fitting best (and   
   > "best" sadly includes also bad languages if there's no alternative).   
      
   Which bad languages are these?   
      
   > The build-times have rarely been an issue; never in private context,   
   > and in professional contexts with MLOCS of code these things have   
   > been effectively addressed.   
      
   Not really. There are the workarounds and compromises that I listed:   
   compilation is avoided as much as possible. For that you need to use   
   independent compilation, and require dependency graphs and external   
   tools to manage the process.   
      
   That CDECL took, what, 49 seconds on my machine, to process 68Kloc of C?   
   That's a whopping 1400 lines per second!   
      
   If we go back 45 years to machines that were 1000 times slower, the same   
   process would only manage 1.4 lines per second, and it would take 13   
   HOURS, to create an interactive program that explained what 'int   
   (*(*(*)))[]()' (whatever it was) might mean.   
      
   So, yeah, build-time is a problem, even on the ultra-fast hardware we   
   have now.   
      
   Bear in mind that CDECL (like every finished product you build from   
   source) is a working, debugged program. You shouldn't need to do that   
   much analysis of it. And here, its performance is not critical either:   
   you don't even need fast code from it.   
      
      
      
   (I recall you were unfamiliar with make   
   > files, or am I misremembering?)   
      
   I know makefiles. Never used them, never will. You might recall that I   
   create my own solutions.   
      
   >>   
   >> Now imagine further if the CPython interpreter was inself written and   
   >> executed with CPython.   
   >>   
   >> So, the 'speed' of a language (ie. of its typical implementation, which   
   >> also depends on the language design) does matter.   
   >>   
   >> 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!   
      
   > Speed is a topic, but as I wrote you have to put it in context   
      
   Actually, the real topic is slowness. I'm constantly coming across   
   things which I know (from half a century working with computers) are far   
   slower than they ought to be.   
      
   But I'm also coming across people who seem to accept that slowness as   
   just how things are. They should question things more!   
      
   > I can't tell about the "many" that you have in mind, and about their   
   > mindset; I'm sure you either can't tell.   
      
   I'm pretty sure there are quite a few million users of scripting languages.   
      
   >   
   > I'm using for very specific types of tasks "scripting languages" -   
   > and keep in mind that there's no clean definition of that!   
      
   They have typical characteristics as I'm quite sure you're aware. For   
   example:   
      
   * Dynamic typing   
   * Run from source   
   * Instant edit-run cycle   
   * Possible REPL   
   * Uncluttered syntax   
   * Higher level features   
   * Extensive libraries so that you can quickly 'script' most tasks   
      
   So, interactivity and spontaneity. But they also have cons:   
      
   * Slower execution   
   * Little compile-time error checking   
   * Less control (of data structures for example)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)