www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D mentioned on Rust discussions site

reply Russel Winder <russel winder.org.uk> writes:
https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-syst=
em-for-ownership-borrowing/42872


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
May 19 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:

 Programming languages evolve or die. During early stage 
 evolution there is always experimentation. This seems fine – as 
 long as the experiments do not go into a release prior to 
 completion.
The best example of this is Java. It's evolved a lot over the years, in spite of being extremely heavily used and being an enterprise programming language. The Rust leadership would do well to keep in mind that evolution is not optional. Especially for a language that has a tiny fraction of the popularity of Java (in spite of the front page of Hacker News).
May 20 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2020 8:42 AM, bachmeier wrote:
 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
 
 Programming languages evolve or die. During early stage evolution there is 
 always experimentation. This seems fine – as long as the experiments do not
go 
 into a release prior to completion.
The best example of this is Java. It's evolved a lot over the years, in spite of being extremely heavily used and being an enterprise programming language. The Rust leadership would do well to keep in mind that evolution is not optional. Especially for a language that has a tiny fraction of the popularity of Java (in spite of the front page of Hacker News).
Languages that are used over long periods of time evolve greatly after 1.0. exception.
May 20 2020
next sibling parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:
 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 

Before Ansi C came along, C lacked function prototypes and "const". I think an Ansi Standard came way later after "C version 1.0", whatever that really was.
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 12:02 AM, Araq wrote:
 On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:
 Languages that are used over long periods of time evolve greatly after 1.0. 

 exception.
Before Ansi C came along, C lacked function prototypes and "const". I think an Ansi Standard came way later after "C version 1.0", whatever that really was.
I know that well. It's a glacial change compared with what has happened in other languages. C version 1.0 would be K+R C, which was properly standardized in C89, and handful of minor improvements came with C99.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 07:40:11 UTC, Walter Bright wrote:
 On 5/21/2020 12:02 AM, Araq wrote:
 On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:
 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 

Before Ansi C came along, C lacked function prototypes and "const". I think an Ansi Standard came way later after "C version 1.0", whatever that really was.
I know that well. It's a glacial change compared with what has happened in other languages. C version 1.0 would be K+R C, which was properly standardized in C89, and handful of minor improvements came with C99.
Glacial or not, K&R C was significantly different from Ansi C, so C evolved after version 1 just like the other languages, features were added. I don't see this "notable exception". Ymmv I guess.
May 21 2020
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 21 May 2020 at 08:36:51 UTC, Araq wrote:

 improvements came with C99.
Glacial or not, K&R C was significantly different from Ansi C, so C evolved after version 1 just like the other languages, features were added. I don't see this "notable exception". Ymmv I guess.
"evolve greatly after 1.0" C has not evolved "greatly". By comparison, Java is very nearly a different language.
May 21 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 1:36 AM, Araq wrote:
 Glacial or not, K&R C was significantly different from Ansi C, so C evolved 
 after version 1 just like the other languages, features were added. I don't
see 
 this "notable exception". Ymmv I guess.
Having implemented K+R C, C89, and C99, I know how little it actually changed.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 09:49:21 UTC, Walter Bright wrote:
 On 5/21/2020 1:36 AM, Araq wrote:
 Glacial or not, K&R C was significantly different from Ansi C, 
 so C evolved after version 1 just like the other languages, 
 features were added. I don't see this "notable exception". 
 Ymmv I guess.
Having implemented K+R C, C89, and C99, I know how little it actually changed.
Having read GCC's source code with its PROTO() macro everywhere to compensate for the changes, I know how much it actually changed. ;-)
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 2:53 AM, Araq wrote:
 Having read GCC's source code with its PROTO() macro everywhere to compensate 
 for the changes, I know how much it actually changed. ;-)
Function prototyping was a welcome, but trivial, change. I know, I went through it.
May 21 2020
parent Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 20:19:47 UTC, Walter Bright wrote:
 On 5/21/2020 2:53 AM, Araq wrote:
 Having read GCC's source code with its PROTO() macro 
 everywhere to compensate for the changes, I know how much it 
 actually changed. ;-)
Function prototyping was a welcome, but trivial, change. I know, I went through it.
"trivial"? It affects every single function ever written in C. But ok, trivial. So let's compare that to the 'List' vs 'List<String>' changes for Java's introduction of generics then. Hmmmm.
May 21 2020
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:
 On 5/20/2020 8:42 AM, bachmeier wrote:
 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
 
 [...]
The best example of this is Java. It's evolved a lot over the years, in spite of being extremely heavily used and being an enterprise programming language. The Rust leadership would do well to keep in mind that evolution is not optional. Especially for a language that has a tiny fraction of the popularity of Java (in spite of the front page of Hacker News).
Languages that are used over long periods of time evolve greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal,
ANSI C89 and then C99 changed C significantly. Some of the features introduced make modern C quite different from the initial K&R C.
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 3:57 AM, Patrick Schluter wrote:
 ANSI C89 and then C99 changed C significantly. Some of the features introduced 
 make modern C quite different from the initial K&R C.
Sorry, nope. What C89 mostly did was clear up unspecified areas in K+R that had resulted in incompatible compilers. In particular, whether value-preserving or sign-preserving integral promotions were done. About half the compilers did it one way, half the other. Value-preserving rules were selected, and the out-of-luck C compiler vendors were pretty graceful in accepting the changes for the greater good. Another was clearing up confusion in how the preprocessor was supposed to work. C99 mainly cleared up a lot of uncertainty in IEEE floating point arithmetic, by stamping approval on the obvious things the C compilers were doing anyway. C99 added a couple new features, which were badly designed and remain unused - things like 'restrict' and that weird way to allocate arrays on the stack. Oh, and those miserable trigraphs, which were never used outside of test suites. Maybe you're talking about function prototyping. They were very welcome, indeed, but they didn't make C "quite different" at all. A "quite different" change would be something like adding modules, or getting rid of the preprocessor.
May 21 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:
 On 5/21/2020 3:57 AM, Patrick Schluter wrote:
 ANSI C89 and then C99 changed C significantly. Some of the 
 features introduced make modern C quite different from the 
 initial K&R C.
Sorry, nope. What C89 mostly did was clear up unspecified areas in K+R that had resulted in incompatible compilers. In particular, whether value-preserving or sign-preserving integral promotions were done. About half the compilers did it one way, half the other. Value-preserving rules were selected, and the out-of-luck C compiler vendors were pretty graceful in accepting the changes for the greater good. Another was clearing up confusion in how the preprocessor was supposed to work. C99 mainly cleared up a lot of uncertainty in IEEE floating point arithmetic, by stamping approval on the obvious things the C compilers were doing anyway. C99 added a couple new features, which were badly designed and remain unused - things like 'restrict' and that weird way to allocate arrays on the stack. Oh, and those miserable trigraphs, which were never used outside of test suites. Maybe you're talking about function prototyping. They were very welcome, indeed, but they didn't make C "quite different" at all. A "quite different" change would be something like adding modules, or getting rid of the preprocessor.
As a C user I can only witness the impact on the use of the language not on its implementation. Some of the features introduced had quite the impact in the the resulting code, but were minimal to implement as they were already C++ features like the for with variable definition, variable definition anywhere. I guarantee that if you tried to translate one of my current C code to an ancient compiler it would be a pain to get to work. Alone the preprocessor varargs would make porting to pre C99 very difficult endeavour. This said, while the changes might be more conservative than to what happened to other languages, your statement that C hasn't evolved is simply false.
May 21 2020
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:


 This said, while the changes might be more conservative than to 
 what happened to other languages, your statement that C hasn't 
 evolved is simply false.
"evolve greatly" You guys keep ignoring the adverb.
May 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Friday, 22 May 2020 at 05:45:16 UTC, Mike Parker wrote:
 On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:


 This said, while the changes might be more conservative than 
 to what happened to other languages, your statement that C 
 hasn't evolved is simply false.
"evolve greatly" You guys keep ignoring the adverb.
Because it doesn't mean anything. [x] Users had to patch every function in order to get type safety. Check. [x] Compiler writers had considerable effort in implementing the new standards. Check. [x] New features like overloading, and type system extension like 'const' or 'restrict' were added. Check. [x] New code doesn't compile with older compilers without jumping through all sort of hoops. Check. In fact, Java's backwards compatibility story looks better than C's to me.
May 22 2020
next sibling parent NaN <divide by.zero> writes:
On Friday, 22 May 2020 at 07:08:30 UTC, Araq wrote:
 On Friday, 22 May 2020 at 05:45:16 UTC, Mike Parker wrote:
 On Friday, 22 May 2020 at 05:32:52 UTC, Patrick Schluter wrote:


 This said, while the changes might be more conservative than 
 to what happened to other languages, your statement that C 
 hasn't evolved is simply false.
"evolve greatly" You guys keep ignoring the adverb.
Because it doesn't mean anything.
"C hasn't evolved" and "C hasn't evolved greatly", are absolutely two different statements. Walter even listed some changes himself, so he admits some evolution, he just doesnt view it as a great change. Which at the end of the day is a subjective call. I doubt any of you will change each others perspective on that. Walter knows what changed, he doesnt view it as a big thing, writing out a list wont change that...
May 22 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2020 12:08 AM, Araq wrote:
 [x] Users had to patch every function in order to get type safety. Check.
They didn't have to change anything. The following code compiles today on gcc: foo(i, j) { return i + j; }
 [x] Compiler writers had considerable effort in implementing the new
standards. 
 Check.
Nope. (Note that I speak from actual experience.) Want something that's hard to implement? See exception handling, which wasn't added. Ya know, I've actually implemented a K+R compiler, then upgraded it to C89, then C99. You've got a very tough hill to climb trying to tell me what is hard to implement and what isn't.
 [x] New features like overloading, and type system extension like 'const' or 
 'restrict' were added. Check.
Overloading was not added. 'const' was added, but could be ignored, and did not result in any significant coding style change. I already discussed 'restrict' which remains unused.
 [x] New code doesn't compile with older compilers without jumping through all 
 sort of hoops. Check.
That's true of any new feature, trivial or not.
May 22 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:
 On 5/22/2020 12:08 AM, Araq wrote:
 [x] Users had to patch every function in order to get type 
 safety. Check.
They didn't have to change anything. The following code compiles today on gcc: foo(i, j) { return i + j; }
It does not compile in C99. Old style declarations and implicit int are forbidden in C99.
May 23 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 9:30 AM, Patrick Schluter wrote:
 It does not compile in C99.
 Old style declarations and implicit int are forbidden in C99.
Ok, I had forgotten that. They still gave people 10 years to upgrade :-)
May 25 2020
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:
 On 5/22/2020 12:08 AM, Araq wrote:
 [x] Compiler writers had considerable effort in implementing 
 the new standards. Check.
Nope. (Note that I speak from actual experience.) Want something that's hard to implement? See exception handling, which wasn't added.
Aren't setjmp/longjmp a form of exception handling?
May 24 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/24/2020 4:17 AM, Mark wrote:
 Aren't setjmp/longjmp a form of exception handling?
Yes, but you can do it rather simply without adding the machinery of EH.
May 25 2020
prev sibling parent Araq <rumpf_a web.de> writes:
On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:
 On 5/22/2020 12:08 AM, Araq wrote:
 [x] Users had to patch every function in order to get type 
 safety. Check.
They didn't have to change anything. The following code compiles today on gcc: foo(i, j) { return i + j; }
 [x] Compiler writers had considerable effort in implementing 
 the new standards. Check.
Nope. (Note that I speak from actual experience.) Want something that's hard to implement? See exception handling, which wasn't added. Ya know, I've actually implemented a K+R compiler, then upgraded it to C89, then C99. You've got a very tough hill to climb trying to tell me what is hard to implement and what isn't.
Well your C99 implementation isn't widely used and if you were to do it properly, you would have had to review every line of code in your optimizers to see if they break the new threading model in subtle ways. I guess you didn't do that, so C is still a simple language to implement when you don't try too hard and have few if any users.
 [x] New features like overloading, and type system extension 
 like 'const' or 'restrict' were added. Check.
Overloading was not added. 'const' was added, but could be ignored, and did not result in any significant coding style change. I already discussed 'restrict' which remains unused.
Overloading was added, see the _Generic keyword in C11.
 [x] New code doesn't compile with older compilers without 
 jumping through all sort of hoops. Check.
That's true of any new feature, trivial or not.
Exactly, that's the point. C isn't special.
May 26 2020
prev sibling next sibling parent Araq <rumpf_a web.de> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:

 A "quite different" change would be something like adding 
 modules, or getting rid of the preprocessor.
Or adding a memory model to the language for parallelism/concurrency so that you need to review every line of code in your optimizer and see if it does a transformation that is now invalid... Hmmm.
May 21 2020
prev sibling parent reply Henrik <henrik nothing.com> writes:
On Thursday, 21 May 2020 at 20:34:19 UTC, Walter Bright wrote:
 C99 mainly cleared up a lot of uncertainty in IEEE floating 
 point arithmetic, by stamping approval on the obvious things 
 the C compilers were doing anyway. C99 added a couple new 
 features, which were badly designed and remain unused - things 
 like 'restrict' and that weird way to allocate arrays on the 
 stack. Oh, and those miserable trigraphs, which were never used 
 outside of test suites.
Hi Walter, do you find the ideas of the restrict keyword and VLA bad, or only the current implementation in C99? If the ideas are good, how would you have implemented them instead? I'm using the latest version of C in my work, so your answer would be interesting to see. BR, Henrik
May 22 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2020 2:22 AM, Henrik wrote:
 do you find the ideas of the restrict keyword and VLA bad, or only the current 
 implementation in C99?
I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right. VLA just sucked from beginning to end.
 If the ideas are good, how would you have implemented 
 them instead?
Restrict working requires great care on the part of the programmer to not make a mistake with it, as it is unchecked by the compiler. Which means the vast majority of users will just introduce subtle bugs when they try it. Which means no sane programmer will use it. VLA relies far too much on the vagaries of the stack implementation. Hence it's unportable and unreliable. 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 C89's adoption of function prototypes was a home run, but note I said adoption, not invention. They were invented by C++, and C compiler vendors (like mine) added them to C, and the committee just stamped its approval on it. C has resisted anything else that hails from C++.
May 22 2020
next sibling parent reply NaN <divide by.zero> writes:
On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
 On 5/22/2020 2:22 AM, Henrik wrote:
 do you find the ideas of the restrict keyword and VLA bad, or 
 only the current implementation in C99?
I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right.
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. He also said that inlining is the single most important optimisation.
May 23 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 23 May 2020 at 09:03:38 UTC, NaN wrote:
 On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
 On 5/22/2020 2:22 AM, Henrik wrote:
 do you find the ideas of the restrict keyword and VLA bad, or 
 only the current implementation in C99?
I've done some experiments with restrict in gcc, examined the generated code, and found the optimizations it does and does not do baffling. I wonder if perhaps it is used so little that nobody really bothered to get the semantics right.
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. He also said that inlining is the single most important optimisation.
He's right about const. As for inlining LLVM loves inlining. It's not always the right choice. The reason why it's deemed important is because it allows the optimizer to effectively see across function boundaries (since merging the function bodies removes that.) And it can specialize the callee code for the callers requirements. However that can also lead to problems with code-size and therefore i-cache stalls, (the worst kind of stalls). that said, I-caches are pretty large these days to support out-of-order execution. So maybe that's less of a problem running on modern cpus. On an embedded device you'll want to disable the inliner through (which is what -Os or Oz) does.
May 23 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:

 Restrict working requires great care on the part of the 
 programmer to not make a mistake with it, as it is unchecked by 
 the compiler. Which means the vast majority of users will just 
 introduce subtle bugs when they try it. Which means no sane 
 programmer will use it.
Dennis Ritchie wrote a paper on why 'noalias' precursor to 'restrict' was an 'abomination'. http://www.lysator.liu.se/c/dmr-on-noalias.html
 VLA relies far too much on the vagaries of the stack 
 implementation. Hence it's unportable and unreliable.

 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. https://www.lysator.liu.se/c/bwk-on-pascal.html I for one am glad that C is stable and not being constantly tweaked. In part this is why it is so successful.
May 23 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 23 May 2020 at 13:18:38 UTC, Dibyendu Majumdar 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.
Yeah, because it is so hard to type: int *ptr = &my_array[0] // instead of int *ptr = my_array; I guess the benefit is that C developers don't get RSI for their pointer and arrays handling code.
 https://www.lysator.liu.se/c/bwk-on-pascal.html
Most of those issues were sorted out by the mid-80's, also PL/I dialects, BLISS, Ada and Modula-2 don't suffer from them. Ironically, NEWP, a systems programming language 10 years older than C, still exists and Unisys uses its security features as means to sell ClearPath MCP against UNIX based OSes for goverment level security. Whereas those that still use C get what they deserve, https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://mybuild.microsoft.com/sessions/f22a612d-0030-4e55-b389-2da0f99b8839 "Microsoft's Safe Systems Programming Languages Effort" https://mybuild.microsoft.com/sessions/61de34c5-b111-4ece-928f-541854875862 And guess what Google is doing starting with Android 11,
 Platform hardening - We’ve expanded use of compiler-based 
 sanitizers in security-critical components, including BoundSan, 
 IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap 
 pointer tagging for apps targeting Android 11 or higher, to 
 help apps catch memory issues in production. These hardening 
 improvements may surface more repeatable/reproducible app 
 crashes in your code, so please test your apps. We've used 
 HWAsan to find and fix many memory errors in the system, and we 
 now offer HWAsan-enabled system images to help you find such 
 issues in your apps.
https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.HTML Which is just catchin up with what iOS, Solaris SPARC and Azure Sphere are already doing. So is the trust on C developer's capabilites to actually write memory corruption free code.
May 23 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. https://www.lysator.liu.se/c/bwk-on-pascal.html
The article does not support the argument. The article (section 2.1) discusses statically-sized arrays only, and the problem is that the size is part of the type; however, that's the case in C as well, as it should. 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.
May 23 2020
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 23.05.20 19:08, 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. https://www.lysator.liu.se/c/bwk-on-pascal.html
The article does not support the argument. The article (section 2.1) discusses statically-sized arrays only, and the problem is that the size is part of the type; however, that's the case in C as well, as it should. 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 because lengths would often be stored multiple times, for example if you have multiple arrays of the same length or otherwise related lengths. Fixed-size arrays where the length is part of the type can actually work well, the type system just has to be a little less naive. This is what I do in my research programming languages. For example, the following merge sort code uses fixed-size arrays, where the sizes are run-time values: def merge[a:*](less: a×a→𝔹)[n:ℕ,m:ℕ](xs: a^n, ys: a^m): a^(n+m){ (i, j) := (0, 0); r := []: a[]; while i<n ∧ j<m{ if less(xs[i], ys[j]){ r ~= [xs[i]]; i += 1; }else{ r ~= [ys[j]]; j += 1; } } return r ~ xs[i..n] ~ ys[j..m] coerce a^(n+m); } def sort[a:*](less: a×a→𝔹)[n:ℕ](xs: a^n): a^n{ if n<=1{ return xs; } rec := sort(less); return merge(less)(rec(xs[0..n div 2]), rec(xs[n div 2..n])); }
May 23 2020
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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.
May 23 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
May 23 2020
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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).
May 23 2020
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 23 2020
prev sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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 The real problem in my view is that people use C/C++ to write code they should not.
May 24 2020
next sibling parent reply Les De Ridder <les lesderid.net> writes:
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.
May 24 2020
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
 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.
Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
May 24 2020
next sibling parent reply The Holy Drinker <the holy.drinker> writes:
On Sunday, 24 May 2020 at 11:08:42 UTC, Dibyendu Majumdar wrote:
 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
 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.
Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
I haven't used it, but here's an OS written in Rust, https://www.redox-os.org/. Zig will probably be used to write one, too. I wish I could say the same for D, but the former two languages have mind-share, and developers are enthused by them.
May 24 2020
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 24 May 2020 at 16:05:38 UTC, The Holy Drinker wrote:
 I haven't used it, but here's an OS written in Rust, 
 https://www.redox-os.org/. Zig will probably be used to write 
 one, too. I wish I could say the same for D, but the former two 
 languages have mind-share, and developers are enthused by them.
There is a kernel written in D: https://github.com/PowerNex/PowerNex
May 24 2020
parent reply The Holy Drinker <the holy.drinker> writes:
On Sunday, 24 May 2020 at 17:49:02 UTC, Meta wrote:
 On Sunday, 24 May 2020 at 16:05:38 UTC, The Holy Drinker wrote:
 I haven't used it, but here's an OS written in Rust, 
 https://www.redox-os.org/. Zig will probably be used to write 
 one, too. I wish I could say the same for D, but the former 
 two languages have mind-share, and developers are enthused by 
 them.
There is a kernel written in D: https://github.com/PowerNex/PowerNex
Yes, but it's nowhere near where redox is at, and I doubt it ever will be in such a place. Plus, Rust is much younger than D, and it already has an OS that's actively developed and fairly along. Such is life.
May 24 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 24 May 2020 at 23:22:42 UTC, The Holy Drinker wrote:
 Yes, but it's nowhere near where redox is at, and I doubt it 
 ever will be in such a place. Plus, Rust is much younger than 
 D, and it already has an OS that's actively developed and 
 fairly along. Such is life.
I think the powernex thing started off as a fork of one of my little toys I was doing 2012ish - D is quite excellent for the task, was back then and even better now - but the task is also basically a waste of time. It is something you do because you have time to kill so it favors the young.
May 24 2020
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:
 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
 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.
Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable. Let's do it the other way: What proof there is for the claim that those languages cannot be used for writing OSes? I know D enough to know that it can be used to manage a CPU, send electrical signals to all the I/O devices around it, etc. Ali
May 25 2020
next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:
 On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:
 
 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but in 
 the doing.
It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable.
Of course that would be silly. My assumption is that someone will write an OS in one of these languages because of security concerns. I think Google is looking at using Rust in Fuchsia. Fuchsia is interesting because the kernel was initially in C, but now I believe mostly it is in C++ to gain additional type safety. https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md
 Let's do it the other way: What proof there is for the claim 
 that those languages cannot be used for writing OSes? I know D 
 enough to know that it can be used to manage a CPU, send 
 electrical signals to all the I/O devices around it, etc.
Well there are several things to consider. First is memory safety - I believe the only way to write OS in D or Rust is to use unsafe constructs in parts. Arguably this can be done in C++ too - mostly use smart pointers for example, and make restricted use of unsafe code. Secondly a real world OS that is used can tell us if truly the resulting OS was more secure than say Linux which is written in C. Right now there are theoretical claims that the OS will be more secure. In case of Rust there is an additional question - can development scale? Rust is particularly hard programming language in my view. Writing simple linked list or tree structure is not a trivial task in Rust. So can it scale to thousands of developers? Finally performance impact of safe code. One of the reasons why folks use unsafe practices is that it is most performant. I am not suggesting that D cannot be used to write an OS, but it remains to be seen whether an OS written in D or Rust is actually more secure in the real world.
May 25 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:
 On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:
 On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:
 
 Well the jury is still out on these. Until we see a real OS 
 written in Rust or D or Zig - he proof is not in claims but 
 in the doing.
It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable.
Of course that would be silly. My assumption is that someone will write an OS in one of these languages because of security concerns. I think Google is looking at using Rust in Fuchsia. Fuchsia is interesting because the kernel was initially in C, but now I believe mostly it is in C++ to gain additional type safety. https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md
 Let's do it the other way: What proof there is for the claim 
 that those languages cannot be used for writing OSes? I know D 
 enough to know that it can be used to manage a CPU, send 
 electrical signals to all the I/O devices around it, etc.
Well there are several things to consider. First is memory safety - I believe the only way to write OS in D or Rust is to use unsafe constructs in parts. Arguably this can be done in C++ too - mostly use smart pointers for example, and make restricted use of unsafe code. Secondly a real world OS that is used can tell us if truly the resulting OS was more secure than say Linux which is written in C. Right now there are theoretical claims that the OS will be more secure.
That one is easy, IBM i and IBM z/OS are written in a mix of Assembly and PL/S. Modern versions now also include C++, but it wasn't there during their first 20 years. Unisys ClearCase MCP, written in NEWP, an almost safe systems programming language, 10 years older than C, the OS doesn't do Assembly, all CPU low level features are exposed as compiler intrisics. Was one of the first OSes to introduce the concept of unsafe code already during the 60's, any executable or library with unsafe code is tainted and requires admin being signed off by the admin for execution. Unisys still keeps it around and sells it to governments and business that need three letter agency security level access for data processing. Common to all of them, C is only used on the POSIX containers.
May 25 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:
 First is memory safety - I believe the only way to write OS in 
 D or Rust is to use unsafe constructs in parts. Arguably this 
 can be done in C++ too - mostly use smart pointers for example, 
 and make restricted use of unsafe code.
Memory management in OS development is special and differs a lot from writing normal applications. In C++, you usually don't use STL at all because it is usually configured for some other operating system and will not compile at all. Just including std::shared_ptr will include a lot of other things and compilation will fail. Second, there are hidden allocations in the STL containers and you don't want those when writing operating systems. With operating systems you want to control every allocation in order to minimize memory use and fragmentation. Linux is full of "smart pointers" ie. reference counting but they are done manually. Same would be in C++, reference counting is done manually. You want to minimize the increase/decrease of counters in such environment, something you might not care that much about in applications. There are other things that you avoid in C++, like std::function that has hidden allocations. Operating systems developers usually make a special library that is tailored for such development. Also forget about exceptions and RTTI. Right now C++ seems to be the best fit for operating system development. Extra safety like bounds checking in D is a good thing but the full feature set of C++ still out-competes D as you have to use betterC. The memory safety in for example Rust is just in the way when writing operating systems. You have to resort to so many tricks outside the safe language that it is more or less useless. Also Rust is a highly annoying language when it comes many classical data structures. D is in a middle spot here but lacks features like full polymorphism in betterC which still makes C++ a better choice.
May 25 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 13:04:42 UTC, IGotD- wrote:
 On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:
 First is memory safety - I believe the only way to write OS in 
 D or Rust is to use unsafe constructs in parts. Arguably this 
 can be done in C++ too - mostly use smart pointers for 
 example, and make restricted use of unsafe code.
Memory management in OS development is special and differs a lot from writing normal applications. In C++, you usually don't use STL at all because it is usually configured for some other operating system and will not compile at all. Just including std::shared_ptr will include a lot of other things and compilation will fail. Second, there are hidden allocations in the STL containers and you don't want those when writing operating systems. With operating systems you want to control every allocation in order to minimize memory use and fragmentation. Linux is full of "smart pointers" ie. reference counting but they are done manually. Same would be in C++, reference counting is done manually. You want to minimize the increase/decrease of counters in such environment, something you might not care that much about in applications. There are other things that you avoid in C++, like std::function that has hidden allocations. Operating systems developers usually make a special library that is tailored for such development. Also forget about exceptions and RTTI. Right now C++ seems to be the best fit for operating system development. Extra safety like bounds checking in D is a good thing but the full feature set of C++ still out-competes D as you have to use betterC. The memory safety in for example Rust is just in the way when writing operating systems. You have to resort to so many tricks outside the safe language that it is more or less useless. Also Rust is a highly annoying language when it comes many classical data structures. D is in a middle spot here but lacks features like full polymorphism in betterC which still makes C++ a better choice.
Apparently people writing high integrity kernels in languages like Ada/SPARK don't find bounds checking a nuisance. Which by the way, also applies to C and C++ written kernels via static analysis tooling validation like MISRA and AUTOSAR.
May 25 2020
parent reply welkam <wwwelkam gmail.com> writes:
On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:
 Apparently people writing high integrity kernels in languages 
 like Ada/SPARK don't find bounds checking a nuisance.
I looked at generated assembler if boundscheck=off did something and found that in few places that I looked it did nothing. Most array accesses happen in a foreach loop and compiler is smart enough to remove those checks. I haven't done thorough investigation but my guess is that array bounds checks are left in places where you should have checks even if you wrote that code in C.
May 25 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 May 2020 at 20:30:51 UTC, welkam wrote:
 On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:
 Apparently people writing high integrity kernels in languages 
 like Ada/SPARK don't find bounds checking a nuisance.
I looked at generated assembler if boundscheck=off did something and found that in few places that I looked it did nothing. Most array accesses happen in a foreach loop and compiler is smart enough to remove those checks. I haven't done thorough investigation but my guess is that array bounds checks are left in places where you should have checks even if you wrote that code in C.
Indeed, bounds checking elision has been a thing for ages in everything else other than C / C++ / Objective-C, and mostly when it doesn't work, it is considered a compiler bug that needs to be eventually fixed.
May 25 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 4:33 AM, Dibyendu Majumdar wrote:
 First is memory safety - I believe the only way to write OS in D or Rust is to 
 use unsafe constructs in parts.
Rust is heavily reliant on unsafe library modules to get key things done. D relies on that, too (hence safe and system code), but Rust's more restrictive model needs more of it. live will, too.
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:48 AM, Ali Çehreli wrote:
 It would be wasteful to write an OS to prove the claims. Unless there is a 
 technical impossibility, then it's doable.
 
 Let's do it the other way: What proof there is for the claim that those 
 languages cannot be used for writing OSes? I know D enough to know that it can 
 be used to manage a CPU, send electrical signals to all the I/O devices around 
 it, etc.
I've written embedded systems with no operating system, and drivers for operating systems. There's no technical reason why DasBetterC can't be used for this. In fact, it would shine at it.
May 25 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P T -- The early bird gets the worm. Moral: ewww...
May 25 2020
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/25/20 3:20 PM, H. S. Teoh wrote:
 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P T
Walter said he noticed the same thing a few days before his DConf 2018 presentation in Munich. :) Ali
May 25 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/25/20 6:20 PM, H. S. Teoh wrote:
 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P
I assumed that was the joke all along!
May 25 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 5:11 PM, Andrei Alexandrescu wrote:
 On 5/25/20 6:20 PM, H. S. Teoh wrote:
 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P
I assumed that was the joke all along!
I couldn't have come up with a better pun in 50 years. This one was quite by fortuitous accident.
May 25 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 3:20 PM, H. S. Teoh wrote:
 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P
It is. It came about because I actually wrote "D as Better C" and did a double take!
May 25 2020
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 25 May 2020 at 22:20:04 UTC, H. S. Teoh wrote:
 On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via 
 Digitalmars-d wrote: [...]
 DasBetterC
[...] Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P T
Yes the very first time I read it, I read it as Das Better C. It should come with a blinkenlights module.
May 26 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 24 May 2020 at 11:08:42 UTC, Dibyendu Majumdar wrote:
 On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
 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.
Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
The improvements that Microsoft has been doing to .NET out of their Midori and .NET Native experience, alongside their recent announcement at BUILD 2020 for first class support for Rust on Windows, alongside Amazon, Oracle, Apple and Google's ongoing adoption on their OS and cloud platforms, kind of prove the point for me. I occasionally still come over here due to the community, and less so about D.
May 25 2020
prev sibling parent ag0aep6g <anonymous example.com> writes:
On 24.05.20 11:29, Dibyendu Majumdar wrote:
 Types are a convenience for manipulating memory - a piece of memory can 
 be recast to any type at any time.
That's not true with strict aliasing.
May 24 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 23 2020
prev sibling parent mw <mingwu gmail.com> writes:
On Wednesday, 20 May 2020 at 21:30:16 UTC, Walter Bright wrote:
 Languages that are used over long periods of time evolve 
 greatly after 1.0. Fortran, Basic, C++, Java, Perl, Pascal, 

Speaking of language evolution, when D can get string interpolation in? it's great help in debug print. https://forum.dlang.org/post/jtlogapmndsezrjvylaw forum.dlang.org
May 21 2020
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:

 Who wants to use an "ongoing experiment" to write real world 
 software? That's to invite disaster. And worse than an 
 "experiment" that might have a sound scientific basis, D keeps 
 adding stuff at whim because others have it too, like 
 children. I wonder why D hasn't gained the traction its users 
 think it should have. Hm. There's a lot more to programming 
 and PLs than fancy ideas. A certain rigidity and 
 straight-lacedness is often the result of a lot of (creative) 
 thinking and experimentation that takes place before a PL 
 reaches 1.0 - not afterwards.
Programming languages evolve or die. During early stage evolution there is always experimentation. This seems fine – as long as the experiments do not go into a release prior to completion.
Evolve yes. And yes, Java was too conservative for too long until Kotlin came along. But there's a difference between a language evolving when there's a need to evolve (changes in hardware, networking, big data, new platforms or even changes in programming culture (you know, the whole lot), and the erratic addition of the latest fancy features, i.e. when the language becomes a playground for hackers and nerds, forever chaotic and immature. Mike Parker Finally, dear Mike Parker, since you have deleted my original reply to Russel, may I ask you to delete any answer that quotes my answer, else your censorship looks a bit inconsistent. But consistency is apparently not held in highly regarded here anyway, given your statement from the 19 October 2019: "I also don't want to be deleting negative posts just because they're negative. Then we get into the business of deleting replies that quote them, and maybe even losing some actual useful signal in all the noise." Here's the full statement: https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org If it wasn't you, Mike, who took down my answer, please remind that person of your statement on Forum Moderation. Anyway, as soon as people have to revert to censorship (it's not the first time here either) they have something to hide. Greatness speaks for itself.
May 20 2020
next sibling parent Just Another D Programmer <ja d.p> writes:
On Wednesday, 20 May 2020 at 17:49:49 UTC, Chris wrote:
 "I also don't want to be deleting negative posts just because 
 they're negative. Then we get into the business of deleting 
 replies that quote them, and maybe even losing some actual 
 useful signal in all the noise."

 Here's the full statement: 
 https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org

 If it wasn't you, Mike, who took down my answer, please remind 
 that person of your statement on Forum Moderation.

 Anyway, as soon as people have to revert to censorship (it's 
 not the first time here either) they have something to hide. 
 Greatness speaks for itself.
I didn't catch the entirety of your reply, but I am able to read what Russel quoted. From those excerpts, I think the negativity wasn't the issue but your superfluously rude phrasing--something with which you seemingly have an issue. This is, of course, merely my opinion, and Mike can speak for himself.
May 20 2020
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
20.05.2020 20:49, Chris пишет:
 On Wednesday, 20 May 2020 at 14:14:05 UTC, Russel Winder wrote:
  
 Evolve yes. And yes, Java was too conservative for too long until Kotlin 
 came along. But there's a difference between a language evolving when 
 there's a need to evolve (changes in hardware, networking, big data, new 
 platforms or even changes in programming culture (you know, the whole 
 lot), and the erratic addition of the latest fancy features, i.e. when 
 the language becomes a playground for hackers and nerds, forever chaotic 
 and immature.
 
  Mike Parker
 Finally, dear Mike Parker, since you have deleted my original reply to 
 Russel, may I ask you to delete any answer that quotes my answer, else 
 your censorship looks a bit inconsistent. But consistency is apparently 
 not held in highly regarded here anyway, given your statement from the 
 19 October 2019:
 
 "I also don't want to be deleting negative posts just because they're 
 negative. Then we get into the business of deleting replies that quote 
 them, and maybe even losing some actual useful signal in all the noise."
 
 Here's the full statement: 
 https://forum.dlang.org/post/vqfhwstyyozrsxegquxe forum.dlang.org
 
 If it wasn't you, Mike, who took down my answer, please remind that 
 person of your statement on Forum Moderation.
 
 Anyway, as soon as people have to revert to censorship (it's not the 
 first time here either) they have something to hide. Greatness speaks 
 for itself.
I do not like the censorship but the last your posts I've seen are negative plus do not contain useful information for community. If you disappointed in D that is a normal thing, just go ahead, take another PL and leave us. Please, do not repeat to us that you think we were/are wrong. But if you want to return - welcome back!
May 20 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2020 10:49 AM, Chris wrote:
 Finally, dear Mike Parker, since you have deleted my original reply to Russel, 
 may I ask you to delete any answer that quotes my answer, else your censorship 
 looks a bit inconsistent. But consistency is apparently not held in highly 
 regarded here anyway, given your statement from the 19 October 2019:
That post can be justifiably removed for unprofessional demeanor in belittling others. Continue doing so, and they'll be removed, too. Mike has my full support and his decisions are final.
May 20 2020
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 20 May 2020 at 21:26:40 UTC, Walter Bright wrote:
 On 5/20/2020 10:49 AM, Chris wrote:
 Finally, dear Mike Parker, since you have deleted my original 
 reply to Russel, may I ask you to delete any answer that 
 quotes my answer, else your censorship looks a bit 
 inconsistent. But consistency is apparently not held in highly 
 regarded here anyway, given your statement from the 19 October 
 2019:
That post can be justifiably removed for unprofessional demeanor in belittling others. Continue doing so, and they'll be removed, too. Mike has my full support and his decisions are final.
First of all, thanks Mike Parker for also deleting Russel's answer that contained my original answer (I still wonder how that could escape you). It looks a lot better now, more consistent. Well done. Second, Walter, I've noticed that the word "unprofessional" has become a blanket term for anything the D leadership doesn't like / want to hear. In my opinion, D has become a political enterprise. Thirdly, is there an update of the companies that use D? How many really use it, do the companies listed still use D (what about sociomantic?) and what do they use it for? Facebook is listed, I remember Andrei did some stuff (including a script like program), are they still using it actively?
May 22 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 22 May 2020 at 15:27:13 UTC, Chris wrote:

Just in case, I'd like to have an answer to this:

Is there an update of the companies that use D? How many really 
use it, do the companies listed still use D (what about 
sociomantic?) and what do they use it for? Facebook is listed, I 
remember Andrei did some stuff (including a script like program), 
are they still using it actively?
May 22 2020
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/22/20 8:28 AM, Chris wrote:> On Friday, 22 May 2020 at 15:27:13 
UTC, Chris wrote:
 Just in case, I'd like to have an answer to this:

 Is there an update of the companies that use D? How many really use it,
 do the companies listed still use D (what about sociomantic?) and what
 do they use it for? Facebook is listed, I remember Andrei did some stuff
 (including a script like program), are they still using it actively?
Unless the users are as excited as I am to present at conferences how they benefit from D, nobody can answer those questions. Open source does not work that way. Even if one asked Sociomantic or Facebook, they are not obliged to give answers. Ali
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 09:00:03 UTC, Ali Çehreli wrote:

 Unless the users are as excited as I am to present at 
 conferences how they benefit from D, nobody can answer those 
 questions. Open source does not work that way. Even if one 
 asked Sociomantic or Facebook, they are not obliged to give 
 answers.

 Ali
Fair enough, but I think it would make sense to contact those companies. I'm sure Facebook would be willing to give you an answer like "We are still using it actively." However, if you list Facebook on your homepage and _if_ it's only because Andrei once wrote some stuff (because he actually worked there), that looks a bit weird, exaggerated, not optimal. Imagine somebody finds out that your claims are inflated, they might get very angry. By the way, you're probably one of the people to ask this question. Are there annual financial reports of the D Language Foundation? How the money was spent etc.?
May 25 2020
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 22 May 2020 at 15:27:13 UTC, Chris wrote:

 First of all, thanks Mike Parker for also deleting Russel's 
 answer that contained my original answer (I still wonder how 
 that could escape you). It looks a lot better now, more 
 consistent. Well done.
Either I completely overlooked it or Russel uses a newsreader and had already downloaded the post before I deleted it but replied after. Our policy is to delete posts that quote deleted posts.
 Second, Walter, I've noticed that the word "unprofessional" has 
 become a blanket term for anything the D leadership doesn't 
 like / want to hear. In my opinion, D has become a political 
 enterprise.
I have to disagree with this. Forum moderation is not censorship and there's nothing political behind it. I deleted your post not because of the opinion you expressed, but because of the manner in which you expressed it. You have a habit of insulting the people who put their time and energy into this project. Your posts have in the past derailed and disrupted otherwise civil discussions. I would not have deleted your post if you had not included that insult, or it if were a one-off. But for you, it's a pattern. And I will delete any future posts if you can't refrain from insulting people. You can be critical and civil at the same time. Please try to do so going forward.
May 22 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/22/2020 8:27 AM, Chris wrote:
 Second, Walter, I've noticed that the word "unprofessional" has become a
blanket 
 term for anything the D leadership doesn't like / want to hear. In my opinion,
D 
 has become a political enterprise.
Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.
May 22 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 02:59:18 UTC, Walter Bright wrote:
 On 5/22/2020 8:27 AM, Chris wrote:
 Second, Walter, I've noticed that the word "unprofessional" 
 has become a blanket term for anything the D leadership 
 doesn't like / want to hear. In my opinion, D has become a 
 political enterprise.
Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.
It'd help if the moderator also explained why a post was deleted (instead of using a blanket term like "unprofessional" which is in itself unprofessional), else it looks quite random. I think Joakim left over what he perceived as double standards in forum moderation. (Was it really worth to lose a contributor like Joakim over this?) In the old days there was practically no moderation and D wasn't the worse for it. I wonder what changed that made the leadership adopt a stricter stance on moderation. It doesn't reflect well on the D Foundation when comments by certain people (like myself) are scrutinized and deleted while some outright rude comments, attacks and even false accusations are not. May I remind you that it was the leadership that started to treat users in a rude manner. You, Walter, answered evasively and went on to twist my words so I looked like an unreasonable fool. (One user noticed this and pointed it out to you.) This gave me the impression that you were looking down your nose at us. It hasn't escaped my attention either how Manu has been treated here (DIPs). Maybe you should ponder on this a little. Last but not least, I think there's a growing feeling in the community that D should be rewritten as D3. Steven Schveighofer wrote a post about it. I don't understand why on earth D is not rewritten in a clean and sound manner. Take what really works, the great features that D undoubtedly has, get rid of half-baked features and all the baggage like audodecoding etc. Implement a proper ecosystem right from the start (this is of utmost importance). Why not make D great again? Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?
May 23 2020
next sibling parent reply Tony <tonytdominguez aol.com> writes:
On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:
 On Saturday, 23 May 2020 at 02:59:18 UTC, Walter Bright wrote:
 On 5/22/2020 8:27 AM, Chris wrote:>> Second, Walter, I've 
 noticed that the word "unprofessional"
 [...]
Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.
It'd help if the moderator also explained why a post was deleted (instead of using a blanket term like "unprofessional" which is in itself unprofessional), else it looks quite random. I think Joakim left over what he perceived as double standards in forum moderation. (Was it really worth to lose a contributor like Joakim over this?) In the old days there was practically no moderation and D wasn't the worse for it. I wonder what changed that made the leadership adopt a stricter stance on moderation. It doesn't reflect well on the D Foundation when comments by certain people (like myself) are scrutinized and deleted while some outright rude comments, attacks and even false accusations are not. May I remind you that it was the leadership that started to treat users in a rude manner. You, Walter, answered evasively and went on to twist my words so I looked like an unreasonable fool. (One user noticed this and pointed it out to you.) This gave me the impression that you were looking down your nose at us. It hasn't escaped my attention either how Manu has been treated here (DIPs). Maybe you should ponder on this a little. Last but not least, I think there's a growing feeling in the community that D should be rewritten as D3. Steven Schveighofer wrote a post about it. I don't understand why on earth D is not rewritten in a clean and sound manner. Take what really works, the great features that D undoubtedly has, get rid of half-baked features and all the baggage like audodecoding etc. Implement a proper ecosystem right from the start (this is of utmost importance). Why not make D great again? Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?
Joakim kept arguing in an increasingly petulant manner that the D conference should be canceled. He appeared to think that he had proven that it should be canceled and would not consider any notion that if enough people want to go to it, it should be held. I would guess he left because he couldn’t get his way. I can see why you are very concerned about forum moderation as you don’t appear to use D and seem to visit the forum to solely to get perverse pleasure from degrading the language and those who work on it.
May 23 2020
next sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 15:18:51 UTC, Tony wrote:
 Joakim kept arguing in an increasingly petulant manner that the 
 D conference should be canceled. He appeared to think that he 
 had proven that it should be canceled and would not consider 
 any notion that if enough people want to go to it, it should be 
 held. I would guess he left because he couldn’t get his way.
"petulant", interesting.
 I can see why you are very concerned about forum moderation as 
 you don’t appear to use D and seem to visit the forum to solely 
 to get perverse pleasure from degrading the language and those 
 who work on it.
Well, this shows you the flexible standards that are applied here. Your comment is unprofessional, it belittles others and makes assumptions about other people's motives. Very well, I'm not a snowflake, but in the name of consistency may I ask Mike Parker to remove Tony's comment. It fulfills the criteria that make a comment eligible for deletion according to Mike Parker's and Walter Bright's own definition. Anything else would be inconsistent and reek of double standards (and people will notice it sooner or later).
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/23/2020 8:18 AM, Tony wrote:
 seem to visit the forum to solely to get perverse pleasure from 
 degrading the language and those who work on it.
We expect professional decorum at all times toward all forum members.
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:57:47 UTC, Walter Bright wrote:
 On 5/23/2020 8:18 AM, Tony wrote:
 seem to visit the forum to solely to get perverse pleasure 
 from degrading the language and those who work on it.
We expect professional decorum at all times toward all forum members.
Then please delete his post [1] just as you deleted others that you deemed "unprofessional", for consistency's and credibility's sake. Else it looks like two standards are being applied, one to critics of D (deletion), others to its proponents/defenders (slap on the wrist). [1] https://forum.dlang.org/post/dnvcsbzrzeboxucmejdm forum.dlang.org
May 26 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:

 Deleting criticism is certainly not the right approach and will 
 come back to bite you. Sometimes it's easier to just do the 
 dishes than to come up with ever new excuses why you can't do 
 the dishes. Why not write a new clean version of D?
Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.
May 23 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:
 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:

 Deleting criticism is certainly not the right approach and 
 will come back to bite you. Sometimes it's easier to just do 
 the dishes than to come up with ever new excuses why you can't 
 do the dishes. Why not write a new clean version of D?
Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.
And I should add that if we weren't using a web interface to a newsgroup server, we would most likely have better moderation tools. We'd be able to edit posts. But all we can do is delete them.
May 23 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 23 May 2020 at 16:03:13 UTC, Mike Parker wrote:
 And I should add that if we weren't using a web interface to a 
 newsgroup server, we would most likely have better moderation 
 tools. We'd be able to edit posts. But all we can do is delete 
 them.
There's really no technical reason why you can't do that now, just editing the server database. People with a local copy will still see the old one, of course, but that's just like how mailing list users like me don't see any deletion actions either.
May 23 2020
next sibling parent Johnny <jo h.nny> writes:
On Saturday, 23 May 2020 at 16:11:30 UTC, Adam D. Ruppe wrote:
 There's really no technical reason why you can't do that now, 
 just editing the server database.

 People with a local copy will still see the old one, of course, 
 but that's just like how mailing list users like me don't see 
 any deletion actions either.
Yeah, mod logs and notifications of mod actions are all possible, but like everything, someone needs to step up and implement them.
May 23 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 23 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:
 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:

 Deleting criticism is certainly not the right approach and 
 will come back to bite you. Sometimes it's easier to just do 
 the dishes than to come up with ever new excuses why you can't 
 do the dishes. Why not write a new clean version of D?
Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.
90%? Where's the proof? You shouldn't make exact statements like that based on an estimate.
May 25 2020
parent NaN <divide by.zero> writes:
On Monday, 25 May 2020 at 08:25:30 UTC, Chris wrote:
 On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:
 On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:

 Deleting criticism is certainly not the right approach and 
 will come back to bite you. Sometimes it's easier to just do 
 the dishes than to come up with ever new excuses why you 
 can't do the dishes. Why not write a new clean version of D?
Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.
90%? Where's the proof? You shouldn't make exact statements like that based on an estimate.
Dont feed the troll.
May 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 23 2020
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:
 Joakim is welcome to return anytime he wants, and we've told 
 him that.
So you forgive him? Great!
May 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:28 AM, Chris wrote:
 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:
 Joakim is welcome to return anytime he wants, and we've told him that.
So you forgive him? Great!
We didn't ask him to leave. We only required that he conform to the forum rules. Anyone is welcome here if they comport themselves in a professional manner.
May 25 2020
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:47:36 UTC, Walter Bright wrote:
 On 5/25/2020 1:28 AM, Chris wrote:
 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:
 Joakim is welcome to return anytime he wants, and we've told 
 him that.
So you forgive him? Great!
We didn't ask him to leave. We only required that he conform to the forum rules. Anyone is welcome here if they comport themselves in a professional manner.
That's not the point. The point was that you treated him in a way that made him lose faith in D and its leadership. There was stonewalling and censorship which sounds familiar to me. My point was that by treating him in this way, you lost a contributor to and a proponent of D. Was it really worth it? I get the impression that you don't really regret it, so somehow you must think it was worth it, for what reason, I don't know.
May 26 2020
next sibling parent NaN <divide by.zero> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:
 On Monday, 25 May 2020 at 20:47:36 UTC, Walter Bright wrote:
 On 5/25/2020 1:28 AM, Chris wrote:
 On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:
Dont feed the troll.
May 26 2020
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:
 On Monday, 25 May 2020 at 20:47:36 That's not the point. The 
 point was that you treated him in a way that made him lose 
 faith in D and its leadership. There was stonewalling and 
 censorship which sounds familiar to me.
Walter deleted one of Joakim's posts (and the subsequent thread) for a gratuitous insult. Joakim claimed his post was deleted for criticizing DConf, despite the fact that all of hos other posts criticizing DConf were still online. He and I had an email discussion about this and he refused to accrpt it. It's unfortunate that some people can't understand the difference between modrration and censorship, but if they insist on that position there's nothiing we can do about it. Now, if you wish to discuss this topic further, please start a new thread. It's gone way off topic for this thread.
May 26 2020
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 26 May 2020 at 11:21:51 UTC, Chris wrote:
 That's not the point. The point was that you treated him in a 
 way that made him lose faith in D and its leadership. There was 
 stonewalling and censorship which sounds familiar to me. My 
 point was that by treating him in this way, you lost a 
 contributor to and a proponent of D. Was it really worth it? I 
 get the impression that you don't really regret it, so somehow 
 you must think it was worth it, for what reason, I don't know.
Hm, what the point is, then? The first thought is that in your opinion is that the languge maintainers should more clearly admit some mistakes you think they have made. But that can't be everything. If you were simply fed up with the langauge and it's leadership, you would just leave. There are thousands of screwed up projects at the Internet, and they are simply abandoned. What is it that is holding you here arguing for the sinking ship (as that is what D is judging by your posts)?
May 26 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 23 May 2020 at 02:59:18 UTC, Walter Bright wrote:
 On 5/22/2020 8:27 AM, Chris wrote:
 Second, Walter, I've noticed that the word "unprofessional" 
 has become a blanket term for anything the D leadership 
 doesn't like / want to hear. In my opinion, D has become a 
 political enterprise.
Belittling other members and/or impugning their motives, is unprofessional behavior. It's not hard to understand.
May I ask you to remove this comment then: https://forum.dlang.org/post/dnvcsbzrzeboxucmejdm forum.dlang.org Secondly, again you do not answer a single question or address any of the issues raised. This pattern stared to emerge around 2017 I think. Instead of addressing issues raised the manner in which they are raised is more important. So an inconvenient comment / question is either labelled as "unprofessional" or "unspecific". In this way you don't need to address the issue. Hm, politicians do that when they have no substantial arguments, engineers shouldn't behave like that. So once again: 1. Is the list of companies that use D up to date? What is D mainly used for or is it still being used actively? E.g. Facebook, do they still use it? 2. Will there be some sort of D3 that incorporates all the great features and drops the dead weight? It would actually be a good monument of your life's work.
May 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/25/2020 1:23 AM, Chris wrote:
 Secondly, again you do not answer a single question or address any of the
issues 
 raised. This pattern stared to emerge around 2017 I think. Instead of
addressing 
 issues raised the manner in which they are raised is more important. So an 
 inconvenient comment / question is either labelled as "unprofessional" or 
 "unspecific". In this way you don't need to address the issue. Hm, politicians 
 do that when they have no substantial arguments, engineers shouldn't behave
like 
 that. So once again:
You're not getting a response as long as you keep asking questions in a rude manner.
May 25 2020
parent Chris <wendlec tcd.ie> writes:
On Monday, 25 May 2020 at 20:53:46 UTC, Walter Bright wrote:
 On 5/25/2020 1:23 AM, Chris wrote:
 Secondly, again you do not answer a single question or address 
 any of the issues raised. This pattern stared to emerge around 
 2017 I think. Instead of addressing issues raised the manner 
 in which they are raised is more important. So an inconvenient 
 comment / question is either labelled as "unprofessional" or 
 "unspecific". In this way you don't need to address the issue. 
 Hm, politicians do that when they have no substantial 
 arguments, engineers shouldn't behave like that. So once again:
You're not getting a response as long as you keep asking questions in a rude manner.
How exactly were the questions asked in a "rude" manner? Anyway, here they are again: 1. Is there an update of the companies that (still) use D (cf. sociomantic)? 2. Is Facebook still actively developing software in D? 3. Are there plans for a D3 that will contain all / most of the good features and drop the dead weight / errors? 4. Are there annual financial statements of the D Language Foundation that can be accessed by the public/users/community?
May 26 2020
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 20.05.20 16:14, Russel Winder wrote:
 On Wed, 2020-05-20 at 10:07 +0000, Chris via Digitalmars-d wrote:
 On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
 https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-ownership-borrowing/42872
[gheli] "It is inspired by Rust's borrow checker, but it fails in comparison to it. It provides very little guarantees and does not prioritize safety. It is being adding (IMO) simply as a PR stunt as the current implementation stands." > One of the Rust illuminati complained about this comment, asking
people to
 respect others' work. The point was well made and seems to have attracted a
 lot of support.
 
It is a bit weird that anyone would sign up for the Rust forums for the sole purpose of making a non-PC comment about D. :) The reaction to the above comment was predictable but I don't think it was necessary. ZiCog's subsequent comment was just as dismissive but it was phrased using nice words so he did not get a wrist slap. Basically it's just a translation of the comment to PC speak. "I prefer to think of it this way." Personally I prefer the atmosphere of the D forums -- generally respectful and professional, but being respectful is not subordinate to being able to make technical points, passionate debate is allowed and you don't have to spend time deciphering criticism that is disguised as a compliment or wondering whether your point has been taken.
May 20 2020
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-05-20 at 22:10 +0200, Timon Gehr via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Personally I prefer the atmosphere of the D forums -- generally=20
 respectful and professional, but being respectful is not subordinate to=
=20
 being able to make technical points, passionate debate is allowed and=20
 you don't have to spend time deciphering criticism that is disguised as=
=20
 a compliment or wondering whether your point has been taken.
The Rust forum is generally very good, very positive, even when discussing crufty bits of Rust =E2=80=93 of which there are many, just like any other = programming language. The posts being dissected in this thread here is very unusual and hence the interjection of the Rust illuminati to stop the disrespectful negative vibes. I think that D got a mention in the Rust forum is overall very good. It's j= ust sad the person used disrespectful tones. It happens in all language specifi= c milieu though, due I would suggest to tribalism, to try and protect the les= s confident members from a potential threat to the tribe's canon. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
May 21 2020
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 21 May 2020 at 09:09:27 UTC, Russel Winder wrote:
 The Rust forum is generally very good, very positive, even when 
 discussing crufty bits of Rust – of which there are many, just 
 like any other programming language. The posts being dissected 
 in this thread here is very unusual and hence the interjection 
 of the Rust illuminati to stop the disrespectful negative vibes.

 I think that D got a mention in the Rust forum is overall very 
 good. It's just sad the person used disrespectful tones. It 
 happens in all language specific milieu though, due I would 
 suggest to tribalism, to try and protect the less confident 
 members from a potential threat to the tribe's canon.
I think you missed Timons point. He talked about the reaction to the dismissive comments, not dismissive comments themselves. Here, I have never seen a moderator to drop in as quickly as he did in Rust forums. I think Timon meant that he prefers our higher tolerance of negativity. And I agree with him.
May 21 2020
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 20 May 2020 at 20:10:27 UTC, Timon Gehr wrote:
 Personally I prefer the atmosphere of the D forums -- generally 
 respectful and professional, but being respectful is not 
 subordinate to being able to make technical points, passionate 
 debate is allowed and you don't have to spend time deciphering 
 criticism that is disguised as a compliment or wondering 
 whether your point has been taken.
I've never seen folks on the Rust forums shy away from detailed debate of technical points. I do get that it's not nice to feel there are people looking over your shoulder policing your tone, but in general, all the rules come down to is "don't be a [TECHNICAL TERM]". Which isn't _that_ hard, and is something we all ought to aim for. At the end of the day we're in a lucky position, because our community is smaller and closer-knit, that we can get away without much moderation. Rust's forum rules are an inevitable consequence of growth, and to a degree some of their growth may have been made easier because they pro-actively enforced standards of community behaviour from early on.
May 21 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 21.05.20 14:14, Joseph Rushton Wakeling wrote:
 On Wednesday, 20 May 2020 at 20:10:27 UTC, Timon Gehr wrote:
 Personally I prefer the atmosphere of the D forums -- generally 
 respectful and professional, but being respectful is not subordinate 
 to being able to make technical points, passionate debate is allowed 
 and you don't have to spend time deciphering criticism that is 
 disguised as a compliment or wondering whether your point has been taken.
I've never seen folks on the Rust forums shy away from detailed debate of technical points. ...
My expectation would be that technical points are ignored or deleted if someone feels they are are phrased the wrong way. I might be wrong, but currently I have no desire to post on the Rust forums as it does not appear to be welcoming to all perspectives.
 I do get that it's not nice to feel there are people looking over your 
 shoulder policing your tone, but in general, all the rules come down to 
 is "don't be a [TECHNICAL TERM]".  Which isn't _that_ hard, and is 
 something we all ought to aim for.
There is a difference between a rule being something to strive for and being something that makes sense to enforce formally, especially based on a very vague formalization that everyone agrees with (but nobody agrees with anyone else on what it means). Arguably, the moderator is being a [TECHNICAL TERM]. I think it's ridiculous to reprimand someone for calling a change log entry a "PR stunt", especially if you are not even interested enough in the subject matter to have an opinion on whether it's true or not and therefore add nothing of substance to the topic at hand. I doubt that this opinion would be welcome on the Rust forums.
 At the end of the day we're in a lucky position, because our community 
 is smaller and closer-knit, that we can get away without much 
 moderation.
I.e., we respect each other more, therefore we don't get offended so easily.
 Rust's forum rules are an inevitable consequence of growth, 
 and to a degree some of their growth may have been made easier because 
 they pro-actively enforced standards of community behaviour from early on.
The enforcement is necessarily superficial, inconsistent, biased and will tend to be overzealous. Anyway, I don't claim my opinion on this is universal or shared by the majority. It's possible that this is a contributor to Rust's popularity. Maybe upvoting generic moderation comments feels nice to some people. (It's the comment with the largest number of hearts in the thread even though it is essentially without merit and completely off-topic.)
May 21 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:

 Maybe upvoting generic moderation comments feels nice to some 
 people. (It's the comment with the largest number of hearts in 
 the thread even though it is essentially without merit and 
 completely off-topic.)
Well it's easy to agree with. Without having to look for sources of information. Or having to go through the trouble of validating them.
May 21 2020
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:
 My expectation would be that technical points are ignored or 
 deleted if someone feels they are are phrased the wrong way.
Is that based on actual experience of this happening? Best not to assume without evidence.
 I might be wrong, but currently I have no desire to post on the 
 Rust forums as it does not appear to be welcoming to all 
 perspectives.
It's worth pointing out that their forum FAQ explicitly discourages responding to a post's tone rather than to its content. Which does rather suggest that actually they want people to _overlook_ phrasing and focus on the technical points.
 There is a difference between a rule being something to strive 
 for and being something that makes sense to enforce formally, 
 especially based on a very vague formalization that everyone 
 agrees with (but nobody agrees with anyone else on what it 
 means).
Where's the formal enforcement in this case? Unless I missed something, a moderator merely offered advice as to how to achieve a more constructive discussion.
 At the end of the day we're in a lucky position, because our 
 community is smaller and closer-knit, that we can get away 
 without much moderation.
I.e., we respect each other more, therefore we don't get offended so easily.
Rather, that we _know_ each other better, and so are less likely to misinterpret each other or assume bad faith. People seem to get offended here reasonably often, even so :-)
 The enforcement is necessarily superficial, inconsistent, 
 biased and will tend to be overzealous. Anyway, I don't claim 
 my opinion on this is universal or shared by the majority. It's 
 possible that this is a contributor to Rust's popularity. Maybe 
 upvoting generic moderation comments feels nice to some people. 
 (It's the comment with the largest number of hearts in the 
 thread even though it is essentially without merit and 
 completely off-topic.)
I'm not sure I see what was superficial, inconsistent, or biased about this particular intervention: unsubstantiated accusations of bad faith are generally toxic to good discussion and I don't see the problem in reminding people of that. Odds are that would happen in this community too, it's just more likely to be a regular member of the community that does the reminding, rather than someone with formal moderator responsibilities. No community scales without having some measure of enforcement of expected standards of behaviour. And while I might not necessarily draw the line where the Rust forums do, it doesn't seem like a particularly egregious line, all things considered, to step in to remind people to be constructive, assume good faith, and keep on topic.
May 21 2020
parent welkam <wwwelkam gmail.com> writes:
On Thursday, 21 May 2020 at 20:10:06 UTC, Joseph Rushton Wakeling 
wrote:
 unsubstantiated accusations of bad faith are generally toxic to 
 good discussion
This reminded me of this. Watch it until ~14 min for relevant part. https://youtu.be/soYkEqDp760?t=621 I think we all have seen here how one person with one comment just derails the conversation and we get increased hostility towards each other. Because of this I think moderation is a necessary evil but it requires great wisdom to draw lines correctly.
May 21 2020
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:
 My expectation would be that technical points are ignored or 
 deleted if someone feels they are are phrased the wrong way. I 
 might be wrong, but currently I have no desire to post on the 
 Rust forums as it does not appear to be welcoming to all 
 perspectives.
FWIW I do feel that the mods are being a tad heavy-handed in trying to push people to not widen the discussion to broader language comparisons. I might feel differently if there were more people actually discussing the OB feature in-depth, but in such a short thread, with so few participants, it seems unnecessarily intrusive. Still, it remains advice only so far. If I get a ban or a timeout I may feel obliged to invite you to say "I told you so" ... :-)
May 22 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 22.05.20 15:29, Joseph Rushton Wakeling wrote:
 On Thursday, 21 May 2020 at 15:58:58 UTC, Timon Gehr wrote:
 My expectation would be that technical points are ignored or deleted 
 if someone feels they are are phrased the wrong way. I might be wrong, 
 but currently I have no desire to post on the Rust forums as it does 
 not appear to be welcoming to all perspectives.
FWIW I do feel that the mods are being a tad heavy-handed in trying to push people to not widen the discussion to broader language comparisons.  I might feel differently if there were more people actually discussing the OB feature in-depth, but in such a short thread, with so few participants, it seems unnecessarily intrusive. Still, it remains advice only so far.  If I get a ban or a timeout I may feel obliged to invite you to say "I told you so" ... :-)
Which is why they don't want to do that and instead prefer if you comply based on the latent threat of it happening. :P Also, the tone is getting more stern, arguably getting close to or crossing the line of what they would consider acceptable for participants in the actual discussion. Fewer hearts now, too.
May 22 2020
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 22 May 2020 at 15:48:04 UTC, Timon Gehr wrote:
 Which is why they don't want to do that and instead prefer if 
 you comply based on the latent threat of it happening. :P
Yes. Which is partly why I took the decision to tweak the dragon's tail by arguing that our "off-topic" was actually relevant :-P
 Also, the tone is getting more stern, arguably getting close to 
 or crossing the line of what they would consider acceptable for 
 participants in the actual discussion. Fewer hearts now, too.
Indeed.
May 23 2020
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
 https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-ownership-borrowing/42872
There is a technical question I'd like to ask here. One of the participants in that thread posted what I considered to be a rather contrived example where `malloc`, `free`, and casts from pointer to value types and back (!) were combined to produce a use-after-free effect. Of course it's trivial to find ways to get the compiler to catch the casts as unsafe. But in trying this out I settled on a much simpler formulation that still doesn't get caught as a violation of ` live` rules: ``` live int* test1() { import core.stdc.stdlib : free, malloc; import std.stdio : writefln; scope p = cast(int*) malloc(int.sizeof); free(p); writefln!"%d"(*p); return p; } ``` Now, I'm not making any judgement here -- this is a provisional feature with many limitations, that is clearly intended as a first step to something bigger, and which is clearly advertised as having a _lot_ of bugs right now. But I would like to understand, for my own sake, why the above example is not detecting that it's invalid to dereference `p` for the `writeln`, or indeed to return `p` from the function. (Tried with a freshly built dmd 2.092.0.)
May 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2020 2:26 PM, Joseph Rushton Wakeling wrote:
 (Tried with a freshly built dmd 2.092.0.)
Because it's a bug I fixed fairly recently. Not sure if it's been pulled yet. Anyhow, my version of dmd produces: live int* test1() { import core.stdc.stdlib : free, malloc; import core.stdc.stdio; scope p = cast(int*) malloc(int.sizeof); free(p); printf("%d\n",*p); // variable `p` has undefined state and cannot be read return p; // variable `p` has undefined state and cannot be read // variable `p` is returned but is Undefined } The error messages aren't the greatest, but they are accurate.
May 21 2020
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 22 May 2020 at 02:04:19 UTC, Walter Bright wrote:
 Because it's a bug I fixed fairly recently.
Ah, all good then. So just wait for 2.092.1? :-)
May 22 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
 https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-ownership-borrowing/42872
Again, what are we supposed discuss in this thread? Make it a rule that OP must be clear what we are supposed to discuss. Posting a link isn't enough, there should be some kind of text that explains what OP to discuss or a question to be answered. Doing this and there is a less chance that the thread derails.
May 22 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 22.05.20 17:58, IGotD- wrote:
 On Tuesday, 19 May 2020 at 11:38:48 UTC, Russel Winder wrote:
 https://users.rust-lang.org/t/dlang-adds-a-borrowchecker-called-the-ob-system-for-owner
hip-borrowing/42872 
Again, what are we supposed discuss in this thread? Make it a rule that OP must be clear what we are supposed to discuss. Posting a link isn't enough, there should be some kind of text that explains what OP to discuss or a question to be answered. Doing this and there is a less chance that the thread derails.
There does not have to be a rail.
May 22 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, May 23, 2020 at 09:05:47PM -0700, Walter Bright via Digitalmars-d wrote:
 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 Sat, May 23, 2020 at 09:15:18PM -0700, Walter Bright via Digitalmars-d wrote:
 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.
Hear, hear. Having worked for the past 25 years in the industry primarily with C code, I have to say that the amount of C code with hidden potential buffer overflows is staggering. In spite of a big push in the past 10 or so years towards safer C coding practices, I still regularly come across code that have potential buffer overflows hidden deep within a large codebase, and code being freshly written that *still* depend on unfounded assumptions about array length -- because manually passing the length is just too cumbersome, and people either don't bother with it, or make mistakes while doing it (nothing like passing the wrong length to screw up your day -- esp. when it gets missed by QA and proceeds to explode in the customer's production environment -- or worse, it *doesn't* get noticed by the customer until a hacker decides to exploit it). Not to mention the gigantic pain in writing said code in C in the first place -- you constantly have to be burning mental calories trying to keep track of which pointer goes with which length, making sure to manually check bounds, making sure to think thrice about your loop to prevent overruns, endless calls to strlen() without even thinking about the performance consequences. I'm serious, I work with a huge codebase of almost 2 million LOC, and strlen calls are everywhere, including inside macros that nobody really takes the time to understand but just sprinkle everywhere in their code. The complexity of managing all of this is just beyond any normal person's capacity given the tight deadlines we have to meet, so people just call strlen willy-nilly without even thinking about the performance consequences. And of course, the huge bulk of code that expects null-terminated strings means it's just not worth trying to encapsulate the length in any sort of way -- you make yourself incompatible with just about everything else, and end up spending endless effort converting to/from char* instead, which is not any better. So the problem perpetuates itself, and becomes an accumulated cost that nobody can feasibly improve without rewriting the entire darned thing from ground up. (And even then, all it takes is for *someone* to start using char* again, and suddenly you're back to square one. No sane C coder uses anything *but* char* for strings in "normal" C code. Esp. code that needs to talk to other C libraries not written by your team. It's inextricably ingrained in C culture.) And strlen isn't even the end of it; because of manual memory management, everyone defensively strdup's every darned string that they intend to keep, because there's just no other sane way of ensuring the pointer won't get invalidated later (and no guarantee, thanks to default mutability, that someone won't change the contents of the string down the line and screw up the assumptions in your code). So in addition to strlen, your average typical C code is plagued with endless calls to strdup or equivalent, even for simple things like taking substrings. Some people complain about D strings being immutable(char)[], but I tell you, encapsulated in that seemingly-trivial construct is a ton of experience-backed insight about string management in C-like programming paradigms that's worth careful study. People like bashing D because of the GC, but nobody talks about how *not* needing to call strlen() or strdup() endlessly is such a performance booster, not to mention it makes your code a LOT simpler and your APIs a lot cleaner to work with. Considering just how much work has been poured into mitigating the horrible consequences of "no fat pointers" and null-terminated strings -- think about how much effort has been poured into dealing with buffer overflow bugs over the past 10 years: entire cottage industries have grown up around developing tools for detecting and fixing these sorts of things, and who knows how much money poured into cleaning up the consequences of the countless security exploits enabled by said buffer overflows -- the laughable "benefits" of saving a couple of bytes by using only lean pointers hardly measures up to anything less than a colossal design mistake in retrospect. If you can even call them "benefits": think of all the costly workarounds people have had to put up with: everyone inventing their own way of passing array length instead of having a standardized API, and inevitably doing it poorly / with costly slip-ups, and the memory cost of needing to invent, store, and manage data structures needed to manage all of this -- I surmise this in itself already counteracts any meager savings one may have gained by avoiding fat pointers. (Just think: in any persistent struct that carries pointers to arrays: you're already paying for the cost of a fat pointer because you need to store the length somehow anyway, except everyone invents their own way of doing this so you're essentially already paying for fat pointers but with none of the benefits of having a standardized fat pointer type that's been tested to do it correctly: you run the risk of human error at every turn.) D arrays being fat pointers is a HUGE step at getting rid of the nonsensical churn C's array-pointers lead to. And immutable(char)[] is a huge saver in terms of performance. The two taken together is one of D's strengths. T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
May 23 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
You should write this up and post it on Reddit / Hackernews!
May 24 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 24, 2020 at 06:02:53PM -0700, Walter Bright via Digitalmars-d wrote:
 You should write this up and post it on Reddit / Hackernews!
Feel free to copy-n-paste it, you have my full permission. I'm done with Reddit and have no interest in investing in another timesink like Hackernews. I have too much on my hands and not enough time to do it. T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
May 24 2020
prev sibling parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Sunday, 24 May 2020 at 06:08:42 UTC, H. S. Teoh wrote:
 On Sat, May 23, 2020 at 09:05:47PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 [...]
On Sat, May 23, 2020 at 09:15:18PM -0700, Walter Bright via Digitalmars-d wrote:
 [...]
[...]
I totally agree with this. I am teaching low-level courses like assembly language and operating systems and I have to tell you most of the students (even top students) have a lot of problems implementing data structures correctly in C. Almost all of them make mistakes with regards to null-terminated strings, arrays and pointers. That is mostly because they are focused on implementing the actual algorithm/solution and they do not care about the rest of the details. If a veteran programmer sometimes accidentally introduces a buffer overflow bug, imagine how it is for a young programmer that is eager to focus on interesting problems and doesn't care about boring stuff like making sure the length of the array is correct. We are talking about students that will get hired in 1-2 years and most likely it will take a while before they actually understand the importance of paying attention to this sort of issues; in the mean time they will recklessly introduce vulnerabilities all over the place. Having an automatic method of verification is the best solution to this sort of problem. Languages have evolved enough so that we should not concern ourselves with such low-level details.
May 25 2020