Re: Baby X is bor nagain

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. That's by design.
May be, ultra-smart compiler will be able to do a little better than
ultra-fast compiler used today, but the difference would be small.

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.

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.

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.

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.

So, what would your students say?