Path: ...!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: question about linker
Date: Fri, 6 Dec 2024 16:41:34 +0100
Organization: A noiseless patient Spider
Lines: 296
Message-ID: <viv5ve$2dqir$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vicfra$13nl4$1@dont-email.me>
 <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnp3$1ovvm$2@paganini.bofh.team> <vihpjh$2hgg1$1@dont-email.me>
 <vihrh1$2hk5l$1@dont-email.me> <vii0jp$2jkd9$1@dont-email.me>
 <viifv8$2opi7$1@dont-email.me> <vik28b$390eg$1@dont-email.me>
 <vik8tc$3ang9$1@dont-email.me> <vikjff$3dgvc$1@dont-email.me>
 <viku00$3gamg$1@dont-email.me> <vil0qc$3fqqa$3@dont-email.me>
 <vil82t$3ie9o$2@dont-email.me> <vila9j$3j4dg$1@dont-email.me>
 <vin4su$49a6$1@dont-email.me> <vin95m$5da6$1@dont-email.me>
 <vinh3h$7ppb$1@dont-email.me> <vinjf8$8jur$1@dont-email.me>
 <vip5rf$p44n$1@dont-email.me> <viprao$umjj$1@dont-email.me>
 <viqfk9$13esp$1@dont-email.me> <viqhmn$131h8$3@dont-email.me>
 <visbmp$1ks59$1@dont-email.me> <visgs7$1mgdb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 06 Dec 2024 16:41:37 +0100 (CET)
Injection-Info: dont-email.me; posting-host="93e92a81d0a7c9dde582f0456d5b8ed6";
	logging-data="2550363"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/c6+dz4MWsye0Q/om4HCRok16n58xklpI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:ojuyX+tyOLqrQlNaDJCB/+OJgEI=
Content-Language: en-GB
In-Reply-To: <visgs7$1mgdb$1@dont-email.me>
Bytes: 15519

On 05/12/2024 16:29, Bart wrote:
> On 05/12/2024 14:00, David Brown wrote:
>> On 04/12/2024 22:31, Bart wrote:
> 
>> And while you are at it, buy a better screen.  You were apparently 
>> unable to read the bit where I said that /saving typing/ is a pathetic 
>> excuse.
> 
> I can't type. It's not a bad excuse at all. I have also suffered from 
> joint problems. (In the 1980s I was sometimes typing while wearing 
> woolen gloves to lessen the impact. I haven't needed to now; maybe I've 
> slowed down, but I do take more care.)

Being unable to type, on its own, is not a good excuse - it's an 
essential skill for productive programmers.  But having joint problems 
/is/ a good excuse.  Three main ways of improving the situation would be 
getting a better keyboard (perhaps one of these with a split in the 
middle and more comfortable angles), using "stick keys" or other desktop 
tools to aid combination keys, and to use a good IDE and editor and a 
well-supported language that has structured scopes and identifiers, so 
that predictive input can significantly reduce the characters you have 
to type.  The goal of that last part is to reduce the number of 
characters you have to type, rather than the number of characters in the 
source code.

> 
>>> You said my namespaces were jumbled. They generally work as people 
>>> expect, other than some different rules on name resolution.
>>
>> No, they work as /you/ expect.  Not "people".
> 
> The concept is so simple that is not much about it for anyone to tweak.

"Simple" does not equate to "matching expectations".

> 
> A qualified name looks like this (this also applies to a single identifer):
> 
>    A.B.C
> 
> 'A' is a top-level name. It is this that the name-resolution in a 
> language needs to identify.
> 
> Presumably, in your C and C++ languages, all possible top-level names 
> must be directly visible. Only in C++ with 'using namespace' does it 
> allow a search for names not directly visible, by looking also in 
> certain places.

There are a variety of additional situations where namespaces and scopes 
are searched in C++.  Some are fairly obvious - within a class method 
definition, other class members are directly visible.  Others such as 
argument-dependent lookup involve some very complicated rules - I'd be 
surprised if anyone in comp.lang.c++ can give an accurate summary of 
them all without looking up references.  (And for your own sanity, I'd 
advise against looking them up yourself!)  Without a doubt, these would 
be tough to implement in a compiler.  But the point of them is that, as 
far as possible, name lookup "just works" for the programmer as well as 
they might reasonably expect.  "Matching expectation" and being 
convenient to the programmer in most cases is certainly /not/ simple.

> 
> This is where the rules diverge a little from what I do. Given 'CHUMMY' 
> modules X, Y, Z (which I deliberately choose), then each effectively 
> includes 'using namespace' for each of the other two modules.
> 

And that's the key flaw.  It is not what /I/ would expect, it's not what 
I think many other people would expect, and it is certainly not what I 
would want.  If I am writing module X and I want to use symbol "foo" 
from module Y, then I expect to say explicitly that I am using module Y 
(via an "import" or "include" statement), and I expect to say explicitly 
that I want "foo" from module Y (as "Y.foo", "Y::foo", "using Y", "using 
Y.foo", "from foo import Y", or whatever suits the language).

When I read a source file in any language, and I see the use of an 
identifier "foo", I want to know where that came from - I want to be 
able to find that out without doubt.  If it is written "Y.foo", then 
there is no doubt.  If I see "using Y.foo", there is no doubt - but I'd 
prefer that to be local to the function or block.  If I see "using Y", I 
know it might be from Y or it might be local to module X, but at least 
it is not in Z or some other unmentioned file.  If it is a symbol that 
is used a lot in the module, then maybe it worth a file-scope "using" 
statement of some kind - it will take more effort to figure out where it 
is from, but at least that knowledge will be re-used many times.

What you have done here is taken something that was close to being very 
useful, and turned it into something that is even worse than C - at 
least in C you have the #include lines, and because everyone knows it 
doesn't have namespaces you often get a clue from identifier names with 
prefixes.

You have snatched defeat from the jaws of victory in order to save a 
couple of lines at the start of each file - with the result that your 
language is only suitable for small single-developer programs.


> So my approach is a little more informal, and more convenient. 

"Informal" is a common theme for your language and your tools.  And 
"convenient" means convenient for you alone, not other people, and 
certainly not other people working together.  I suppose that is 
reasonable enough since you are the only one using your language and 
tools - why should you bother making something useful for people who 
will never use them?  But this is a root cause of why no one thinks your 
language or your tools would be of any use to them - and why you get so 
much backlash when you try to claim that they are better than other 
languages or tools.  Perhaps they are good for /you/, but not for anyone 
else.


> 
>>   You designed the language for one person - you.  It would be 
>> extraordinary if it did not work the way /you/ expect!
> 
> Yep. And yet, it is not some obscure, exotic monstrosity. It's not that 
> different from most others, and it's not that hard to understand.

It /is/ obscure and exotic.  That's a given for a home-made one-person 
language - regardless of any similarities with existing languages. 
(Monstrosity or not is in the eye of the beholder.)

> 
>>   That way they are influenced by lots of opinions, experiences, 
>> desires, and use-cases way beyond what any one person could ever have.
> 
> A shame it didn't work for C!

It did.

> 
>> So the way namespaces work in C++ is something that - by my rough 
>> finger-in-the-air estimates - dozens of people were involved in 
>> forming the plans, hundreds of people would have had a chance to 
>> comment and 
> 
> Yeah. Design-by-committee. Just about every feature of C++ is a dog's 
> dinner of overblown, over-complex features. C++ doesn't do 'simple'. 
> (Look at the 'byte' type for example; it's not just a name for 'u8'!)
> 

"Simple" is not a goal for a language.  It is not helpful by itself.  A 
Turing machine is one of the simplest computing systems around - no one 
would want to write code with that!

C++ has a lot of complication.  Some of it is intentional, and a lot of 
it is a by-product of backwards compatibility - new versions can't re-do 
things with a better syntax or through out old parts.  (Remember, it's a 
real language - people can't just change the language and compiler when 
they want to write something a little differently in the source code.)

And a lot of C++'s complexity is about making it easier to use for the 
majority of the code.  Complicated template structures, rvalue 
references, and all the rest make it really difficult to make a good 
"vector" class.  But they mean it is possible to make a good vector 
class that other programmers can use - and it is okay if the job is 
difficult for the library developer or other C++ expert if the result is 
that ordinary code can be relatively simple and efficient.

I have a project where I have written a library for our card, while the 
customer writes the application, all in C++.  In the library I have a 
set of template classes for use with IO pins, including multiple 
inheritance, "curiously recurring template pattern", inline variables, 
and lots of other "advanced" stuff.  This all means that the guy writing 
the application code can write "led_red.on();" in a simple, clear manner 
========== REMAINDER OF ARTICLE TRUNCATED ==========