[TUHS] Re: [TUHS]: C dialects

[TUHS] Re: [TUHS]: C dialects

[Douglas McIlroy]

> In hindsight Algol68 may have been the last committee designed
> language that was good.

The committee itself fractured over the design. Dissenters who thought
it was far too complex upped stakes and formed WG2.3, which pointedly
concentrated on program design, not language.

Doug

[TUHS] Re: [TUHS]: C dialects

[Luther Johnson]

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

I take your points. C gives a lot of freedom, but all things are not 
possible. I think what comes to mind for me is when I see the idea of 
trying to limit solutions to use only certain certain "design patterns", 
I usually would go in the direction of more freedom and less rules.

On 03/14/2023 12:48 PM, John Cowan wrote:
>
>
> On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com 
> <mailto:luther@makerlisp.com>> wrote:
>
>     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.
>
>
> ORLY?  Do you reject C, then, because it does not support 
> self-modifying code or the ability to jump into the middle of a 
> procedure without going through the prologue?  These are baked-in 
> preferences, and if a C program compiles at all, you can be sure that 
> it does neither of these things, even if it would benefit your program 
> greatly if they were available.
>
>     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.
>
>
> Since you agree that it is a matter of taste, there can of course be 
> no disputing it.


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

[TUHS] Re: [TUHS]: C dialects

[Joseph Holsten]

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

Is TUHS still the right place for this discussion?

On Tue, Mar 14, 2023, at 12:48, John Cowan wrote:
> 
> 
> On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com> wrote:
>> 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.
>> 
> 
> ORLY?  Do you reject C, then, because it does not support self-modifying code or the ability to jump into the middle of a procedure without going through the prologue?  These are baked-in preferences, and if a C program compiles at all, you can be sure that it does neither of these things, even if it would benefit your program greatly if they were available.
> 
>> 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.
> 
> Since you agree that it is a matter of taste, there can of course be no disputing it.

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

[TUHS] Re: [TUHS]: C dialects

[John Cowan]

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

On Mon, Mar 13, 2023 at 3:24 PM Luther Johnson <luther@makerlisp.com> wrote:

> 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.
>

ORLY?  Do you reject C, then, because it does not support self-modifying
code or the ability to jump into the middle of a procedure without going
through the prologue?  These are baked-in preferences, and if a C program
compiles at all, you can be sure that it does neither of these things, even
if it would benefit your program greatly if they were available.

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.
>

Since you agree that it is a matter of taste, there can of course be no
disputing it.

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

[TUHS] Re: [TUHS]: C dialects

[Luther Johnson]

[-- 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 --]

[TUHS] Re: [TUHS]: C dialects

[Luther Johnson]

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

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: 5572 bytes --]