Re: question about linker

On 04/12/2024 16:09, Bart wrote:

On 04/12/2024 09:02, David Brown wrote:

On 03/12/2024 19:42, Bart wrote:

 

It really /does/ matter - regardless of what the language allows or does not allow.

>
Why?

>
code the reading is important order people to.
>
Or, if you prefer,
>
Order is important to people reading the code.

 

>
The compiler spends milliseconds reading the code.  Programmers spend hours, days, or more reading the code.  It's not particularly important if the language requires a particular order or not, except in how it helps or hinders the programmer in their order of the code.

 You've lost me.
 A language source file isn't a story that needs to be consumed sequentially. It will be a collection of functions that will have some arbitrary call-pattern at runtime, perhaps different each time.
 

Nobody said the file has to be read by people sequentially - though it is usually a good idea if it makes sense that way.  (How else would you expect a new maintainer of the code to read it?)  I simply said it has to be ordered with due care and attention - a code file should not just be a random pile of functions and data.

So the static ordering is irrelevant.

Yes, apparently I /have/ lost you.

 

I've already made it clear what I think is wrong about your solution - the jumbling of namespaces.  (And /please/ don't harp on about C's system again - the fact that C does not have a good way of handling namespaces does not suddenly make /your/ version good.)
>

All it does is allow you to write F() instead of A.F(). You can do the same thing in C++ (there it saves you writing A::), by doing this (AIUI):
>
   using A;

>
(You mean "using namespace A;".  It's no problem that you don't know the right syntax for C++, but I'm correcting it in case you want to try anything on godbolt.org.)
>
Yes, C++ /allows/ you to do that - if you explicitly choose to do so for a particular namespace.  Thus if you are going to use identifiers from a namespace often, and you are confident it will not lead to conflicts, then you can do so.  C++ "using namespace A;" is commonly used in a few circumstances:

 It's used to avoid cluttering code with ugly xxx:: qualifiers, and save some typing at the same time. That's pretty much it.

Buy a better keyboard.  Saving typing is a pathetic excuse.
There's nothing wrong with having an /optional/ way to make shortcuts in the code syntax to make it easier to read - that can definitely be a good thing.  Overly long identifiers do not help readability.  But it should be opt-in - like in C++ namespaces - not jumble everything by default.  (For the same reason, C functions should have been "static" by default and required explicit "extern" indicators.)

 To that end, C++ and my language achieve the same thing.

No, you got it backwards - apparently because laziness trumps code structure and scalability in your book.

I just decided to make 'using namespace xxx' the default, and haven't got around to making it optional. (In an early version, I did need such a directive.)
 (However it most likely differs from C++ in what it calls 'namespaces'.
 My remarks have been about the namespace that is created by a module.
 I understand that C++ namespaces can be created in other ways, like classes.

In reference to C++, I have been using the term "namespaces" the way C++ specifically defines the term "namespace".  Perhaps I should have given a reference to that in some way - this is comp.lang.c, after all.
What you are now talking about is what C calls "name spaces" - with a space.  C++ does not use that term in its standards (at least, not in the C++20 standards I have open here) - it does not have a clear name for the concept, as far as I have found.  (I am not nearly as familiar with the C++ standards as I am with the C standards, so if this matters then perhaps someone else can chime in.)

I sort of have that too, but rarely use the feature:
   record foo =
      proc F = println "FOO/F" end
  end
   record bar =
      proc F = println "BAR/F" end
  end
   proc F = println "MAIN/F" end
   proc main =
      foo.F()
      bar.F()
      F()
  end
 Here, I don't need to create instances of foo and bar; they serve to encapsulate any kinds of named entities.)
 

That seems to be something akin to C++ classes or structs with static methods.  But I'm not sure, and certainly not sure how it is relevant.

 

This crashes. This program is impossible to write in my language when both modules are part of the program.

>
I'm sorry, I thought you meant if a sane C programmer wrote good code but accidentally had conflicting types.  C is not as tolerant of idiots as some languages.

 

So it's a lot more fool-proof.

 

If you are a fool, you should probably avoid programming entirely.

 Fuck you.

Did I call you a fool, or otherwise insult you?  No, I said that fools should not be programming, and programming languages and tools should not be designed to cater for fools.  A language or compiler should do its best to help spot mistakes in code, because every programmer makes mistakes sometimes - but it doesn't have to bother about people writing clearly and intentionally bad code.

Obviously you're going to shoot down whatever I say, trash whatever I have achieved, because .... I've really no idea.
 

I have been trying to stick to facts and justified opinions.  As always, I think some things in your languages are good, other things are bad. Some are simply disappointing - you had the opportunity to make something better with no regard for backwards compatibility or existing code, yet you choose not to.  Instead, you emphasised laziness and lack of structure.  Okay, it's your language and your choice, and you are the only one that might suffer from it.  Perhaps you simply don't care what anyone else might think or how future maintainers might view the code, because you know no one else will ever use it.

Yesterday you tried to give the misleading impression that compiling a substantial 200Kloc project only took 1-3 seconds with gcc.
 

No, I did not.  I said my builds of that project typically take 1-3 seconds.  I believe I was quite clear on the matter.
If I do a full, clean re-compile of the code, it takes about 12 seconds or so.  But only a fool would do that for their normal builds.  Are you such a fool?  I haven't suggested you are - it's up to you to say if that's how you normally build projects.
If I do a full, clean re-compile /sequentially/, rather than with parallel jobs, it would be perhaps 160 seconds.  But only a fool would do that.

I gave some timings that showed gcc-O0 taking 50 times longer than tcc, and 150 times longer with -O2.
 That is the real picture. Maybe your machine is faster than mine, but I doubt it is 100 times faster. (If you don't like my benchmark, then provide another in portable C.)
 All this just so you can crap all over the benefits of small, faster, simpler tools.

Your small, fast, simple tools are - as I have said countless times - utterly useless to me.  Perhaps you find them useful, but I have never known any other C programmer who would choose such tools for anything but very niche use-cases.
The real picture is that real developers can use real tools in ways that they find convenient.  If you can't do that, it's your fault.  (I don't even believe it is true that you can't do it - you actively /choose/ not to.)
And since compile speed is a non-issue for C compilers under most circumstances, compiler size is /definitely/ a non-issue, and "simplicity" in this case is just another word for "lacking useful features", there are no benefits to your tools.
If you feel these tools are useful to you, fine - use them.  Don't expect anyone else to think they are a good idea.

 I'm pretty sure tcc won't compile your projects, because your projects will be 100% dependent on the special features, extensions, and options of your prefered tools. So that is hardly surprising.
 

Of course tcc won't work - I work with embedded systems, and as I have said countless times, your little tools don't target the devices I use. I /need/ good optimisations - it's not an option, it's a requirement to get fast enough code for the end system to work.  So your toys would not be usable even if they supported the right target.  I use C++ as well as C - your toys don't support that.  I use C17 (and will move to C23 when my tools support it) - tcc supports only up to partial C99 support, and $DEITY only knows what partial C standard your compiler handles.  I use some extensions - I know tcc supports some gcc extensions, but it's unlikely to handle everything I use.  And I need additional features and tools beyond the compiler, such as specific linker scripts and setups.

But that's not a reason to dismiss it for everyone else.
 

Other people make their own choices - I don't decide for them.  They will have their own reasons for dismissing tcc.

Languages and tools should try to be accident-proof, not fool-proof.

 And yet my product IS fool-proof. So again, fuck you.
 

It's nice to see you have a clear, reasoned argument for your case.