Re: Baby X is bor nagain

On 27/06/2024 13:16, bart 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.

I would expect Ben's students to understand the difference between a low level language aimed at systems programming and high efficiency binaries, and a high-level language aimed at ease of development, convenience, and simplifying coding by avoiding manual resource management.  I would expect his students to see the difference in the languages, the different appropriate uses of the languages, and the different requirements for tools for those languages.
I'd expect that from you too.  Since you seem ignorant of these things, I explained them to you.  If you won't listen, or even try to think a little, then I can't help you learn.

 It just seemed to me to be blind prejudice.
 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.

I don't think I bothered answering that one because it is clearly a pointless question.  Again, if you don't read what I and others write, answering your questions is a waste of time.

 Assuming the answer is No, it must be the bigger, much slower product, then it sounds like irrational hatred.
 So, what would your students say?
 

Maybe if they read your posts, they would think you are projecting.  You have consistently shown an irrational hatred and blind prejudice to C, gcc, IDEs, make, Linux, and indeed every programming language that is not your own invention, every compiler that is not your own or tcc, every editor, linter, build automation system, and other software development tool, and every OS except Windows.  I don't quite know how tcc and Windows escaped your obsessive "not invented here" syndrome.
Like most developers, I try to use the best tool for the job - where "best" can depend on many factors, including convenience and familiarity.  So when I embed file data in my C and C++ projects, I use the same compiler I use for the rest of the project (which is usually, but not always, gcc).  Even if tcc supported the targets I use (which it does not), why would I bother messing around with an extra tool there? gcc does the job in a time I consider practically instant (and therefore doing it faster is no benefit).
I have no "irrational hatred" of tcc - it is simply incapable (in a great many ways) of doing the job I need from a compiler, and for the jobs it /can/ do it is in no way better than the tools I already need and have.