Re: [TUHS] v7 K&R C

[Clem Cole <clemc@ccc.com>]

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

On Thu, May 14, 2020 at 2:42 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> The essence of object-oriented programming is operator overloading.

Mumble -- I'm not so sure ...  Kay coined the term, and I've not directly
taken that away from his writings.  But maybe I missed it.

I'm a little reluctant to argue here.  I feel a little like I did when I
was arguing with my thesis advisor years ago ;_)    I so respect you
opinion and you have demonstrated to me that you are correct on so many
things.



>
> Mathematics has prospered on operator overloading, and that's why I
> wanted it.

FWIW:  That was Wulf's argument for the BLISS syntax for indirection.   It
made more sense mathematically.   The problem was that the animals were
already beyond the fields and long lost in the forest, so closing the barn
door later didn't help.  Bill later recanted, that while the idea was the
right one, in practice, he was a bad idea.




> ...
> users with poor taste are tempted to recycle the old ones for incongruous
> purposes.
>
Ah, this here is, of course, the crux of the issue.  Who shall be
the arbiters of good taste.   Doug most of the time, I agree with you and
think you have done a fantastic job of being one of those arbiters.   But
like my friend and mentor Wulf, I have to admit the ugly way we did for
years; stands.  What you bought, given what we got, seems unbalanced.

There is way too much 'bad' code and I think the overloading multiplies the
bad over the good.

>
> C++ offers more features than C and thus more ways to write obscure code.
>
It's worse than that.  The language definition is constantly peed on by the
masses.   Whereas Dennis (and Steve) took a very measured approach as to
when and how to add features to C and while it is admittedly quirky, I find
C code a lot more understandable.  To me, the features that were added to C
were ones that experience showed made sense [structs/unions/function
prototypes/void/void*].  But as Larry and I have pointed out, not all of
them did (enums).  I don't have the same warm feelings about C++.

My complaint with C++ was (is) it just 'too much'.   If Bjorne had added
classes and some of the original simpler things that his original "C with
Classes" paper had and stopped, I think I might be willing to use it
today.  But like Larry, I avoid it if at all possible.   In practice, its a
tarbaby, and little good has come of it in my world.

I applaud Rob, Ken, Brian and Russ with Go - I think thye hit on a better
medium, certainly for userspace code.  And thankfully they have not (so
far) been tempted to 'fix it' (although I have heard rumors that Russ has
things up his sleeve).  And for me, the jury is still out on Rust (Dan
Cross I admit got to me to rethink its value a bit, but I have not yet used
it for anything). And Python, which I had hoped would be a reasonable
replacement for Perl, also became a mess when people 'improved' it.




> But when it happens, blame the writer, not the tool.
>
Fair point.  I've seen some awesome BLISS code in my day.  I bet if I
looked I could find some excellent C++.   But in my experience, the signal
to noise ratio is not in favor of either.

Respectfully,
Clem

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