• Confusing language, library and OS

    From James Harris@21:1/5 to David Brown on Mon Dec 13 18:03:22 2021
    From another thread:

    On 07/12/2021 09:57, David Brown wrote:
    On 07/12/2021 10:22, Bart wrote:

    That might be the case on Unix where where the OS and C are so
    intertwined that that you don't know where one ends and the other
    begins.

    No, /you/ don't know where one ends and the other begins

    I suspect that's true of many of us. It /is/ confusing when:

    1. the C standards documents include the standard library, not just C
    2. Clib and OS calls are invoked in the same way (flat namespace)
    3. compiler and linker are expected to /search/ for referenced files
    4. the 'OS calls' aren't really OS calls but wrappers
    5. C headers are separate from the modules they describe
    6. one C header can bundle declarations for multiple modules and one
    module may need the inclusion of multiple headers (AIUI)

    IMO that's a bit of a mess. All of those, even if I understand them
    correctly (which is far from certain), blur the boundaries between the language, the language's library/ies, and the operating system.

    In a new language all of those six problems can be fixed - and should
    be, IMO.


    --
    James Harris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to James Harris on Tue Dec 14 09:35:00 2021
    On 13/12/2021 19:03, James Harris wrote:
    From another thread:

    On 07/12/2021 09:57, David Brown wrote:
    On 07/12/2021 10:22, Bart wrote:

    That might be the case on Unix where where the OS and C are so
    intertwined that that you don't know where one ends and the other
    begins.

    No, /you/ don't know where one ends and the other begins

    I suspect that's true of many of us. It /is/ confusing when:

    1. the C standards documents include the standard library, not just C
    2. Clib and OS calls are invoked in the same way (flat namespace)
    3. compiler and linker are expected to /search/ for referenced files
    4. the 'OS calls' aren't really OS calls but wrappers
    5. C headers are separate from the modules they describe
    6. one C header can bundle declarations for multiple modules and one
    module may need the inclusion of multiple headers (AIUI)

    IMO that's a bit of a mess. All of those, even if I understand them
    correctly (which is far from certain), blur the boundaries between the language, the language's library/ies, and the operating system.

    In a new language all of those six problems can be fixed - and should
    be, IMO.



    I am not sure how much of a "problem" this all is - we've had C for
    decades, and it seems unlikely that you, me, or anyone else in this
    group is smarter than the last 40-odd years worth of programmers,
    language designers and systems architects put together.

    Without going into details of your points, since that might just start
    another long and unproductive thread, I would certainly agree that the
    single flat namespace of C is a limitation of the language. Any new
    language that aspires to be used for more than small and simple tasks
    needs hierarchical namespace handling of some sort - modules,
    namespaces, units, interfaces, whatever you want to call it and however
    you want to divide it up. And it is definitely important to think
    through the balance between flexibility and structure here - there are significant pros and cons associated with tying interface files and implementation files together tightly or loosely.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)