XPost: alt.folklore.computers
From: cross@spitfire.i.gajendra.net
In article <10jjg7k$5l5$2@dont-email.me>,
The Natural Philosopher wrote:
>On 06/01/2026 14:46, Peter Flass wrote:
>> On 1/6/26 03: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.
>>
>> Nothing at all like it. Higher-level than C, for example.
>
>Well I will simply disagree. Business transactions are very simple beasts.
I think it's best to think of COBOL as a DSL for business data
processing. Sure, one can write a compiler in it...but one can
also write a compiler in `sed`. Outside of a satisfying a dare
or winning a bet, it doesn't seem like a very good idea.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
