Invidious instances:

https://invidious.flokinet.to/watch?v=2ImfbGm0fls
https://invidious.namazso.eu/watch?v=2ImfbGm0fls
https://vid.puffyan.us/watch?v=2ImfbGm0fls
https://inv.riverside.rocks/watch?v=2ImfbGm0fls
https://invidious.weblibre.org/watch?v=2ImfbGm0fls
https://yt.artemislena.eu/watch?v=2ImfbGm0fls
https://invidious.osi.kr/watch?v=2ImfbGm0fls

And much more: https://redirect.invidious.io/watch?v=2ImfbGm0fls

Matheus.

On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
> On 4/17/2022 1:12 PM, Walter Bright wrote:
>> https://nwcpp.org/
>> 
>> An online presentation.
>> 
>> Monday at 7PM PST.
>
> Slides:
>
> https://nwcpp.org/talks/2022/modules_in_c.pdf
>
> Video:
>
> https://www.youtube.com/watch?v=2ImfbGm0fls

Here is the answer to the 2 questions you posed in your presentation:
(1) why nobody has done this in 40 years?
(2) what went on with C++ for 20 years?

It's simple.

Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.

On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:
> On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
>> On 4/17/2022 1:12 PM, Walter Bright wrote:
>>> https://nwcpp.org/
>>> 
>>> An online presentation.
>>> 
>>> Monday at 7PM PST.
>>
>> Slides:
>>
>> https://nwcpp.org/talks/2022/modules_in_c.pdf
>>
>> Video:
>>
>> https://www.youtube.com/watch?v=2ImfbGm0fls
>
> Here is the answer to the 2 questions you posed in your presentation:
> (1) why nobody has done this in 40 years?
> (2) what went on with C++ for 20 years?
>
> It's simple.
>
> Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.

I don't quite get it, did you mean the C import isn't worth the cost?

On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:
> On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
>> On 4/17/2022 1:12 PM, Walter Bright wrote:
>>> https://nwcpp.org/
>>> 
>>> An online presentation.
>>> 
>>> Monday at 7PM PST.
>>
>> Slides:
>>
>> https://nwcpp.org/talks/2022/modules_in_c.pdf
>>
>> Video:
>>
>> https://www.youtube.com/watch?v=2ImfbGm0fls
>
> Here is the answer to the 2 questions you posed in your presentation:
> (1) why nobody has done this in 40 years?
> (2) what went on with C++ for 20 years?
>
> It's simple.
>
> Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.

Stepstone did it for Objective-C with #import, and Apple with module maps for C and Objective-C, the modules design that preceeded C++ modules on clang.

Then we have those failed attempts at fixing C like SafeC.

And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it back when they were teaching in Texas university, here is the 2009 paper,

"A Principled, Complete, and Efficient Representation of C++"

https://www.stroustrup.com/gdr-bs-macis09.pdf

Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by serializing C++ code into database representation, both failed due to high hardware requirements for late 80's/early 90's PCs.

Lucid Energize Demo in 1993

https://www.youtube.com/watch?v=pQQTScuApWk

Its database system, Cadillac,

"Foundation for a C++ Programming Environment"

https://dreamsongs.com/Files/Energize.pdf

Visual Age for C++ v4,

http://www.edm2.com/0704/vacpp4/vacpp4.html

> The build environment is totally different from traditional compilers. The concept of header files and source code files is obsolete. VAC++ utilizes a global approach to definitions and implementations. That is, once a definition is processed it stays in memory for the duration of the build. To maintain compatibility, header files can still be #included. This new approach to handling source code is disorienting at first and will make migrating existing code to the compiler somewhat difficult. Errors pertaining to objects being defined more than once will likely occur while migrating. Often these errors are incorrect. The work around is to remove the #include line in the source file that contains the offending “redefinition”.

https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y#v=onepage&q&f=false

Additionally the way pre-compiled headers work on C++ Builder and Visual C++, versus the UNIX way, meant that on Windows the reward of the action did not outweigh the costs incurred, and ironically Visual C++ is the one leading the C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, and pinging back on those 2009 learnings.

On 5/29/2022 11:13 PM, Paulo Pinto wrote:
> Stepstone did it for Objective-C with #import,

Not the same as C doing the importing of C code.

> and Apple with module maps for C and Objective-C, the modules design that preceeded C++ modules on clang.
> 
> Then we have those failed attempts at fixing C like SafeC.
> 
> And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it back when they were teaching in Texas university, here is the 2009 paper,
> 
> "A Principled, Complete, and Efficient Representation of C++"
> 
> https://www.stroustrup.com/gdr-bs-macis09.pdf

Going around the horn, really doing it the hard way. Besides, writing a paper is not the same thing as implementing a working system. There were many proposals about adding modules to C, they just all went nowhere.


> Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by serializing C++ code into database representation, both failed due to high hardware requirements for late 80's/early 90's PCs.

Yee gods, doing it with a database representation is certainly going around the horn.

Note that neither D nor ImportC rely on some database or symbol table file.


> Lucid Energize Demo in 1993
> 
> https://www.youtube.com/watch?v=pQQTScuApWk
> 
> Its database system, Cadillac,
> 
> "Foundation for a C++ Programming Environment"
> 
> https://dreamsongs.com/Files/Energize.pdf
> 
> Visual Age for C++ v4,
> 
> http://www.edm2.com/0704/vacpp4/vacpp4.html
> 
>> The build environment is totally different from traditional compilers. The concept of header files and source code files is obsolete. VAC++ utilizes a global approach to definitions and implementations. That is, once a definition is processed it stays in memory for the duration of the build. To maintain compatibility, header files can still be #included. This new approach to handling source code is disorienting at first and will make migrating existing code to the compiler somewhat difficult. Errors pertaining to objects being defined more than once will likely occur while migrating. Often these errors are incorrect. The work around is to remove the #include line in the source file that contains the offending “redefinition”.
> 
> https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y#v=onepage&q&f=false 
> 
> 
> Additionally the way pre-compiled headers work on C++ Builder and Visual C++, versus the UNIX way, meant that on Windows the reward of the action did not outweigh the costs incurred, and ironically Visual C++ is the one leading the C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, and pinging back on those 2009 learnings.

Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.

On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
> On 5/29/2022 11:13 PM, Paulo Pinto wrote:
>> [...]
>
> Not the same as C doing the importing of C code.
>
>> [...]
>
> Going around the horn, really doing it the hard way. Besides, writing a paper is not the same thing as implementing a working system. There were many proposals about adding modules to C, they just all went nowhere.
>
>
>> [...]
>
> Yee gods, doing it with a database representation is certainly going around the horn.
>
> Note that neither D nor ImportC rely on some database or symbol table file.
>
>
>> [...]
>
> Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.

I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.

On 6/4/2022 5:29 AM, Paulo Pinto wrote:
> I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.

Writing a paper is not doing it first.

On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:
> On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
>> On 5/29/2022 11:13 PM, Paulo Pinto wrote:
>>
>>
>> Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.
>
> I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.

Yikes whats up with you man? You need a hug?

On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:
> On 6/4/2022 5:29 AM, Paulo Pinto wrote:
>> I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.
>
> Writing a paper is not doing it first.

That paper had a real implementation to follow along, while Lucid and IBM products were real things one could buy.

On Sunday, 5 June 2022 at 04:42:44 UTC, claptrap wrote:
> On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:
>> On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
>>> On 5/29/2022 11:13 PM, Paulo Pinto wrote:
>>>
>>>
>>> Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.
>>
>> I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.
>
> Yikes whats up with you man? You need a hug?

Nah, fed up with "D did it first, other languages keep copying us" meme.

Don't worry, I refrain myself in the future.