[TUHS] Re: [TUHS]: C dialects

[Luther Johnson <luther@makerlisp.com>]

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

I meant to say engineer "out" the necessity ...doh ! I shot myself in 
the foot there ...

On 03/13/2023 12:24 PM, Luther Johnson wrote:
>
> I agree with everything you just said here.
>
> One of the motivations behind new dialects and languages, which I 
> think is very harmful, is the idea that we can and should, engineer 
> the necessity to know and understand what we are doing when we program 
> in a given language. I'm not talking about semantic leverage, higher 
> level languages with more abstract functions on more abstract data, 
> there are real benefits there, we will all probably agree to that.
>
> I'm talking more about where the intent is to invest languages with 
> more "safety", "good practices", to bake certain preferences into 
> language features, so that writers no longer recognize these as 
> engineering choices, and the language as a means of expression of any 
> choice we might make, but that the language has built-in "the right 
> way" to do things, and if the program compiles and runs at all, then 
> it must be safe and working in certain respects.
>
> No matter what language, craft and knowledge are not optional. The 
> language that we choose for a problem domain wants to give us freedom 
> to express our choices, while taking care of the things that wold 
> otherwise weigh us down. Some people would say that's exactly what the 
> new dialects bring us, but I see too much artificial orthodoxy 
> invented last week, and too many declarations of the "one true way", 
> in many of the most recent languages, for my taste.
>
> On 03/13/2023 12:00 PM, Clem Cole wrote:
>>
>>
>> On Mon, Mar 13, 2023 at 12:00 PM Paul Winalski 
>> <paul.winalski@gmail.com <mailto:paul.winalski@gmail.com>> wrote:
>>
>>     ... Thecommittee's goal is to standardize existing practice of
>>     the language
>>     in a way that is implementable on the widest range of hardware and OS
>>     platforms, _/and to provide a controlled way to add language
>>     extensions./_
>>
>> Ah, the problem, of course, is right there.
>>
>> Too many people try to "fix" programming languages, particularly 
>> academics and folks working on a new PhD. Other folks (Gnu is the 
>> best example IMO) want to change things so the compiler writers (and 
>> it seems like the Linux kernel developers) can do something "better" 
>> or "more easily." As someone (I think Dan Cross) said, when that 
>> happens, it's no longer C. Without Dennis here to say "whoa," - the 
>> committee is a tad open loop.   Today's language is hardly the 
>> language I learned before the "White Book" existed in the early/mid 
>> 1970s.  It's actually quite sad.   I'm not so sure we are "better" off.
>>
>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they 
>> are now requiring and fall back at least to K&R2 -- keep it simple. 
>> The truth is that we still use the language today is that K&R2 C was 
>> then (and still is) good enough and got (gets) the job done extremely 
>> well.    Overall, I'm not sure all the new "features" have added all 
>> that much.
>> ᐧ
>


[-- Attachment #2: Type: text/html, Size: 6221 bytes --]