From: janis_papanagnou+ng@hotmail.com   
      
   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.   
      
   > [...]   
   >   
   > 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. 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.   
      
   > 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.   
      
   If that's the sole task of the program the speed is not very appealing.   
   But I had not looked into the code, the algorithms implemented, or the   
   features it supports. Criticism may be justified, maybe not.   
      
   But you're creating a tool just once, and then use it arbitrary times.   
   This is as a user of the tool. So why you care so much is beyond me.   
   As a developer of the tool the used algorithms and the build process   
   is under your control.   
      
   >   
   > 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? - Or that   
   you cannot use that tool when time-traveling "back 45 years"?   
      
   >   
   > 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.   
      
   (Erm.. - so after the rant you're now agreeing?)   
      
   >   
   >> (I recall you were unfamiliar with make   
   >> files, or am I misremembering?)   
   >   
   > 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.   
      
   >   
   >>>   
   >>> 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.   
      
   Sure, you would. Obviously. - You've never been the widely accepted   
   standard source for sensible general purpose solutions, though.   
      
   >   
   > 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.   
      
   You had presented your statement as if there'd be a pressing logical   
   decision route. It is not.   
      
   >   
   > And yet here you are: you say 'certainly not'. Obviously *you* know   
   > everyone else's mindset!   
      
   No. I neither said nor implied that. (I suggest to re-read what you   
   said and what I wrote.)   
      
   >   
   >> 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.   
      
   Fair enough.   
      
   >   
   > But I'm also coming across people who seem to accept that slowness as   
   > just how things are. They should question things more!   
      
   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. Or some persistent deficiencies in   
   some GNU/Linux tools and runtime system. Or services presented per Web   
   interface.   
      
   Speed is one factor. (I said that before.)   
      
   >   
   >> 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.   
      
   This is of no doubt, I'd say.   
      
   What was arguable was the made-up _decision step_ concerning speed   
   and "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:   
      
   Yes, you're right, since I mentioned them I'm aware of them. But they   
   are not serving a clear definition of "scripting languages"; they are   
   basically just hints.   
      
   >   
   > * 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.)   
      
   > * Run from source   
      
   How about JIT, how about intermediate languages?   
      
   > * Instant edit-run cycle   
   > * Possible REPL   
      
   > * Uncluttered syntax   
      
   Have a look at the syntax of (e.g.) the Unix shell "scripting language".   
      
   > * Higher level features   
      
   Not a distinguished characteristic of scripting languages.   
      
   > * Extensive libraries so that you can quickly 'script' most tasks   
      
   Awk (for example) is a stand-alone scripting language.   
      
   >   
   > So, interactivity and spontaneity. But they also have cons:   
   >   
   > * Slower execution   
      
   Yes, but they can be rather fast (with intermediate code (GNU Awk),   
   precompiled language elements (Genie), or other means). It very much   
   depends on the languages, on "both types" of languages.   
      
   > * Little compile-time error checking   
      
   (We already commented in your above point "Dynamic typing".)   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)