Re: Baby X is bor nagain

On 27/06/2024 13:31, David Brown wrote:

On 27/06/2024 13:16, bart wrote:

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'd say that a lower level language can also benefit from fast turnaround, conveniences and friendly, informal tools. Not every C program is some mission-critical bit of software.

I'd expect that from you too.  Since you seem ignorant of these things,

You can't help being insulting and patronising, can you?

I explained them to you.  If you won't listen, or even try to think a little, then I can't help you learn.

You're also unwilling to learn. You're like someone used to driving a high-end car or even a truck, who considers a bicycle (or even a cheap car) a toy.
(The first time I was able to comfortably afford a new car, it was one of the cheapest available. It did the job of getting me from A to B perfectly well, it could do 100mph, just about, and even had room to stick my bike in the back!)

>
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.

I wanted to see the point at which a translation task turned, in your view, from a simple mechanical process, where any tool, particularly a nippy one, will do, into one involving a language where suddenly in-depth analyis and tools that are magnitudes bigger and slower become a must.

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,

I don't hate IDEs. I just don't use them. The dislike of C is not irrational: remember I tried to implement it, and my dislike of it increased; it was an even poorer design than I'd thought.
The dislike of 'make' is also rational; nearly always it makes life harder for me than if a more straightforward build option was provided.

Linux,

I don't hate Linux either. What I hate is it being foisted upon me for the wrong reasons. For example having to use Linux, or MSYS or Cygwin, because some stuff I want to build, even if supposedly cross-platform, has those dependencies.

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.

I admire quite a few languages and products. But I tend to admire simplicity, user-friendliness, lack of bloat, lack of unnecessary dependencies, elegant aesthetics, and things that 'just work'.
I do dislike brace-syntax, 0-based indexing, and case-sensitivity. Those are common characteristics.

Like most developers, I try to use the best tool for the job

Sure, you're a user, you don't get involved in devising new languages or creating tools, you have to use existed, trusted products. But you let that get in the way of your views with a low tolerance for anything different or that seems amateurish or pointless.
Over a decade ago I started looking at whole-program compilers which, if I was more into optimising, would be lend themselves easily to whole-program optimisation.
But while you will dismiss my own efforts out of hand, you do at least appreciate the benefits of 'LTO' (which I consider a third rate version of what I do, and considerably more complex).

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.

This is what I mean about you being incapable of being objective. You dissed the whole idea of tcc for everyone. Whereas what you mean is that it wouldn't benefit /you/ at all.
I can understand that: if you have a dozen slow components of some elaborate process, replacing one with a faster one would make little difference.
My view is different: I already have /half/ a dozen /fast/ components, then replacing just one with a slow product like 'gcc' makes a very noticeable difference.