From: bc@freeuk.com   
      
   On 29/10/2025 05:57, Janis Papanagnou wrote:   
   > On 28.10.2025 12:16, bart wrote:   
   >> 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?   
   >   
   > Are you hunting for a language war discussion? - I won't start it here.   
   > If you want, please start an appropriate topic in comp.lang.misc or so.   
      
   I'm just looking for /anything/ you don't like! Since you seem to be   
   remarkably uncritical of everything - except all the stuff I do.   
      
      
   >   
   >> [...]   
   >>   
   >> 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,   
   >   
   > We are not in these days any more.   
      
   The point of the comparison to 1000-times slower hardware is to   
   highlight how remarkably slow some modern toolsets are.   
      
   > Nowadays there's much more complex   
   > software; some inherently bad designed software, and in other cases   
   > they might not care about tweaking the last second out of a process   
   > (for various reasons). So this comparison isn't really contributing   
   > anything here.   
      
   Software might be bigger, but that is why you use LPS figures rather   
   than overall build-time.   
      
   However, I also picked on this task since it wouldn't have changed   
   signicantly over those decades.   
      
      
      
   >> So, yeah, build-time is a problem, even on the ultra-fast hardware we   
   >> have now.   
   >   
   > What problem? - That you don't want to wait a few seconds?   
      
   You KNOW compile- and build-times can be a serious bottleneck, and   
   people are looking into ways to improve that, other than throwing extra   
   hardware resources at it.   
      
   Either you haven't experienced that, or you are remarkably tolerant and   
   patient.   
      
   The actual problem I picked up on is that the build-time was out of   
   proportion to the scale of the task. In this case of a one-off build, it   
   is not that consequential. But it suggests something is wrong.   
      
   On current hardware we must surely be able to do better than 1-2K lines   
   per second, even if optimising. And I know we can because some products,   
   not just mine, can manage 500-1000 times faster.   
      
      
   >> I know makefiles. Never used them, never will.   
   >   
   > (Do what you prefer. - After all you're not cooperating with others in   
   > your personal projects, as I understood, so there's no need to "learn"   
   > [or just use!] things you don't like. If you think it's a good idea to   
   > spend time in writing own code for already solved tasks, I'm fine with   
   > that.)   
   >   
   >> You might recall that I create my own solutions.   
   >   
   > I don't recall, to be honest. But let's rather say; I'm not astonished   
   > that you have "created your own solutions". (Where other folks would   
   > just use an already existing, flexibly and simply usable, working and   
   > supported solution.) - So that's your problem not anyone else's.   
      
   Because existing solutions DIDN'T EXIST in a practical form (remember I   
   worked with 8-bit computers), or they were hopelessly slow and   
   complicated on restricted hardware.   
      
   I don't need a linker, I don't need a makefile, I don't need lists of   
   dependencies between modules, I don't need independent compilation, I   
   don't use object files.   
      
   The generated makefile for the 49-module CDECL project is 2000 lines of   
   gobbledygook; that's not really selling it to me!   
      
   If *I* had a 49-module C project, the build info I'd supply you would   
   basically be that list of files, plus the source files.   
      
   With my language, you'd need exactly two files: a self-contained   
   compiler, and a self-contained source file amalgamation. For a 600KB   
   binary, it might take as much as 0.2 seconds to build.   
      
   I consider that a more satisfactory solution that writing 2000 lines of   
   garbage. YMMV.   
      
      
      
   > I also think that there a not few people that accept inferior quality;   
   > how else could the success of, say, DOS, Windows, and off-the-shelf   
   > MS office software, be explained.   
      
   MS products are fairly solid. They are superb at backwards compatibility   
   and at compatibility across machines in general. That's why Windows apps   
   can be supplied as binaries that will work on any Windows machine.   
      
   However they tend to be absolutely huge, complicated and slow, even more   
   so than any Linux tools. (It once took 90 minutes to install VS.   
   Starting it - usually inadvertently due to file associations - took 90   
   seconds.)   
      
   >> * Dynamic typing   
   >   
   > Marcel van der Veer is advertising Genie (his Algol 68 interpreter) as   
   > a system usable for scripting. (With no dynamic but static typing.)   
      
   This product is unusual, but then it's not clear where Algol 68 lies.   
   It's a not really a static language like C, Rust, Zig, Go, Java ... but   
   it's also not as high-level as ones like Haskell or OCaml, which are   
   static or type-infered.   
      
   The first group are usually compiled but may offer interpreted options.   
   Such languages can be naturally converted to performant native code.   
      
   However A68G prioritises interpretation. While there is a   
   compile-to-native option, it's not very performant.   
      
   So overall it's a curiosity. (An interesting one because after several   
   decades, I was finally able to try out Algol68 for real. I wasn't   
   impressed, and nothing to do with its speed either.)   
      
      
      
   >> * Run from source   
   >   
   > How about JIT, how about intermediate languages?   
      
   Intermediate languages (designed for compiler backends) are irrelevant.   
   Whether they even have a textual source format is a detail.   
      
   JIT-ing used in place of AOT-compilation for static languages is   
   something new. I haven't come across examples so I don't know how it   
   comes across, or what latencies there might be.   
      
   Personally, I can run both C (single file programs ATM) and my languages   
   directly from source, with no discernible delay, via a VERY FAST AOT   
   step. But I wouldn't class them as scripting languages for other reasons.   
      
      
   >> * Little compile-time error checking   
   >   
   > (We already commented in your above point "Dynamic typing".)   
      
   There's more that could be done. Take:   
      
       F(x, y, z)   
      
   F is a function in some imported module. In most dynamic languages, the   
   import is done at runtime so the number of arguments, or if F is even a   
   function can't be checked at compile-time.   
      
   In my dynamic language, the import is done at compile-time so there's   
   more that can be checked in advance. It's less dynamic, but x, y, z can   
   still be dynamically typed.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)