Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Thu, 27 Jun 2024 14:31:30 +0200
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <v5jm32$2nqvp$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad>
 <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad>
 <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad>
 <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad>
 <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me>
 <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Jun 2024 14:31:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2c137c1eaf8fb4dfcedbcabe9e9f720c";
	logging-data="2878457"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/4WssDTwT4D16DFSxKF69qY0lPauV3qLQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:wI7vivZvvbIkvy33eN8KppH1eB8=
In-Reply-To: <v5jhls$2m7np$1@dont-email.me>
Content-Language: en-GB
Bytes: 6093

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.