On Saturday, 23 May 2020 at 20:11:17 UTC, Dibyendu Majumdar wrote:
> On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu wrote:
>> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>>>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>>>
>>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>>> 
>>> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
>>> 
>>
>> There's no doubt in my mind that the absence of a universal "doped pointer" (pointer plus extent) built-in or standard library in C has caused innumerable problems. The fact that early C versions could not return structs by value might have contributed to that decision.
>
> A doped pointer or hidden length would not be in the spirit of C.
>
> I would agree that the standard library could have been better designed but that is a different problem.
>
> C was designed as a replacement for assembly - not another high level language.  Of course C is unsafe for general purpose programming - it wasn't designed for that. C treats memory as a blob to be manipulated - types are there to help you do that more easily but that is all they do.

BCPL as C's percusor (given B) was never intended to be a general purpose systems programming language, rather as its name implies, for Bootstraing CPL.

As many things in computing it just got misused beyond its original purpose.

C designers had 10 years of high level systems programming languages, going back to ESPOL and NEWP at Burroughs, followed by PL/I, the PL/S and PL.8 at IBM, and BLISS at VAX, to get themselves inspired, assuming access to the respective papers or publications, which a place like Bells Labs certainly would provide in some form.

On 5/23/20 11:46 AM, Timon Gehr wrote:> On 23.05.20 19:08, Andrei Alexandrescu wrote:

>> There's no doubt in my mind that the absence of a universal "doped
>> pointer" (pointer plus extent) built-in or standard library in C has
>> caused innumerable problems. The fact that early C versions could not
>> return structs by value might have contributed to that decision.
>
> I think they also considered it wasteful

I doubt it.

> because lengths would often be
> stored multiple times, for example if you have multiple arrays of the
> same length or otherwise related lengths.

It is understandable that there are cases where the cost of that length variable is measurable:

* Multiple arrays,
* Having the same length,
* and they are so short that the extra length is costly

Well, then the language has other facilities to deal with it.

Ali

On 5/23/20 4:11 PM, Dibyendu Majumdar wrote:
> On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu wrote:
>> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>>>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>>>
>>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>>>
>>> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
>>>
>>
>> There's no doubt in my mind that the absence of a universal "doped pointer" (pointer plus extent) built-in or standard library in C has caused innumerable problems. The fact that early C versions could not return structs by value might have contributed to that decision.
> 
> A doped pointer or hidden length would not be in the spirit of C.

It would be in plain sight, the point being it's associated with the pointer. Right now there's a cottage industry of analysis tools figuring out which size parameter matches which pointer parameter.

This "no fat pointers" decision cascaded into another disastruous choice - zero terminated strings. Worse than even autodecoding :o).

On 5/23/2020 2:03 AM, NaN wrote:
> There's a video on YouTube Chandler Caruth about how LLVM optimises C++, one of the interesting points he made was that const is literately zero help to the compiler for optimisation.

I discovered that myself back in the 80's. It's a huge reason why D has immutable.

On 5/23/2020 6:18 AM, Dibyendu Majumdar wrote:
>> https://www.digitalmars.com/articles/C-biggest-mistake.html
> 
> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.

The amount of buffer overflows enabled by it is legendary.

On 5/23/2020 4:50 PM, Andrei Alexandrescu wrote:
> This "no fat pointers" decision cascaded into another disastruous choice - zero terminated strings. Worse than even autodecoding :o).

Ironically, a lot of C's speed advantage is lost in endlessly scanning strings to find their length.

On 5/23/2020 7:33 AM, Chris wrote:
> Deleting criticism is certainly not the right approach and will come back to bite you.

We don't delete criticism of D. We delete rudeness towards other forum members.

We also neither edit posts nor delete parts of posts. If it contains rudeness towards others, the whole thing gets removed, along with any replies that quote it.

Therefore, if you do not want your criticisms of D deleted, do not package it with rudeness towards other forum members.

Joakim is welcome to return anytime he wants, and we've told him that.

On 5/23/2020 9:11 AM, Adam D. Ruppe wrote:
> There's really no technical reason why you can't do that now, just editing the server database.

We can indeed do that, but editing posts made by others opens up a terrible can of worms. So if any part of a post is unacceptable, we chose to delete the entire post.

On Saturday, 23 May 2020 at 23:50:55 UTC, Andrei Alexandrescu wrote:
> On 5/23/20 4:11 PM, Dibyendu Majumdar wrote:
>> On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu wrote:
>>> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>>>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>>>>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>>>>
>>>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>>>>
>>>> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
>>>>
>>>
>> A doped pointer or hidden length would not be in the spirit of C.
>
> It would be in plain sight, the point being it's associated with the pointer. Right now there's a cottage industry of analysis tools figuring out which size parameter matches which pointer parameter.
>
> This "no fat pointers" decision cascaded into another disastruous choice - zero terminated strings. Worse than even autodecoding :o).

I think it is a fallacy to think having fat pointers would solve anything. As I mentioned in my previous post in C there isn't a strong relationship between types and memory. Types are a convenience for manipulating memory - a piece of memory can be recast to any type at any time. You need a fundamentally different model - and that was already solved by Java in 1995.

http://www.stroustrup.com/1995_Java_whitepaper.pdf

In 1993 Dennis Ritchie said following about C arrays:

C's solution to this has real problems, and people who are complaining about safety definitely have a point. Nevertheless, C's approach has in fact lasted, and actually does work. ... You can't take the pure language and use it, for example, as a system programming language. It needs other things.

What's interesting is that in 2020 we still do not have a viable replacement for C. Why?

Because C's choices are necessary choices for a systems programming language.
If that wasn't the case everyone would just be writing programs in Java, C# or Go.

The real problem in my view is that people use C/C++ to write code they should not.

On Sunday, 24 May 2020 at 09:29:23 UTC, Dibyendu Majumdar wrote:
> [...]
>
> What's interesting is that in 2020 we still do not have a viable replacement for C. Why?

C++ and D(asBetterC) are viable replacements in my experience. C++
explicitly has design goals like 'Leave no room for a lower level
language' and the zero-overhead principle. These generally apply to
DasBetterC too.

Many would also argue that Rust and some newer languages like Zig fit
the bill too.