www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Talk on what a systems programming language needs to replace C

reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
https://youtu.be/l9hM0h6IQDo
Aug 25
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar 
wrote:
 https://youtu.be/l9hM0h6IQDo
What he doesn't mention is that compared to other languages many of the algorithms and programming models will not work in Rust and you have rethink them often making them more complicated and slower. Therefore I think Rust is a bad fit for "system programming". The entire talk is about evangelizing Rust contrary to what he says. He also says he constantly have to add more stuff into the language in order to make work better as a systems programming language which kind of contradicts the idea that Rust is suitable for system programming. There are other languages that can do anything C can without any changes to the language.
Aug 25
next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 26 August 2019 at 06:51:33 UTC, IGotD- wrote:
 On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar 
 wrote:
 https://youtu.be/l9hM0h6IQDo
The entire talk is about evangelizing Rust contrary to what he says. He also says he constantly have to add more stuff into the language in order to make work better as a systems programming language which kind of contradicts the idea that Rust is suitable for system programming.
I ignored the evangelizing bits. What I took from the talk is that there are two things: a) The compelling feature is the Rust automatic memory management /memory safety without GC and runtime - that can motivate systems programmers to move from C. b) Parity with C - this is where Rust lacks and needs enhancements. Comparing with D, perhaps D excels at b) but lacks a compelling memory management solution that would motivate systems programmers. Regards
Aug 26
next sibling parent reply drug <drug2004 bk.ru> writes:
26.08.2019 12:30, Dibyendu Majumdar пишет:
 
 I ignored the evangelizing bits.
 
 What I took from the talk is that there are two things:
 
 a) The compelling feature is the Rust automatic memory management 
 /memory safety without GC and runtime - that can motivate systems 
 programmers to move from C.
Many people don't agree to you because very often low-level Rust code uses unsafe block very much. This definitely isn't as good as you say.
 
 b) Parity with C - this is where Rust lacks and needs enhancements.
 
 Comparing with D, perhaps D excels at b) but lacks a compelling memory 
 management solution that would motivate systems programmers.
 
 Regards
 
Aug 26
next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 26 August 2019 at 10:23:38 UTC, drug wrote:

 a) The compelling feature is the Rust automatic memory 
 management /memory safety without GC and runtime - that can 
 motivate systems programmers to move from C.
 Many people don't agree to you because very often low-level 
 Rust code uses unsafe block very much. This definitely isn't as 
 good as you say.
Hi, just for clarity I am not saying this: I just summarised the main points in the talk. Regards
Aug 26
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-08-26 at 13:23 +0300, drug via Digitalmars-d wrote:
 [=E2=80=A6]
 Many people don't agree to you because very often low-level Rust code=20
 uses unsafe block very much. This definitely isn't as good as you say.
=20
[=E2=80=A6] The safe/unsafe modes are the failing of Rust, even though it is necessary.= In order to do safe "systems programming", there has to be a very well designe= d and test unsafe layer. This is also true of applications programming using C linkage libraries, bu= t in most cases the needed unsafe wrappers can be generated automatically and they work very well. --=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
Aug 26
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-08-26 at 09:30 +0000, Dibyendu Majumdar via Digitalmars-d wrot=
e:
[=E2=80=A6]
 a) The compelling feature is the Rust automatic memory management=20
 /memory safety without GC and runtime - that can motivate systems=20
 programmers to move from C.
It would be nice if this were the case, but Rust is two systems, the safe a= nd unsafe systems, and you have to build a lot of infrastructure to use safe c= ode over unsafe code.
 b) Parity with C - this is where Rust lacks and needs=20
 enhancements.
But why is the purpose to make Rust a superset of C. Why can't we challenge that C is the ideal language for "systems programming" except that it has problems such as buffer overflow. OK so C is a portable assembly language focussed on PDP-8 and PDP-11 hacked to work on VAX-11, but why can't we sta= rt afresh? So Rust and Go are trying to do that, but are they failing in the goal. Go I'd say yes since it has become a Web programming language, and th= at is not "systems programming" nor the only thinkg that C needed replacing fo= r. Rust has a problem because of the unsafe mode needed for systems level work= .
 Comparing with D, perhaps D excels at b) but lacks a compelling=20
 memory management solution that would motivate systems=20
 programmers.
As I understand it, D, like, Go, requires a runtime system over and above t= he C runtime system. --=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
Aug 26
next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 26 August 2019 at 10:44:59 UTC, Russel Winder wrote:

 But why is the purpose to make Rust a superset of C. Why can't 
 we challenge that C is the ideal language for "systems 
 programming" except that it has problems such as buffer 
 overflow. OK so C is a portable assembly language focussed on 
 PDP-8 and PDP-11 hacked to work on VAX-11, but why can't we 
 start afresh?
Personally I think neither Rust nor D can replace C. C is a high level assembler. A replacement needs to be a better high level assembler rather than a language that has many abstractions. The particular quality of C is that you can mentally see how your code translates to machine code. Languages with lot of scaffolding destroy this property.
Aug 26
next sibling parent IGotD- <nise nise.com> writes:
On Monday, 26 August 2019 at 10:55:34 UTC, Dibyendu Majumdar 
wrote:
 Personally I think neither Rust nor D can replace C.
 C is a high level assembler. A replacement needs to be a better 
 high level assembler rather than a language that has many 
 abstractions.
 The particular quality of C is that you can mentally see how 
 your code translates to machine code. Languages with lot of 
 scaffolding destroy this property.
C++ has already replaced C in systems programming. I experienced this shift about 10 years ago and after most of my near HW projects have been done in C++. There is nothing C++ cannot do that C can. Speed wise C++ is very close C and offers more possibilities. You have to know what you can use and what side effects some features have. Systems programming in C++ is a bit different compared if you would write an application.
Aug 26
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via Digitalmars-d wrot=
e:
[=E2=80=A6]
 Personally I think neither Rust nor D can replace C.
 C is a high level assembler. A replacement needs to be a better=20
 high level assembler rather than a language that has many=20
 abstractions.
 The particular quality of C is that you can mentally see how your=20
 code translates to machine code. Languages with lot of=20
 scaffolding destroy this property.
But isn't that at the core of problem? C is a fairly good portable assemble= r and so there are no controls, and no support for ideas such as RAII unless = the programmer implements it themselves. Use C and all the things such as buffe= r overflow are programmer problems. If systems programmers want to escape from problems of portable assembly language programs such as buffer overrun, then they need to eschew C and portable assemblers and create a new language for systems programming. Whet= her Rust, Go, or DasBetterC are it is highly unlikely if the language people wa= nt is a superset of C. I worry that the whole project of putting all the problems of C into Rust t= o make is a C superset ruins Rust and fails to make Rust a replacement for C. --=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
Aug 27
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
 On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via 
 Digitalmars-d wrote: […]
 Personally I think neither Rust nor D can replace C.
 C is a high level assembler. A replacement needs to be a better
 high level assembler rather than a language that has many
 abstractions.
 The particular quality of C is that you can mentally see how 
 your
 code translates to machine code. Languages with lot of
 scaffolding destroy this property.
But isn't that at the core of problem? C is a fairly good portable assembler and so there are no controls, and no support for ideas such as RAII unless the programmer implements it themselves. Use C and all the things such as buffer overflow are programmer problems. If systems programmers want to escape from problems of portable assembly language programs such as buffer overrun, then they need to eschew C and portable assemblers and create a new language for systems programming. Whether Rust, Go, or DasBetterC are it is highly unlikely if the language people want is a superset of C. I worry that the whole project of putting all the problems of C into Rust to make is a C superset ruins Rust and fails to make Rust a replacement for C
Unless they are targeting PDP-11 class CPUs, like PICs, I doubt most C developers will understand how the auto-vectorizer and optimizer opportunities due to UB opportunities have decided to generate a specific set of Assembly code. The portable Assembly myth of C is long gone in the age of multi-core, pipelined, out-of-order execution units, with NUMA, vector units and GPGPUs.
Aug 27
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-08-27 at 16:07 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
=20
 The portable Assembly myth of C is long gone in the age of=20
 multi-core, pipelined, out-of-order execution units, with NUMA,=20
 vector units and GPGPUs.
There is the truth and there is the perception by the masses, which may be = the same, but all too often are at odds. My excuse is that I used C on PDP-11 and VAX-11, and then when new processo= rs came along I moved on to other programming languages. It is most interesting that imperative programming languages are inconsiste= nt with modern processors, and yet everyone still thinks sequence is a valuabl= e concept of a program. --=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
Aug 27
parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Tuesday, 27 August 2019 at 17:04:40 UTC, Russel Winder wrote:
 On Tue, 2019-08-27 at 16:07 +0000, Paulo Pinto via 
 Digitalmars-d wrote: […]
 
 The portable Assembly myth of C is long gone in the age of 
 multi-core, pipelined, out-of-order execution units, with 
 NUMA, vector units and GPGPUs.
There is the truth and there is the perception by the masses, which may be the same, but all too often are at odds. My excuse is that I used C on PDP-11 and VAX-11,
Like this one? :) https://www.ioccc.org/2018/mills/hint.html
Sep 03
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-09-03 at 22:40 +0000, Laeeth Isharc via Digitalmars-d wrote:
 On Tuesday, 27 August 2019 at 17:04:40 UTC, Russel Winder wrote:
[=E2=80=A6]
 My excuse is that I used C on PDP-11 and VAX-11,
=20 Like this one? :) =20 =20 https://www.ioccc.org/2018/mills/hint.html
Seems like fun, but no. I meant real physical PDP-11 (I can't remember if it was a 45 or a 70) with tape drives various RK05 and a weird disk subsystem that presented as 4 * RK05, and about 40 or so cheap VT100 emulating terminals. Also there was a GT/44 (I think that was the designation it was a rack mounter PDP-11 with a 14" vector graphics display very suitable for playing Lunar Lander). Octal was clearly the correct number base for all systems programming using= a PDP-11. Then we got a VAX-11 750 with three 20Mb drives (that looked like top loadi= ng washing machines). Huge upgrade as hexadecimal became the one true number base for all systems programming. It is left as an exercise for the reader to deduce or even infer why octal = and hexadecimal were so important in these different cases. --=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
Sep 05
prev sibling next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
 On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via 
 Digitalmars-d wrote: […]
 Personally I think neither Rust nor D can replace C.
 C is a high level assembler. A replacement needs to be a better
 high level assembler rather than a language that has many
 abstractions.
 The particular quality of C is that you can mentally see how 
 your
 code translates to machine code. Languages with lot of
 scaffolding destroy this property.
But isn't that at the core of problem? C is a fairly good portable assembler and so there are no controls, and no support for ideas such as RAII unless the programmer implements it themselves. Use C and all the things such as buffer overflow are programmer problems.
I think that a better C would simply provide / reimplement some aspects of C so that the programmer has better hope of catching certain bugs, but not take away the essential quality of C being a high level assembler. If D could be stripped of many of its features then in the better C guise it would be close. The fact that Better C mode is an option is not ideal IMO as D is more likely to be viewed in its entirety. Rust's problem is that it has gone to an extreme position to try to help, but in the process simple things are no longer simple, and looking at Rust code is not the same as looking at C code in terms of transparency.
Aug 27
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
 C is a fairly good portable assembler
No its not. C needs a lot of built in compiler macros/functions/extensions to have enough control over generated assembler. But at this time people dont make distinction between a language and compiler provided additions to the language.
Aug 28
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-08-28 at 19:38 +0000, welkam via Digitalmars-d wrote:
 On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
 C is a fairly good portable assembler
No its not. C needs a lot of built in compiler=20 macros/functions/extensions to have enough control over generated=20 assembler. But at this time people dont make distinction between=20 a language and compiler provided additions to the language. =20
Fair enough: clearly I should have s/is/was/ --=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
Sep 03
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2019 3:44 AM, Russel Winder wrote:
 As I understand it, D, like, Go, requires a runtime system over and above the
 C runtime system.
DasBetterC does not. That was the point of DasBetterC.
Aug 27
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-08-26 at 06:51 +0000, IGotD- via Digitalmars-d wrote:
 On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar=20
 wrote:
 https://youtu.be/l9hM0h6IQDo
=20 What he doesn't mention is that compared to other languages many=20 of the algorithms and programming models will not work in Rust=20 and you have rethink them often making them more complicated and=20 slower. Therefore I think Rust is a bad fit for "system=20 programming".
Given that the person's goal is to make Rust a superset of C, I do not see = how you make the above inference. What algorithms and programming models are possible in C that are not possible in Rust? I suspect if there are N programmers in the world, there are 3N+10 definiti= ons of "systems programming". Go developers have changed their mind on the definition a few times over the years.
 The entire talk is about evangelizing Rust contrary to what he=20
 says. He also says he constantly have to add more stuff into the=20
 language in order to make work better as a systems programming=20
 language which kind of contradicts the idea that Rust is suitable=20
 for system programming.
I disagree. He clearly states he isn't evangelising Rust but hopes that peo= ple feel evangelised for Rust due to the talk, which is weird. The entire talk = is about transforming Rust to be a superset of C.
 There are other languages that can do anything C can without any=20
 changes to the language.
And Rust is already one of those.=20 Given there is C and people feel it is time to move on to a better language= , and we have D, C++, Rust, and Go as the obvious candidates, there is a prob= lem none of these are actually candidates for the job of replacing C. Even Go, which is supposed explicitly to be C for the 2010s. --=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
Aug 26
next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 26 August 2019 at 10:37:29 UTC, Russel Winder wrote:
 Given that the person's goal is to make Rust a superset of C, I 
 do not see how you make the above inference. What algorithms 
 and programming models are possible in C that are not possible 
 in Rust?
These are typically, intrusive lists, structures that points to each others (circular references), custom allocators. "Impossible" was a little bit the wrong word that I used. Difficult would be the word or "not worth it". Some of the algorithms can be done but those I've seen require a huge amount of boiler plate for something C would just need a few lines. Circular references is something Rust cannot deal with, unless you explicitly use pointers or RC objects. RC objects are not always welcome in systems programming and raw pointers requires you to do your own memory management so Rust loses its point. I just think the way you program Rust doesn't fit systems programming and it is not worth the extra hazzle. The amount of unsafe hatches you would open in Rust would contradict its grand "safe" selling point.
 Given there is C and people feel it is time to move on to a 
 better language, and we have D, C++, Rust, and Go as the 
 obvious candidates, there is a problem none of these are 
 actually candidates for the job of replacing C. Even Go, which 
 is supposed explicitly to be C for the 2010s.
The speaker is right about one thing and that is that a systems programming language must not have a runtime dependency, or the runtime is completely OS independent. With this definition this includes C, C++, D (-betterC only) and Rust. As far as I know Go is runtime dependent and does not qualify for this definition.
Aug 26
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2019 4:00 AM, IGotD- wrote:
 The speaker is right about one thing and that is that a systems programming 
 language must not have a runtime dependency, or the runtime is completely OS 
 independent. With this definition this includes C, C++, D (-betterC only) and 
 Rust. As far as I know Go is runtime dependent and does not qualify for this 
 definition.
C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.
Aug 27
next sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:
 On 8/26/2019 4:00 AM, IGotD- wrote:
 The speaker is right about one thing and that is that a 
 systems programming language must not have a runtime 
 dependency, or the runtime is completely OS independent. With 
 this definition this includes C, C++, D (-betterC only) and 
 Rust. As far as I know Go is runtime dependent and does not 
 qualify for this definition.
C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.
That's why you always disable exceptions as well as RTTI in embedded C++ programming and the runtime dependency is gone. It's a bit of shame because exception could be useful there as well. The problem with exceptions is that it allocates dynamic memory which makes it unusable for some use cases (fragmentation, time, locking). However, this proposal from Herb Sutter http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf is highly interesting from that point of view. Do you think this proposal would fit D?
Aug 27
prev sibling next sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-08-27 08:08:34 +0000, Walter Bright said:

 C++ requires a runtime library that supports exception handling. 
 DasBetterC does not need anything that C doesn't have.
Is there a difference between BetterC and DasBetterC? -- Robert M. Mnch http://www.saphirion.com smarter | better | faster
Aug 27
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 28 August 2019 at 06:01:22 UTC, Robert M. Münch 
wrote:
 On 2019-08-27 08:08:34 +0000, Walter Bright said:

 C++ requires a runtime library that supports exception 
 handling. DasBetterC does not need anything that C doesn't 
 have.
Is there a difference between BetterC and DasBetterC?
Das joke aside, it's the same thing "D as better C"
Aug 27
parent reply Eugene Wissner <belka caraus.de> writes:
On Wednesday, 28 August 2019 at 06:36:21 UTC, Patrick Schluter 
wrote:
 On Wednesday, 28 August 2019 at 06:01:22 UTC, Robert M. Münch 
 wrote:
 On 2019-08-27 08:08:34 +0000, Walter Bright said:

 C++ requires a runtime library that supports exception 
 handling. DasBetterC does not need anything that C doesn't 
 have.
Is there a difference between BetterC and DasBetterC?
Das joke aside, it's the same thing "D as better C"
I read this always as "Das better C" too :D
Aug 28
parent Jacob Carlborg <doob me.com> writes:
On 2019-08-28 09:05, Eugene Wissner wrote:

 I read this always as "Das better C" too :D
Yeah, D translated into German :) -- /Jacob Carlborg
Aug 28
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:
 On 8/26/2019 4:00 AM, IGotD- wrote:
 The speaker is right about one thing and that is that a 
 systems programming language must not have a runtime 
 dependency, or the runtime is completely OS independent. With 
 this definition this includes C, C++, D (-betterC only) and 
 Rust. As far as I know Go is runtime dependent and does not 
 qualify for this definition.
C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.
DasBetterC is really quite brilliant. I'm a bit disappointed that so many D fans on this forum react negatively to it. It would be even better if there were more available libraries built with DasBetterC, like formatted printing, so there is less "roll your own". I'm sympathetic to Mike Franklin's efforts to make D more "pay for only what you use" but DasBetterC hits a sweet spot now.
Sep 04
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2019 9:30 AM, bpr wrote:
 DasBetterC is really quite brilliant. I'm a bit disappointed that so many D
fans 
 on this forum react negatively to it.
Sometimes I think it is what D should have been in the beginning.
Sep 04
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-09-04 at 16:15 -0700, Walter Bright via Digitalmars-d wrote:
 On 9/4/2019 9:30 AM, bpr wrote:
 DasBetterC is really quite brilliant. I'm a bit disappointed that so ma=
ny
 D fans=20
 on this forum react negatively to it.
=20 Sometimes I think it is what D should have been in the beginning.
But then you wouldn't have a sensible binding/wrapper of GTK+ for D and thu= s no actual usefulness of D. ;-) --=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
Sep 05
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 4 September 2019 at 23:15:37 UTC, Walter Bright 
wrote:
 On 9/4/2019 9:30 AM, bpr wrote:
 DasBetterC is really quite brilliant. I'm a bit disappointed 
 that so many D fans on this forum react negatively to it.
Sometimes I think it is what D should have been in the beginning.
I think that too! It would have been hard to see this when D came out; Java was on a roll, C++ seemed to be waning, and Moore's Law was still going strong. DasBetterC is, as its name suggests a better C, much more so than C++ IMO. I believe DasBetterC would have lessened the need for Rust. Ah, counterfactuals... There's still room in the world for DasBetterC, so I hope the development continues. It's great that many of the annoying restrictions have been lifted.
Sep 05
parent reply bachmeier <no spam.net> writes:
On Thursday, 5 September 2019 at 17:56:09 UTC, bpr wrote:

 It would have been hard to see this when D came out; Java was 
 on a roll, C++ seemed to be waning, and Moore's Law was still 
 going strong. DasBetterC is, as its name suggests a better C, 
 much more so than C++ IMO. I believe DasBetterC would have 
 lessened the need for Rust. Ah, counterfactuals...
Well, quite simply, D would have seen little interest in the early days if didn't have a GC, based on my recollection. Stroustrup was even talking about garbage collected C++. I could be wrong, since there was no Hacker News or Reddit to teach me about the one true path, but D would not have been the marvelous language it is today, and would have had a marketing problem without a GC. It's true that Rust does appeal to the sliver of programmers that think memory management is an awesome way to spend Saturday night, but let's let Rust have those users and worry about a good experience for the rest.
 There's still room in the world for DasBetterC, so I hope the 
 development continues. It's great that many of the annoying 
 restrictions have been lifted.
Exactly. There's no reason to choose between D and betterC because we can have both.
Sep 05
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2019 at 07:33:05PM +0000, bachmeier via Digitalmars-d wrote:
[...]
 It's true that Rust does appeal to the sliver of programmers that
 think memory management is an awesome way to spend Saturday night, but
 let's let Rust have those users and worry about a good experience for
 the rest.
+1, couldn't have said it better. Coming from a C/C++ background, I'm well-versed in all-nighters spent debugging memory management problems, and personally I find D's GC a godsend. I am *so* much more productive with the GC when performance isn't a big issue, and even when it is, there are ways to control the GC so that it stays out of the bottlenecks in the code. It isn't as though this is Java where you are *forced* to use the GC, after all. (In many cases the GC isn't a problem as long as you don't trigger it inside performance-sensitive inner loops. Cutting out GC from the *entire* application as a knee-jerk reaction is, IMNSHO, premature optimization. Heck, even game engines these days support higher-level scripting in GC'd languages -- you just have to keep the GC out of the core performance sensitive code and it's Good Enough(tm).)
 There's still room in the world for DasBetterC, so I hope the
 development continues. It's great that many of the annoying
 restrictions have been lifted.
Exactly. There's no reason to choose between D and betterC because we can have both.
+1. T -- Designer clothes: how to cover less by paying more.
Sep 05
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2019 1:21 PM, H. S. Teoh wrote:
 Coming from a C/C++ background, I'm
 well-versed in all-nighters spent debugging memory management problems,
I just spend three days trying to track down memory corruption problems in CTFE.
Sep 05
prev sibling parent IGotD- <nise nise.com> writes:
On Thursday, 5 September 2019 at 20:21:12 UTC, H. S. Teoh wrote:
 On Thu, Sep 05, 2019 at 07:33:05PM +0000, bachmeier via 
 Digitalmars-d wrote: [...]
 It's true that Rust does appeal to the sliver of programmers 
 that think memory management is an awesome way to spend 
 Saturday night, but let's let Rust have those users and worry 
 about a good experience for the rest.
+1, couldn't have said it better. Coming from a C/C++ background, I'm well-versed in all-nighters spent debugging memory management problems, and personally I find D's GC a godsend. I am *so* much more productive with the GC when performance isn't a big issue, and even when it is, there are ways to control the GC so that it stays out of the bottlenecks in the code. It isn't as though this is Java where you are *forced* to use the GC, after all. (In many cases the GC isn't a problem as long as you don't trigger it inside performance-sensitive inner loops. Cutting out GC from the *entire* application as a knee-jerk reaction is, IMNSHO, premature optimization. Heck, even game engines these days support higher-level scripting in GC'd languages -- you just have to keep the GC out of the core performance sensitive code and it's Good Enough(tm).)
 There's still room in the world for DasBetterC, so I hope 
 the development continues. It's great that many of the 
 annoying restrictions have been lifted.
Exactly. There's no reason to choose between D and betterC because we can have both.
+1. T
There two situations here when it comes memory management. When programming near hardware or OS level stuff you often want to manage your memory yourself. These are often very specialized allocators in order to optimize the usage and fragmentation. Here you deal with the memory management manually anyway. The other side to this are applications where I don't really care about the memory that much, in this case GC is king and that Rust way of manage memory is just annoying at least for my projects. I want to go from A to B as easily as possible and GC is usually the best approach for this. Computers are supposed to work for us, not the other way around. I think that D have the opportunity to provide both scenarios. Most of the library can be GC but there are exceptions. String manipulations should avoid GC as this is often done in an OS less or real time environment as well. IO should avoid to too, for performance reasons as well. I also say, keep the GC. Remove the GC where it makes sense. -betterC should continue to evolve and I would actually like to see classes with polymorphism (both GC and manually allocated) with betterC as well.
Sep 07
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-08-26 at 11:00 +0000, IGotD- via Digitalmars-d wrote:
[=E2=80=A6]
=20
 These are typically, intrusive lists, structures that points to=20
 each others (circular references), custom allocators.=20
 "Impossible" was a little bit the wrong word that I used.=20
 Difficult would be the word or "not worth it". Some of the=20
 algorithms can be done but those I've seen require a huge amount=20
 of boiler plate for something C would just need a few lines.=20
 Circular references is something Rust cannot deal with, unless=20
 you explicitly use pointers or RC objects. RC objects are not=20
 always welcome in systems programming and raw pointers requires=20
 you to do your own memory management so Rust loses its point. I=20
 just think the way you program Rust doesn't fit systems=20
 programming and it is not worth the extra hazzle. The amount of=20
 unsafe hatches you would open in Rust would contradict its grand=20
 "safe" selling point.
But circular data structures requires pointers in C, so to claim implementi= ng such things in Rust using Rust pointers is a failing of Rust is a bit unfai= r. Also std::collections::LinkedList seems to do most of the work needed. It is the case that the Rust split of crate_X for the Rust facing, and crate_X_sys for the C facing creates apparent infrastructure issues, but it does allow for properly constraining all the unsafe stuff into properly tes= ted small chinks.=20 Writing library/application code using a Rust with a Rust facing wrapper ba= sed over the unsafe C facing wrapper makes things much, much easier that writin= g C code with all the manual RAII rubbish required because C has no support for RAII. [=E2=80=A6]
 The speaker is right about one thing and that is that a systems=20
 programming language must not have a runtime dependency, or the=20
 runtime is completely OS independent. With this definition this=20
 includes C, C++, D (-betterC only) and Rust. As far as I know Go=20
 is runtime dependent and does not qualify for this definition.
I suspect this also rules out C as a systems programming language since the= re is a C runtime system which is OS specific, along with the C library. :-) But yes D and Go rule themselves out for any situation that cannot admit a = GC initialisation, though I suspect fear of GC is over-prevalent in far too mu= ch of systems programming.=20 --=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
Aug 27
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 August 2019 at 10:37:29 UTC, Russel Winder wrote:
 On Mon, 2019-08-26 at 06:51 +0000, IGotD- via Digitalmars-d 
 wrote:
 On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar 
 wrote:
 https://youtu.be/l9hM0h6IQDo
What he doesn't mention is that compared to other languages many of the algorithms and programming models will not work in Rust and you have rethink them often making them more complicated and slower. Therefore I think Rust is a bad fit for "system programming".
Given that the person's goal is to make Rust a superset of C, I do not see how you make the above inference. What algorithms and programming models are possible in C that are not possible in Rust? I suspect if there are N programmers in the world, there are 3N+10 definitions of "systems programming". Go developers have changed their mind on the definition a few times over the years.
 The entire talk is about evangelizing Rust contrary to what he 
 says. He also says he constantly have to add more stuff into 
 the language in order to make work better as a systems 
 programming language which kind of contradicts the idea that 
 Rust is suitable for system programming.
I disagree. He clearly states he isn't evangelising Rust but hopes that people feel evangelised for Rust due to the talk, which is weird. The entire talk is about transforming Rust to be a superset of C.
 There are other languages that can do anything C can without 
 any changes to the language.
And Rust is already one of those. Given there is C and people feel it is time to move on to a better language, and we have D, C++, Rust, and Go as the obvious candidates, there is a problem none of these are actually candidates for the job of replacing C. Even Go, which is supposed explicitly to be C for the 2010s.
Apparently ARM, Google, Apple and Microsoft think otherwise, given that: - Android's GPGPU debugger is mostly written in Go - The hypervisor used on ChromeOS and Google Cloud Computer, gVisor, is written in Go - Fuchsia TCP/IP stack and volume management tooling is written in Go - ChromeOS sandboxing is written in Rust - Android since Treble uses Java and C++ for drivers, the classical Linux drivers are deemed legacy - Apple's kernel and future driver stack is written in a mix of C++ and Swift - Windows uses a mix of C++ and .NET, since Windows 8 kernel code has been being migrated to C++, with COM (UWP) increasing its focus as userspace API - Fuchsia is written in a mix of C++, Dart and Rust, with the L4 C bits being migrated to C++ - ARM mbed is written in C++ One thing that everyone seems to be missing from this talk, lost in the usual D vs Rust argumentations, is that the speaker has a responsability position at Intel, and it also relates to Intel's adoption of Rust.
Aug 26
parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Monday, 26 August 2019 at 12:31:23 UTC, Paulo Pinto wrote:

 One thing that everyone seems to be missing from this talk, 
 lost in the usual D vs Rust argumentations, is that the speaker 
 has a responsability position at Intel, and it also relates to 
 Intel's adoption of Rust.
The reason I highlighted this talk was because of who/which organization it came from. Josh is also a Kernel hacker if I am not mistaken. Regarding your argument that Go is a systems language - I guess Google using it doesn't count, but Go is used for writing databases etc. But not sure you could use Go everywhere that C can be used. Go has a built-in scheduler, and GC etc.
Aug 26
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 August 2019 at 14:12:37 UTC, Dibyendu Majumdar 
wrote:
 On Monday, 26 August 2019 at 12:31:23 UTC, Paulo Pinto wrote:

 One thing that everyone seems to be missing from this talk, 
 lost in the usual D vs Rust argumentations, is that the 
 speaker has a responsability position at Intel, and it also 
 relates to Intel's adoption of Rust.
The reason I highlighted this talk was because of who/which organization it came from. Josh is also a Kernel hacker if I am not mistaken. Regarding your argument that Go is a systems language - I guess Google using it doesn't count, but Go is used for writing databases etc. But not sure you could use Go everywhere that C can be used. Go has a built-in scheduler, and GC etc.
Regarding Go as systems language, here is some literature, from one of its influences http://www.projectoberon.com http://www.ocp.inf.ethz.ch/wiki/Documentation/Front And related hardware, https://pcper.com/tag/oberonstation/ And a surviving vendor, https://www.astrobe.com I can also cite a multitude of other languages. In fact, D also has a built-in scheduler and GC. As you might imagine, I belong to the crowd that would rather see a better GC (thanks very much for all improvements by the way), than betterC or trying to copy Rust, just because it is getting all the love by the FAANG.
Aug 26
parent reply IGotD- <nise nise.com> writes:
On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:
 As you might imagine, I belong to the crowd that would rather 
 see a better GC (thanks very much for all improvements by the 
 way), than betterC or trying to copy Rust, just because it is 
 getting all the love by the FAANG.
There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion. A better GC is always welcome and we should really focus on that rather trying to be Rust with its memory management and other quirks.
Aug 26
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 26, 2019 at 09:48:45PM +0000, IGotD- via Digitalmars-d wrote:
 On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:
 
 As you might imagine, I belong to the crowd that would rather see a
 better GC (thanks very much for all improvements by the way), than
 betterC or trying to copy Rust, just because it is getting all the
 love by the FAANG.
There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion.
+1.
 A better GC is always welcome and we should really focus on that
 rather trying to be Rust with its memory management and other quirks.
+1. T -- MASM = Mana Ada Sistem, Man!
Aug 26
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
27.08.2019 0:48, IGotD- пишет:
 
 There is a lot of Rust click bait in this forum and some "look Rust can 
 do this and that, we must have it too". I think that D should follow its 
 own path and should not trying to ape Rust in every fashion.
 
Totally agree
 A better GC is always welcome and we should really focus on that rather 
 trying to be Rust with its memory management and other quirks.
More over I'm satisfied with current GC in D because I use it for simplicity not performance. For latter I use manual memory handling.
Aug 27
prev sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 26 August 2019 at 21:48:45 UTC, IGotD- wrote:
 On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:

 There is a lot of Rust click bait in this forum and some "look 
 Rust can do this and that, we must have it too". I think that D 
 should follow its own path and should not trying to ape Rust in 
 every fashion.
I know, it's annoying. But a while ago it was Go and before that C++ (among other things). Every few years (or even every year) D is chasing after a new "must have" feature. And usually it's done, before one could possibly know if feature X will work for Go or Rust. I'd say relax a little bit and do your own thing, and maybe later you can see what features you could incorporate (that's what C++ does, I think). This "must have" mentality does a lot of damage to D, old bugs and shortcomings are neglected, there are new half-baked features, an outsider only sees a mess and insiders think "Ah, WTF!" fearing their code might break, because D now has to work with feature X. D will never learn.
Aug 27
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2019 3:37 AM, Russel Winder wrote:
 Given there is C and people feel it is time to move on to a better language,
 and we have D, C++, Rust, and Go as the obvious candidates, there is a problem
 none of these are actually candidates for the job of replacing C. Even Go,
 which is supposed explicitly to be C for the 2010s.
I've translated a lot of C code into betterC, and it isn't hard and do not find myself missing anything about C in the process.
Aug 27
parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Tuesday, 27 August 2019 at 08:06:35 UTC, Walter Bright wrote:
 On 8/26/2019 3:37 AM, Russel Winder wrote:
 Given there is C and people feel it is time to move on to a 
 better language,
 and we have D, C++, Rust, and Go as the obvious candidates, 
 there is a problem
 none of these are actually candidates for the job of replacing 
 C. Even Go,
 which is supposed explicitly to be C for the 2010s.
I've translated a lot of C code into betterC, and it isn't hard and do not find myself missing anything about C in the process.
I think if we could make this process easy,maybe even automatic that would make it much easier to adopt D. C2Rust was a DoD project that cost millions I think. But maybe we could make it an SAoC project next year. We could use their CBOR dump of the C AST or DMC. But is it unfair to say D is missing an AST that's pleasant to work with? I'm not sure whether it would be better to construct a parse tree or AST for this purpose but eg with DPP my personal sense is it would be useful to have a way to generate D code at a more abstract level than strings. Anyway if you could translate C to D it surely wouldn't hurt.
Sep 03
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc wrote:
 I'm not sure whether it would be better to construct a parse 
 tree or AST for this purpose but eg with DPP my personal sense 
 is it would be useful to have a way to generate D code at a 
 more abstract level than strings.
You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.
Sep 03
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 3 September 2019 at 22:44:08 UTC, Adam D. Ruppe wrote:
 On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc 
 wrote:
 I'm not sure whether it would be better to construct a parse 
 tree or AST for this purpose but eg with DPP my personal sense 
 is it would be useful to have a way to generate D code at a 
 more abstract level than strings.
You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.
In action: https://youtu.be/HvunD0ZJqiA?t=1216 (shameless plug) Bastiaan.
Sep 04
prev sibling parent Laeeth Isharc <laeeth kaleidic.io> writes:
On Tuesday, 3 September 2019 at 22:44:08 UTC, Adam D. Ruppe wrote:
 On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc 
 wrote:
 I'm not sure whether it would be better to construct a parse 
 tree or AST for this purpose but eg with DPP my personal sense 
 is it would be useful to have a way to generate D code at a 
 more abstract level than strings.
You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.
Yes - it's not difficult. It's just that with quite a few things it's a matter of how much you can bite off at once and also continued maintenance cost. So if there's a good library for it then what might be just beyond what's possible becomes possible.
Sep 04
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2019 3:37 PM, Laeeth Isharc wrote:
 But is it unfair to say D is missing an AST that's pleasant to work with?
 
 I'm not sure whether it would be better to construct a parse tree or AST for 
 this purpose but eg with DPP my personal sense is it would be useful to have a 
 way to generate D code at a more abstract level than strings.
 
 Anyway if you could translate C to D it surely wouldn't hurt.
This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time. The trouble is, it is incredibly powerful. People find themselves unable to resist its siren call, and use it to invent their own language. They never bother to document this language. It winds up balkanizing the underlying language so they cannot share code or even talk to each other. This doesn't happen overnight, it takes a few years. And then it's too late. Some examples: 1. Lisp macros 2. Macro assemblers 3. C macro preprocessor 4. C++ expression templates (3) is a bit of an interesting case. The C macros are very limited in capability, but that barely slowed down the rush to build crazy contraptions with it and embed them everywhere. I've fallen into this trap myself with both (2) and (3). It took 10+ years of experience to finally realize what a bad idea it was, as it is an enemy of writing understandable, maintainable, reusable, and encapsulated code. You don't hear much about C++ expression templates these days. For a few years they were quite the darling, until the scope of the horror became apparent. Think of it like when the devil says you can have anything you want. It seems great for a while, but nothing good comes from it.
Sep 04
next sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Wednesday, 4 September 2019 at 23:13:21 UTC, Walter Bright 
wrote:
 On 9/3/2019 3:37 PM, Laeeth Isharc wrote:
 But is it unfair to say D is missing an AST that's pleasant to 
 work with?
 
 I'm not sure whether it would be better to construct a parse 
 tree or AST for this purpose but eg with DPP my personal sense 
 is it would be useful to have a way to generate D code at a 
 more abstract level than strings.
 
 Anyway if you could translate C to D it surely wouldn't hurt.
This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time.
Yes,so I understand though I do recall seeing your talk from ages back.
 The trouble is, it is incredibly powerful. People find 
 themselves unable to resist its siren call, and use it to 
 invent their own language. They never bother to document this 
 language. It winds up balkanizing the underlying language so 
 they cannot share code or even talk to each other.
Funnily enough we have written our own language that's quite coupled to D and that even allows you to write inline D. I just realized last night that means you could write inline asm in it too :O (it took 1hr 15 minutes to implement inline D as a first version and it's not yet in master so I haven't fully absorbed the implications yet). Would be nice to be able to transpile the language to D for performance - by far the easiest route as once we have type inference it should map quite cleanly from SIL to D. Anyway,I suppose in a systems language you trust the programmer but having gone to extraordinary lengths myself to solve the problem of balkanisation I also understand your point. There are negative spillover effects. I don't see how allowing creating D AST via a library presents a serious risk though. And I wonder a bit about DSLs. I agree with you about not abusing operator overloading. You should make it an explicit DSL instead. But then the answer ought to be that there are libraries that make it easy to develop DSLs. The competition is quite stiff. There are frameworks that build editor plugins with syntax highlighting etc all in an integrated way. In some ways D is peculiarly suited to writing DSLs. It's not difficult to write a parser but having Pegged can make the difference between an unrealistic project and just about being able to accomplish something. The type marshalling capabilities makes the standard library easy. But I guess if you compare to what's easy with LINQ and Rosslyn there is something missing. It's not trivial to hook up the AST of your DSL to LLVM or similar. Not difficult but it's not no work if you don't already know it. What's your take on Rust macros? I am not familiar with them so I don't know myself.
Sep 04
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-09-05 at 00:32 +0000, Laeeth Isharc via Digitalmars-d wrote:
[=E2=80=A6]
 I don't see how allowing creating D AST via a library presents a=20
 serious risk though.
There are certainly risks, but either you assume all programmers are evil a= nd must be protected by the language designer from making errors the language designer doesn't like, or you assume a community of sensible programmers wh= o work together to make the best of potentially dangerous features. Groovy took the latter view and the community pulled together and even produced some totally unexpected by totally wonderful features. The general history of programming languages does tend to be the knowledgea= ble authority kindly protecting programmers from trying to do bad (in the eyes = of the authority) things. The history of programming is the history of trying to protect programmers from doing things.
 And I wonder a bit about DSLs.  I agree with you about not=20
 abusing operator overloading.  You should make it an explicit DSL=20
 instead.
Internal or external DSLs. For internal DSLs (my experience is Python and Groovy) then operator overloading is essential to make any sensible progres= s. Also, perhaps bizarrely, using an object oriented view of program execution (i.e. messages passed to receivers) helps a great deal.
 But then the answer ought to be that there are libraries that=20
 make it easy to develop DSLs.
=20
 The competition is quite stiff. There are frameworks that build=20
 editor plugins with syntax highlighting etc all in an integrated=20
 way.
=20
 In some ways D is peculiarly suited to writing DSLs.  It's not=20
 difficult to write a parser but having Pegged can make the=20
 difference between an unrealistic project and just about being=20
 able to accomplish something.  The type marshalling capabilities=20
 makes the standard library easy.
External DSLs maybe but not internal DSLs.
 But I guess if you compare to what's easy with LINQ and Rosslyn=20
 there is something missing.  It's not trivial to hook up the AST=20
 of your DSL to LLVM or similar.  Not difficult but it's not no=20
 work if you don't already know it.
=20
 What's your take on Rust macros?  I am not familiar with them so=20
 I don't know myself.
I have only dabbled a little, but they are quite good. And fully typed checked. I am sure you can do nasty things with them, but for the simple ca= ses I have used them for they do the job as needed. --=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
Sep 05
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2019 5:32 PM, Laeeth Isharc wrote:
 What's your take on Rust macros?  I am not familiar with them so I don't know 
 myself.
I know they exist and Rust relies on them as a substitute for language features common in other languages, but I don't know much about them beyond that. DSLs can be (and are) done in D using string mixins. What you can't do is hijack D's syntax for the DSL, which is what AST macros enable.
Sep 05
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-09-04 at 16:13 -0700, Walter Bright via Digitalmars-d wrote:
 On 9/3/2019 3:37 PM, Laeeth Isharc wrote:
 But is it unfair to say D is missing an AST that's pleasant to work wit=
h?
=20
 I'm not sure whether it would be better to construct a parse tree or AS=
T
 for=20
 this purpose but eg with DPP my personal sense is it would be useful to
 have a=20
 way to generate D code at a more abstract level than strings.
=20
 Anyway if you could translate C to D it surely wouldn't hurt.
=20 This is essentially what AST macros are, a feature that has been repeated=
ly=20
 proposed for D. I've blocked it each time.
=20
 The trouble is, it is incredibly powerful. People find themselves unable =
to=20
 resist its siren call, and use it to invent their own language. They neve=
r=20
 bother to document this language. It winds up balkanizing the underlying=
=20
 language so they cannot share code or even talk to each other.
This didn't happen in Groovy. AST macros were added, and new language capabilities ensued and all in all it was agreed that Groovy was better for AST macros and that they should have been added earlier.
 This doesn't happen overnight, it takes a few years. And then it's too la=
te.
=20
 Some examples:
=20
 1. Lisp macros
There is not just one Lisp. SBCL, CLisp, and Clojure do things differently = but all do things really rather well.
 2. Macro assemblers
 3. C macro preprocessor
 4. C++ expression templates
5. Groovy AST macros.
 (3) is a bit of an interesting case. The C macros are very limited in=20
 capability, but that barely slowed down the rush to build crazy
 contraptions=20
 with it and embed them everywhere.
=20
 I've fallen into this trap myself with both (2) and (3). It took 10+ year=
s
 of=20
 experience to finally realize what a bad idea it was, as it is an enemy o=
f=20
 writing understandable, maintainable, reusable, and encapsulated code.
As are almost all programming language features. The lesson from Groovy was= to actively avoid doing stupid things and to trust programmers not to f### thi= ngs up. Which they didn't.
 You don't hear much about C++ expression templates these days. For a few
 years=20
 they were quite the darling, until the scope of the horror became apparen=
t.
=20
 Think of it like when the devil says you can have anything you want. It
 seems=20
 great for a while, but nothing good comes from it.
--=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
Sep 05
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2019 3:06 AM, Russel Winder wrote:
 As are almost all programming language features.
Pedantically true, but carefully designing features so they do not encourage such excess is reasonably effective. For example, D's operator overloading is set up to make it hard to do abominations like C++ iostreams.
 The lesson from Groovy was to
 actively avoid doing stupid things and to trust programmers not to f### things
 up. Which they didn't.
All programmers agree with this sentiment, and create a hellish mess anyway. (I can't comment on Groovy, since I know too little about it or its community.)
Sep 05
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2019 at 01:50:03PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/5/2019 3:06 AM, Russel Winder wrote:
[...]
 The lesson from Groovy was to actively avoid doing stupid things and
 to trust programmers not to f### things up. Which they didn't.
Sorry to say, having worked in the industry for a few decades, I have exactly the opposite sentiment. Perhaps things aren't that way where you are, and that's good for you. Where I am, the worst possible code gets written because the language allowed it, and it falls upon my shoulders to fix the inscrutable problems therein long after the original author has moved on to greener pastures. "Trust the programmer" is an attitude I used to subscribe to, but these days it leaves a bitter taste in my mouth.
 All programmers agree with this sentiment, and create a hellish mess
 anyway.
[...] Yep. Especially when there's a deadline and the customer is being unreasonable, and your job is on the line, then anything goes. Unreadable hacks using C macros? Sure, if it gets the job done before you're fired. Operator overload abuse? Sure, if it gets the job done before you're fired. Inscrutable pointer casting hacks? Oh yes, if it gets the product shipped by the deadline. Making things easier for the poor sod who'll be maintaining your code a decade later? That's not even a consideration when the deadline is looming, the customer is demanding, and the project manager is angry. Some things should not be allowed by the language, or at least should be harder to do compared to the "right" way. The incentives need to be right. Free-for-all usually means lowest common denominator, and believe me, when it comes to average code quality in your typical "enterprise" code, that denominator is low indeed. T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Sep 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2019 2:29 PM, H. S. Teoh wrote:
 Yep.  Especially when there's a deadline and the customer is being
 unreasonable, and your job is on the line, then anything goes.
 Unreadable hacks using C macros?  Sure, if it gets the job done before
 you're fired.  Operator overload abuse? Sure, if it gets the job done
 before you're fired.  Inscrutable pointer casting hacks?  Oh yes, if it
 gets the product shipped by the deadline.  Making things easier for the
 poor sod who'll be maintaining your code a decade later?  That's not
 even a consideration when the deadline is looming, the customer is
 demanding, and the project manager is angry.
 
 Some things should not be allowed by the language, or at least should be
 harder to do compared to the "right" way. The incentives need to be
 right. Free-for-all usually means lowest common denominator, and believe
 me, when it comes to average code quality in your typical "enterprise"
 code, that denominator is low indeed.
I have a slight disagreement with this. Too often the mess is created by programmers who sincerely believe they *are* doing the right thing. They're proud of it. Being able to recognize this unfortunately only comes via a lot of experience.
Sep 07
parent Andrea Fontana <nospam example.com> writes:
On Saturday, 7 September 2019 at 21:19:51 UTC, Walter Bright 
wrote:
 I have a slight disagreement with this. Too often the mess is 
 created by programmers who sincerely believe they *are* doing 
 the right thing. They're proud of it. Being able to recognize 
 this unfortunately only comes via a lot of experience.
I agree with both of you. I've seen both the cases. And I even know programmers that are doing this by purpose: they write unreadable/unmaintainable code to become indispensable for the company.
Sep 13
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-09-05 at 14:29 -0700, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 05, 2019 at 01:50:03PM -0700, Walter Bright via Digitalmars-d
 wrote:
 On 9/5/2019 3:06 AM, Russel Winder wrote:
[...]
 The lesson from Groovy was to actively avoid doing stupid things and
 to trust programmers not to f### things up. Which they didn't.
=20 Sorry to say, having worked in the industry for a few decades, I have exactly the opposite sentiment. Perhaps things aren't that way where you are, and that's good for you. Where I am, the worst possible code gets written because the language allowed it, and it falls upon my shoulders to fix the inscrutable problems therein long after the original author has moved on to greener pastures. "Trust the programmer" is an attitude I used to subscribe to, but these days it leaves a bitter taste in my mouth.
I too have worked in the industry for decades, perhaps I just employed good programmers as opposed to crap ones. There is clearly a distribution of ability (a truly complicated concept I agree) as programmers amongst programmers and to be honest most people below the median are really not ve= ry good at all. Many can and do get better, far too many just take the money a= nd ignore any notion of personal or organisational betterment. For the best programmers programming language features are enabling. For th= e worst programmers the constraints and dictats of programming languages rare= ly stop them creating truly crap code. If you cannot trust your programmers then change the programmers or close t= he organisation.
=20
 All programmers agree with this sentiment, and create a hellish mess
 anyway.
[...] =20 Yep. Especially when there's a deadline and the customer is being unreasonable, and your job is on the line, then anything goes. Unreadable hacks using C macros? Sure, if it gets the job done before you're fired. Operator overload abuse? Sure, if it gets the job done before you're fired. Inscrutable pointer casting hacks? Oh yes, if it gets the product shipped by the deadline. Making things easier for the poor sod who'll be maintaining your code a decade later? That's not even a consideration when the deadline is looming, the customer is demanding, and the project manager is angry.
Isn't this really a description of a crap organisation using crap programme= rs? If this is the way software industry is always going to behave maybe the wh= ole thing should be culled and restarted.
 Some things should not be allowed by the language, or at least should be
 harder to do compared to the "right" way. The incentives need to be
 right. Free-for-all usually means lowest common denominator, and believe
 me, when it comes to average code quality in your typical "enterprise"
 code, that denominator is low indeed.
Clearly the building of abstractions inherently means some restriction on w= hat can be done with the machine. Programming language enshrine this, along wit= h the prejudices of the language developer. The question is all to often are = the prejudices of the language designer copeable with by programmers or will th= ey choose another language. Lack of operator overloading in D as is present in C++ and Python still irritates me (it constrains making nice abstraction, which are internal DSLs) but clearly the operator creation of Algol68 and Scala clearly leads to incomprehensible babble very quickly given the way t= he official examples suggest using it.=20 --=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
Sep 07
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-09-05 12:06, Russel Winder wrote:

 As are almost all programming language features. The lesson from Groovy was to
 actively avoid doing stupid things and to trust programmers not to f### things
 up. Which they didn't.
Well, in D you can do a lot of stupid things as well. Different kind of stupid things, like corrupting the memory. But everyone seems to think that is perfectly fine. -- /Jacob Carlborg
Sep 07
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-09-05 01:13, Walter Bright wrote:

 This is essentially what AST macros are, a feature that has been 
 repeatedly proposed for D. I've blocked it each time.
I just going to leave this here for everyone: https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s :) -- /Jacob Carlborg
Sep 05
next sibling parent bpr <brogoff gmail.com> writes:
On Thursday, 5 September 2019 at 12:32:16 UTC, Jacob Carlborg 
wrote:
 On 2019-09-05 01:13, Walter Bright wrote:

 This is essentially what AST macros are, a feature that has 
 been repeatedly proposed for D. I've blocked it each time.
I just going to leave this here for everyone: https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s :)
Ha, I agree that AST macros would be useful, but I don't think they're coming to the D language. Maybe a general purpose macro processor could satisfy some of these desires?
Sep 05
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2019 at 02:32:16PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 2019-09-05 01:13, Walter Bright wrote:
 
 This is essentially what AST macros are, a feature that has been
 repeatedly proposed for D. I've blocked it each time.
I just going to leave this here for everyone: https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s
[...] So what happened since then that Walter is now staunchly against AST macros? T -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
Sep 05
prev sibling parent a11e99z <black80 bk.ru> writes:
On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar 
wrote:
 https://youtu.be/l9hM0h6IQDo
A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python: https://github.com/ixy-languages/ixy-languages
Sep 12