XPost: alt.folklore.computers
From: bowman@montana.com
On Wed, 7 Jan 2026 09:56:20 +0000, The Natural Philosopher wrote:
> On 06/01/2026 21:06, c186282 wrote:
>> On 1/6/26 05:10, The Natural Philosopher wrote:
>>> On 06/01/2026 03:27, Peter Flass wrote:
>>>> On 1/5/26 12:50, John Ames wrote:
>>>>> On Mon, 5 Jan 2026 12:33:53 -0700 Peter Flass
>>>>> wrote:
>>>>>
>>>>>> Actually, many systems programming languages have no I/O, the idea
>>>>>> being that non-OS programs call the OS to do the I/O, and the OS
>>>>>> interacts directly with the hardware.
>>>>>
>>>>> "Systems programming" usually implies implementation of an OS,
>>>>> though,
>>>>> and IIRC that was the sense that Kernighan was using. You can't
>>>>> excuse limitations by "oh, the OS handles that" when your program
>>>>> *is* the OS.*
>>>>>
>>>>> * (Obviously, there's a certain point in any HLL where Deep Magic
>>>>> has
>>>>> to handle interfacing between language constructs and bare
>>>>> metal,
>>>>> but
>>>>> the higher up the "threshold of minimum abstraction" is, the
>>>>> less suitable it is for systems programming in the first place.
>>>>> Of course, there's also the problem where seemingly *any*
>>>>> language that's not designed for systems programming will
>>>>> ultimately get pressed into service for systems programming
>>>>> *somewhere...*)
>>>>>
>>>>>
>>>> I seem to recall reading that someone once wrote an OS in COBOL.
>>>
>>> From what little I know COBOL looked very like assembler.
>>
>>
>> If assembler was RIDICULOUSLY WORDY :-)
>>
> Some assembler is...it's a choice. Especially Macro assembler...
I remember a strange attempt to do Win32 API programming in 'assembler'.
The author more or less reinvented C using MASM.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
