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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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. Münch
http://www.saphirion.com
smarter | better | faster
Aug 27 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019



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 2019



  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 2019



 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 2019



 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 2019



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 2019



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 2019



 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 2019



 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 2019



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 2019



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

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



 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

 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



 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





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 2019



  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 2019



  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 2019



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





=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 2019



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

 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



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 2019



 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 2019



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 2019



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



OCaml, Haskell, Swift, Javascript, and Python:
https://github.com/ixy-languages/ixy-languages



 Sep 12 2019