Re: Baby X is bor nagain

On 27/06/2024 13:24, Michael S wrote:

On Thu, 27 Jun 2024 12:16:14 +0100
bart <bc@freeuk.com> wrote:
 

On 26/06/2024 13:15, Ben Bacarisse wrote:

bart <bc@freeuk.com> writes:
  

On 25/06/2024 16:12, David Brown wrote:

...

I /do/ use Python.  I use it when it is an appropriate language
to use, which is very different circumstances from when I use C
(or C++). Different tools for different tasks.

>
And yet neither of you are interested in answering my question,
which was why its simplistic bytecode compiler is acceptable in
this scenario, but would be considered useless if applied to C
code.

>
You throw out a lot of these sorts of question, by which I mean
questions that you either /do/ know the answers to or which you
/should/ know the answers to.
>
If a software engineering student asked me this sort of "challenge"
question it would immediately become homework: come up with at
least two scenarios in which a simplistic C bytecode compiler would
be an unacceptable tool to use, and two in which Python with a
trivial bytecode compiler would be an acceptable tool to use.  In
each case explain why.  Anyone who could not would get marked down
on the course.

>
>
I'm not sure what you're implying here.
>
Some here are consistently saying that any compiler whose internal
processes are not at the scale or depth that you find in
'professional', 'industrial scale' products like gcc, clang, icc, is
not worth bothering with and is basically a useless toy.
>
And yet those same people are happy that such a straightforward
compiler, which does less error-checking than Tiny C, is used within
the dynamic scripting languages they employ.
>
It just seemed to me to be blind prejudice.
>

 The difference is that in dynamically typed scripting language like
python only most blatant syntactic error can be caught during initial
compilation. The rest is caught in runtime.

Some things can be caught at runtime in dynamic code. A few of those could also be caught at runtime in C processed with a simple compiler; such tests are easier to add than to try and optimise.
But catching things are runtime isn't as useful (the program might already be at the customer site, or it might be part-way through a long-running task - or just before the end!). Testing dynamic code needs a different approach.
Yet, people still run those scripting languages, because they confer advantages. One might be an instant (or near-instant) edit-run cycle, and a simpler (ie. non-existent) build process. Yet another might be informality and tolerance.
Those in turn can lead to different ways of developing code.
Some of those benefits useful in static languages too! But they also provide extra discipline via strict typing, and much faster execution even with zero optimisation.

On the other hand, C language provides significant amount of static info
that enables quite useful compile-time analysis. A lot more of mistakes
or 'likely mistakes' can be found not just in theory, but in practice.

Yes, but even tcc will do that. Although this is not helped by the C language not requiring type errors to be treated seriously.

There are language that provide more static info than C, e.g. Ada. I
fully expect that, other thing being equal, Ada compiler would be
slower than C compiler.
 And then there exist one language that provides ALOT more static info
than C. I think, you can name it yourself, it happens to be the most
hyped programming language of our times. Not by chance, compiler for
this language is VERY slow.

Are you talking about Rust? A few years ago I did a bunch of compilation-speed benchmarks. On one test, Rustc -O would have taken an estimated 80,000 times longer to compile a program than Tiny C.
Although Rustc is getting better, it is still slow, and there is no equivalent product like tcc for that language.
Here are some notes from its docs:
* TCC compiles so fast that even for big projects Makefiles may not be necessary.
* TCC can also be used to make C scripts, i.e. pieces of C source that you run as a Perl or Python script. Compilation is so fast that your script will be as fast as if it was an executable.
* With libtcc, you can use TCC as a backend for dynamic code generation
To do that can be added when you want to distribute programs a C source on restricted hardware.
(I remember trying to build one of my one-file C programs on an RPi1. gcc would have taken from half a minute to a couple of minutes. I didn't have tcc then, but tests with my C compiler showed it could be done in a second or two; I expect tcc would have been even better.)
For me, compilation should be like turning on a light; it should just work instantly.
My own MCC product is not as good or as fast as TCC (but it produces somewhat better code). My own MM product for my language, is about as fast, and can be faster due to having proper modules. It could be used for scripting.

Somehow, I tend to agree with other posters that say that you likely
know all that quite well, but pretend to not know for sake of arguments.

I wanted other posters to say why they thought a simple compiler is OK within certain products (where its use is hidden away) but are so adamantly against it when it comes to C:
DB:
 >At no point in all this does anyone care in the slightest about the speed of your little toys or of the cute little tcc.  tcc might be ideal for the half-dozen people in the world who think C scripts are a good idea, and it had its place in a time when "live Linux" systems were booted from floppies, but that's about it.

 

They were also unwilling to answer questions about whether, given a
simpler task of translating initialisation data such as long
sequences of integer constants, or strings, they'd be willing to
entrust it to such a 'toy' compiler or even a dedicated tool. Since
here there is no analysis to be done nor any optimisation.
>
Assuming the answer is No, it must be the bigger, much slower
product, then it sounds like irrational hatred.
>

 In my practice the answer is 'No' not because of 'hatred'. The
situations like those do not happen often enough to justify hassle of
using more than one compile for the same language in the same project.

Presumably because they use such complex and long-winded build processes already that any benefit would be lost in the noise.
Not everyone uses such processes, and then the benefits are clearer.