From: antispam@fricas.org   
      
   bart  wrote:   
   > On 27/10/2025 13:39, Janis Papanagnou wrote:   
   >> On 27.10.2025 13:50, bart wrote:   
   >>> On 27/10/2025 02:08, Janis Papanagnou wrote:   
   >>>> On 26.10.2025 12:26, bart wrote:   
   >   
   >> Speed is not an end in itself. It must be valued in comparison with   
   >> all the other often more relevant factors (that you seem to completely   
   >> miss, even when explained to you).   
   > Speed seems to be important enough that huge efforts have gone into   
   > creating the best optimising compilers over decades.   
   >   
   > Fantastically complex products like LLVM exist, which take 100 times   
   > longer to compile code than a naive compiler, in order to eke out the   
   > last bit of performance.   
   >   
   > Similarly, massive investment has gone into making dynamic languages   
   > fast, like the state-of-the-art products used in running JavaScript, or   
   > the numerous JIT approaches used to accelerate languages like Python and   
   > Ruby.   
   >   
   > Build-speed is taken seriously enough, and most 'serious' compilers are   
   > slow enough, that complex build systems exist, which use dependencies in   
   > order to avoid compilation as much as possible.   
   >   
   > Or failing that, by parallelising builds across multiple cores, possibly   
   > even across distributed machines.   
   >   
   > So, fortunately some people take this stuff more seriously than you do.   
   >   
   > I am also involved in this field, and my experimental work takes the   
   > approach of simplicity to achieve results.   
   >   
   >   
   >>   
   >> I know your goals are space and speed. And that's fine in principle   
   >> (unless you're ignoring other relevant factors).   
   >   
   > LLVM is a backend project which is massively bigger, more complex and   
   > slower (in build speed) than my stuff, by a number of magnitudes in each   
   > case.   
   >   
   > The resulting code however, might only be a fraction of a magnitude   
   > faster (for example the 0.3 vs 0.4 timings above, achieved via gcc, but   
   > LLVM would be similar).   
   >   
   > And that's if you apply the optimiser, which I would only use for   
   > production builds, or for benchmarking. Otherwise its code is just as   
   > poor as mine, or worse, but it still takes longer to build stuff!   
   >   
   > For me the trade-offs of a big, cumbersome product don't work. I like my   
   > near-zero builds and can work more spontaneously!   
   >   
   >>> It's still at least FIVE TIMES FASTER than A68G! [2-3 TIMES FASTER]   
   >>   
   >> So what? - I don't need a Lua system. So why should I care.   
   >>   
   >> You are the one who seems to think that the speed factor is the most   
   >> important factor to choose a language for a project. - You are wrong   
   >> for the general case. (But it may be right for your personal universe,   
   >> of course.)   
   >   
   > You are wrong. What language do you use most? Let's say it is C   
   > (although you usually post about every other language except C!).   
   >   
   > Then, suppose your C compiler was written in Python rather than C++ or   
   > whatever and run under CPython. What you think would happen to your   
   > build-times?   
   >   
   > 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   
   > for productivity. In reality those easy languages are far too slow in   
   > most cases.   
      
   It is not clear what you mean by "easy dynamic languages".  Take   
   Objective Caml as an example.  It has read-eval-print loop, so   
   you can do interactive developement, so it is quit "dynamic".   
   It seems that most developement is done using bytecode interpreter,   
   but there is also optimizing compiler which can boast about   
   its benchmark results.  OTOH, it has strict type system and   
   you need to stick to its rules.  So not entirely easy, but   
   if you write correct code compiler will automatically assign   
   types, so you can avoid writing any type declarations.   
   Do you consider Objective Caml as an "easy dynamic language"?   
      
   Concerning choice of language: much code is in big programs and   
   is quite expensive to rewrite such a program in a different   
   language.  So simply a lot of coding uses the same language   
   in which program is written.  It is also common to write new   
   parts in a different language, but then the new language must   
   be link compatible with the old one.  For example, classic   
   algoritmic languages like Fortran, Cobol, Algol, Pascal, C,   
   Modula 2 or Ada used to have link compatible implementations:   
   with modest effort one can call routines in one language from   
   the other.   
      
   For me correctness of programs is important and I find   
   static typing quite helpful in improving correctness.   
   First, compile time type checks catch a lot of errors   
   that would otherwise require extensive tests to catch.   
   In other words, errors are caught earlier than say with   
   dynamic typing.  Second, well defined types serve as   
   documentation of used data structures and interfaces.   
   This make my thinking about program clearer which   
   tends to reduce mistakes that I make.   
      
   A lot of folks consider types are hard things and   
   associate "easy language" with one which is dynamically   
   typed, or worse essentially untyped.   
      
   My experience with dynamically typed languages is that in   
   largish program there may be essentially nonsense code which   
   is not executed in normal operation.  But rarely it gets   
   executed leading to crashes or nonsence results.  If you have   
   small project with good developers than this is less of a   
   problem.  Also, practices like "you add tests first and can   
   only add code to fix failing test" help.  But for large   
   project with average or below average abilities and   
   requirtement of high quality code typically management want   
   all possible way to monitor and increase quality.  Which   
   frequenty means using staticaly typed language.   
      
   So, compatiblity with existing code may lead to use of   
   otherwise suboptimal language.  Quality usually is opposite   
   of "easy" and may lead to use of staticaly typed language.   
      
   OTOH, for me biggest productivity boost comes from garbage   
   collection.  But AFAIK problem of cooperation between garbage   
   collectors do not have satisfactory solution.  More precisely,   
   if memory use were not a concern, then one could simply   
   turn C 'free' into a no-op (and do similar thing in other   
   languages).  Consequently, there would be no garbage   
   collection and no problem of incompatibility between garbage   
   collectors.  But with easy style of programing, a program   
   can easiliy allocate say a gigabyte per second.  If program   
   need to run for long time one would get ridiculosly large   
   memory use.  So for short running programs one can somemtimes   
   tolerate lack of dealocation and garbage collection,   
   such program simply uses few times more memory than it should.   
   But for longer running programs you can get unbounded growth   
   of memory use, which is usually unacceptable.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)