digitalmars.D - Talk on what a systems programming language needs to replace C
- Dibyendu Majumdar (1/1) Aug 25 2019 https://youtu.be/l9hM0h6IQDo
- IGotD- (14/15) Aug 25 2019 What he doesn't mention is that compared to other languages many
- Dibyendu Majumdar (12/20) Aug 26 2019 I ignored the evangelizing bits.
- drug (3/19) Aug 26 2019 Many people don't agree to you because very often low-level Rust code
- Dibyendu Majumdar (4/10) Aug 26 2019 Hi, just for clarity I am not saying this: I just summarised the
- Russel Winder (18/22) Aug 26 2019 [=E2=80=A6]
- Russel Winder (30/38) Aug 26 2019 On Mon, 2019-08-26 at 09:30 +0000, Dibyendu Majumdar via Digitalmars-d w...
- Dibyendu Majumdar (8/14) Aug 26 2019 Personally I think neither Rust nor D can replace C.
- IGotD- (9/16) Aug 26 2019 C++ has already replaced C in systems programming. I experienced
- Russel Winder (27/34) Aug 27 2019 On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via Digitalmars-d w...
- Paulo Pinto (8/32) Aug 27 2019 Unless they are targeting PDP-11 class CPUs, like PICs, I doubt
- Russel Winder (20/24) Aug 27 2019 There is the truth and there is the perception by the masses, which may ...
- Laeeth Isharc (3/12) Sep 03 2019 Like this one? :)
- Russel Winder (26/33) Sep 05 2019 Seems like fun, but no.
- Dibyendu Majumdar (12/27) Aug 27 2019 I think that a better C would simply provide / reimplement some
- welkam (5/6) Aug 28 2019 No its not. C needs a lot of built in compiler
- Russel Winder (9/16) Sep 03 2019 Fair enough: clearly I should have s/is/was/
- Walter Bright (2/4) Aug 27 2019 DasBetterC does not. That was the point of DasBetterC.
- Russel Winder (28/44) Aug 26 2019 Given that the person's goal is to make Rust a superset of C, I do not s...
- IGotD- (20/29) Aug 26 2019 These are typically, intrusive lists, structures that points to
- Walter Bright (3/8) Aug 27 2019 C++ requires a runtime library that supports exception handling. DasBett...
- IGotD- (10/19) Aug 27 2019 That's why you always disable exceptions as well as RTTI in
- =?iso-8859-1?Q?Robert_M._M=FCnch?= (6/8) Aug 27 2019 Is there a difference between BetterC and DasBetterC?
- Patrick Schluter (4/9) Aug 27 2019 Das
- Eugene Wissner (3/14) Aug 28 2019 I read this always as "Das better C" too :D
- Jacob Carlborg (4/5) Aug 28 2019 Yeah, D translated into German :)
- bpr (8/17) Sep 04 2019 DasBetterC is really quite brilliant. I'm a bit disappointed that
- Walter Bright (2/4) Sep 04 2019 Sometimes I think it is what D should have been in the beginning.
- Russel Winder (12/18) Sep 05 2019 But then you wouldn't have a sensible binding/wrapper of GTK+ for D and ...
- bpr (11/16) Sep 05 2019 I think that too!
- bachmeier (14/22) Sep 05 2019 Well, quite simply, D would have seen little interest in the
- H. S. Teoh (18/28) Sep 05 2019 +1, couldn't have said it better. Coming from a C/C++ background, I'm
- Walter Bright (2/4) Sep 05 2019 I just spend three days trying to track down memory corruption problems ...
- IGotD- (21/50) Sep 07 2019 There two situations here when it comes memory management. When
- Russel Winder (34/54) Aug 27 2019 But circular data structures requires pointers in C, so to claim impleme...
- Paulo Pinto (23/58) Aug 26 2019 Apparently ARM, Google, Apple and Microsoft think otherwise,
- Dibyendu Majumdar (8/12) Aug 26 2019 The reason I highlighted this talk was because of who/which
- Paulo Pinto (16/29) Aug 26 2019 Regarding Go as systems language, here is some literature, from
- IGotD- (8/12) Aug 26 2019 There is a lot of Rust click bait in this forum and some "look
- H. S. Teoh (6/19) Aug 26 2019 +1.
- drug (4/11) Aug 27 2019 More over I'm satisfied with current GC in D because I use it for
- Chris (12/18) Aug 27 2019 I know, it's annoying. But a while ago it was Go and before that
- Walter Bright (3/7) Aug 27 2019 I've translated a lot of C code into betterC, and it isn't hard and do n...
- Laeeth Isharc (13/23) Sep 03 2019 I think if we could make this process easy,maybe even automatic
- Adam D. Ruppe (5/9) Sep 03 2019 You can always build an AST in objects, then
- Bastiaan Veelo (4/15) Sep 04 2019 In action: https://youtu.be/HvunD0ZJqiA?t=1216
- Laeeth Isharc (5/16) Sep 04 2019 Yes - it's not difficult. It's just that with quite a few things
- Walter Bright (23/30) Sep 04 2019 This is essentially what AST macros are, a feature that has been repeate...
- Laeeth Isharc (38/55) Sep 04 2019 Yes,so I understand though I do recall seeing your talk from ages
- Russel Winder (34/58) Sep 05 2019 There are certainly risks, but either you assume all programmers are evi...
- Walter Bright (5/7) Sep 05 2019 I know they exist and Rust relies on them as a substitute for language f...
- Russel Winder (30/72) Sep 05 2019 T
- Walter Bright (6/10) Sep 05 2019 Pedantically true, but carefully designing features so they do not encou...
- H. S. Teoh (28/33) Sep 05 2019 Sorry to say, having worked in the industry for a few decades, I have
- Walter Bright (5/20) Sep 07 2019 I have a slight disagreement with this. Too often the mess is created by...
- Andrea Fontana (6/10) Sep 13 2019 I agree with both of you. I've seen both the cases. And I even
- Russel Winder (43/77) Sep 07 2019 I too have worked in the industry for decades, perhaps I just employed g...
- Jacob Carlborg (6/9) Sep 07 2019 Well, in D you can do a lot of stupid things as well. Different kind of
- Jacob Carlborg (6/8) Sep 05 2019 I just going to leave this here for everyone:
- bpr (5/11) Sep 05 2019 Ha, I agree that AST macros would be useful, but I don't think
- H. S. Teoh (7/15) Sep 05 2019 [...]
- a11e99z (5/6) Sep 12 2019 A high-speed network driver written in C, Rust, Go, C#, Java,
On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar wrote:https://youtu.be/l9hM0h6IQDoWhat 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 2019
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: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. Regardshttps://youtu.be/l9hM0h6IQDoThe 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.
Aug 26 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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: […]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.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
Aug 27 2019
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 2019
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: […]Like this one? :) https://www.ioccc.org/2018/mills/hint.htmlThe 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,
Sep 03 2019
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]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.ukMy 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
Sep 05 2019
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: […]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.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.
Aug 27 2019
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:C is a fairly good portable assemblerNo 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 2019
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: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.ukC is a fairly good portable assemblerNo 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
Sep 03 2019
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 2019
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: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.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".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 2019
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 2019
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 2019
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:On 8/26/2019 4:00 AM, IGotD- wrote: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?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 2019
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. Münch http://www.saphirion.com smarter | better | faster
Aug 27 2019
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:Das joke aside, it's the same thing "D as better C"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?
Aug 27 2019
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:I read this always as "Das better C" too :DOn 2019-08-27 08:08:34 +0000, Walter Bright said:Das joke aside, it's the same thing "D as better C"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?
Aug 28 2019
On 2019-08-28 09:05, Eugene Wissner wrote:I read this always as "Das better C" too :DYeah, D translated into German :) -- /Jacob Carlborg
Aug 28 2019
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:On 8/26/2019 4:00 AM, IGotD- wrote: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.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.
Sep 04 2019
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 2019
On Wed, 2019-09-04 at 16:15 -0700, Walter Bright via Digitalmars-d wrote:On 9/4/2019 9:30 AM, bpr wrote:nyDasBetterC is really quite brilliant. I'm a bit disappointed that so ma=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.ukD fans=20 on this forum react negatively to it.=20 Sometimes I think it is what D should have been in the beginning.
Sep 05 2019
On Wednesday, 4 September 2019 at 23:15:37 UTC, Walter Bright wrote:On 9/4/2019 9:30 AM, bpr wrote: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.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 05 2019
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 2019
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).)+1. T -- Designer clothes: how to cover less by paying more.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 2019
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 2019
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: [...]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.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).)+1. TThere'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 07 2019
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 2019
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: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.On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar 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? 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.https://youtu.be/l9hM0h6IQDoWhat 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.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.
Aug 26 2019
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 2019
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: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.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 2019
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 2019
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:+1.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.+1. T -- MASM = Mana Ada Sistem, Man!
Aug 26 2019
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 agreeA 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 2019
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: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.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.
Aug 27 2019
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 2019
On Tuesday, 27 August 2019 at 08:06:35 UTC, Walter Bright wrote:On 8/26/2019 3:37 AM, Russel Winder wrote: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.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.
Sep 03 2019
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 2019
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:In action: https://youtu.be/HvunD0ZJqiA?t=1216 (shameless plug) Bastiaan.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 04 2019
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: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.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 04 2019
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 2019
On Wednesday, 4 September 2019 at 23:13:21 UTC, Walter Bright wrote:On 9/3/2019 3:37 PM, Laeeth Isharc wrote:Yes,so I understand though I do recall seeing your talk from ages back.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.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 2019
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 2019
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 2019
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:h?But is it unfair to say D is missing an AST that's pleasant to work wit=T=20 I'm not sure whether it would be better to construct a parse tree or AS=ly=20for=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=proposed for D. I've blocked it each time. =20 The trouble is, it is incredibly powerful. People find themselves unable =to=20resist its siren call, and use it to invent their own language. They neve=r=20bother to document this language. It winds up balkanizing the underlying==20language 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 macrosThere 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 templates5. 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=sof=20 experience to finally realize what a bad idea it was, as it is an enemy o=f=20writing understandable, maintainable, reusable, and encapsulated code.As are almost all programming language features. The lesson from Groovy was= to 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 2019
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 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 2019
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:[...]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.The lesson from Groovy was to actively avoid doing stupid things andAll 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 2019
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 2019
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 2019
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: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.On 9/5/2019 3:06 AM, Russel Winder wrote:[...]=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.The lesson from Groovy was to actively avoid doing stupid things and=20Isn'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.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.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 2019
On 2019-09-05 12:06, Russel Winder wrote:As are almost all programming language features. The lesson from Groovy was to 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 2019
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 2019
On Thursday, 5 September 2019 at 12:32:16 UTC, Jacob Carlborg wrote:On 2019-09-05 01:13, Walter Bright wrote: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?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 :)
Sep 05 2019
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:[...] 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. KernighanThis 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
Sep 05 2019
On Sunday, 25 August 2019 at 10:06:07 UTC, Dibyendu Majumdar wrote:https://youtu.be/l9hM0h6IQDoOCaml, Haskell, Swift, Javascript, and Python: https://github.com/ixy-languages/ixy-languages
Sep 12 2019