www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Maybe D is right about GC after all !

reply Walter Bright <newshound2 digitalmars.com> writes:
"C, Python, Go, and the Generalized Greenspun Law"

http://esr.ibiblio.org/?p=7804
Dec 19 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 
 http://esr.ibiblio.org/?p=7804


I must agree, GC is a wonderful fallback.

Although I do wish we had better scope+RC support.
Signatures too would have significant benefit towards AMM.
Dec 19 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2017 2:02 AM, rikki cattermole wrote:

 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 
 I must agree, GC is a wonderful fallback.


I tend to write hybrid programs in D, so I wouldn't call it a fallback. Just 
like I might use both structs and classes!
Dec 19 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 19/12/2017 10:09 AM, Walter Bright wrote:

 On 12/19/2017 2:02 AM, rikki cattermole wrote:

 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I must agree, GC is a wonderful fallback.


 
 I tend to write hybrid programs in D, so I wouldn't call it a fallback. 
 Just like I might use both structs and classes!


I'm working mostly on library type code like SPEW. Where I do use both 
sturcts and classes but prefer IAllocator over the GC (even if the 
instance is the GC) with RC.

Indeed, for quick utility things I don't bother with anything else 
either! :)
Dec 19 2017
prev sibling parent reply Mengu <mengukagan gmail.com> writes:
On Tuesday, 19 December 2017 at 10:09:41 UTC, Walter Bright wrote:

 On 12/19/2017 2:02 AM, rikki cattermole wrote:

 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 
 I must agree, GC is a wonderful fallback.


 I tend to write hybrid programs in D, so I wouldn't call it a 
 fallback. Just like I might use both structs and classes!


hi walter

i never had a chance to thank you for d, so here it goes: thank 
you very much! been in love with it for so long. despite my 
anger, i keep coming back :)

would you mind writing a tutorial / blog post on this matter for 
dummies such as myself? from what i gather from the forum posts 
is that _in theory_ we can do this but _in reality_ most of us 
don't know how.
Dec 19 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2017 2:30 PM, Mengu wrote:

 i never had a chance to thank you for d, so here it goes: thank you very much! 
 been in love with it for so long. despite my anger, i keep coming back :)


You're welcome!


 would you mind writing a tutorial / blog post on this matter for dummies such
as 
 myself? from what i gather from the forum posts is that _in theory_ we can do 
 this but _in reality_ most of us don't know how.


I'm not very good at tutorials. But plenty of others here are!
Dec 19 2017
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 19 December 2017 at 22:30:57 UTC, Mengu wrote:

 On Tuesday, 19 December 2017 at 10:09:41 UTC, Walter Bright 
 wrote:

 I tend to write hybrid programs in D, so I wouldn't call it a 
 fallback. Just like I might use both structs and classes!




[snip]


 would you mind writing a tutorial / blog post on this matter 
 for dummies such as myself? from what i gather from the forum 
 posts is that _in theory_ we can do this but _in reality_ most 
 of us don't know how.


Anything in particular you find missing in the GC-series blog 
posts [1]?

[1] https://dlang.org/blog/the-gc-series/
Dec 20 2017
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
rikki cattermole wrote:


 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 http://esr.ibiblio.org/?p=7804


 I must agree, GC is a wonderful fallback.

 Although I do wish we had better scope+RC support.


but Rikki, we have this! i'm using refcounted structs for years, and it 
works like a charm! ;-)
Dec 19 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/12/2017 11:30 AM, ketmar wrote:

 rikki cattermole wrote:
 

 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 http://esr.ibiblio.org/?p=7804


 I must agree, GC is a wonderful fallback.

 Although I do wish we had better scope+RC support.


 
 but Rikki, we have this! i'm using refcounted structs for years, and it 
 works like a charm! ;-)


And that is why I said better!
Dec 19 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
rikki cattermole wrote:


 On 19/12/2017 11:30 AM, ketmar wrote:

 rikki cattermole wrote:
 

 On 19/12/2017 9:54 AM, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 http://esr.ibiblio.org/?p=7804


 I must agree, GC is a wonderful fallback.

 Although I do wish we had better scope+RC support.


 but Rikki, we have this! i'm using refcounted structs for years, and it 
 works like a charm! ;-)


 And that is why I said better!


you can't have better than working! ;-)
Dec 19 2017
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 19 December 2017 at 11:30:14 UTC, ketmar wrote:

 but Rikki, we have this! i'm using refcounted structs for 
 years, and it works like a charm! ;-)


You can either have guaranteed memory-safe (due to DIP1000) but 
inefficient RC (due to extra runtime checks*), or efficient and 
not memory safe. That's why DIP74, DIP77 were created.

* 
https://forum.dlang.org/post/aeeffshzkfjbrejztksj forum.dlang.org
Dec 21 2017
prev sibling next sibling parent reply w0rp <devw0rp gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


I think D and the GC are highly appropriate for developing high 
performance application software. That's where D really shines. 
It's a shame that Qt is such a nightmare to use in anything that 
isn't C++. GTK is easy enough to use at least. What's funny is 
that both frameworks implement their own memory management 
schemes. That points to a need for automatic memory management.
Dec 19 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 19 December 2017 at 10:54:12 UTC, w0rp wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I think D and the GC are highly appropriate for developing high 
 performance application software. That's where D really shines. 
 It's a shame that Qt is such a nightmare to use in anything 
 that isn't C++. GTK is easy enough to use at least. What's 
 funny is that both frameworks implement their own memory 
 management schemes. That points to a need for automatic memory 
 management.


Why only application software?  The point of that blog post is 
that whole swathes of system programming should be done with 
mostly GC, leaving only OS kernels, some real-time apps, and the 
highly-constrained embedded space to the betterC mode.
Dec 19 2017
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 19 December 2017 at 11:03:37 UTC, Joakim wrote:

 On Tuesday, 19 December 2017 at 10:54:12 UTC, w0rp wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I think D and the GC are highly appropriate for developing 
 high performance application software. That's where D really 
 shines. It's a shame that Qt is such a nightmare to use in 
 anything that isn't C++. GTK is easy enough to use at least. 
 What's funny is that both frameworks implement their own 
 memory management schemes. That points to a need for automatic 
 memory management.


 Why only application software?  The point of that blog post is 
 that whole swathes of system programming should be done with 
 mostly GC, leaving only OS kernels, some real-time apps, and 
 the highly-constrained embedded space to the betterC mode.


Which is actually how Android works.

NDK is quite constrained and its only purpose is for high 
performance 3D graphics (Vulkan), real-time audio, SIMD/NEON and 
integrating existing C and C++ code into Java.

Everything else is done in Java, and on Android Things even user 
space drivers are implemented in Java.

Also where Microsoft is driving UWP into, C++ for kernel, 
graphics and performance critical UWP components, and everything 
else in .NET Native.

Even the UI team does their Fluent UI graphical effect demos in 


--
Paulo
Dec 20 2017
prev sibling next sibling parent reply I Love Stuffing <ilovestuffing gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


I'm still not sure why this precludes GC from just being a 
standard library feature vs. a language feature. D is probably 
better prepared than other languages in doing that cleanly.
Dec 19 2017
next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing 
wrote:

 I'm still not sure why this precludes GC from just being a 
 standard library feature vs. a language feature. D is probably 
 better prepared than other languages in doing that cleanly.


GC is the runtime library feature, it's accepted as a default 
because it's provided by the default runtime.
Dec 21 2017
prev sibling parent reply Emma Watson <emmawatson.8855 gmail.com> writes:
On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing 
wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I'm still not sure why this precludes GC from just being a 
 standard library feature vs. a language feature. D is probably 
 better prepared than other languages in doing that cleanly.


Probably this one could be the answer
Dec 22 2017
parent reply Dan Partelly <i i.com> writes:
On Friday, 22 December 2017 at 12:13:39 UTC, Emma Watson wrote:

 On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing 
 wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I'm still not sure why this precludes GC from just being a 
 standard library feature vs. a language feature. D is probably 
 better prepared than other languages in doing that cleanly.


 Probably this one could be the answer


I believe so, yes. GC should be a library feature, std library of 
the language should be independent of existence of a garbage 
collector, and the language itself should not contain features 
which are dependent of the existence of a garbage collector. 
(strings, maps, unbounded arrays all should have been part of 
standard lib IMO and not part of the core language and dependent 
of GC.

I wanted to look at D as a "beter C++", with simple and sane 
metaprograming and metaligusitic features.  It is almost there, 
but unfortunately, not 0 cost abstraction without loosing too 
much. You depend too much of having garbage collection active. It 
works as a "betterC" it seems, but you loose a lot of 
functionality which should be in a "better C" and again, a lot 
from the standard libraries is lost. Template C++ 2017 works well 
for a better C as well, and I retain 0 cost abstraction, decent 
(yet inferior to D meta-programming), closures,
exceptions, scopes...

Perhaps Im wrong, I only play with D by several days.
Dec 22 2017
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2017-12-22 at 13:38 +0000, Dan Partelly via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 I wanted to look at D as a "beter C++", with simple and sane=20
 metaprograming and metaligusitic features.  It is almost there,=20
 but unfortunately, not 0 cost abstraction without loosing too=20
 much. You depend too much of having garbage collection active. It=20
 works as a "betterC" it seems, but you loose a lot of=20
 functionality which should be in a "better C" and again, a lot=20
 from the standard libraries is lost. Template C++ 2017 works well=20
 for a better C as well, and I retain 0 cost abstraction, decent=20
 (yet inferior to D meta-programming), closures,
 exceptions, scopes...


[=E2=80=A6]

I think we are now in a world where Rust is the zero cost abstraction
language to replace C and C++, except for those who are determined to
stay with C++ and evolve it.

D, like Go, should glory in having a GC and just go with it.
 =20
Of course this does not mean the GC as is is good enough. Go is on its
third I believe, and Java on it's fifth.

--=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
Dec 22 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction language to replace C and C++, except for those who 
 are determined to stay with C++ and evolve it.


Why should we settle for this ? D code (efortless) is easier to 
read then Rust. I assume this to be true for a lot of programmers 
who know C/C++. It also introperates very well with C, which is 
great boon, since at low level we live on the shoulder of a titan 
written in C.  It has tremnedous features, and ironically the 
best of them could have been designed to not relay on GC. As most 
, if not all, of the features offered by its library could have 
been done with no GC.


 D, like Go, should glory in having a GC and just go with it.

 Of course this does not mean the GC as is is good enough. Go is 
 on its
 third I believe, and Java on it's fifth.


A good implementation at library level of GC would mean that I 
can use one single language
in all areas of system programming. Or at least, a implementation 
where std:: and core features of language should not relay on GC. 
This, IMO is an advantage not to be neglected. A better C mode 
with a very powerfull high level standard library (like std:: ), 
exceptions, RAII, classes (yes, why not ) typeid would be a very 
big step ahead. All those could be done without having to worry 
about existence of GC. C++ has all those.

IMO the key here is the standard libray of the language. Nothing 
in it should relay  on the existence of GC. Why, why, does it 
have to depend on GC and hence automatically disqualify itself 
from a better C world ? The C runtime ezposed by core is 
powerfull, but imagine having std:: power in better C as well. I 
really lament this.

You could have the best of the two worlds.
Dec 22 2017
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:

 On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder 
 wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction language to replace C and C++, except for those 
 who are determined to stay with C++ and evolve it.


 Why should we settle for this ? D code (efortless) is easier to 
 read then Rust. I assume this to be true for a lot of 
 programmers who know C/C++. It also introperates very well with 
 C, which is great boon, since at low level we live on the 
 shoulder of a titan written in C.  It has tremnedous features, 
 and ironically the best of them could have been designed to not 
 relay on GC. As most , if not all, of the features offered by 
 its library could have been done with no GC.


 D, like Go, should glory in having a GC and just go with it.

 Of course this does not mean the GC as is is good enough. Go 
 is on its
 third I believe, and Java on it's fifth.


 A good implementation at library level of GC would mean that I 
 can use one single language
 in all areas of system programming. Or at least, a 
 implementation where std:: and core features of language should 
 not relay on GC. This, IMO is an advantage not to be neglected. 
 A better C mode with a very powerfull high level standard 
 library (like std:: ), exceptions, RAII, classes (yes, why not 
 ) typeid would be a very big step ahead. All those could be 
 done without having to worry about existence of GC. C++ has all 
 those.

 IMO the key here is the standard libray of the language. 
 Nothing in it should relay  on the existence of GC. Why, why, 
 does it have to depend on GC and hence automatically disqualify 
 itself from a better C world ? The C runtime ezposed by core is 
 powerfull, but imagine having std:: power in better C as well. 
 I really lament this.

 You could have the best of the two worlds.


You seem not to have read the original link and Walter's first 
post: why would we expend all that effort on a small, shrinking 
niche of the language market that is populated by a couple 
thousand diehard programmers who won't look at any new language?

That's not to say the core team is ignoring that market, as the 
betterC mode is geared toward some of them who don't need all the 
features you want, but realistically it will take years for D to 
provide all D features with an easy choice of GC or not, if it's 
even technically feasible.  Given that GC is already here and 
addresses a much bigger market, there's no point in Osborning all 
that's available _today_ by forever dreaming for a fully no-GC 
stdlib that's not going to be here anytime soon.

If that's what you really want though, I suggest you pitch in, as 
Mike Franklin has being doing recently:

https://github.com/dlang/dmd/pulls/JinShil
Dec 22 2017
parent Dan Partelly <i i.com> writes:
On Friday, 22 December 2017 at 17:21:12 UTC, Joakim wrote:

 You seem not to have read the original link and Walter's first 
 post: why would we expend all that effort on a small, shrinking 
 niche of the language market that is populated by a couple 
 thousand diehard programmers who won't look at any new language?



  Empiricall Id say that a lot of those programmers are interested 
in both old and new languages, from Lisp to D. But nevermind 
that. Those people are not idiots really. They would use any 
language which gets the job done, and they would use as high 
level as possible to get the job done. They look and then they go 
back from practical reasons. And a 10% market of C programmers is 
not really small niche. D could have got a lot of those, if it 
made just one more good decision regarding the "how" of GC and 
libs. The IOT is upon us, automation is upon us, embeded devices 
slowly become ubiquitous in cosumer market, while a lot of 
languages shoot themselves in the foot from beeing a part of this 
market with poor decisions.



  Given that GC is already here and addresses a much bigger 
 market, there's no point in Osborning all that's available 
 _today_ by forever dreaming for a fully no-GC stdlib that's not 
 going to be here anytime soon.


Sure. This is why I said I lament the choiche done. Today the 
vast std lib of D should have been not GC dependent. So IMO, D 
made a good decision having GC (they did a lot of great decsions 
btw, D is phenomenal good IMO) and D made a very bad decision 
having a std lib dependant on GC, convenience language features 
dependant by gc (vectors , hashes and the like belong to the 
library ), and core language features dependant on GC (classes / 
exceptions whatever)

So there you have it. Regarding GC, in my opinion D made both a 
good decision and a bad one.
Dec 23 2017
prev sibling next sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:

 On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder 
 wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction language to replace C and C++, except for those 
 who are determined to stay with C++ and evolve it.


 Why should we settle for this ? D code (efortless) is easier to 
 read then Rust. I assume this to be true for a lot of 
 programmers who know C/C++. It also introperates very well with 
 C, which is great boon, since at low level we live on the 
 shoulder of a titan written in C.  It has tremnedous features, 
 and ironically the best of them could have been designed to not 
 relay on GC. As most , if not all, of the features offered by 
 its library could have been done with no GC.


 D, like Go, should glory in having a GC and just go with it.

 Of course this does not mean the GC as is is good enough. Go 
 is on its
 third I believe, and Java on it's fifth.


 A good implementation at library level of GC would mean that I 
 can use one single language
 in all areas of system programming. Or at least, a 
 implementation where std:: and core features of language should 
 not relay on GC. This, IMO is an advantage not to be neglected. 
 A better C mode with a very powerfull high level standard 
 library (like std:: ), exceptions, RAII, classes (yes, why not 
 ) typeid would be a very big step ahead. All those could be 
 done without having to worry about existence of GC. C++ has all 
 those.

 IMO the key here is the standard libray of the language. 
 Nothing in it should relay  on the existence of GC. Why, why, 
 does it have to depend on GC and hence automatically disqualify 
 itself from a better C world ? The C runtime ezposed by core is 
 powerfull, but imagine having std:: power in better C as well. 
 I really lament this.

 You could have the best of the two worlds.


Regarding GC being built into the core language, from [the D 
faq](https://dlang.org/faq.html):

"**Can't garbage collection be done in C++ with an add-on 
library?**

Yes, I use one myself. It isn't part of the language, though, and 
requires some subverting of the language to make it work. Using 
gc with C++ isn't for the standard or casual C++ programmer. 
Building it into the language, like in D, makes it practical for 
everyday programming chores."

I'm new to D. Coming primarily from Python these days, I'm 
looking at D not as a better C++ (haven't used that in many 
years), but as a better Python.
Dec 22 2017
next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Friday, 22 December 2017 at 18:59:34 UTC, John Gabriele wrote:

 I'm new to D. Coming primarily from Python these days, I'm 
 looking at D not as a better C++ (haven't used that in many 
 years), but as a better Python.


I'm quite similar. New to D (been using it for a month now). I 

the fact that D makes it easy to bypass it where necessary and 
the language gives me more control over my program if I need.

I wish D would stop bending over backwards to appease C/C++ 
programmers. I think D would have more success branding itself as 
a general purpose language and letting itself become the language 
it should be, not the language some C++ programmer wants but is 
never going to use anyway.
Dec 22 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham wrote:

 language it should be, not the language some C++ programmer 
 wants but is never going to use anyway.


Ironically, D is so close to beeing the language a C++ programmer 
would really use that you can smell it. It doesnt have to bend, 
since it got so close with a lot of good decisions. D is the 
first language Im aware of which  has the potential to satisfy 
the needs of a very large portion of the market,
Dec 23 2017
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-12-23 09:15, Dan Partelly wrote:


 Ironically, D is so close to beeing the language a C++ programmer would
 really use that you can smell it. It doesnt have to bend, since it got
 so close with a lot of good decisions.


That's because it already has bent over backwards several times to get 
to the current state. -betterC, C++ ABI compatibility and so on.

-- 
/Jacob Carlborg
Dec 24 2017
prev sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Saturday, 23 December 2017 at 08:15:04 UTC, Dan Partelly wrote:

 On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham 
 wrote:

 language it should be, not the language some C++ programmer 
 wants but is never going to use anyway.


 Ironically, D is so close to beeing the language a C++ 
 programmer would really use that you can smell it. It doesnt 
 have to bend, since it got so close with a lot of good 
 decisions. D is the first language Im aware of which  has the 
 potential to satisfy the needs of a very large portion of the 
 market,


How much further does D have to go to start snatching C++'s 
userbase?

In my honest opinion, D doesn't offer as much of an advantage 

template syntax, modules (although that idea is being floated in 
the C++ community), but what else? The C++ juggernaut keeps 
piling on new features every 3 years. It's hard for D to stay in 
the lead (that is if it is).



and performance sucks.


would have a greater appeal on those audiences.


duplicate the code for each size of the vector and then again for 
each type. You can cut down on the type duplications by using the 
dynamic keyword but that infers a performance hit. On the flip 
side, D's metaprogramming reduces the complexity of writing such 
utilities.



OOP can do and offers many other paradigms. D is more a toolbox 
to let you program the way you want. C++ is much the same, just 
uglier. Thus, there's going to be less draw to D from C++.

I also recall someone saying that C++'s memory problem is fixed. 
D's MMM seems infantile in comparison.


Well, you can. But it gets ugly and unidiomatic. You also have to 
consult the documentation frequently to know what certain 
allocates. In D you can receive warnings about what allocates GC 
memory (compiler flag -- can't remember which one (-vgc on DMD?)) 
and also enforce non-gc allocations. It also lets me use other 
memory management techniques if need be.

I think D should try to advertise to more restrictive languages 


than it will from the C++ crowd.
Dec 24 2017
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 24 December 2017 at 15:00:09 UTC, Dylan Graham wrote:

 On Saturday, 23 December 2017 at 08:15:04 UTC, Dan Partelly 
 wrote:

 On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham 
 wrote:

 language it should be, not the language some C++ programmer 
 wants but is never going to use anyway.


 Ironically, D is so close to beeing the language a C++ 
 programmer would really use that you can smell it. It doesnt 
 have to bend, since it got so close with a lot of good 
 decisions. D is the first language Im aware of which  has the 
 potential to satisfy the needs of a very large portion of the 
 market,


 How much further does D have to go to start snatching C++'s 
 userbase?

 In my honest opinion, D doesn't offer as much of an advantage 

 template syntax, modules (although that idea is being floated 
 in the C++ community), but what else? The C++ juggernaut keeps 
 piling on new features every 3 years. It's hard for D to stay 
 in the lead (that is if it is).


That's the biggest problem with C++, they pile on relentlessly 
half baked feature after half baked feature in a big dump that no 
one with a life can ever grasp.




 and performance sucks.


 would have a greater appeal on those audiences.



for deployment. They could be the best languages since sliced 
bread, they would still be annoying to deploy as the runtime is 
an emulator.

I ported 1 app from Java to D. It was so unspectacular (or better 
said it was spectacularly easy) that you're probably right. 
Reaching to Java devs is a good idea. The advantage of Java 
though, is not the language but the huge, huge, huge existing 
libraries and packages and know how. This will be difficult to 
overcome  for any language.
Dec 24 2017
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2017-12-24 at 16:51 +0000, Patrick Schluter via Digitalmars-d
wrote:

=20


[=E2=80=A6]


 for deployment. They could be the best languages since sliced=20
 bread, they would still be annoying to deploy as the runtime is=20
 an emulator.
=20
 I ported 1 app from Java to D. It was so unspectacular (or better=20
 said it was spectacularly easy) that you're probably right.=20
 Reaching to Java devs is a good idea. The advantage of Java=20
 though, is not the language but the huge, huge, huge existing=20
 libraries and packages and know how. This will be difficult to=20
 overcome  for any language.
=20


But unless people submit proposals showing how D beats Java in direct
competition, the JVM focused people will never know. Take DevoxxUK and
JAXLondon the two primary JVM-related conferences in London. No mention
of Go or Rust, let alone D. Single language conferences are tools for
retaining people within the language, ditto programs such as Java
Champions.=20
=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
Dec 24 2017
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 24 December 2017 at 17:08:26 UTC, Russel Winder wrote:

 On Sun, 2017-12-24 at 16:51 +0000, Patrick Schluter via 
 Digitalmars-d wrote:

 


 […]


 infrastructure for deployment. They could be the best 
 languages since sliced bread, they would still be annoying to 
 deploy as the runtime is an emulator.
 
 I ported 1 app from Java to D. It was so unspectacular (or 
 better said it was spectacularly easy) that you're probably 
 right. Reaching to Java devs is a good idea. The advantage of 
 Java though, is not the language but the huge, huge, huge 
 existing libraries and packages and know how. This will be 
 difficult to overcome  for any language.
 


 But unless people submit proposals showing how D beats Java in 
 direct
 competition, the JVM focused people will never know. Take 
 DevoxxUK and
 JAXLondon the two primary JVM-related conferences in London. No 
 mention
 of Go or Rust, let alone D. Single language conferences are 
 tools for
 retaining people within the language, ditto programs such as 
 Java
 Champions.


New things grow at the fringes.  See the work of Clayton 
Christensen and his book the Innovator's Dilemma.  A head-on 
assault is ill-advised.  People looking for salvation are easier 
to talk to than those who don't see anything wrong with what 
they're doing currently.
Dec 24 2017
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2017-12-24 at 17:13 +0000, Laeeth Isharc via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 New things grow at the fringes.  See the work of Clayton=20
 Christensen and his book the Innovator's Dilemma.  A head-on=20
 assault is ill-advised.  People looking for salvation are easier=20
 to talk to than those who don't see anything wrong with what=20
 they're doing currently.


Not my experience in the JVM-related community, and to an extent the
Python community, at least in the UK. Head on collisions create debate,
and get you remembered. The debate generally leads to change, even if
not the change initially envisaged. At least the status quo gets
perturbed.

Just dealing with the fringes and solving their problems rarely get
serious traction. cf. Golo, Gosu, Fantom, Crystal, Pony, all of which
solve definite problems but none of which have any serious traction to
move programming on.

--=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
Dec 24 2017
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 24 December 2017 at 20:58:51 UTC, Russel Winder wrote:

 On Sun, 2017-12-24 at 17:13 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:

 […]
 
 New things grow at the fringes.  See the work of Clayton 
 Christensen and his book the Innovator's Dilemma.  A head-on 
 assault is ill-advised.  People looking for salvation are 
 easier to talk to than those who don't see anything wrong with 
 what they're doing currently.


 Not my experience in the JVM-related community, and to an 
 extent the Python community, at least in the UK. Head on 
 collisions create debate, and get you remembered. The debate 
 generally leads to change, even if not the change initially 
 envisaged. At least the status quo gets perturbed.

 Just dealing with the fringes and solving their problems rarely 
 get serious traction. cf. Golo, Gosu, Fantom, Crystal, Pony, 
 all of which solve definite problems but none of which have any 
 serious traction to move programming on.


It's much better to have a monopoly of some niche or set of 
niches and to use energy from success to expand out from there, 
than to have a small market share of an enormous market.  And 
niche in this case is not something simple - it's people who have 
a certain set of kinds of problems and certain capabilities and 
who have the ability to make decisions on merits for them rather 
than primarily social factors.

See Peter Thiel's Zero to One for another expression of the same 
point.

 From a strategic perspective, it's by far better for the 
challenger not to be taken seriously for the longest possible 
time until the moment is ripe, if it's possible to achieve that.

It takes a long time for a programming language to be adopted.  
And the more ambitious the language, perhaps the longer it takes 
to mature and the longer it will be for it to achieve wide 
adoption.  D is a pretty ambitious language!

I can appreciate that if one's business involves teaching people 
a language then this is frustrating.  But I'd suggest taking a 
step back and looking at things from the point of view of the 
language itself, which is an organic creature not wholly under 
the control of its creators.  (See node.js).
Dec 27 2017
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 16:57 +0000, Laeeth Isharc via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 It's much better to have a monopoly of some niche or set of=20
 niches and to use energy from success to expand out from there,=20
 than to have a small market share of an enormous market.  And=20
 niche in this case is not something simple - it's people who have=20
 a certain set of kinds of problems and certain capabilities and=20
 who have the ability to make decisions on merits for them rather=20
 than primarily social factors.


Witness that it is likely that Kotlin will take over from Java as the
primary language of Android application development.

In the end this is that the programming language offers something very
significant to allow a change in the extant market leader.


 See Peter Thiel's Zero to One for another expression of the same=20
 point.
=20
  From a strategic perspective, it's by far better for the=20
 challenger not to be taken seriously for the longest possible=20
 time until the moment is ripe, if it's possible to achieve that.


But the challenger must offer something that the extant market leader
does not that the majority of the people in the game value. Without an
obvious an unassailable value there will be no change in market leader.


 It takes a long time for a programming language to be adopted. =20
 And the more ambitious the language, perhaps the longer it takes=20
 to mature and the longer it will be for it to achieve wide=20
 adoption.  D is a pretty ambitious language!


Experimentally it takes 10 years for a language to achieve status these
days. Exceptions prove the rule!

The challenger has to offer something that the community value. Rust
offers memory safety over C. D offers "better C++". This is the wrong
message to achieve traction. D must offer something that C++ does not
offer.


 I can appreciate that if one's business involves teaching people=20
 a language then this is frustrating.  But I'd suggest taking a=20
 step back and looking at things from the point of view of the=20
 language itself, which is an organic creature not wholly under=20
 the control of its creators.  (See node.js).


But as of 2017-03-30 I have no hidden agenda, i.e. I retired. :-) This
mjeans I am just doing what I want, which currently is organising ACCU
conference, organising DevoxxUK conferences and programming DVB-T and
DAB clients. D has failed to get traction at ACCU, has no chance at all
at DevoxxUK, and has lost to Rust in DVB-T and DAB applications.

--=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
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
Dec 27 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 27 December 2017 at 18:13:41 UTC, Russel Winder 
wrote:

 The challenger has to offer something that the community value. 
 Rust offers memory safety over C. D offers "better C++". This 
 is the wrong message to achieve traction. D must offer 
 something that C++ does not offer.


If you're a better version of one of the market leaders, that's 
good enough.  If you were just a better Erlang, that'd be a 
marketing problem!


 But as of 2017-03-30 I have no hidden agenda, i.e. I retired. 
 :-) This mjeans I am just doing what I want, which currently is 
 organising ACCU conference, organising DevoxxUK conferences and 
 programming DVB-T and DAB clients. D has failed to get traction 
 at ACCU, has no chance at all at DevoxxUK, and has lost to Rust 
 in DVB-T and DAB applications.


So D is invisible in the places you frequent, but has anybody 
written an entire storage system in Rust?

https://www.theregister.co.uk/2017/12/22/a_dive_into_wekaios_parallel_file_system_tech/

My point is that D and Rust are both currently lower-traction 
languages, so it's expected that you don't find them in many 
places.  Rust is certainly doing better right now, because it is 
focused on the niche of memory safety, but that means Gerald 
almost certainly isn't going to use it for his Gtk-based tiling 
terminal emulator:

https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/

D and Rust are going after different markets, but D is trying to 
stay more general-purpose, which Rust has abandoned so far 
(though their upcoming GC may be a step towards more general use).

On Wednesday, 27 December 2017 at 18:41:41 UTC, Laeeth Isharc 
wrote:

 That's really the whole point about D.  It's an era where 
 people start out assuming that using the right tool for the job 
 means that one tool can't do two different kinds of job well.  
 But, as Walter has said elsewhere I think, in some cases that's 
 because the tools people are used to using are limited, whereas 
 in fact there's no need for that - just use one tool that's 
 good at both.
  It's going to be a struggle to recognise such a tool if you 
 start with the presumption it cannot exist.


This reminded me of a current theme in tech, the tension between 
modularity and integration.  Here's an example quote from a 
couple months ago:

"But the long arc of history shows how hard it is to succeed in 
vertical integration after you build on horizontal foundations. 
Generations of managers graduated from the modular school of 
thought, specializing rather than generalizing. Now they are 
facing an integrated experiential world where progress depends on 
wrapping the mind around very broad systems problems."
http://www.asymco.com/2017/10/04/orthogonal-pivots/

The canonical example is how Apple doesn't compete on 
feature/spec checklists but on an integrated experience that just 
works better.  That may be tougher to market for tech users, but 
it is increasingly what people want, even many programmers.
Dec 28 2017
parent Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 20:03:06 UTC, Joakim wrote:

 The canonical example is how Apple doesn't compete on 
 feature/spec checklists but on an integrated experience that 
 just works better.  That may be tougher to market for tech 
 users, but it is increasingly what people want, even many 
 programmers.


Spot on.

Even markets which are occupied by tech users, like BSD/Linux 
servers goes into this direction. Systemd is a prime example. It 
allows modern functionality and integration which in today's 
world is a must. And it still not provies enough. Devices are 
hotplugged all the time, they go in different power states, they 
respond asynch to system wide, net wide, and soon, world wide 
events ... the user mode paradigm of Unix is woefully inadequate 
and unprepared for this world. It needs serious adjustments. 
(arguably  even kernels on free unix like OSes are unprepared, no 
modern LPC comparable to what can be found in NT derived kernels 
for example)

Yet the users do not seen it this way. A big part of Linux users 
went so far as to make life threats towards systemd engineers. 
They hate any attempt to modernization and integration. They do 
prefer the autoexec.bat like init systems spawning fragile 
scaffoldings of scripts. Too much choice begets fragmentation, 
both from a technical point of view and a social one. 
Fragmentation begets tribes, and tribes kill each other.

Likewise, in a company , it is in my opinion better to keep the 
languages used across the board as limited as possible, instead 
of an everlasting search for best tool for each of the problem 
you face. Just see if you can solve it with the tools you already 
have, don't try to build a scaffolding of techs you barely 
unde5rstand and control because the are the "best"
Dec 28 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 8:57 AM, Laeeth Isharc wrote:

 It's much better to have a monopoly of some niche or set of niches and to use 
 energy from success to expand out from there, than to have a small market
share 
 of an enormous market.


Back in the 80's, Zortech made a killing because we had the only C++ compiler 
that would generate 16 bit Windows code.

I found this out by asking the sales guys what feature of ZTC++ was closing the 
deal - X, Y, Z, all the features I held dear. They'd say nope. Customers wanted 
to use C++ for Win16, ZTC++ supported that, sold!

I learned a lot from that.
Dec 27 2017
next sibling parent reply Dan partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 22:36:08 UTC, Walter Bright 
wrote:

 On 12/27/2017 8:57 AM, Laeeth Isharc wrote:

 It's much better to have a monopoly of some niche or set of 
 niches and to use energy from success to expand out from 
 there, than to have a small market share of an enormous market.


 Back in the 80's, Zortech made a killing because we had the 
 only C++ compiler that would generate 16 bit Windows code.

 I found this out by asking the sales guys what feature of ZTC++ 
 was closing the deal - X, Y, Z, all the features I held dear. 
 They'd say nope. Customers wanted to use C++ for Win16, ZTC++ 
 supported that, sold!

 I learned a lot from that.


That a product which fulfils a need in a total void sells? No 
disrespect, but aint it a bit tautological ? Can you find a 
similar void today which is to be filled by D ? Better yet can 
you create one ?
Dec 27 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 00:36:32 UTC, Dan partelly wrote:

 Can you find a similar void today which is to be filled by D ?
 Better yet can you create one ?


No need to create one. It already exists.

The need for highly flexible, portable, powerful, fast, compiled 
language, that is easy to understand and pleasant to work with.
Dec 27 2017
parent reply Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 02:16:03 UTC, codephantom wrote:


 No need to create one. It already exists.

 The need for highly flexible, portable, powerful, fast, 
 compiled language, that is easy to understand and pleasant to 
 work with.


Id wish things would be so simple. Unfortunately, no, there is no 
void to be filled by a monopoly here.   It's a place full of 
competition, and to gain a spot (not bene, a spot, the monopoly 
doesnt exist) you have to demonstrate that you are a compelling 
enough improvement.
And this is battle you can't won on technical grounds alone.

  Recall the need for an OS which is consistent, elegant , better 
than Unix ? And recall how the Plan 9 masterpiece failed in 
trying to fill that space ?

https://en.wikipedia.org/wiki/Worse_is_better [1]
Dec 27 2017
parent reply codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 02:39:58 UTC, Dan Partelly wrote:

 Id wish things would be so simple. Unfortunately, no, there is 
 no void to be filled by a monopoly here.   It's a place full of 
 competition, and to gain a spot (not bene, a spot, the monopoly 
 doesnt exist) you have to demonstrate that you are a compelling 
 enough improvement.


https://www.youtube.com/watch?v=vYEKEIpM2zo
Dec 27 2017
parent reply Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 02:48:11 UTC, codephantom wrote:

 https://www.youtube.com/watch?v=vYEKEIpM2zo


Thanks Ill watch it, but when I mentioned worse is better I 
didn't had C++ in mind. I thought at new language who gains 
traction lately but it is clearly inferior to D technically.

It was... Go.
Dec 27 2017
parent reply codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 02:53:56 UTC, Dan Partelly wrote:

 On Thursday, 28 December 2017 at 02:48:11 UTC, codephantom 
 wrote:

 https://www.youtube.com/watch?v=vYEKEIpM2zo


 Thanks Ill watch it, but when I mentioned worse is better I 
 didn't had C++ in mind. I thought at new language who gains 
 traction lately but it is clearly inferior to D technically.

 It was... Go.


I tried Go. I didn't like it. Syntax changes were not necessary, 
and I got the feeling that the philosophy of Go, is that 
programmers are incompetent and need training wheels. It wasn't 
for me.

I looked at Rust, but never tried it, as I found the syntax to 
pretty awful - and it reminded my too much of C++.

I looked at D, it looked nice. Syntax was familiar, and very C 
like (which is the best kind of syntax IMHO). I decided to try 
it.. and I just found it easy to work with...despite some bugs, 
which you kinda of have to accept for now..but it's getting a lot 
better.

Most importantly for me, is that it works on FreeBSD, otherwise 
I'll lose interest immediately. I still use C though, as C is 
still 'the' primary language on x..BSD, and will remains so for 
the forseeable future.

But gee.. I can do things in D so easily and quickly compare to 
C, and I don't feel like I giving up much for that convenience. 
Compare that to running dotnet ... grrrr...you sit there just 
waiting for the program to load.

So everyone comes to a new language with their own requirements.

Work out what your's are... or just play with it.. and enjoy what 
it has to offer.
Dec 27 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2017-12-28 at 03:34 +0000, codephantom via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I tried Go. I didn't like it. Syntax changes were not necessary,=20
 and I got the feeling that the philosophy of Go, is that=20
 programmers are incompetent and need training wheels. It wasn't=20
 for me.


The core of go is lightweight processes and message passing/channels.
This makes it an excellent language and one of the reasons it has taken
off. (D has heavyweight processes and message passing which is great,
but isn't the same as Go.) A core principle for Go is that Google
interns can't break stuff in Google code. Add that to being a GC
focused extension of C and voila Go. It is a good language if you get
into it: a small language with a few annoying quirks, but a simple way
of working with objects and types, a small well constructed core
library, and a quasi-infinite, flexible secondary library, that allows
anyone to contribute at any time.

Plus the implicit pressure of being from Google, with JetBrains IDE
supports, and you get a very successful language, that has ended up
being a niche language: The Web. As opposed to being a general purpose
systems programming language.


 I looked at Rust, but never tried it, as I found the syntax to=20
 pretty awful - and it reminded my too much of C++.


The syntax is fine, and it is so unlike C++, it is easy to get into. I
am using Rust as my primary language for all GStreamer stuff now.


 I looked at D, it looked nice. Syntax was familiar, and very C=20
 like (which is the best kind of syntax IMHO). I decided to try=20
 it.. and I just found it easy to work with...despite some bugs,=20
 which you kinda of have to accept for now..but it's getting a lot=20
 better.
=20
 Most importantly for me, is that it works on FreeBSD, otherwise=20
 I'll lose interest immediately. I still use C though, as C is=20
 still 'the' primary language on x..BSD, and will remains so for=20
 the forseeable future.


Which is a tragedy. Why use portable assembler in 2017 when there are
actual high level languages such as Go, Rust, D, available for
everything except the very lowest level work.


 But gee.. I can do things in D so easily and quickly compare to=20
 C, and I don't feel like I giving up much for that convenience.=20
 Compare that to running dotnet ... grrrr...you sit there just=20
 waiting for the program to load.



wrong context and so got a bad feel. The same is true for Java. Kotlin,
Groovy, I guess which are great in a JVM-centred context.


 So everyone comes to a new language with their own requirements.


But mostly their own prejudices. Everyone brings their baggage.


 Work out what your's are... or just play with it.. and enjoy what=20
 it has to offer.
=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
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
Dec 28 2017
parent reply codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder 
wrote:

 On Thu, 2017-12-28 at 03:34 +0000, codephantom via 
 Digitalmars-d wrote:

 


 […]

 I tried Go. I didn't like it. Syntax changes were not I looked 
 at Rust, but never tried it, as I found the syntax to pretty 
 awful - and it reminded my too much of C++.


 The syntax is fine, and it is so unlike C++, it is easy to get 
 into. I am using Rust as my primary language for all GStreamer 
 stuff now.


I disagree.

Here is some Rust code...

use std::io::stdin;
fn someFunction(vec: Vec<int>) {}
let  mut vec = Vec::new();
let mut age: i32 = 1;
etc...
etc.....

The syntax is just weird, in my opinion.. it's like some martian 
language...

Clearly, applied psychology was not front of mind when designing 
that syntax ;-)
(and I believe the syntax was pretty controverial anyway, and 
underwent constant changes...but they still managed to get it 
wrong .. in my opinion).


 But gee.. I can do things in D so easily and quickly compare 
 to C, and I don't feel like I giving up much for that 
 convenience. Compare that to running dotnet ... grrrr...you 
 sit there just waiting for the program to load.



 is the wrong context and so got a bad feel. The same is true 
 for Java. Kotlin, Groovy, I guess which are great in a 
 JVM-centred context.




several seconds sometimes before the dotnet runtime loads itself 
and starts doing the job I asked it to do. Once it runs it's not 
'too' bad, but still noticably slower than a native compiled 

people wait for things to load like this is just pathetic..it 
needs to get better... or in the dumpster it goes.
Dec 28 2017
parent reply Mengu <mengukagan gmail.com> writes:
On Friday, 29 December 2017 at 00:26:04 UTC, codephantom wrote:

 On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder 
 wrote:

[...]


 I disagree.

 [...]


syntax is not weird at all. it is ML-ish.
Dec 28 2017
parent codephantom <me noyb.com> writes:
On Friday, 29 December 2017 at 07:54:53 UTC, Mengu wrote:

 On Friday, 29 December 2017 at 00:26:04 UTC, codephantom wrote:

 On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder 
 wrote:

[...]


 I disagree.

 [...]


 syntax is not weird at all. it is ML-ish.


oh. I didn't know..

in any case, ML syntax is even weirder ;-)

Since a large portion of programmers ( I assume) are familiar 

understand why Rust chose to go down a completely different path 
with their syntax.

Familiar syntax is really important, especially as I swap between 
those langauges that I just mentioned..alot.

Rust is out, for me, simply because I don't want to be confused 
by their weird syntax everytime I go from one language to the 
next. With D, I can switch constantly from it to C, without 
incurring any syntax induced psychological trauma.
Dec 29 2017
prev sibling parent Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Thursday, 28 December 2017 at 00:36:32 UTC, Dan partelly wrote:

 On Wednesday, 27 December 2017 at 22:36:08 UTC, Walter Bright 
 wrote:

 On 12/27/2017 8:57 AM, Laeeth Isharc wrote:

 It's much better to have a monopoly of some niche or set of 
 niches and to use energy from success to expand out from 
 there, than to have a small market share of an enormous 
 market.


 Back in the 80's, Zortech made a killing because we had the 
 only C++ compiler that would generate 16 bit Windows code.

 I found this out by asking the sales guys what feature of 
 ZTC++ was closing the deal - X, Y, Z, all the features I held 
 dear. They'd say nope. Customers wanted to use C++ for Win16, 
 ZTC++ supported that, sold!

 I learned a lot from that.


 That a product which fulfils a need in a total void sells? No 
 disrespect, but aint it a bit tautological ? Can you find a 
 similar void today which is to be filled by D ? Better yet can 
 you create one ?


Read Peter Thiel's Zero To One, and maybe Walter's point will 
become clear.  If you don't want to read it, that's fine too, but 
it's hard to have a discussion if someone isn't familiar with the 
background of how challengers very often tend to succeed and 
isn't interested to learn about it.

Yes, evidently enough  people using D believe it fills a need.  
See list of companies using D.  Most of them have better things 
to do than post in the forum however.

 From my point of view, D already has a monopoly, as I don't see 
an alternative that's in the same league for what I want to do. 
I'm not going to spell out all the reasons here.

By far the best thing if you want to form an assessment of the 
language for your own needs is to watch a bunch of dconf videos, 
read the bits of Phobos that appeal to you, read lots of other D 
code and start trying to solve your own problems.

I don't think it's a language suitable for everyone, but I do 
think most people for whom it's suitable today will quickly get 
why if they take some of those steps I suggested...
Dec 27 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 14:36 -0800, Walter Bright via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 I found this out by asking the sales guys what feature of ZTC++ was
 closing the=20
 deal - X, Y, Z, all the features I held dear. They'd say nope.
 Customers wanted=20
 to use C++ for Win16, ZTC++ supported that, sold!
 [=E2=80=A6]


Give the punters what they want, even if it is not what they need or
should want. ;-)

--=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
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
Dec 28 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2017 9:13 AM, Laeeth Isharc wrote:

 New things grow at the fringes.  See the work of Clayton Christensen and his 
 book the Innovator's Dilemma.  A head-on assault is ill-advised.  People
looking 
 for salvation are easier to talk to than those who don't see anything wrong
with 
 what they're doing currently.


Yes, great book! That's the purpose of -betterC. Going after the fringes.
Dec 25 2017
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2017 8:51 AM, Patrick Schluter wrote:

 I ported 1 app from Java to D. It was so unspectacular (or better said it was 
 spectacularly easy) that you're probably right. Reaching to Java devs is a
good 
 idea. The advantage of Java though, is not the language but the huge, huge,
huge 
 existing libraries and packages and know how. This will be difficult to 
 overcome  for any language.


Yup. It's the library that makes Java, not the language. This makes it pretty 
hard to attract Java devs.
Dec 25 2017
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 24 December 2017 at 16:51:45 UTC, Patrick Schluter 
wrote:

 That's the biggest problem with C++, they pile on relentlessly 
 half baked feature after half baked feature in a big dump that 
 no one with a life can ever grasp.


I think D has more first class language features (and thus 
special casing) than C++.  For instance, C++ lambdas are just 
sugar over objects and most of the new stuff is primarily library 
features with some minor language tweaks to back it. So I don't 
think the core C++ language itself has changed dramatically.

Like, constexpr is mostly about allowing things that were 
forbidden, but it is opening new ways to structure code, which in 
turn "deprecates" some old clumsy idioms… Except those old clumsy 
idioms linger… both in online tutorials, in code bases and of 
course in the mentality of the programmers…

Since those "deprecated" idioms are built by combining features 
it cannot easily be detected and transformed into "modern" idioms 
by a tool either. Whereas a high level dedicated language feature 
could more easily be "deprecated" and dealt with in a language 
upgrade.

Which is one downside of using library-based constructs over 
language constructs.

So I am a bit torn on library vs language features.  From an 
aesthetics point of view having a small and expressive language 
seems like the better choice, but one can make good arguments for 
a low level oriented DSL as well.

With a well designed DSL the compiler author might more easily 
reason about the programmers intent and perhaps make better 
optimization choices… thus allowing the programmer to write more 
readable performant code…

I think the DSL approach makes more sense as computer 
architecture get less simplistic.

Although currently CPU vendors target C-like code, that might 
change in the future as less code is written in C-like languages…
Dec 30 2017
prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
Programming languages are tools for solving problems, and people 
face different problems and they also have different capabilities 
and tastes, which means even for people facing identical 
problems, the right tool for the job may not be the same because 
they aren't identical as groups and as individuals.

Languages are also about much more than syntax; they are also 
about communities, ecosystems, and values.  In the beginning 
people generally join a community because they admire the values 
and capabilities of those prominent in the community.  Prestige 
often has a lot to do with that.

How does prestige develop?  From tangible consequences produced 
by able and virtuous people acting together to create something.  
There's a long lead time on that one, but it's not something that 
can be rushed.

It's also hard to begin something - much energy poured in for no 
tangible result.  You love your creation, but for a long time 
indeed it does not love you back.  However once it ignites then 
things take on a momentum of their own.  It's almost impossible 
to believe because you're expecting it to be difficult, like 
usual, and somehow things just almost magically start to unfold 
in that direction without your having to do that much.

On Sunday, 24 December 2017 at 15:00:09 UTC, Dylan Graham wrote:

 How much further does D have to go to start snatching C++'s 
 userbase?


That's already happening, surely.  Here there are lots of former 
C++ programmers, or professional C++ programmers who write D on 
the side.  Andy Smith gave a talk about use of D in the automated 
trading systems at a financial company - I won't say who it is, 
but it's a very well-known firm that's well established and in 
the top handful of hedge funds.

We're a newer fund (established in 2014, we were the largest 
Asian hedge fund startup), but we're starting to explore the use 
of D, and one project where we are moving to D was originally 
written in C++.  It forms the basis of our analytics across the 
firm.  And I didn't need to sell it because when someone is 
suffering they are looking for salvation, which is what D 
represents.

Before, we had C++ analytics (and for each one the implementation 



function???  And a new trader starts who would like to access the 
analytics from Python.  Oh, and it would also be nice to have the 
analytics accessible from R, Java, Julia and Matlab.

Conceptually, there are other ways to get to the same result.  
But practically for us we decided to rewrite the analytics in D 
and generate code at compile-time to wrap the functions to make 
them accessible from other languages (for native code ABI, with 
other language wrapping being generated at a combination of 
compile and run-time).  It's by far a cleaner and easier-to-read 
solution.  And it doesn't need selling to anyone, because it's an 
upfront cost that pays dividends for years not just on current 
code but all the new code that will be written in time.  D has 
unit-testing and documentation generation built in, and as far as 
the community goes, there's an expectation that you use these!

Wrapping for Excel is largely done (excel-d) and I've got 
something basic that can be used for Java if you are relaxed 
about efficiency (which we mostly are for that use case).  We're 

now fixed to work also on 64 bit Windows), but we will try going 
via generating Cython as it's a bit cleaner.  There's still more 
work to do, but it's a much better solution.

And I think that's how D will be adopted.  People who have 
problems, for which using D is in part the solution.  And 
decision-makers who are acting as principals not agents, so that 
they can act without having to spend a huge investment on 
addressing social factors (there are always social factors, but 
it's a matter of proportion).

Liran at Weka didn't have to ask someone to decide to use a new 
language he had never used before for a startup building complex 
code that had to just work.  He had earned the right to decide, 
and there's plenty of risk in a startup anyway, and I suppose his 
investors trusted his judgment.  Similarly, Remedy Games had a 
problem, and from his account of it, Manu was not entirely 
serious when he suggested why don't we use D for scripting, but 
the group was receptive, and they didn't need to make a 
presentation to the board to act.  Andy Smith was in a position 
where he could 'build a prototype' in D, and then decide it 
wasn't necessary after all to rewrite in C++.

Of course recognition that D can be helpful won't happen all by 
itself.  It's worth doing the work to spread awareness, as we 
are.  But if people agree, then I think talking about success 
stories, warts and all, is likely to be quite persuasive.  And 
also to explain how to address the difficulties of relatively 
early adoption (Manu talked about documentation, training 
materials and so on).


 The C++ juggernaut keeps piling on new features every 3 years. 
 It's hard for D to stay in the lead (that is if it is).


Then why do C++ programmers here say D has ruined them for C++.  
Piling on features and never refactoring,redesigning, or removing 
old functionality - what does that lead to in an application?  
And it's not better in a programming language.




 and performance sucks.


 OOP can do and offers many other paradigms. D is more a toolbox 
 to let you program the way you want. C++ is much the same, just 
 uglier. Thus, there's going to be less draw to D from C++.


And OO has other difficulties in terms of readability and 
fragmentation of the code.  The banana/gorilla/jungle problem 
described by Joe Armstrong.



 would have a greater appeal on those audiences.


It's not a quantity of features thing though, is it?  People 
don't like Apple products because they have more features (even 
when they do).  It's because of good design, and that's something 
you can copy but that it is difficult to do in a dynamic sense.


 I think D should try to advertise to more restrictive languages 


 crowd than it will from the C++ crowd.


Facebook say 'code wins arguments'.  So it's much better to write 
a blog post and say other people should do more along these lines 
than just argue for it.  And concrete and vivid examples might be 
more persuasive (though complementary to technical arguments).
Dec 24 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2017-12-24 at 16:58 +0000, Laeeth Isharc via Digitalmars-d
wrote:

 Programming languages are tools for solving problems, and people=20
 face different problems and they also have different capabilities=20
 and tastes, which means even for people facing identical=20
 problems, the right tool for the job may not be the same because=20
 they aren't identical as groups and as individuals.


Thinking of a programming language as a domain specific language for
solving problems in a domain helps with this. Along with can a language
enable creation of a DSL for solving my problems. Creating functions is
creating a DSL in any language.


 Languages are also about much more than syntax; they are also=20
 about communities, ecosystems, and values.  In the beginning=20
 people generally join a community because they admire the values=20
 and capabilities of those prominent in the community.  Prestige=20
 often has a lot to do with that.


The issue of communities, aka tribes, cannot be underestimated. The
sense of belonging, and us vs. them, are very, very powerful in
determining success and failure for any programming language.


 How does prestige develop?  From tangible consequences produced=20
 by able and virtuous people acting together to create something. =20
 There's a long lead time on that one, but it's not something that=20
 can be rushed.


And sales and marketing. Arguably C was the last language that got
traction based solely on technical benefit and tribalism. All other
languages with traction since have had serious marketing behind them.
=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
Dec 24 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Sunday, 24 December 2017 at 21:27:12 UTC, Russel Winder wrote:

 And sales and marketing. Arguably C was the last language that 
 got
 traction based solely on technical benefit and tribalism. All 
 other
 languages with traction since have had serious marketing behind 
 them.


1995. A dark year. Two of the crappiest language ever devised by 
man arrived. Both gained traction. Java, through marketing. PhP 
though tribalism.
Dec 24 2017
next sibling parent reply Tony <tonytdominguez aol.com> writes:
On Sunday, 24 December 2017 at 22:04:00 UTC, Dan Partelly wrote:


 1995. A dark year. Two of the crappiest language ever devised 
 by man arrived. Both gained traction. Java, through marketing. 
 PhP though tribalism.


What makes Java a "crappy" language?

I think PHP's success is due to its ability to integrate HTML 
statements. Also, it was often the only option back in the day 
from cheap web hosting services. And it seemed like on those 
cheap web hosts, when offered, Python and Perl were accessed via 
CGI, while PHP used via an Apache module which I think gave it a 
speed/resource utilization advantage.
Dec 24 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Sunday, 24 December 2017 at 22:21:28 UTC, Tony wrote:

 On Sunday, 24 December 2017 at 22:04:00 UTC, Dan Partelly wrote:


 1995. A dark year. Two of the crappiest language ever devised 
 by man arrived. Both gained traction. Java, through marketing. 
 PhP though tribalism.


 What makes Java a "crappy" language?


It starts with "everything must be a class". An die hard OOP 
language with little support for anything else. And to put it in 
the words of the great Alex Stepanov:


Yes. STL is not object oriented. I think that object orientedness 
is almost as much of a hoax as Artificial Intelligence. I have 
yet to see an interesting piece of code that comes from these OO 
people. [1]

The second big issue this language caused is social in nature - 
the intellectual eclipse in schools and the programmers it 
created. See "The Perils of Java schools"[2].

It beget some horrific software, bloated to hell. I recall seeing 
desktop financial apps which spawned web servers on desktop and 
had the UI in browser. Starting slow, big, the Java mentality 
beget those horrors. You could see Wirth's law [3] in every 
almost every program.

[1] http://www.stlport.org/resources/StepanovUSA.html
[2] 
https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/
[3] https://en.wikipedia.org/wiki/Wirth%27s_law
Dec 25 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2017-12-25 at 08:12 +0000, Dan Partelly via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 It starts with "everything must be a class". An die hard OOP=20
 language with little support for anything else. And to put it in=20
 the words of the great Alex Stepanov:
=20
=20
 Yes. STL is not object oriented. I think that object orientedness=20
 is almost as much of a hoax as Artificial Intelligence. I have=20
 yet to see an interesting piece of code that comes from these OO=20
 people. [1]


Very much the same could be, and indeed has been, said of the STL. i.e.
that there is no interesting piece of software using it. Having said
that it also caused a useful revolution in programming in the area
where C++ was, and is, used.

One persons opinion is irrelevant, unless you believe in advocacy
research.


 The second big issue this language caused is social in nature -=20
 the intellectual eclipse in schools and the programmers it=20
 created. See "The Perils of Java schools"[2].


There were problem with the Java revolution in university education in
1994, but there was also a lot of good stuff that came out of it.
Without a proper historical analysis, all that is left is (non-
constructive) prejudice.


 It beget some horrific software, bloated to hell. I recall seeing=20
 desktop financial apps which spawned web servers on desktop and=20
 had the UI in browser. Starting slow, big, the Java mentality=20
 beget those horrors. You could see Wirth's law [3] in every=20
 almost every program.


There is no doubt that software bloat has been a problem over the
years. Much of it is centred on Java, but then there is a lot in all
software. But then C and C++ brought us buffer overruns. All
programming languages bring awfulness as well as some goodness.

--=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
Dec 25 2017
parent reply Dan Partelly <i i.com> writes:
On Monday, 25 December 2017 at 10:20:44 UTC, Russel Winder wrote:


 One persons opinion is irrelevant, unless you believe in 
 advocacy research.


I believe in it in the sense that it can be used to stir powerful 
social forces to serve propaganda. No language should be without 
propaganda, since adoption will most likely be more modulated by 
social factors instead of technical excellence.
Dec 26 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2017-12-26 at 08:18 +0000, Dan Partelly via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 I believe in it in the sense that it can be used to stir powerful=20
 social forces to serve propaganda. No language should be without=20
 propaganda, since adoption will most likely be more modulated by=20
 social factors instead of technical excellence.
=20


All of which brings us full circle: when it comes to programming
languages and software development, it is all about advocacy,
prejudice, and belief, there is very, very little science happening =E2=80=
=93
and most of the science that is happening is in the psychology of
programming, about which most developers of programming languages know
nothing.

--=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
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
Dec 26 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 12:18:09 UTC, Russel Winder wrote:

 All of which brings us full circle: when it comes to 
 programming languages and software development, it is all about 
 advocacy, prejudice, and belief, there is very, very little 
 science happening – and most of the science that is happening 
 is in the psychology of programming, about which most 
 developers of programming languages know nothing.


+1

I genuinely believe, that it is psychological science that will 
play the most important role in terms of what programming 
languages of the future will look like.

psychological studies should be integrated into every CS course.
Dec 26 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2017-12-26 at 12:26 +0000, codephantom via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I genuinely believe, that it is psychological science that will=20
 play the most important role in terms of what programming=20
 languages of the future will look like.
=20
 psychological studies should be integrated into every CS course.


Sadly I cannot see either of these happening. There is already too much
to pack in to an undergraduate CS (*) course even if first programming
and simple algorithms moves out into pre-university education =E2=80=93 as =
has
now happened in the UK. Also far too few universities have good
CS/Psych cooperation.

There also needs to be much greater education everywhere about socio-
technical systems. To be honest I'd prioritise this over programming
language design since programmers can always use crap languages, but
can they build the right system right?


(*) CS is a misnomer, computer science is not really about computers,
and there is essentially no science in 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
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
Dec 26 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Tuesday, 26 December 2017 at 15:53:50 UTC, Russel Winder wrote:


 There also needs to be much greater education everywhere about 
 socio- technical systems. To be honest I'd prioritise this over 
 programming language design since programmers can always use 
 crap languages, but can they build the right system right?


Ok I'll bite. Can you recommend me some reasonable easy 
literature. Something you can read in free time when you travel, 
not study.   Social interactions where always interesting for me.


 (*) CS is a misnomer, computer science is not really about 
 computers, and there is essentially no science in it.


Yeah, Abelson started his SICP lectures proclaiming that. At 
least the '86 edition which is noe on net.
Dec 26 2017
parent codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 16:50:54 UTC, Dan Partelly wrote:

 Ok I'll bite. Can you recommend me some reasonable easy 
 literature. Something you can read in free time when you 
 travel, not study.   Social interactions where always 
 interesting for me.


https://en.wikipedia.org/wiki/Civilization_and_Its_Discontents
Dec 26 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 15:53:50 UTC, Russel Winder wrote:

 Sadly I cannot see either of these happening. There is already 
 too much to pack in to an undergraduate CS (*) course even if 
 first programming and simple algorithms moves out into 
 pre-university education – as has now happened in the UK. Also 
 far too few universities have good CS/Psych cooperation.


This is changing though, particulary as a result of advances in 
cognitive neuroscience.

i.e. These sciences are bringing about new 'quantifiable' 
knowledge, which can then be formally integrated into education.

But the design of graduate studies really needs to be radically 
transformed, as they simply try to pack far too much in...leaving 
students without any time to reflect on what they're doing, or 
why they're doing it.

In addition, we live in 'the age of distractions and 
mulitasking', so students really learn very little these days 
from doing a degree..(particulary those packed with too much 
stuff).

I think this is why (at least in Australia), there is a 
significant trend towards studying degrees part-time - the 
cognitive load of full-time degrees not longer support the way 
people want to (or just happen to) live these days.

Until univerties stop trying to be money making machines, and get 
back to teaching people how to learn about useful things, then 
not much will change.

Anyway, too see how useful it is, to combine psychology and 
programming language/library design, here is a great paper:

https://synesthesiam.com/assets/hansen2012_architectures.pdf

btw. One of the things I like most about D, has to do with 
'chunking comprehension' - and in comparison to C or C++, D is 
the winner for sure.
Dec 26 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 01:23 +0000, codephantom via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 But the design of graduate studies really needs to be radically=20
 transformed, as they simply try to pack far too much in...leaving=20
 students without any time to reflect on what they're doing, or=20
 why they're doing it.


In which country? All countries have different education systems: you
cannot apply a criticism of one globally.
=20

 In addition, we live in 'the age of distractions and=20
 mulitasking', so students really learn very little these days=20
 from doing a degree..(particulary those packed with too much=20
 stuff).


And the evidence is? I know the USA government department are no longer
allowed to use words and concepts such as science-based and evidence-
based, but the rest of the world still works on needing evidence to
back up an opinion.


 I think this is why (at least in Australia), there is a=20
 significant trend towards studying degrees part-time - the=20
 cognitive load of full-time degrees not longer support the way=20
 people want to (or just happen to) live these days.


Or they just do not have the money to study full-time?


 Until univerties stop trying to be money making machines, and get=20
 back to teaching people how to learn about useful things, then=20
 not much will change.


Not sure which country this is an observation on, but again all
countries are different so a global opinion is not possible. The
problem in the UK is the shift from wholly government funded tertiary
education, to partially government, partially personal funded tertiary
education. The cynical would see this as a way of stopping poor people
getting an education.=20


 Anyway, too see how useful it is, to combine psychology and=20
 programming language/library design, here is a great paper:
=20
 https://synesthesiam.com/assets/hansen2012_architectures.pdf
=20
 btw. One of the things I like most about D, has to do with=20
 'chunking comprehension' - and in comparison to C or C++, D is=20
 the winner for sure.
=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
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
Dec 28 2017
parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 10:57:55 UTC, Russel Winder 
wrote:

 Not sure which country this is an observation on, but again all 
 countries are different so a global opinion is not possible. 
 The problem in the UK is the shift from wholly government 
 funded tertiary education, to partially government, partially 
 personal funded tertiary education. The cynical would see this 
 as a way of stopping poor people getting an education.


It's odd, that humans are still willing to restrict their 
potential through the limitations of 'money' - money being a 
creation of humans, not a restriction nature imposed on us. I 
just don't get it.

The D project is a nice example of people just working together 
to achieve something that all can benefit from.
Dec 28 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 4:18 AM, Russel Winder wrote:

 All of which brings us full circle: when it comes to programming
 languages and software development, it is all about advocacy,
 prejudice, and belief, there is very, very little science happening –
 and most of the science that is happening is in the psychology of
 programming, about which most developers of programming languages know
 nothing.


If you're hinting that I know nothing about the topic, you're mistaken :-)

A fair amount of D's design is based on psychology.
Dec 26 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright 
wrote:


 A fair amount of D's design is based on psychology.


Please elaborate. Which parts ? Where the results you got the 
projected ones, or disappointments ?
Dec 27 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 1:38 AM, Dan Partelly wrote:

 On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:

 A fair amount of D's design is based on psychology.


 Please elaborate. Which parts ? Where the results you got the projected ones,
or 
 disappointments ?



Builtin unittests and Ddoc, for example. There's a big psychological advantage 
to having them built in rather than requiring an external tool. The closeness
to 
C syntax is no accident, for another.

I've been in the compiler biz since the early 80s, working with customers,
doing 
tech support. That results in experience in what works for people and what 
doesn't, even if it is not scientific or better from a CS point of view.
Dec 27 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d
wrote:
[=E2=80=A6]

=20
 Builtin unittests and Ddoc, for example. There's a big psychological
 advantage=20
 to having them built in rather than requiring an external tool. The
 closeness to=20
 C syntax is no accident, for another.
=20
 I've been in the compiler biz since the early 80s, working with
 customers, doing=20
 tech support. That results in experience in what works for people and
 what=20
 doesn't, even if it is not scientific or better from a CS point of
 view.


This does not support the original claim that the design of D by you is
based on psychology. It may be based on your perception of other
programmers needs, which is fine per se, but that is not psychology-
based design.=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
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
Dec 27 2017
next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder 
wrote:

 On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via 
 Digitalmars-d
 wrote:
 […]

 
 Builtin unittests and Ddoc, for example. There's a big 
 psychological
 advantage
 to having them built in rather than requiring an external 
 tool. The
 closeness to
 C syntax is no accident, for another.
 
 I've been in the compiler biz since the early 80s, working with
 customers, doing
 tech support. That results in experience in what works for 
 people and
 what
 doesn't, even if it is not scientific or better from a CS 
 point of
 view.


 This does not support the original claim that the design of D 
 by you is based on psychology. It may be based on your 
 perception of other programmers needs, which is fine per se, 
 but that is not psychology- based design.


That's like saying the way George Soros trades is not based on 
psychology because he doesn't refer to the literature in making 
and articulating his decision-making process.  Instead people 
write papers about how he thinks, because it's not yet in the 
literature!

If published knowledge were what was most important or valuable 
then anyone intelligent with an interest in a subject would be 
part of a war of all against all, because how is it possible to 
have an edge?  But I don't think human expertise can be described 
in that manner.  Karl Polanyi's work is quite interesting:

https://en.wikipedia.org/wiki/Tacit_knowledge
Dec 27 2017
next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 December 2017 at 16:44:25 UTC, Laeeth Isharc 
wrote:

 On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder 
 wrote:

 On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via 
 Digitalmars-d
 wrote:
 […]

 
 Builtin unittests and Ddoc, for example. There's a big 
 psychological
 advantage
 to having them built in rather than requiring an external 
 tool. The
 closeness to
 C syntax is no accident, for another.
 
 I've been in the compiler biz since the early 80s, working 
 with
 customers, doing
 tech support. That results in experience in what works for 
 people and
 what
 doesn't, even if it is not scientific or better from a CS 
 point of
 view.


 This does not support the original claim that the design of D 
 by you is based on psychology. It may be based on your 
 perception of other programmers needs, which is fine per se, 
 but that is not psychology- based design.


 That's like saying the way George Soros trades is not based on 
 psychology because he doesn't refer to the literature in making 
 and articulating his decision-making process.  Instead people 
 write papers about how he thinks, because it's not yet in the 
 literature!

 If published knowledge were what was most important or valuable 
 then anyone intelligent with an interest in a subject would be 
 part of a war of all against all, because how is it possible to 
 have an edge?  But I don't think human expertise can be 
 described in that manner.  Karl Polanyi's work is quite 
 interesting:

 https://en.wikipedia.org/wiki/Tacit_knowledge


On Soros:
http://marketfocusing.com/downloads/soros.pdf
Dec 27 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 16:44 +0000, Laeeth Isharc via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 That's like saying the way George Soros trades is not based on=20
 psychology because he doesn't refer to the literature in making=20
 and articulating his decision-making process.  Instead people=20
 write papers about how he thinks, because it's not yet in the=20
 literature!
=20
 If published knowledge were what was most important or valuable=20
 then anyone intelligent with an interest in a subject would be=20
 part of a war of all against all, because how is it possible to=20
 have an edge?  But I don't think human expertise can be described=20
 in that manner.  Karl Polanyi's work is quite interesting:
=20
 https://en.wikipedia.org/wiki/Tacit_knowledge
=20


I think you are missing the point, but to continue this here is to go
way off topic for this thread and indeed this email list, so maybe we
should start a thread elsewhere to continue this.

--=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
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
Dec 28 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 8:29 AM, Russel Winder wrote:

 This does not support the original claim that the design of D by you is
 based on psychology. It may be based on your perception of other
 programmers needs, which is fine per se, but that is not psychology-
 based design.


All programming language design is based on human factors, i.e. psychology. If 
it was purely computer science based, it would be in binary.
Dec 27 2017
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 04:49:04 UTC, Walter Bright 
wrote:

 On 12/27/2017 8:29 AM, Russel Winder wrote:

 This does not support the original claim that the design of D 
 by you is
 based on psychology. It may be based on your perception of 
 other
 programmers needs, which is fine per se, but that is not 
 psychology-
 based design.


 All programming language design is based on human factors, i.e. 
 psychology. If it was purely computer science based, it would 
 be in binary.


01100010 01110101 01110100 00100000 01001001 00100000 01100011 
01100001 01101110 00100000 01110011 01110000 01100101 01100001 
01101011 00100000 01100010 01101001 01101110 01100001 01110010 
01111001 00100000 01101010 01110101 01110011 01110100 00100000 
01100110 01101001 01101110 01100101 00100001
Dec 27 2017
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 20:49 -0800, Walter Bright via Digitalmars-d
wrote:

 On 12/27/2017 8:29 AM, Russel Winder wrote:

 This does not support the original claim that the design of D by
 you is
 based on psychology. It may be based on your perception of other
 programmers needs, which is fine per se, but that is not
 psychology-
 based design.


=20
 All programming language design is based on human factors, i.e.
 psychology. If=20
 it was purely computer science based, it would be in binary.


If you want to believe that fine. Clearly you are missing the point I
am making, which clearly must be my fault for bad expression. Also
clear it is not worth progressing this debate.

--=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
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
Dec 28 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2017 2:54 AM, Russel Winder wrote:

 Clearly you are missing the point I
 am making, which clearly must be my fault for bad expression.


Whether it's your fault or mine, I apparently have no idea what you mean by the 
phrase "psychology based design".



 Also clear it is not worth progressing this debate.


Not necessarily true. I have always been interested in human factors design, 
going back to my experience designing airplane parts and talking with the 
cockpit design engineers.

A fun example is the warning horns in the cockpit. One was added, I think for 
stall warning. It turned out to be remarkably effective. So they added horns
for 
other emergencies, each with a distinct sound so the pilot could distinguish
them.

But it turned out, in a high stress situation, the pilot would get confused 
associating the sound with what just went wrong, and would take the wrong 
corrective action. Boeing then had the brilliant (and obvious in hindsight, as 
these things so often are) of replacing the horn sounds with words. So the
stall 
warning horn becomes "stall, stall" (I forgot the exact words for it). Problem 
solved!

With programming language design, I'm pretty interested in why programmers make 
the mistakes they do, and if the propensity for making those mistakes can be 
blunted by altering the design of the language. There's a lot of that in D. (I 
enjoy reading articles about what static checkers do, and articles that collect 
statistics on types of bugs.)
Dec 28 2017
prev sibling parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 10:54:08 UTC, Russel Winder 
wrote:

 If you want to believe that fine. Clearly you are missing the 
 point I am making, which clearly must be my fault for bad 
 expression. Also clear it is not worth progressing this debate.


You are asking Walter to 'quantify' something that simply does 
not need to be quantified. This is the problem with the 
scientific method.

Not everything needs to be, or can be, or should be, quantified.

Some things just make sense, and it is obvious, and it can be 
left at that.

Like not having to annotate functions with func, or fn.

Not having to use := when you mean =

etc..
etc....
Dec 28 2017
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright 
wrote:

 On 12/26/2017 4:18 AM, Russel Winder wrote:

 All of which brings us full circle: when it comes to 
 programming
 languages and software development, it is all about advocacy,
 prejudice, and belief, there is very, very little science 
 happening –
 and most of the science that is happening is in the psychology 
 of
 programming, about which most developers of programming 
 languages know
 nothing.


 If you're hinting that I know nothing about the topic, you're 
 mistaken :-)

 A fair amount of D's design is based on psychology.


I'd love to hear more about this sometime.  I think that's what 
people who assess languages based on checklists miss - it's the 
gestalt of the features and how they are organised and the 
consequence of this for the pattern of the code as it emerges, 
rather than particular tickbox features that's appealing.  (I 
agree with code phantom that an adaptation to how people chunk is 
one of those benefits).
Dec 27 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc 
wrote:


 A fair amount of D's design is based on psychology.


 I'd love to hear more about this sometime.


I never thought of this in the context of programming languages, 
but behavior is strongly modulated genetically, epi-genetically, 
and environmentally (this includes the social component).

Some of the forces modulating behaviors are terrifyingly 
powerful. Psycho-social biases and social forces are prime among 
those. So powerful they are that they can make individuals do 
things without even realizing. Conformity, obedience , influence, 
cognitive dissonance,  hundreds (Im not kidding) of social 
biases, in group / out group politics , pride, fear.

No one is immune not even the smartest of us and most exact of 
us. PhD to 8 classes only we are all influenced by those. 
Powerfully.

So it's not really exactly something unexpected that success of a 
programming language is powerfully modulated by this phenomena. 
Everything is. Including how you vote, what is your opinion on 
the right to bear weapon, on wars, on who is the friend and who 
is the enemy and
what is moral or imoral.
Dec 27 2017
parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 December 2017 at 16:53:16 UTC, Dan Partelly 
wrote:

 On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc 
 wrote:


 A fair amount of D's design is based on psychology.


 I'd love to hear more about this sometime.


 I never thought of this in the context of programming 
 languages, but behavior is strongly modulated genetically, 
 epi-genetically, and ***environmentally** (this includes the 
 social component).


Japanese cars were dismissed and laughed at for the longest time. 
  When the price of energy went bananas in the 1970s US auto 
makers were not laughing any more.  (And strategically it would 
have been terrible for the Japanese if US manufacturers had taken 
them seriously earlier).

So big relative price shocks have something to do with adoption.

https://www.quora.com/Python-programming-language-1/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc

https://queue.acm.org/detail.cfm?id=2874238

"For the entire careers of most practicing computer scientists, a 
fundamental observation has consistently held true: CPUs are 
significantly more performant and more expensive than I/O 
devices. The fact that CPUs can process data at extremely high 
rates, while simultaneously servicing multiple I/O devices, has 
had a sweeping impact on the design of both hardware and software 
for systems of all sizes, for pretty much as long as we've been 
building them.

***This assumption, however, is in the process of being 
completely invalidated.***
"
Dec 27 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 8:38 AM, Laeeth Isharc wrote:

 On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:

 On 12/26/2017 4:18 AM, Russel Winder wrote:

 All of which brings us full circle: when it comes to programming
 languages and software development, it is all about advocacy,
 prejudice, and belief, there is very, very little science happening –
 and most of the science that is happening is in the psychology of
 programming, about which most developers of programming languages know
 nothing.


 If you're hinting that I know nothing about the topic, you're mistaken :-)

 A fair amount of D's design is based on psychology.


 
 I'd love to hear more about this sometime.


One fun example is our quest to find the right keyword for read only data. A 
long list of words were examined, like readonly, invariant, etc. Some had 
various baggage connotations, some weren't clear what they meant.

We found ourselves constantly saying things like: "readonly means immutable", 
"invariant means immutable", etc. Finally we got hit with a clue-by-four - 
everyone understood what "immutable" meant, so why not just use "immutable"?

Pure psychology, and nothing to do with computer science.

---

Another is it is known that people have cognitive problems with negation. It 
often just does not register in the mind. This is why version statements in D
do 
not have negation. It more or less forces one to think of using positive
version 
identifiers:

     version (hasFeature) { ... }

as opposed to:

     version (!hasFeature) { ... }

or even worse (yes I've seen it):

     version (!doesNotHaveFeature) { ... } // :-(

In order to do negation, one must resort to:

     version (hasFeature) { } else { ... }

Having converted a lot of C code to D and dealing with things like:

     #if !__OSX__
        ... call X ...

having to redesign the case to use positive features:

     version (hasX)
        ... call X ...

makes the code a lot more readable. It's worth it.

The psychological cognitive issues around negation are known, but I rarely see 
deliberate efforts by programmers to deal with that issue. D kinda forces it, 
and I get resistance to it, but it is worthwhile to push it because the results 
are worth it.
Dec 27 2017
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 27 December 2017 at 20:48:12 UTC, Walter Bright 
wrote:

 On 12/27/2017 8:38 AM, Laeeth Isharc wrote:

 On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright 
 wrote:





 The psychological cognitive issues around negation are known, 
 but I rarely see deliberate efforts by programmers to deal with 
 that issue. D kinda forces it, and I get resistance to it, but 
 it is worthwhile to push it because the results are worth it.


I nearly always reorganise my code so that my `if` statements are 
positive precisely because of this. The only times I don't is 
when the negative branch is a lot shorter, so I "get it out of 
the way" sooner. Even then I try to rename the boolean value to 
not require negation.

I had a hard time convincing my colleagues at my previous job 
that this was an issue. Then again I had a hard time convincing 
them unit tests were a good idea, so there's that.

Atila
Dec 27 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 1:00 PM, Atila Neves wrote:

 I nearly always reorganise my code so that my `if` statements are positive 
 precisely because of this. The only times I don't is when the negative branch
is 
 a lot shorter, so I "get it out of the way" sooner. Even then I try to rename 
 the boolean value to not require negation.
 
 I had a hard time convincing my colleagues at my previous job that this was an 
 issue. Then again I had a hard time convincing them unit tests were a good
idea, 
 so there's that.


I once talked to a real estate agent who told me his proxy for a well-built 
house was whether the screw slots on the electrical outlets lined up or not.
Dec 27 2017
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 27.12.2017 21:48, Walter Bright wrote:

 
 Another is it is known that people have cognitive problems with 
 negation. It often just does not register in the mind.


_Phobos_ does not take this point into account though.

I.e., this seems like an excellent time to bring this up again:
https://issues.dlang.org/show_bug.cgi?id=4535

(The action starts at Comment 7.)
Dec 27 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 3:33 PM, Timon Gehr wrote:

 _Phobos_ does not take this point into account though.
 
 I.e., this seems like an excellent time to bring this up again:
 https://issues.dlang.org/show_bug.cgi?id=4535



Phobos has undergone several waves of grand renaming. At some point this has to 
stop and we need stability.
Dec 27 2017
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 28.12.2017 01:16, Walter Bright wrote:

 On 12/27/2017 3:33 PM, Timon Gehr wrote:

 _Phobos_ does not take this point into account though.

 I.e., this seems like an excellent time to bring this up again:
 https://issues.dlang.org/show_bug.cgi?id=4535


 
 
 Phobos has undergone several waves of grand renaming. At some point this 
 has to stop and we need stability.


This is both true and unrelated.
Dec 27 2017
prev sibling parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 00:16:39 UTC, Walter Bright 
wrote:

 Phobos has undergone several waves of grand renaming. At some 
 point this has to stop and we need stability.


There is nothing better for a progamming language than stability.

There is nothing worse for a progamming language than stability.
Dec 27 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 24 December 2017 at 22:21:28 UTC, Tony wrote:

 On Sunday, 24 December 2017 at 22:04:00 UTC, Dan Partelly wrote:


 1995. A dark year. Two of the crappiest language ever devised 
 by man arrived. Both gained traction. Java, through marketing. 
 PhP though tribalism.


 What makes Java a "crappy" language?

 I think PHP's success is due to its ability to integrate HTML 
 statements. Also, it was often the only option back in the day 
 from cheap web hosting services. And it seemed like on those 
 cheap web hosts, when offered, Python and Perl were accessed 
 via CGI, while PHP used via an Apache module which I think gave 
 it a speed/resource utilization advantage.


PHP's success came from the fact that it was free (like in beer) 
and free (like in open source). All other webserver languages 
were at that time either brittle and  difficult (cgi+perl) or 
high cost solutions like ColdFusion. PHP had the advantage that 
providers could install them on their server farms without 
breaking the bank and also with a semblence of performance and 
security.
LAMP could only become what it is because of the free/free aspect 
of its component.
Dec 25 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2017-12-24 at 22:04 +0000, Dan Partelly via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 1995. A dark year. Two of the crappiest language ever devised by=20
 man arrived. Both gained traction. Java, through marketing. PhP=20
 though tribalism.


I thought 1995 was a good year (*). I have no idea about PHP, but the
Java bubble was interesting, especially having watching it evolve
alongside Self in the 1990 to 1994 period.=20

"Crappy" is a subjective thing with no objective usefulness. There was,
and still is, a lot wrong with Java, and indeed the whole OO obsession
(**), but it caused a very useful revolution in 1994. It remains
arguably the single most important programming language in 2017,
whether a liked state or not.


(*) Mostly because I got a Chair of Computing Science at KCL.

(**) There is a lot wrong with the functional obsession as 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
Dec 25 2017
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 24 December 2017 at 21:27:12 UTC, Russel Winder wrote:

 On Sun, 2017-12-24 at 16:58 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:

 Programming languages are tools for solving problems, and 
 people face different problems and they also have different 
 capabilities and tastes, which means even for people facing 
 identical problems, the right tool for the job may not be the 
 same because they aren't identical as groups and as 
 individuals.


 Thinking of a programming language as a domain specific 
 language for solving problems in a domain helps with this. 
 Along with can a language enable creation of a DSL for solving 
 my problems. Creating functions is creating a DSL in any 
 language.


That's an extremely odd way to conceive of D, IMO, like 
conceiving of a banana as being like an apple, only it tastes 
like a banana and has a different shape.

If a general purpose programming language is to be conceived of 
as a domain specific language, what's the difference between a 
true domain specific language and a regular programming language?

That's really the whole point about D.  It's an era where people 
start out assuming that using the right tool for the job means 
that one tool can't do two different kinds of job well.  But, as 
Walter has said elsewhere I think, in some cases that's because 
the tools people are used to using are limited, whereas in fact 
there's no need for that - just use one tool that's good at both. 
  It's going to be a struggle to recognise such a tool if you 
start with the presumption it cannot exist.  And talking about 
languages as identical with DSLs only encourages this 
misconception, I think.



 How does prestige develop?  From tangible consequences 
 produced by able and virtuous people acting together to create 
 something. There's a long lead time on that one, but it's not 
 something that can be rushed.


 And sales and marketing. Arguably C was the last language that 
 got traction based solely on technical benefit and tribalism. 
 All other languages with traction since have had serious 
 marketing behind them.


I don't think I suggested that tribalism in the everyday sense of 
the word is favourable to the adoption of a language.  But that 
aside, C is quite a big example, and I don't see that it has no 
relevance to the present, even though conditions are of course 
different.  Was Python adopted because of a big marketing budget? 
  If so, I didn't know that - who paid for it?  How about R?

I think you also need to consider consequences of beliefs if you 
are wrong and the choices available in circumstances (unless you 
can figure out how to create new choices).  You write as if 
adoption is flatlining.  It isn't - it's growing at a healthy 
pace, as best I can see.  Human perception doesn't deal very well 
with compound growth.  It's disappointing for a long time, and 
all of a sudden it's surprising.

It's by far best at this point to get across successful stories 
about the adoption of D to people who are already receptive to 
them because they have some problems that D might help with than 
to try to get people to listen to you who have no interest in 
listening.  Persuasion works when people are ready to move 
towards you.  You can't compel that.
Dec 27 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 18:41 +0000, Laeeth Isharc via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 That's an extremely odd way to conceive of D, IMO, like=20
 conceiving of a banana as being like an apple, only it tastes=20
 like a banana and has a different shape.


Not really. When you write a function and give it a name, you extend
the working programming language for the application by the label and
it's abstraction.=20
=20

 If a general purpose programming language is to be conceived of=20
 as a domain specific language, what's the difference between a=20
 true domain specific language and a regular programming language?


There isn't one. As you write a program in the base language you extend
the working language by the abstractions, functions, classes, etc. that
you give names to. The application creates it's own working language
based on the base general purpose language.

Further the programmer has their own head language which is based on
the base programming language but with influence of all previously
learned languages. So a person who first learned Fortran and then D has
a different head language to a person who has learned C then D. These
two people appreciate the use of D in different ways so the starting
point for writing any program using D is different.

Marian Petre has spent 30 or so years experimenting on the head
language and programming expertise, as have others.

[=E2=80=A6]

=20
 I don't think I suggested that tribalism in the everyday sense of=20
 the word is favourable to the adoption of a language.  But that=20
 aside, C is quite a big example, and I don't see that it has no=20
 relevance to the present, even though conditions are of course=20
 different.  Was Python adopted because of a big marketing budget?=20
   If so, I didn't know that - who paid for it?  How about R?


Python hit the scene in an interesting way and gained a small
following. That tribe then grew fairly organically without, at least
initially, any formal corporate backing. Even today Python development
is not directly backed by the corporations, but there is significant
indirect support now. You are right, Python is an example, post C, of a
language that grew without marketing budget.

R grew as a domain specific language for statistics. Whilst R could
grow, from what I have seen (so not experimental data), people switch
to Python for it's generality rather than continue with R. My personal
sample is biased as it was hedge funds needing R =E2=86=92 Python training,=
 and
hedge funds and others needing Matlab=E2=86=92 Python training.


 I think you also need to consider consequences of beliefs if you=20
 are wrong and the choices available in circumstances (unless you=20
 can figure out how to create new choices).  You write as if=20
 adoption is flatlining.  It isn't - it's growing at a healthy=20
 pace, as best I can see.  Human perception doesn't deal very well=20
 with compound growth.  It's disappointing for a long time, and=20
 all of a sudden it's surprising.


:-)

This is not a point we can argue with philosophy, we must await actual
data in the future.


 It's by far best at this point to get across successful stories=20
 about the adoption of D to people who are already receptive to=20
 them because they have some problems that D might help with than=20
 to try to get people to listen to you who have no interest in=20
 listening.  Persuasion works when people are ready to move=20
 towards you.  You can't compel that.


Agreed. However I'd say you don't need to have them want to move to
you, though that helps, just that they want to move away from where
they are now.

Having constructive ripostes for negative criticism rather than just
getting defensive also helps. No excuses, that is guaranteed to lose
support.=20

I like D and am using it for some Gtk stuff. However the GStreamer folk
are backing Rust (for memory safety issues noted earlier) so even
though D has a GStreamer binding (thanks to Mike and GtkD) I more or
less have to use Rust because it is the official binding. Comparing and
contrasting D and Rust is interesting for me. Both have many pluses and
many minuses. However, in the end, the GStreamer core people know C,
C++ a bit, D not at all. I suspect even if the choice had been Rust or
D, Rust would have been chosen because it has no GC and D is a GC
language.

--=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
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
Dec 28 2017
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:

 On Wed, 2017-12-27 at 18:41 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:

 


 […]
 However the GStreamer folk are backing Rust (for memory safety 
 issues noted earlier) so even though D has a GStreamer binding 
 (thanks to Mike and GtkD) I more or less have to use Rust 
 because it is the official binding. Comparing and contrasting D 
 and Rust is interesting for me. Both have many pluses and many 
 minuses. However, in the end, the GStreamer core people know C, 
 C++ a bit, D not at all. I suspect even if the choice had been 
 Rust or D, Rust would have been chosen because it has no GC and 
 D is a GC language.


Not only GStreamer, Rust is on its way to become an offical GNOME 
language, and who knows, eventually take over Vala's role.
Dec 28 2017
parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:

 On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
 wrote:

 On Wed, 2017-12-27 at 18:41 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:

 


 […]
 However the GStreamer folk are backing Rust (for memory safety 
 issues noted earlier) so even though D has a GStreamer binding 
 (thanks to Mike and GtkD) I more or less have to use Rust 
 because it is the official binding. Comparing and contrasting 
 D and Rust is interesting for me. Both have many pluses and 
 many minuses. However, in the end, the GStreamer core people 
 know C, C++ a bit, D not at all. I suspect even if the choice 
 had been Rust or D, Rust would have been chosen because it has 
 no GC and D is a GC language.


 Not only GStreamer, Rust is on its way to become an offical 
 GNOME language, and who knows, eventually take over Vala's role.


I haven't followed Gnome+Rust news. What suggests Rust may be on 
its way to become an official Gnome language?

I'd think that people looking to write apps for Gnome would be 
more inclined to use a *higher*-level language, like D (see GtkD) 
or Python (see PyGObject) rather than a lower-level one like Rust 
where there's a need to deal with borrowing and lifetimes.

Another possible contender I'd forgotten about: 
[Kotlin/Native](https://github.com/JetBrains/kotlin-native). I 
see they have some sample code for using GTK: 
<https://github.com/JetBrains/kotlin-native/tree/master/samples/gtk>.
Dec 28 2017
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2017-12-28 at 16:43 +0000, John Gabriele via Digitalmars-d
wrote:

 On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:

 On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder=20
 wrote:

=20






[=E2=80=A6]

 Not only GStreamer, Rust is on its way to become an offical=20
 GNOME language, and who knows, eventually take over Vala's role.




I think Vala is rapidly becoming a failed experiment. A great idea to
embody the GNOME object model via a programming language with a code
generator to C, but traction outside a core group has failed.


 I haven't followed Gnome+Rust news. What suggests Rust may be on=20
 its way to become an official Gnome language?


There is an increasing dissatisfaction with C for GNOME object model
working due to lack of RAII and buffer overruns, at least in the small
area of GNOME stuff I know.


 I'd think that people looking to write apps for Gnome would be=20
 more inclined to use a *higher*-level language, like D (see GtkD)=20
 or Python (see PyGObject) rather than a lower-level one like Rust=20
 where there's a need to deal with borrowing and lifetimes.


Python works fine but people are increasingly against a non-native
language, that distributed as source with perceived lack of compile
type checking. Only one of the complaints has any real validity, and
that is very real.


 Another possible contender I'd forgotten about:=20
 [Kotlin/Native](https://github.com/JetBrains/kotlin-native). I=20
 see they have some sample code for using GTK:=20
 <https://github.com/JetBrains/kotlin-native/tree/master/samples/gtk>.


Last time I looked at the Kotlin/Native GTK+ binding it was literally
calls to the C API, which is worse than using C because with Kotlin you
expect a higher level binding =E2=80=93 which C++, D, and Rust all provide.

--=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
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
Dec 28 2017
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 28 December 2017 at 16:43:41 UTC, John Gabriele 
wrote:

 On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto 
 wrote:

 On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
 wrote:

 On Wed, 2017-12-27 at 18:41 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:

 


 […]
 However the GStreamer folk are backing Rust (for memory 
 safety issues noted earlier) so even though D has a GStreamer 
 binding (thanks to Mike and GtkD) I more or less have to use 
 Rust because it is the official binding. Comparing and 
 contrasting D and Rust is interesting for me. Both have many 
 pluses and many minuses. However, in the end, the GStreamer 
 core people know C, C++ a bit, D not at all. I suspect even 
 if the choice had been Rust or D, Rust would have been chosen 
 because it has no GC and D is a GC language.


 Not only GStreamer, Rust is on its way to become an offical 
 GNOME language, and who knows, eventually take over Vala's 
 role.


 I haven't followed Gnome+Rust news. What suggests Rust may be 
 on its way to become an official Gnome language?



GNOME and Rust devs are collaborating on how to easily integrate 
Rust with the Gtk+ object model.

Meetings were held at GUADEC, and a few projects, like GStreamer 
are now only using Rust for new code being written. It remains 
open what they will do with existing plugins.

The blog reports about those meetings are quite easy to find.

For example,

https://2017.guadec.org/talks-and-events/index.html#abstract-5-replacing_c_library_code_with_rust_what_i_learned

https://internals.rust-lang.org/t/rust-and-gnome-meeting-notes/4339
Dec 30 2017
prev sibling parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:

 However, in the end, the GStreamer core people know C, C++ a 
 bit, D not at all. I suspect even if the choice had been Rust 
 or D, Rust would have been chosen because it has no GC and D is 
 a GC language.


That is a little misleading. It was always the intention of Rust 
designers to allow userd to tie into a garbage collector - like 
spidermonkey.

It was never designed to be a language that can't make use of GC.

D has gc by default instead. But it's flexible enough to use 
RAII, and you can customise GC a lot....

So Gstreamer people could have easily worked with D, and I don't 
believe D's GC implementation would have been a show stopper for 
them.
Dec 28 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2017 7:00 AM, Dylan Graham wrote:

 I also recall someone saying that C++'s memory problem is fixed. D's MMM seems 
 infantile in comparison.


Only if someone considers this as fixed:

     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


and this as infantile:

      safe:
     int foo(int* p) { return p[1]; }
     int bar(int i) {return foo(&i); }

     dmd -c test.d
     test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
     test.d(4): Error: cannot take address of parameter i in  safe function bar
Dec 25 2017
parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright wrote:

 Only if someone considers this as fixed:

     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


good example..and it makes a good point.

however, let that point be not that C/C++ is flawed (since 
pointers are meant to let you point to anywhere), but rather that 
the code example is flawed.

there is a difference between a flawed language, and flawed use 
of that language.

e.g. what if I accidently left out the  safe attribute on those 
functions in D?
Dec 25 2017
next sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 26 December 2017 at 07:01:16 UTC, codephantom wrote:

 On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright 
 wrote:

 Only if someone considers this as fixed:

     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


 good example..and it makes a good point.

 however, let that point be not that C/C++ is flawed (since 
 pointers are meant to let you point to anywhere), but rather 
 that the code example is flawed.

 there is a difference between a flawed language, and flawed use 
 of that language.

 e.g. what if I accidently left out the  safe attribute on those 
 functions in D?


Then whoever is using your code (you?) will find that out when 
they call your functions from a  safe function.
Dec 25 2017
parent codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 07:33:18 UTC, Mark wrote:

 Then whoever is using your code (you?) will find that out when 
 they call your functions from a  safe function.


And if they forget to annotate their so called 'safe' function 
with  safe...what happens then?

Comparing the 'memory safety' of languages seems a little 
pointless to me..because any programmer can stuff up in any 
language.

As it stands, D does not nullify the truth of that statement.

Which makes me wonder why it is, that  safe is not default in D, 
and Phobos for that matter?

If it were, then that would be a more useful thing to promote D, 
because, as it currently stands, if I forget to annotate my 
function with  safe, then I'm in the same world of forgetting to 
do something in C..or C++.. or whatever...(like checking whether 
I'm referencing a valid memory address).
Dec 26 2017
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 26 December 2017 at 07:01:16 UTC, codephantom wrote:

 On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright 
 wrote:

 Only if someone considers this as fixed:

     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


 good example..and it makes a good point.

 however, let that point be not that C/C++ is flawed (since 
 pointers are meant to let you point to anywhere), but rather 
 that the code example is flawed.

 there is a difference between a flawed language, and flawed use 
 of that language.

 e.g. what if I accidently left out the  safe attribute on those 
 functions in D?


The point is that the presence of one  safe: line in the module 
can be mechanically checked, over one million devs working on a 
codebase.

The whole point of Walter argumentation is 'mechanically'.

/Paolo
Dec 26 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 09:03:31 UTC, Paolo Invernizzi 
wrote:

 The point is that the presence of one  safe: line in the module 
 can be mechanically checked, over one million devs working on a 
 codebase.

 The whole point of Walter argumentation is 'mechanically'.

 /Paolo


My C/C++ code can be 'mechanically' checked too.. and those 
checks are better than they've even been, and getting better.

btw. I'm not arguing against the point Walter made in his 
reponse. Rather I'm just trying to point out that anyone saying 
that D is inherently safe, is wrong.

D provides a great deal of flexibility, and increasingly so, and, 
flexibility breeds bugs!

(don't get me wrong, I like D precisely because of this 
flexibilty).

But if I come with the mindset of 'safety first' (which i don't - 
but lets say I did), then D has some interesting surprises in 
store for me - the most obvious of which, is  safe is not default.
Dec 26 2017
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 26 December 2017 at 09:21:20 UTC, codephantom wrote:

 On Tuesday, 26 December 2017 at 09:03:31 UTC, Paolo Invernizzi 
 wrote:

 The point is that the presence of one  safe: line in the 
 module can be mechanically checked, over one million devs 
 working on a codebase.

 The whole point of Walter argumentation is 'mechanically'.

 /Paolo


 My C/C++ code can be 'mechanically' checked too.. and those 
 checks are better than they've even been, and getting better.


IMHO, the lost list of vulnerability in code shipped by "first 
class enterprises" is just crying out that C/C++ is not 
mechanically checkable.
And we are talking about company that can literally spend an 
Everest of money on that.

/Paolo
Dec 26 2017
parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 10:00:25 UTC, Paolo Invernizzi 
wrote:

 IMHO, the lost list of vulnerability in code shipped by "first 
 class enterprises" is just crying out that C/C++ is not 
 mechanically checkable.
 And we are talking about company that can literally spend an 
 Everest of money on that.

 /Paolo


Well, the 'mechanics of checking' continue to need improvement, 
whether it's C, C++, D, or whatever....

A language that is flexible enough to do the things you can do 
with such a language, comes at a cost.. which is safety (or 
program correctness to be precise). Flexibility breeds bugs! 
That's just how it is. It's inescapable.

And I doubt that it has anything to do with how much money you 
can spend.

In the example below, which is D code, I simply have to 'forget' 
to annotate with  safe, and then it's anyone's guess at to what 
will happen (at least in the second example)

i.e. the mechanical checks don't occur because I simply 'forgot' 
to do something.

// ---
module test;

import std.stdio;

// from: 
https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/

// look at how flexible D is...
void main()
{
     auto buf = new int[1];

     //buf[2] = 1; // compiles ok, even with  safe.
                   // but get range violation at runtime,
                   // whether you use  safe or not
                   // (unless you've disabled bounds checking)

     buf.ptr[2] = 1; // compiles ok, runs ok  - or does it?
                     // however, if you 'remember' to use  safe,
                     // then it won't compile, and you're safe.

}
// -----
Dec 26 2017
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 26 December 2017 at 11:54:12 UTC, codephantom wrote:

 On Tuesday, 26 December 2017 at 10:00:25 UTC, Paolo Invernizzi 
 wrote:

 IMHO, the lost list of vulnerability in code shipped by "first 
 class enterprises" is just crying out that C/C++ is not 
 mechanically checkable.
 And we are talking about company that can literally spend an 
 Everest of money on that.

 /Paolo


 Well, the 'mechanics of checking' continue to need improvement, 
 whether it's C, C++, D, or whatever....

 A language that is flexible enough to do the things you can do 
 with such a language, comes at a cost.. which is safety (or 
 program correctness to be precise). Flexibility breeds bugs! 
 That's just how it is. It's inescapable.

 And I doubt that it has anything to do with how much money you 
 can spend.

 In the example below, which is D code, I simply have to 
 'forget' to annotate with  safe, and then it's anyone's guess 
 at to what will happen (at least in the second example)

 i.e. the mechanical checks don't occur because I simply 
 'forgot' to do something.

 // ---
 module test;

 import std.stdio;

 // from: 
 https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/

 // look at how flexible D is...
 void main()
 {
     auto buf = new int[1];

     //buf[2] = 1; // compiles ok, even with  safe.
                   // but get range violation at runtime,
                   // whether you use  safe or not
                   // (unless you've disabled bounds checking)

     buf.ptr[2] = 1; // compiles ok, runs ok  - or does it?
                     // however, if you 'remember' to use  safe,
                     // then it won't compile, and you're safe.

 }
 // -----



I have to disagree, again.

It's factual that you can mechanically impose that a module 
contains only  safe code, and you can do it in multiple ways. You 
can 'mechanically' impose to write memory safe code in D.

With C/C++ you simply can't do it anything similar, today (and, 
IMHO, neither tomorrow): the rising of Rust is here to tell us 
exactly that.

/Paolo
Dec 26 2017
parent reply Dan Partelly <i i.com> writes:
On Tuesday, 26 December 2017 at 13:54:09 UTC, Paolo Invernizzi 
wrote:


 With C/C++ you simply can't do it anything similar, today (and, 
 IMHO, neither tomorrow): the rising of Rust is here to tell us 
 exactly that.

 /Paolo


Excuse me, since I don't really follow the "raise and fall " of 
new languages. Is really Rust rising and shining ? Tiobe (for all 
it's flows) put it on 0.530 index, just *below* ADA (great 
language, for SW engineering if you ask me , Id wish I could get 
a chance to learn it better).  D's index 0.950 much better than 
Rust's.
Dec 26 2017
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2017-12-26 at 16:40 +0000, Dan Partelly via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 Excuse me, since I don't really follow the "raise and fall " of=20
 new languages. Is really Rust rising and shining ? Tiobe (for all=20
 it's flows) put it on 0.530 index, just *below* ADA (great=20
 language, for SW engineering if you ask me , Id wish I could get=20
 a chance to learn it better).  D's index 0.950 much better than=20
 Rust's.


TIOBE has nothing concrete to say about the languages themselves, it is
a metric of how much buzz on the search engines there is about the
language. Generally this is correlated with how much people do not
understand about a language and are prepared to ask publicly. There is
also a huge hysteresis in the measure.

TIOBE can be fun, but nothing serious can be inferred from the data.

As for the particular question, language such as Groovy have great
traction but very little TIOBE buzz. Rust has lots of technical things
about memory safety but the buzz isn't really there yet.

Which leads to another observation: if a language has a strong language
specific mail list of forum very little gets said outside that arena
and so TIOBE doesn't pick it up. So in a sense TIOBE is a measure of
disparateness of the community.


--=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
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
Dec 26 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 3:54 AM, codephantom wrote:

 I simply have to 'forget' to annotate with  safe


Not annotating with  safe is mechanically checkable as well.
Dec 26 2017
parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 22:56:40 UTC, Walter Bright wrote:

 On 12/26/2017 3:54 AM, codephantom wrote:

 I simply have to 'forget' to annotate with  safe


 Not annotating with  safe is mechanically checkable as well.


If I were trying to create a marketing campaign for D, as being a 
safe language, then  safe being default would be the cornerstone 
of such a campaign.

Then you cannot 'forget' to use it, and there would be no need to 
check anything.

Then, anything not meant to be ' safe' has to be explicately, 
intentionally, marked as something else...and you simply cannot 
'forget' to do that, otherwise the code just won't compile 
correctly (I assume).

Since  safe is not default, such a marketing campaign would be 
pointless.

As such, as better and more realistic marketing campaign would 
promote D as being primarily a flexible language, with 'safe' 
features you can make use of, if you need them, some of which are 
on by default, and some which are not.
Dec 26 2017
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 00:13 +0000, codephantom via Digitalmars-d wrote:
[=E2=80=A6]

 As such, as better and more realistic marketing campaign would=20
 promote D as being primarily a flexible language, with 'safe'=20
 features you can make use of, if you need them, some of which are=20
 on by default, and some which are not.


So remove the  safe annotation because everything is safe by default
and introduce an  unsafe annotation to deal with the cases where lack
of safety is required. Hummm=E2=80=A6 isn't that exactly what Rust has done=
?
 =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
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
Dec 27 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 1:21 AM, codephantom wrote:

 My C/C++ code can be 'mechanically' checked too.. and those checks are better 
 than they've even been, and getting better.


I compiled the code snippet with clang++, a modern C++ compiler, with -Wall. It 
did not detect the obvious error.
Dec 26 2017
parent reply codephantom <me noyb.com> writes:
On Tuesday, 26 December 2017 at 22:55:18 UTC, Walter Bright wrote:

 I compiled the code snippet with clang++, a modern C++ 
 compiler, with -Wall. It did not detect the obvious error.



https://clang.llvm.org/docs/AddressSanitizer.html
Dec 26 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 3:59 PM, codephantom wrote:

 On Tuesday, 26 December 2017 at 22:55:18 UTC, Walter Bright wrote:

 I compiled the code snippet with clang++, a modern C++ compiler, with -Wall. 
 It did not detect the obvious error.


 https://clang.llvm.org/docs/AddressSanitizer.html



That's not mechanical checking, because it is a runtime check that requires a 
test case that would actually trip it. Without a careful, manually created test 
suite, it does not detect anything. AS is not present in the shipped product.

AS is a hackish workaround for the failure of the language to prevent such
things.

AS is just a more modern valgrind, which has been around for ages, and has 
failed to turn C/C++ into memory safe languages.
Dec 26 2017
parent reply codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 07:49:33 UTC, Walter Bright 
wrote:

 AS is a hackish workaround for the failure of the language to 
 prevent such things.

 AS is just a more modern valgrind, which has been around for 
 ages, and has failed to turn C/C++ into memory safe languages.


Well, I don't want C to become a memory safe programming 
language. I want my pointer to be able to point to anywhere, and 
I mean..anywhere ;-)

As for D, I agree that memory safety is clearly not an 
afterthought that requires 'hackish workarounds', like C++ needs.

btw. I'd like to see D 3.x introduce a breaking change and make 
 safe the default, instead of  system. I think that would be huge 
boost for D going forward.

How practical that is, I would have no idea.

But as an 'end user' of D, I would prefer to have to explicitely 
mark code as  system, rather than have to explicitely mark code 
as  safe, and therefore having to find tools that help me check 
whether I 'forgot' to do that.
Dec 27 2017
parent rjframe <dlang ryanjframe.com> writes:
On Wed, 27 Dec 2017 08:36:13 +0000, codephantom wrote:


 btw. I'd like to see D 3.x introduce a breaking change and make  safe
 the default, instead of  system. I think that would be huge boost for D
 going forward.
 
 How practical that is, I would have no idea.
 
 But as an 'end user' of D, I would prefer to have to explicitely mark
 code as  system, rather than have to explicitely mark code as  safe, and
 therefore having to find tools that help me check whether I 'forgot' to
 do that.



I used to agree. For people that use  safe religiously, a tool could 
easily fix the breakage (it's just a toggle), and for most others the tool 
could still fix everything, though with a little more work. But it's so 
easy to do this now without breaking anything.

```
module mymodule;  safe:

 system
class ABC {
    int func(int* p, size_t len) {
        return p[0] + p[1];
    }
}

string thisIsSafe() { return "Yay!"; }
```

I actually like requiring the explicit  safe at the module declaration 
now; it tells other programmers "I intend this module to be memory- safe"; 
you just need a quick grep for  system and  trusted to find exceptions.

Sure, that expression of intention wouldn't be necessary if it were 
default, but I don't really see the benefit in changing it now. People who 
care will add the attribute, people that don't care, won't; knowing the 
programmer's intention can be useful, too.
Dec 27 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:

 The point is that the presence of one  safe: line in the module can be 
 mechanically checked, over one million devs working on a codebase.
 
 The whole point of Walter argumentation is 'mechanically'.


That's right. C++ is based on faith in the programmer using best practices. D
is 
not based on faith, it can be automatically checked.
Dec 26 2017
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote:


 On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:

 The point is that the presence of one  safe: line in the module can be
 mechanically checked, over one million devs working on a codebase.
 
 The whole point of Walter argumentation is 'mechanically'.


 
 That's right. C++ is based on faith in the programmer using best
 practices. D is not based on faith, it can be automatically checked.



If the programmer opts-in to those checks... it's a +1 for pragmatism but 
does make marketing the language a bit weird -- one-liners spawn 
objections to the integrity of the claim (such as a portion of this 
thread; if there are objections within the community, how much more will 
we find objections outside it!).

When I hear someone talk about a memory-safe language (especially as a 
major feature), I do think memory-safe by default. The thing is, D does 
have support for memory-safety by default (bound-checked arrays, etc.), 
and allows you to opt-in to greater safety guarantees; but that's not what 
many think of when they think memory-safe (it doesn't really help that 
every language provides their own, slightly different, definition).

And D has faith that programmers using  trusted know what they're doing 
(for both writing and calling the function). There is no avoiding trust in 
a useful language.
Dec 27 2017
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote:

 On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote:


 On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:

 The point is that the presence of one  safe: line in the 
 module can be mechanically checked, over one million devs 
 working on a codebase.
 
 The whole point of Walter argumentation is 'mechanically'.


 
 That's right. C++ is based on faith in the programmer using 
 best practices. D is not based on faith, it can be 
 automatically checked.



 If the programmer opts-in to those checks... it's a +1 for 
 pragmatism but does make marketing the language a bit weird -- 
 one-liners spawn objections to the integrity of the claim (such 
 as a portion of this thread; if there are objections within the 
 community, how much more will we find objections outside it!).

 When I hear someone talk about a memory-safe language 
 (especially as a major feature), I do think memory-safe by 
 default. The thing is, D does have support for memory-safety by 
 default (bound-checked arrays, etc.), and allows you to opt-in 
 to greater safety guarantees; but that's not what many think of 
 when they think memory-safe (it doesn't really help that every 
 language provides their own, slightly different, definition).

 And D has faith that programmers using  trusted know what 
 they're doing (for both writing and calling the function). 
 There is no avoiding trust in a useful language.


I prefer pragmatism over marketing all the times.

If I was a company evaluating a language, I would notice that my 
safety goal can be reached right today:

- the language guarantees that pieces of written code are memory 
safe.
- there are plenty of easy way to force that, during the 
development process.
- there's the possibility to escape this safety net to gain 
flexibility, and such part of the code can by easily searched and 
peer reviewed for memory corruption problems.

That's a big, big advancement compared to the status quo (C/C++).

It's difficult for me to comprehend why a company should not take 
advantage of it, if it cares about memory safety, only because 
 safe is not the default: that's a really _minor_ issue, compared 
to the gain of having the work done.

/Paolo
Dec 27 2017
prev sibling next sibling parent Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote:

 And D has faith that programmers using  trusted know what 
 they're doing (for both writing and calling the function). 
 There is no avoiding trust in a useful language.


I'm just playing devil's advocate.  Faith is something best left 
to priests not engineers. There is a lot of value in code for 
critical systems in having the compiler enforcing safe constructs 
by default. And still trust you enough to let it disable where it 
counts without writing a Tolstoi novel. It is the sane default.

But unfortunately socially people feel different. If safe would 
be the default, they would feel like the government robed them of 
their right to free speech or confiscated their property. The 
aversion to safety in a programming language is nothing but one 
of the countless way in which fear to be robbed of "free will" 
manifests. An unjustified fear after all, for so much of your 
free will is already so limited.

No hacker language == no success.
Dec 27 2017
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 27.12.2017 16:37, rjframe wrote:

 If the programmer opts-in to those checks... it's a +1 for pragmatism but
 does make marketing the language a bit weird -- one-liners spawn
 objections to the integrity of the claim (such as a portion of this
 thread; if there are objections within the community, how much more will
 we find objections outside it!).


Frankly, I can see no need to appeal to people who think that having a 
culture where people feel free to question claims they consider dubious 
somehow reflects badly on the community or the language (hint: it's the 
opposite).
Dec 27 2017
parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 28 Dec 2017 00:57:41 +0100, Timon Gehr wrote:


 On 27.12.2017 16:37, rjframe wrote:

 If the programmer opts-in to those checks... it's a +1 for pragmatism
 but does make marketing the language a bit weird -- one-liners spawn
 objections to the integrity of the claim (such as a portion of this
 thread; if there are objections within the community, how much more
 will we find objections outside it!).


 
 Frankly, I can see no need to appeal to people who think that having a
 culture where people feel free to question claims they consider dubious
 somehow reflects badly on the community or the language (hint: it's the
 opposite).



I must not have explained my thoughts very well there.

My point is that if people that have already begun using the language 
aren't certain it's being accurately described, we can (should?) expect 
those who haven't chosen to learn the language to think the same. But if 
they think it's being misrepresented, they may just decide not to bother. 
We have to be careful to be accurate, and we unfortunately don't get to 
control the definitions of the words we use.

To say that D should become memory-safe by default (as many do) is to 
claim it is not currently memory-safe by default; so can D be called a 
memory-safe language? E.g., would the claim that "D is memory-safe" be 
commonly-interpreted to mean "D is memory-safe by default"?

The MSVC compiler does buffer security checks, by default, in release 
builds[1]. I believe clang lets you add bounds checks via a compiler flag. 
Do these make C++ a memory-safe language? (answer: definitely not)


I think the dlang.org home page description in the "Run Fast" section is 
perfect, or at least nearly so. But I don't think a simple "D is memory-
safe" is even true.


[1]: https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-
security-check
Dec 27 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 7:01 PM, rjframe wrote:

 The MSVC compiler does buffer security checks, by default, in release
 builds[1].


This is simply not checkable memory safety. All it is is setting aside some 
memory locations in strategic places with known values in that memory. If those 
values change, then some code somewhere must have a memory safety bug in it.

It's like picking two triangles and showing Pythagorean's theorem holds for 
them, vs proving Pythagorean's theorem works for all right triangles.
Dec 27 2017
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2017-12-26 at 14:54 -0800, Walter Bright via Digitalmars-d
wrote:
[=E2=80=A6]

 That's right. C++ is based on faith in the programmer using best
 practices. D is=20
 not based on faith, it can be automatically checked.


"Can be" is not the same as "is". Perhaps all D compilers should
enforce the "can be" as "is", with options to switch it off if need be?
This is the route Rust is going, and it has great benefits exactly
because C and C++ do not do this.=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
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
Dec 27 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 8:34 AM, Russel Winder wrote:

 On Tue, 2017-12-26 at 14:54 -0800, Walter Bright via Digitalmars-d
 wrote:

 That's right. C++ is based on faith in the programmer using best
 practices. D is
 not based on faith, it can be automatically checked.


 
 "Can be" is not the same as "is". Perhaps all D compilers should
 enforce the "can be" as "is", with options to switch it off if need be?


This illustrates my point if it was unclear:

C++:
     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


D:
      safe:
     int foo(int* p) { return p[1]; }
     int bar(int i) {return foo(&i); }

     dmd -c test.d
     test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
     test.d(4): Error: cannot take address of parameter i in  safe function bar
Dec 27 2017
parent codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 20:24:04 UTC, Walter Bright 
wrote:

 This illustrates my point if it was unclear:

 C++:
     int foo(int* p) { return p[1]; }
     int bar(int i) { return foo(&i); }

     clang++ -c test.cpp -Wall


 D:
      safe:
     int foo(int* p) { return p[1]; }
     int bar(int i) {return foo(&i); }

     dmd -c test.d
     test.d(3): Error: safe function 'test.foo' cannot index 
 pointer 'p'
     test.d(4): Error: cannot take address of parameter i in 
  safe function bar


Well,I can press the accelerator on my car to the floor, and 
crash the car.

But is that a problem with the car, or the way I used it 
(referring to the C++ portion of your example)? Would be better, 
and fairer, to write that portion in modern C++, and then make 
the comparison with D.

And sure, we can (and do) make cars that modify the acceleraton 
potential, but then you can't do burnouts ;-(

So safety certainly does have real value..but it always wants to 
take something away. (and unfortunately, we're becoming a very 
risk averse society, with more and more freedoms being taken away 
in the name of 'safety' - but I divert..)

Of course, the nice thing about D, is that we can (for the most 
part) switch it from one to the other...so I like that a lot.

But when I really want to put the pedal to the metal, I still 
look to C.

(although, one day the government will try to make C illegal too 
I guess).
Dec 27 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2017-12-23 at 01:12 +0000, Dylan Graham via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 I wish D would stop bending over backwards to appease C/C++=20
 programmers. I think D would have more success branding itself as=20
 a general purpose language and letting itself become the language=20
 it should be, not the language some C++ programmer wants but is=20
 never going to use anyway.


A point worth reiterating.

--=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
Dec 24 2017
prev sibling parent bachmeier <no spam.net> writes:
On Friday, 22 December 2017 at 18:59:34 UTC, John Gabriele wrote:

 I'm new to D. Coming primarily from Python these days, I'm 
 looking at D not as a better C++ (haven't used that in many 
 years), but as a better Python.


If the world views D as a better [insert programming language] 
the marketing battle has been lost. We need the world to view D 
as a convenient way to do [insert some task]. It doesn't even 
have to be the "best" way to do it, just a convenient way.

Claiming to be a better version of some other language is worse 
than no marketing at all. D's "we're a better C++" version of 
marketing is the reason I avoided the language for years. You 
have to like C++ a lot to want an even better version of C++, and 
that definitely doesn't describe me, and given C++'s reputation, 
I'm probably not alone.
Dec 24 2017
prev sibling next sibling parent Dgame <r.schuett.1987 gmail.com> writes:
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:

 Why should we settle for this ? D code (efortless) is easier to 
 read then Rust.


Such statement is highly controversial, since it can be said 
about C/C++, D and most other languages as well.
Dec 23 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2017-12-22 at 16:17 +0000, Dan Partelly via Digitalmars-d
wrote:

 [=E2=80=A6]
 Why should we settle for this ? D code (efortless) is easier to=20
 read then Rust. I assume this to be true for a lot of programmers=20


[=E2=80=A6]

And for many Rust is easier to read than D.=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
Dec 24 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/22/2017 7:23 AM, Russel Winder wrote:

 I think we are now in a world where Rust is the zero cost abstraction
 language to replace C and C++, except for those who are determined to
 stay with C++ and evolve it.


Maybe it is. But that is not because D isn't up to the task. I've converted a 
large program from C to D (Digital Mars C++'s front end) with -betterC and it 
really is a zero cost abstraction. The memory safety benefits are there (DIP 
1000), RAII is there, nested functions, array bounds checking, template 
metaprogramming, CTFE, etc.

I expect to be upgrading a lot of older C code I still use in this manner. I 
just don't want to work in C anymore. Furthermore, I do not need to re-engineer 
the C code to convert it to D - it can be done pretty much by rote, unlike Rust.

D as betterC really is a game changer, for anyone who cares to give it a try.
Dec 23 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright 
wrote:

 D as betterC really is a game changer, for anyone who cares to 
 give it a try.


Walter, would you expect a std suitable for betterC to be 
specified in the language ? You could name it Deimos.
Dec 23 2017
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 23 December 2017 at 09:23:22 UTC, Dan Partelly wrote:


 You could name it Deimos.


That name's already taken:  
https://github.com/D-Programming-Deimos/

Deimos is a repository of D language bindings to many existing 
libraries, though sadly it doesn't appear to get much maintenance.

Personally, I think the C language bindings that currently exist 
in the D runtime should be moved to Deimos and privately imported 
by the ports that need it.  But, I seem to be in the minority on 
that.

Mike
Dec 23 2017
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright 
wrote:

 On 12/22/2017 7:23 AM, Russel Winder wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction
 language to replace C and C++, except for those who are 
 determined to
 stay with C++ and evolve it.


 Maybe it is. But that is not because D isn't up to the task. 
 I've converted a large program from C to D (Digital Mars C++'s 
 front end) with -betterC and it really is a zero cost 
 abstraction. The memory safety benefits are there (DIP 1000), 
 RAII is there, nested functions, array bounds checking, 
 template metaprogramming, CTFE, etc.


Is it planned to add more (I'm thinking of exceptions, which I 
guess means classes too) of full D into betterC? As I wrote 
earlier, it should be possible to achieve some rough kind of 
feature parity with modern C++.

I really do like Rust; I think it's a brilliant language. There 
are domains that require zero cost abstractions that are 
currently NOT covered well by Rust though; D's Mir library is 
pushing into one of those.


 D as betterC really is a game changer, for anyone who cares to 
 give it a try.


Yes, it really is.

I really wish that D had a performant fully precise GC, but I'm 
beginning to think that is unlikely to ever happen. Maybe being a 
betterModernC++ in that regard would be good enough?
Dec 23 2017
prev sibling parent Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright 
wrote:

 On 12/22/2017 7:23 AM, Russel Winder wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction
 language to replace C and C++, except for those who are 
 determined to
 stay with C++ and evolve it.


 Maybe it is. But that is not because D isn't up to the task. 
 I've converted a large program from C to D (Digital Mars C++'s 
 front end) with -betterC and it really is a zero cost 
 abstraction. The memory safety benefits are there (DIP 1000), 
 RAII is there, nested functions, array bounds checking, 
 template metaprogramming, CTFE, etc.

 D as betterC really is a game changer, for anyone who cares to 
 give it a try.


I think D's great strength compared to Rust is that it is much 
easier to code in D. How easy is it write a simple linked list in 
Rust - without using library features? Rust makes even simple 
tasks hard to write.

D as a language combines best features of C, C++ and Java which 
is great in my view. And the better C option makes it really 
viable for creating shared libraries that can be easily used in 
other projects.

Trying to replace C is really not the right goal for D I think. 
In my experience, C and C++ have already been replaced by Java, 

legacy and is just being kept "alive". And nothing beats C for 
systems developers who want a high level assembler rather than 
abstractions and safety features.

In my view, D should be D - the main issue with D is not the 
language, but the tooling. It needs to "just work" on the major 
platforms and needs good IDE support.

Regards
Dibyendu
Dec 30 2017
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Russel Winder wrote:


 I think we are now in a world where Rust is the zero cost abstraction
 language to replace C and C++, except for those who are determined to
 stay with C++ and evolve it.


sorry, but it is not zero cost. we have alot of C and C++ code. converting 
it to Rust is not zero cost at all. and using it as-is won't make our 
codebases any better.

but with D, i can say that converting C code is almost zero cost. i did 
alot of C->D ports, and most of the work was done with "sed". then i have 
to run dmd and add some casts and other simple things (sure, i should 
finally write an automatic converter, but... you know that "ok, next time" 
kind of self-promises ;-).

i also ported some C++ codebases, and it is almost equally easy. mostly due 
to the fact that people tend to avoid "modern" C++ features and 
metaprogramming: it is still hard to use with C++. (with D, btw, i started 
to use templates even before i fully realised that i am using templates ;-)

what i want to say (and didn't, as usual) is that Rust is not zero cost due 
to exisiting codebases. either you have to invest alot of time and efforts 
to port those codebases, or you have to use both Rust and C/C++, and suffer 
the consequences.

and with D, you can port all your code, and use one language, investing 
*much* less efforts than you'd have with Rust/Go. plus, you'll get all the 
things D has to offer, for free.

that is, D actually has *no* competitors. if not google and mozco, people 
won't even start talking seriously about Go/Rust. yet even in this unfair 
race, D presence is constantly growing. just wait a little, and you'll see 
a dawn of Rust and Go. and D will be still there, standing strong and 
proud. ;-)
Dec 23 2017
parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2017-12-23 at 11:33 +0200, ketmar via Digitalmars-d wrote:

 Russel Winder wrote:
=20

 I think we are now in a world where Rust is the zero cost
 abstraction
 language to replace C and C++, except for those who are determined
 to
 stay with C++ and evolve it.


=20
 sorry, but it is not zero cost. we have alot of C and C++ code.
 converting=20
 it to Rust is not zero cost at all. and using it as-is won't make
 our=20
 codebases any better.


I think we are using different meanings of "zero cost abstraction".

[=E2=80=A6]

=20
 what i want to say (and didn't, as usual) is that Rust is not zero
 cost due=20
 to exisiting codebases. either you have to invest alot of time and
 efforts=20
 to port those codebases, or you have to use both Rust and C/C++, and
 suffer=20
 the consequences.


Porting code and "zero cost abstraction" are totally separate things,
there is no causal relation between them.


 [=E2=80=A6]
=20
 that is, D actually has *no* competitors. if not google and mozco,
 people=20
 won't even start talking seriously about Go/Rust. yet even in this
 unfair=20
 race, D presence is constantly growing. just wait a little, and
 you'll see=20
 a dawn of Rust and Go. and D will be still there, standing strong
 and=20
 proud. ;-)


Programming language traction is only partly related to any technical
arguments. Hugely important is resource and marketing. C++ has Intel
and others. Rust has Mozilla and others. Go has Google and others.=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
Dec 24 2017
prev sibling parent codephantom <me noyb.com> writes:
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:

 I think we are now in a world where Rust is the zero cost 
 abstraction language to replace C and C++, except for those who 
 are determined to stay with C++ and evolve it.


Well..there are plenty who are determined to stay with C++ and 
evolve it... so I don't see a replacement for C++ coming anytime 
soon ;-)

In fact, I wouldn't be surprised if there were a C++ renaissance 
in the not too distance future..(don't hold me to that though)

As for C, everyone seems to be trying to make a 'better' C, 
including new kid on the block , Zig ("Zig is a programming 
language which is intended to replace C") - http://ziglang.org/

But some of these so called better C projects just change the 
syntax too much, and the learning curve becomes too much...at 
least for me.. as I don't have that kind of patience anymore, and 
much of the syntax change is just ideologically driven anyway.

D really does have the right balance of 'maintaining syntax' (for 
the most part) that a C developer can instantly recognise and 
begin working with.

= still = =

Out of Go, Rust and D, I find D to be 'the most' refreshing and 
pleasant alternative to C, and I doubt anyone or anything could 
convince me otherwise.

D is also *not* being driven by corporate heads, which means it's 
more free to innovate and become better.

Having said that, nothing is better than C.

And I wish -betterC was renamed -slimD, -saferC, or perhaps, 
-niceAlternativeToC
Dec 23 2017
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Friday, 22 December 2017 at 13:38:25 UTC, Dan Partelly wrote:

 It works as a "betterC" it seems, but you loose a lot of 
 functionality which should be in a "better C" and again, a lot 
 from the standard libraries is lost. Template C++ 2017 works 
 well for a better C as well, and I retain 0 cost abstraction, 
 decent (yet inferior to D meta-programming), closures,
 exceptions, scopes...


It seems that there's an effort from the top to bring more higher 
level features into --betterC. I agree with you that more should 
be there, that it should really be betterC++ and strive for 
feature parity with modern C++.
Dec 22 2017
parent ketmar <ketmar ketmar.no-ip.org> writes:
bpr wrote:


 It seems that there's an effort from the top to bring more higher level 
 features into --betterC. I agree with you that more should be there, that 
 it should really be betterC++ and strive for feature parity with modern 
 C++.


we already have better c++: it is titled "D".
Dec 22 2017
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


"Maybe D is right about GC after all!"

No, GC is just one kind of automatic memory management.  Just 
like we have many different data structures all suited for 
different purposes, we need different memory managers for 
different purposes.  D's mistake is that it has dominantly 
favored one.

Mike
Dec 19 2017
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 19 December 2017 at 12:52:59 UTC, Mike Franklin wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 "Maybe D is right about GC after all!"

 No, GC is just one kind of automatic memory management.  Just 
 like we have many different data structures all suited for 
 different purposes, we need different memory managers for 
 different purposes.  D's mistake is that it has dominantly 
 favored one.

 Mike


But it doesn't preclude you from using others, unlike other that 
force it. Yes it can be a bit of a pain to work around but it can 
be done.
Dec 19 2017
parent I Love Stuffing <ilovestuffing gmail.com> writes:
On Tuesday, 19 December 2017 at 13:16:13 UTC, Nicholas Wilson 
wrote:

 On Tuesday, 19 December 2017 at 12:52:59 UTC, Mike Franklin 
 wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 "Maybe D is right about GC after all!"

 No, GC is just one kind of automatic memory management.  Just 
 like we have many different data structures all suited for 
 different purposes, we need different memory managers for 
 different purposes.  D's mistake is that it has dominantly 
 favored one.

 Mike


 But it doesn't preclude you from using others, unlike other 
 that force it. Yes it can be a bit of a pain to work around but 
 it can be done.


You mean have two bulky GCs around claiming they own memory at 
the same time? What could go wrong...
Dec 19 2017
prev sibling parent reply Tony <tonytdominguez aol.com> writes:
I have heard with regard to reference counting as is done in 
Python, that if two objects each have a reference to the other, 
that they will never be deleted, even if neither is used 
elsewhere in the program. Garbage collection is not supposed to 
have that issue, although I don't know how a garbage collector 
determines that there usage is just via each other and that they 
can be deleted.
Dec 20 2017
next sibling parent Dgame <r.schuett.1987 gmail.com> writes:
On Wednesday, 20 December 2017 at 17:05:41 UTC, Tony wrote:

 I have heard with regard to reference counting as is done in 
 Python, that if two objects each have a reference to the other, 
 that they will never be deleted, even if neither is used 
 elsewhere in the program. Garbage collection is not supposed to 
 have that issue, although I don't know how a garbage collector 
 determines that there usage is just via each other and that 
 they can be deleted.


Here's how PHP does it:
http://php.net/manual/de/features.gc.collecting-cycles.php
Dec 20 2017
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 12/20/2017 09:05 AM, Tony wrote:


 how a garbage collector determines that there usage is just via
 each other and that they can be deleted.


Similar to the PHP link Dgame posted, the GC looks for live objects by 
starting from roots (essentially, the objects on the stack and the 
static variables). Even if there are islands of objects referencing 
others in self or other islands, as long as they are not reachable from 
any root, they are gone.

Ali
Dec 20 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-20 at 17:05 +0000, Tony via Digitalmars-d wrote:

 I have heard with regard to reference counting as is done in=20
 Python, that if two objects each have a reference to the other,=20
 that they will never be deleted, even if neither is used=20
 elsewhere in the program. Garbage collection is not supposed to=20
 have that issue, although I don't know how a garbage collector=20
 determines that there usage is just via each other and that they=20
 can be deleted.


Python uses reference counting, but also has an optional garbage
collector.

cf. https://docs.python.org/3/library/gc.html#module-gc

--=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
Dec 20 2017
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


What do you think of the following comment to that article?

"In well-written modern C++, memory management errors are a 
solved problem. You can just write code, and know that the 
compiler and library will take care of cleaning up for you, just 
like with a GC-based system, but with the added benefit that it’s 
deterministic, and can handle non-memory resources such as file 
handles and sockets too."
Dec 19 2017
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 What do you think of the following comment to that article?

 "In well-written modern C++, memory management errors are a 
 solved problem. You can just write code, and know that the 
 compiler and library will take care of cleaning up for you, 
 just like with a GC-based system, but with the added benefit 
 that it’s deterministic, and can handle non-memory resources 
 such as file handles and sockets too."


I'm no C++ expert, but isn't that because of the use of unique 
pointers and shared pointers? And aren't shared pointers 
reference counted and stuck with the usual limitations associated 
with reference counting?
Dec 19 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 19, 2017 23:53:04 bachmeier via Digitalmars-d wrote:

 On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright

 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 What do you think of the following comment to that article?

 "In well-written modern C++, memory management errors are a
 solved problem. You can just write code, and know that the
 compiler and library will take care of cleaning up for you,
 just like with a GC-based system, but with the added benefit
 that it’s deterministic, and can handle non-memory resources
 such as file handles and sockets too."


 I'm no C++ expert, but isn't that because of the use of unique
 pointers and shared pointers? And aren't shared pointers
 reference counted and stuck with the usual limitations associated
 with reference counting?


What limitations are you concerned about? Certainly, shared_ptr comes with
whatever pros and cons come from non-intrusive (i.e. not built into the
object) reference-counting, but from I've seen, there really isn't much of a
downside to them (_especially_ if you're comparing them to manual memory
management). Mostly, you just have to worry about using weak_ptr when you'd
otherwise have a circular reference. Sure, using the GC is easier but not by
much. In my experience, you can generally just use shared_ptr and not worry
much about memory management, and you get mostly deterministic destruction,
unlike the GC (it's mostly, because there are times when stuff sticks around
a lot longer than you might expect, because something has a reference to it,
which isn't always obvious; it's still technically determinstic, but the
effect can seem pretty non-deterministic sometimes). There are plenty of C++
programmers who have no problem with shared_ptr who would feel quite leery
about using the GC, and for some stuff, the determinism of reference
counting can be critical. With a GC, you can mostly not worry about such
things, but occasionally, you have to be careful, or you'll have problems
with resource management because on the non-determinism (e.g. you really
don't want sockets to closed based on when the GC collects the socket
object). And whether RC or GC is better for performance depends heavily on
what you're doing. RC tends to slow everything down slightly but usually
doesn't have bursts of memory collection (though it can when you free a
large tree of objects at once), whereas the GC doesn't slow stuff down as it
goes along, but it has definite bursts where performance tanks, because a
collection is being run. I'd say that from D's perspective, the main
advantage of the GC over RC is that the compiler can guarantee that it's
 safe, which is more more problematic with RC - that and you don't have to
worry about circular references with the GC like you do with RC.

Overally, I don't think that it's particularly clearcut whether RC or GC is
better overall. The big thing is that the memory is managed automatically
rather than manually.

- Jonathan M Davis
Dec 19 2017
parent bachmeier <no spam.net> writes:
On Wednesday, 20 December 2017 at 00:38:58 UTC, Jonathan M Davis 
wrote:

 On Tuesday, December 19, 2017 23:53:04 bachmeier via 
 Digitalmars-d wrote:

 On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:

 What do you think of the following comment to that article?

 "In well-written modern C++, memory management errors are a 
 solved problem. You can just write code, and know that the 
 compiler and library will take care of cleaning up for you, 
 just like with a GC-based system, but with the added benefit 
 that it’s deterministic, and can handle non-memory resources 
 such as file handles and sockets too."


 I'm no C++ expert, but isn't that because of the use of unique 
 pointers and shared pointers? And aren't shared pointers 
 reference counted and stuck with the usual limitations 
 associated with reference counting?


 What limitations are you concerned about? Certainly, shared_ptr 
 comes with whatever pros and cons come from non-intrusive (i.e. 
 not built into the object) reference-counting, but from I've 
 seen, there really isn't much of a downside to them 
 (_especially_ if you're comparing them to manual memory 
 management). Mostly, you just have to worry about using 
 weak_ptr when you'd otherwise have a circular reference. Sure, 
 using the GC is easier but not by much. In my experience, you 
 can generally just use shared_ptr and not worry much about 
 memory management, and you get mostly deterministic 
 destruction, unlike the GC (it's mostly, because there are 
 times when stuff sticks around a lot longer than you might 
 expect, because something has a reference to it, which isn't 
 always obvious; it's still technically determinstic, but the 
 effect can seem pretty non-deterministic sometimes). There are 
 plenty of C++ programmers who have no problem with shared_ptr 
 who would feel quite leery about using the GC, and for some 
 stuff, the determinism of reference counting can be critical. 
 With a GC, you can mostly not worry about such things, but 
 occasionally, you have to be careful, or you'll have problems 
 with resource management because on the non-determinism (e.g. 
 you really don't want sockets to closed based on when the GC 
 collects the socket object). And whether RC or GC is better for 
 performance depends heavily on what you're doing. RC tends to 
 slow everything down slightly but usually doesn't have bursts 
 of memory collection (though it can when you free a large tree 
 of objects at once), whereas the GC doesn't slow stuff down as 
 it goes along, but it has definite bursts where performance 
 tanks, because a collection is being run. I'd say that from D's 
 perspective, the main advantage of the GC over RC is that the 
 compiler can guarantee that it's  safe, which is more more 
 problematic with RC - that and you don't have to worry about 
 circular references with the GC like you do with RC.

 Overally, I don't think that it's particularly clearcut whether 
 RC or GC is better overall. The big thing is that the memory is 
 managed automatically rather than manually.


That's what I'm getting at. The comment shared by Mark does not 
contradict the blog post. The C++ community gave up on manual 
memory management, just taking a different route to automatic 
memory management, with the associated costs and benefits.
Dec 19 2017
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:

 "In well-written modern C++, memory management errors are a 
 solved problem. You can just write code, and know that the 
 compiler and library will take care of cleaning up for you, 
 just like with a GC-based system, but with the added benefit 
 that it’s deterministic, and can handle non-memory resources 
 such as file handles and sockets too."


They compare it to malloc+free MM.
Dec 21 2017
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 What do you think of the following comment to that article?

 "In well-written modern C++, memory management errors are a 
 solved problem. You can just write code, and know that the 
 compiler and library will take care of cleaning up for you, 
 just like with a GC-based system, but with the added benefit 
 that it’s deterministic, and can handle non-memory resources 
 such as file handles and sockets too."


As a former C++ programmer, the comment is exactly right, in C++ 
resource management is a solved problem (or at least feels like 
it which doesn't say much), and in D it's way more _complex_ 
(many cases, many workarounds, and _you have to understand it_, 
for example you need a mental model of how the GC works).

There is also a downside to the C++ scoped owership wa: you have 
to find an owner for everything even if they are just memory. So 
small scripts in D will be written almost 2x faster because of 
that and rich stdlib.



THe other
Dec 21 2017
parent Mark <smarksc gmail.com> writes:
On Thursday, 21 December 2017 at 13:27:55 UTC, Guillaume Piolat 
wrote:

 [...]

 There is also a downside to the C++ scoped owership wa: you 
 have to find an owner for everything even if they are just 
 memory. So small scripts in D will be written almost 2x faster 
 because of that and rich stdlib.


Right. That's definitely a nuisance. It's probably also an issue 
in Rust with its "borrowing and ownership" apparatus.
Dec 21 2017
prev sibling next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 http://esr.ibiblio.org/?p=7804


The problem with D's GC isn't that one exists. It's that the 
original language design didn't easily accommodate other 
*automatic* memory management facilities. It's now harder to 
integrate them into the language and ecosystem.
Dec 19 2017
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 19, 2017 at 01:54:05AM -0800, Walter Bright via Digitalmars-d wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 
 http://esr.ibiblio.org/?p=7804


Coming from a strong C/C++ background, it took me a good long while to
accept the GC.  I had all the usual objections about lack of control
(e.g. over GC pauses), lack of determinism (never know when something
will get collected), performance, etc..  But there's one thing the GC
gives that no amount of clever programming can: productivity.

It's exactly as ESR says: once your code gets to a certain point of
complexity, in a manual memory management language like C/C++ your
coding time becomes more and more disproportionately spent on managing
memory rather than working on your problem domain. That is, if you wish
to preserve code correctness.  It *is* possible to be productive past
this point, but memory-related bugs become more frequent and eventually
overwhelms your effort to make progress in the problem domain.

After I started writing non-trivial code in D, I found my brain has been
freed up from the constant energy drain of having to think about
managing memory -- is that pointer still in scope, do I have to free it,
have I freed it already, are the parameters borrowed references or
transfer of ownership, should they be borrowed references instead,
should I use a refcounting wrapper instead, what happens to this
template if a refcounted type was passed in instead of something else,
what happens to the reference if an exception is thrown here, ad nauseam
-- now I can actually think about the algorithm as it directly pertains
to the problem domain, rather than constantly fiddling with the dirty
details of memory management.

As a result, not only my productivity skyrocketed, but the correctness
of my algorithms improved. When you're constantly under the nagging of
manual memory management gotchas, you may well churn out
*memory-correct* code, but not necessarily code that's correct *in the
problem domain*.  Being freed from the fidgety concerns of memory
management means more mental resources can be directed at actually
solving the problem at hand and doing a better job at it.  Not to
mention an entire class of memory-related bugs are eliminated by the GC.

That's why nowadays my opinion is that if you're not working with
performance-sensitive code (i.e., where every missed CPU cycle increases
the likelihood of a patient dying or the airplane crashing), and if you
haven't profiled your code to clearly show that the GC is a performance
bottleneck, then you really should just let the GC do its job.  There
*have* been cases where I've found that GC performance is hindering my
code; so far, judicious, strategic use of GC.disable() and manual calls
to GC.collect() have sufficed to fix that, without needing to throw out
the GC baby with the bathwater altogether.  Having to go back to paying
the mental memory management tax on every other line of code I write is
just not a wise use of my time and energy.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
Dec 19 2017
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Seems to me there is a really, really good article for CVu or Overload=20
in all this, starting  with reprinting the ESR article, follwed up by
some experience history article like this.


On Tue, 2017-12-19 at 11:42 -0800, H. S. Teoh via Digitalmars-d wrote:

 On Tue, Dec 19, 2017 at 01:54:05AM -0800, Walter Bright via
 Digitalmars-d wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
=20
 http://esr.ibiblio.org/?p=3D7804


=20
 Coming from a strong C/C++ background, it took me a good long while
 to
 accept the GC.  I had all the usual objections about lack of control
 (e.g. over GC pauses), lack of determinism (never know when something
 will get collected), performance, etc..  But there's one thing the GC
 gives that no amount of clever programming can: productivity.
=20
 It's exactly as ESR says: once your code gets to a certain point of
 complexity, in a manual memory management language like C/C++ your
 coding time becomes more and more disproportionately spent on
 managing
 memory rather than working on your problem domain. That is, if you
 wish
 to preserve code correctness.  It *is* possible to be productive past
 this point, but memory-related bugs become more frequent and
 eventually
 overwhelms your effort to make progress in the problem domain.
=20
 After I started writing non-trivial code in D, I found my brain has
 been
 freed up from the constant energy drain of having to think about
 managing memory -- is that pointer still in scope, do I have to free
 it,
 have I freed it already, are the parameters borrowed references or
 transfer of ownership, should they be borrowed references instead,
 should I use a refcounting wrapper instead, what happens to this
 template if a refcounted type was passed in instead of something
 else,
 what happens to the reference if an exception is thrown here, ad
 nauseam
 -- now I can actually think about the algorithm as it directly
 pertains
 to the problem domain, rather than constantly fiddling with the dirty
 details of memory management.
=20
 As a result, not only my productivity skyrocketed, but the
 correctness
 of my algorithms improved. When you're constantly under the nagging
 of
 manual memory management gotchas, you may well churn out
 *memory-correct* code, but not necessarily code that's correct *in
 the
 problem domain*.  Being freed from the fidgety concerns of memory
 management means more mental resources can be directed at actually
 solving the problem at hand and doing a better job at it.  Not to
 mention an entire class of memory-related bugs are eliminated by the
 GC.
=20
 That's why nowadays my opinion is that if you're not working with
 performance-sensitive code (i.e., where every missed CPU cycle
 increases
 the likelihood of a patient dying or the airplane crashing), and if
 you
 haven't profiled your code to clearly show that the GC is a
 performance
 bottleneck, then you really should just let the GC do its job.  There
 *have* been cases where I've found that GC performance is hindering
 my
 code; so far, judicious, strategic use of GC.disable() and manual
 calls
 to GC.collect() have sufficed to fix that, without needing to throw
 out
 the GC baby with the bathwater altogether.  Having to go back to
 paying
 the mental memory management tax on every other line of code I write
 is
 just not a wise use of my time and energy.
=20
=20
 T
=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
Dec 20 2017
prev sibling next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


But ESR doesn't seem to be fond of the GC idea for C like 
languages though.
He states in a comment:

">For a long time I’ve been holding out hope for a ‘standard’ 
garbage collector library for C. But not gonna hold my breath.

Yeah, good idea not to. People as smart/skilled as you and me 
have been poking at this problem since the 1980s and it’s pretty 
easy to show that you can’t do better than Boehm–Demers–Weiser, 
which has limitations that make it impractical. Sigh…"

Which does not say that he is against D's philosophy to offer GC 
and RC.

Interestingly he doesn't know about D and he hasn't answered your 
comment yet but instead answered another commenter about D and 
got some pointers.
We will see if he looks into D and shares his opinion about it.
Dec 20 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 20.12.2017 09:30, Thomas Mader wrote:

 Interestingly he doesn't know about D


http://esr.ibiblio.org/?p=7724
Dec 20 2017
parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Wednesday, 20 December 2017 at 09:16:34 UTC, Timon Gehr wrote:

 On 20.12.2017 09:30, Thomas Mader wrote:

 Interestingly he doesn't know about D


 http://esr.ibiblio.org/?p=7724


Haven't read that one but it just shows it:

"Since I’ve mentioned D, I suppose this is also the point at 
which I should explain why I don’t see it as a serious contender 
to replace C. Yes, it was spun up eight years before Rust and 
nine years before Go – props to Walter Bright for having the 
vision. But in 2001 the example of Perl and Python had already 
been set – the window when a proprietary language could compete 
seriously with open source was already closing. The wrestling 
match between the official D library/runtime and Tango hurt it, 
too. It has never recovered from those mistakes."

So he doesn't know about the current state of D and I was 
referring to the following comment from 
http://esr.ibiblio.org/?p=7804:

">Eric, have you looked into D *lately*?

No. What’s it got that Go does not?

That’s not intended as a hostile question, I’m trying to figure 
out where to focus my attention when I read up on it."

What I don't get is why he doesn't believe in good GC for C (my 
previous post) but at the same time praising Go for it's GC.
What makes it easier to have a good GC in Go vs. in C?
I guess the GC in D has the same problems as a GC in C.
Dec 20 2017
parent reply thedeemon <dlang thedeemon.com> writes:
On Wednesday, 20 December 2017 at 11:21:59 UTC, Thomas Mader 
wrote:

 What I don't get is why he doesn't believe in good GC for C (my 
 previous post) but at the same time praising Go for it's GC.
 What makes it easier to have a good GC in Go vs. in C?
 I guess the GC in D has the same problems as a GC in C.


A good GC requires the compiler to add special bookkeeping code 
to every pointer mutation in the heap, and to generate special 
data for each function to help GC find all the pointers in its 
stack and closures. Without such help from the compiler you can't 
make anything decent, just a slow half-conservative GC that scans 
whole heap every time and leaks memory being unable to tell 
whether some stack value is a number or a pointer. Go compiler 
includes that special bookkeeping, so the running code is a bit 
slower but GC can be fast, its GC can analyze heap concurrently, 
it can clean it by parts. With C you can't do that. D compiler 
also doesn't insert that bookkeeping code, so running code is 
fast as C but GC is slow and sloppy.
Dec 21 2017
next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:

 A good GC requires the compiler to add special bookkeeping code 
 to every pointer mutation in the heap, and to generate special 
 data for each function to help GC find all the pointers in its 
 stack and closures. Without such help from the compiler you 
 can't make anything decent, just a slow half-conservative GC 
 that scans whole heap every time and leaks memory being unable 
 to tell whether some stack value is a number or a pointer. Go 
 compiler includes that special bookkeeping, so the running code 
 is a bit slower but GC can be fast, its GC can analyze heap 
 concurrently, it can clean it by parts. With C you can't do 
 that. D compiler also doesn't insert that bookkeeping code, so 
 running code is fast as C but GC is slow and sloppy.


But for D it's planned to rewrite the GC to become something like 
the Go GC right?
The last attempt to do this was afaik a Google Summer of code 
project.
Dec 21 2017
parent reply thedeemon <dlang thedeemon.com> writes:
On Thursday, 21 December 2017 at 22:11:26 UTC, Thomas Mader wrote:

 D compiler also doesn't insert that bookkeeping code, so 
 running code is fast as C but GC is slow and sloppy.


 But for D it's planned to rewrite the GC to become something 
 like the Go GC right?
 The last attempt to do this was afaik a Google Summer of code 
 project.


No, not like in Go. A few years ago there was a project 
implementing concurrent GC by forking the process and scanning 
the heap snapshot in parallel to the main process. It kinda 
worked but it's not portable, it won't work on Windows, so don't 
expect it to land into main D distribution and become an official 
GC.
There were other projects to improve current GC, make it more 
precise (but still not 100% precise) and optimize to some extent, 
but they don't bring substantial speed improvements, since the 
main scheme remains the same: no write barriers, scan whole heap 
every time and hope false pointers won't cause too much leaks.

Making the GC more like in Go and JVM means adding write 
barriers, it means making general code slower (we're not 
fast-as-C anymore), it means losing easy C compatibility (hello 
FFI!), it means forbidding many current language features like 
unions and casts, it means changing the language to something 
that's not D anymore.

So I think we can expect some minor improvements in GC, but 
nothing radical.
Dec 21 2017
next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:

 Making the GC more like in Go and JVM means adding write 
 barriers, it means making general code slower (we're not 
 fast-as-C anymore), it means losing easy C compatibility (hello 
 FFI!), it means forbidding many current language features like 
 unions and casts, it means changing the language to something 
 that's not D anymore.

 So I think we can expect some minor improvements in GC, but 
 nothing radical.


What about a special GC mode for SafeD only processes which could 
probably be made precise and maybe even concurrent?
If a process is entirely in SafeD the GC would run in the "safed" 
mode otherwise the conservative GC is being run.

Go seems to make the following assumption which should be doable 
for D too: "Starting with Go 1.3, the runtime assumes that values 
with pointer type contain pointers and other values do not." [1]

[1] https://golang.org/doc/go1.3#garbage_collector
Dec 22 2017
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:

 Making the GC more like in Go and JVM means adding write 
 barriers, it means making general code slower (we're not 
 fast-as-C anymore), it means losing easy C compatibility (hello 
 FFI!)


What exactly will be lost? And do we even have easy C 
compatibility to begin with or you just don't about problems with 
it?


 it means forbidding many current language features like unions 
 and casts


They would cause no more problems than for precise GC, not 
specific to barriers.
Dec 22 2017
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:

 A good GC requires the compiler to add special bookkeeping code 
 to every pointer mutation in the heap, and to generate special 
 data for each function to help GC find all the pointers in its 
 stack and closures.


Precise stack scanning requires compiler support, yes.

You can use mprotect(2) for write barriers, and that doesn't 
require compiler support. It's relatively inefficient, though.


 Without such help from the compiler you can't make anything 
 decent, just a slow half-conservative GC that scans whole heap 
 every time and leaks memory being unable to tell whether some 
 stack value is a number or a pointer.


Numbers tend very much to be small, and pointer values tend not 
to be small, especially on 64-bit. So it shouldn't be that common 
to confuse the two. It should be more common to confuse floating 
point values for pointers, but the odds go down as address space 
increases.

Actually, there's an idea. Instrument real-world code to 
determine what address ranges are least likely to be hit by a 
false pointer, then try to arrange the GC to concentrate 
allocations in those ranges.


 Go compiler includes that special bookkeeping, so the running 
 code is a bit slower but GC can be fast, its GC can analyze 
 heap concurrently, it can clean it by parts. With C you can't 
 do that. D compiler also doesn't insert that bookkeeping code, 
 so running code is fast as C but GC is slow and sloppy.


D also offers better support for not allocating than Go. 
const/immutable to reduce defensive copies. 
std.experimental.allocator. GC.addRange for when you mix the GC 
with manually allocated memory.

Go's only objective with its collector is to reduce the maximum 
pause time, and it's not bad at that. The JVM is going for low 
overhead with its default parameters, and you can muck about with 
it to prioritize low pause times; it's better than Go at both. D 
is currently going for predictability.
Dec 21 2017
parent thedeemon <dlang thedeemon.com> writes:
On Thursday, 21 December 2017 at 22:45:23 UTC, Neia Neutuladh 
wrote:

 You can use mprotect(2) for write barriers, and that doesn't 
 require compiler support. It's relatively inefficient, though.


As I understand it's prohibitively inefficient, that's why this 
approach is not used by any real world GC.


 Without such help from the compiler you can't make anything 
 decent, just a slow half-conservative GC that scans whole heap 
 every time and leaks memory being unable to tell whether some 
 stack value is a number or a pointer.


 Numbers tend very much to be small, and pointer values tend not 
 to be small, especially on 64-bit. So it shouldn't be that 
 common to confuse the two. It should be more common to confuse 
 floating point values for pointers, but the odds go down as 
 address space increases.


Floating point values are also numbers, real numbers. ;)
Indeed in 64 bits our current GC is not too leaky. But still 
people encounter leaks occasionally, when trying to make long 
running services.


 Actually, there's an idea. Instrument real-world code to 
 determine what address ranges are least likely to be hit by a 
 false pointer, then try to arrange the GC to concentrate 
 allocations in those ranges.


I'm not sure all major OSs will let you choose freely address 
ranges when allocating memory.


 D also offers better support for not allocating than Go. 
 const/immutable to reduce defensive copies. 
 std.experimental.allocator. GC.addRange for when you mix the GC 
 with manually allocated memory.


Sure, carefully written D code has all the means to outperform Go.
Dec 21 2017
prev sibling next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 19/12/17 11:54, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 
 http://esr.ibiblio.org/?p=7804
 


I have two takeaways from that article:

1. ESR doesn't understand C++ one bit.
2. I feel exactly the same way about D.

I'll start with 1. I've been writing in C++ for a long time now, and 
have *never* had to spend much time on double frees/leaks. This is 
especially true since C++11, where the built-in types are good enough 
for anything which doesn't include graphs with cycles (and, yes, I would 
use a GC for those).

RAII + reference counting where needed pretty much eliminated those 
problems for me. ESR's lumping of C++ and C together, at the very least, 
lacks an explanation of why C++'s additional tools for handling this 
case are insufficient. A more likely case is that ESR is simply ignorant 
of them and their impact when used correctly.

The only times where I saw people mucking about with the allocators is 
when the *performance* profile was deemed not good enough. D's built-in 
facilities have nothing to offer on that front: The main case against 
the GC is it's horrid (and, worse, unexpected) performance.


I spend a lot of my time on D trying to work around the limitations that 
the GC is imposing on me, to the point where I feel like much we do here 
is to write our own infrastructure, because we can't use the built-in 
one. To be clear, the problem is a performance one here too, but the 
handling is completely different.

In C++ it is possible to start with the built-in facilities and then 
slowly work alternative ones as bottlenecks are analyzed. No such path 
is possible in D. If you don't want to use the GC, you will need to 
rework *everything*. Your entire code will have to revolve around using 
non-GC facilities, most of which you will have to write for yourself.

So, no, I'm not convinced.

Shachar
Dec 20 2017
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 20 December 2017 at 08:49:18 UTC, Shachar Shemesh 
wrote:

 On 19/12/17 11:54, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"
 
 http://esr.ibiblio.org/?p=7804
 


 I have two takeaways from that article:

 1. ESR doesn't understand C++ one bit.
 2. I feel exactly the same way about D.

 I'll start with 1. I've been writing in C++ for a long time 
 now, and have *never* had to spend much time on double 
 frees/leaks. This is especially true since C++11, where the 
 built-in types are good enough for anything which doesn't 
 include graphs with cycles (and, yes, I would use a GC for 
 those).

 RAII + reference counting where needed pretty much eliminated 
 those problems for me. ESR's lumping of C++ and C together, at 
 the very least, lacks an explanation of why C++'s additional 
 tools for handling this case are insufficient. A more likely 
 case is that ESR is simply ignorant of them and their impact 
 when used correctly.

 The only times where I saw people mucking about with the 
 allocators is when the *performance* profile was deemed not 
 good enough. D's built-in facilities have nothing to offer on 
 that front: The main case against the GC is it's horrid (and, 
 worse, unexpected) performance.


 I spend a lot of my time on D trying to work around the 
 limitations that the GC is imposing on me, to the point where I 
 feel like much we do here is to write our own infrastructure, 
 because we can't use the built-in one. To be clear, the problem 
 is a performance one here too, but the handling is completely 
 different.

 In C++ it is possible to start with the built-in facilities and 
 then slowly work alternative ones as bottlenecks are analyzed. 
 No such path is possible in D. If you don't want to use the GC, 
 you will need to rework *everything*. Your entire code will 
 have to revolve around using non-GC facilities, most of which 
 you will have to write for yourself.

 So, no, I'm not convinced.

 Shachar


I agree with you regarding C++ when I program alone, it is 
beautiful safe C++14 (now C++17) code.

However I completely disagree when I have to deal with the 
typical enterprise C++ code, that most of the time looks like C 
being compiled with a C++ compiler, from developers that learned 
it before C++98 and can't care less what is being discussed on 
Reddit and HN.


low level OS integration stuff, because that C++ that I am going 
to touch, written by such devs, will require gloves and tweezers.

--
Paulo
Dec 20 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 12/20/2017 01:14 AM, Paulo Pinto wrote:


 from developers that learned it before C++98 and
 can't care less what is being discussed on Reddit and HN.


I don't blame them one bit because keeping up with C++ and learning C++ 
Core Guidelines is a tremendous task:

 
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

I keep starting writing replies here about C++ Core Guidelines but I 
delete them after counting to ten. Not this time... :)

I think it's a psychological phenomenon worthy of scientific interest 
how a craft with so many guidelines can still be accepted. I am baffled 
how otherwise wonderful and smart people can direct others to that 
document with a straight face, let alone market it as one of the 
greatest gifts to C++ programmers (cf. CppCon 2015 keynotes by Herb 
Sutter and Bjarne Stroustrup.)

Ali
Dec 20 2017
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 20 December 2017 at 18:28:20 UTC, Ali Çehreli wrote:

 On 12/20/2017 01:14 AM, Paulo Pinto wrote:


 from developers that learned it before C++98 and
 can't care less what is being discussed on Reddit and HN.


 I don't blame them one bit because keeping up with C++ and 
 learning C++ Core Guidelines is a tremendous task:


 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

 I keep starting writing replies here about C++ Core Guidelines 
 but I delete them after counting to ten. Not this time... :)

 I think it's a psychological phenomenon worthy of scientific 
 interest how a craft with so many guidelines can still be 
 accepted. I am baffled how otherwise wonderful and smart people 
 can direct others to that document with a straight face, let 
 alone market it as one of the greatest gifts to C++ programmers 
 (cf. CppCon 2015 keynotes by Herb Sutter and Bjarne Stroustrup.)

 Ali


Mostly because it is an easier path to get people to migrate to 
safer coding practices than doing a full reboot, no one wants to 
do a Python 2 to Python 3.

For example, on the Microsoft stack it took years before the 
Windows team would even consider C++ on the kernel (since Vista).

Now that it is there, and they are working to adopt more C++17 
features, get rid of macros and so forth, it will take decades 
before they would even consider using .NET Native or any other 
alternative.

Similar story to the amount of investment Google, Apple, CERN, 
FB, Bloomberg, Goldman Sachs and many others have done in C++ 
during the last decade.

So for them it is easier to steal good ideas from D than to 
migrate to D.
Dec 20 2017
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, December 20, 2017 19:04:20 Paulo Pinto via Digitalmars-d 
wrote:

 On Wednesday, 20 December 2017 at 18:28:20 UTC, Ali Çehreli wrote:

 On 12/20/2017 01:14 AM, Paulo Pinto wrote:

 from developers that learned it before C++98 and
 can't care less what is being discussed on Reddit and HN.


 I don't blame them one bit because keeping up with C++ and
 learning C++ Core Guidelines is a tremendous task:


 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuideline
 s.md

 I keep starting writing replies here about C++ Core Guidelines
 but I delete them after counting to ten. Not this time... :)

 I think it's a psychological phenomenon worthy of scientific
 interest how a craft with so many guidelines can still be
 accepted. I am baffled how otherwise wonderful and smart people
 can direct others to that document with a straight face, let
 alone market it as one of the greatest gifts to C++ programmers
 (cf. CppCon 2015 keynotes by Herb Sutter and Bjarne Stroustrup.)


 Mostly because it is an easier path to get people to migrate to
 safer coding practices than doing a full reboot, no one wants to
 do a Python 2 to Python 3.


I think that the reality of the matter is that such a shift for C++ is
pointless. If you're going to break backwards compatability, you're breaking
one of C++'s greatest strengths. At that point, you might as well go to D or
Rust or some other language that's tried to fill C++'s shoes - or invent
another new language that attempts it. C++ can be improved, and on the
whole, they have been doing exactly that, but fundamentally, they really
can't fix it without going against some of the main reasons why many folks
stick with C++ in the first place.

- Jonathan M Davis
Dec 20 2017
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 12/20/17 10:28, Ali Çehreli wrote:

 On 12/20/2017 01:14 AM, Paulo Pinto wrote:


 from developers that learned it before C++98 and
 can't care less what is being discussed on Reddit and HN.


 I don't blame them one bit because keeping up with C++ and learning C++
 Core Guidelines is a tremendous task:


 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md


 I keep starting writing replies here about C++ Core Guidelines but I
 delete them after counting to ten. Not this time... :)

 I think it's a psychological phenomenon worthy of scientific interest
 how a craft with so many guidelines can still be accepted. I am baffled
 how otherwise wonderful and smart people can direct others to that
 document with a straight face, let alone market it as one of the
 greatest gifts to C++ programmers (cf. CppCon 2015 keynotes by Herb
 Sutter and Bjarne Stroustrup.)

 Ali


I had Chrome estimate how many pages it would be print out. In "Letter" 
size it's 181 double-sided pages. It's not "Guidelines" it is a book on 
"Best Practices"

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
Dec 20 2017
parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 21 December 2017 at 04:16:32 UTC, Adam Wilson wrote:

 On 12/20/17 10:28, Ali Çehreli wrote:

 On 12/20/2017 01:14 AM, Paulo Pinto wrote:


 from developers that learned it before C++98 and
 can't care less what is being discussed on Reddit and HN.


 I don't blame them one bit because keeping up with C++ and 
 learning C++
 Core Guidelines is a tremendous task:


 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md


 I keep starting writing replies here about C++ Core Guidelines 
 but I
 delete them after counting to ten. Not this time... :)

 I think it's a psychological phenomenon worthy of scientific 
 interest
 how a craft with so many guidelines can still be accepted. I 
 am baffled
 how otherwise wonderful and smart people can direct others to 
 that
 document with a straight face, let alone market it as one of 
 the
 greatest gifts to C++ programmers (cf. CppCon 2015 keynotes by 
 Herb
 Sutter and Bjarne Stroustrup.)

 Ali


 I had Chrome estimate how many pages it would be print out. In 
 "Letter" size it's 181 double-sided pages. It's not 
 "Guidelines" it is a book on "Best Practices"


Bjarne, Herb and others are quite aware that the only way to 
actually know the guidelines is via static code analyzers, like 
clang tidy and VC++ checkers.

And lets be a bit honest here, if someone took the effort of 
writing the D Core Guidelines, including warnings about half done 
features and differences between compilers, how many pages would 
it be?

Maybe not 181, but I can easily imagine it getting around 100.

--
Paulo
Dec 20 2017
prev sibling parent codephantom <me noyb.com> writes:
On Wednesday, 20 December 2017 at 18:28:20 UTC, Ali Çehreli wrote:

 I think it's a psychological phenomenon worthy of scientific 
 interest how a craft with so many guidelines can still be 
 accepted.


Actually, the 'core guidelines' is itself a psychological 
phenomenon of interest, given that most people will mostly never 
read it.
Dec 21 2017
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/20/2017 03:49 AM, Shachar Shemesh wrote:

 I spend a lot of my time on D trying to work around the limitations that 
 the GC is imposing on me, to the point where I feel like much we do here 
 is to write our own infrastructure, because we can't use the built-in 
 one. To be clear, the problem is a performance one here too, but the 
 handling is completely different.


I hear you. A student of mine, Alexandru Jercaianu, is working on 
Blizzard, a very interesting approach to memory allocation and safety 
(inspired by Microsoft's Project Snowflake).

At the most fundamental level it's a memory-safe implementation of 
free(). That allows us to huddle D's entire infrastructure around safe 
deterministic memory allocation with little disruption to existing code, 
and simple patterns for new code. Stay tuned, we'll have a release soon.


Andrei
Dec 20 2017
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


That is what I keep saying thanks to my experience using Oberon 
systems during
the 90's, and following everything that was done with Mesa/Cedar, 
Modula-2+, Modula-3, Singularity, Midori, just to name the most 
famous ones in CS circles.


hence .NET Native, and the language changes for features already 
present in D.

The problem is that this yet another area where developers only 
change their opinion if they experience themselves what it means 
to use a GC enabled systems programming language.

It is very hard to change the mentality that just because the GC 
is there, doesn't mean there aren't other ways to manage memory 
and other resources.

GC is a convenience, if at the end the use case constraints 
aren't met, then it is time to profile and use other approaches, 
like actually doing some manual memory management in the hot 
path, but only if it really a must have.

Google is already using Go on some of their Fuchsia system 
modules, like the TCP/IP stack and file system driver utilities, 
maybe someone like Google really needs to push such an OS into 
developers to settle the discussion once for all.

And then D's GC won't be an issue any more, given that the 
language is much better than just using Go.

--
Paulo
Dec 20 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


The question that remains, is how scalable and tunable is "D's GC 
implementation" to my programming needs (whatever they might 
happen to be).

It seems to me, that most GC implementations assume particular 
things about the environment in which they're operating, whereas 
I think that the programmer should be able to tell the GC about 
the environment in which it's operating, and the GC can adjust 
its parameter to that environment (e.g real time collection, 
generational collection, regional collection, etc...).

To the extent that a particular type of GC implementation forces 
its particular model onto the programmer, that I think, is a real 
limitation of GC.

That's why I believe manual memory management, much like the 
language C, will be around for a long time to come.
Dec 21 2017
prev sibling next sibling parent Amorphorious <Amorphorious gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


"Maybe D is right about GC after all"

or maybe not...
Dec 27 2017
prev sibling next sibling parent Adrian <adrian777 on-vol-dot.net> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


Aaaahhhh... if only D had no GC!
But then there is no such thing as perfection in this world.
Dec 28 2017
prev sibling next sibling parent reply Ali <fakeemail example.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


So .. and this is more of a question, to the maintainers and 
creators of D, what does this mean for D, what is the road map 
for D

- More support for GC free programming or
- More commitment to the GC
- Something else

It would be nice to hear from the creators of D, what is their 
vision for future development and enhancement
Dec 31 2017
parent lobo <swamplobo gmail.com> writes:
On Monday, 1 January 2018 at 05:29:06 UTC, Ali wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 So .. and this is more of a question, to the maintainers and 
 creators of D, what does this mean for D, what is the road map 
 for D

 - More support for GC free programming or
 - More commitment to the GC
 - Something else

 It would be nice to hear from the creators of D, what is their 
 vision for future development and enhancement


https://wiki.dlang.org/Vision/2017H2
Jan 01 2018
prev sibling parent reply Nerve <nervecenter7 gmail.com> writes:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


I would simply add that the strongest vocalizations come from 
those with objections. The silent majority that is perfectly okay 
with GC and gets huge development complexity reductions thanks to 
it rarely spare the energy to argue againts the constant GC 
complaints.
Jan 01 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, January 02, 2018 00:34:57 Nerve via Digitalmars-d wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I would simply add that the strongest vocalizations come from
 those with objections. The silent majority that is perfectly okay
 with GC and gets huge development complexity reductions thanks to
 it rarely spare the energy to argue againts the constant GC
 complaints.


+1

- Jonathan M Davis
Jan 01 2018
parent reply Dan Partelly <i i.com> writes:
On Tuesday, 2 January 2018 at 01:07:21 UTC, Jonathan M Davis 
wrote:

 On Tuesday, January 02, 2018 00:34:57 Nerve via Digitalmars-d 
 wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright 
 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I would simply add that the strongest vocalizations come from 
 those with objections. The silent majority that is perfectly 
 okay with GC and gets huge development complexity reductions 
 thanks to it rarely spare the energy to argue againts the 
 constant GC complaints.


 +1

 - Jonathan M Davis


Really, would you expect that the strongest vocalizations should 
come from those with no objections ? (save for ESR's rant ? ). No 
need to answer.
Jan 03 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 03, 2018 19:03:20 Dan Partelly via Digitalmars-d 
wrote:

 On Tuesday, 2 January 2018 at 01:07:21 UTC, Jonathan M Davis

 wrote:

 On Tuesday, January 02, 2018 00:34:57 Nerve via Digitalmars-d

 wrote:

 On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright

 wrote:

 "C, Python, Go, and the Generalized Greenspun Law"

 http://esr.ibiblio.org/?p=7804


 I would simply add that the strongest vocalizations come from
 those with objections. The silent majority that is perfectly
 okay with GC and gets huge development complexity reductions
 thanks to it rarely spare the energy to argue againts the
 constant GC complaints.


 +1

 - Jonathan M Davis


 Really, would you expect that the strongest vocalizations should
 come from those with no objections ? (save for ESR's rant ? ). No
 need to answer.


The problem is that there are some very vocal folks who complain about the
GC, and then that often leads to folks thinking that there's a serious
problem with the fact that D has a GC, when arguably, that isn't true at
all. There are pros and cons to using a GC, there are some circumstances
where it's not appropriate, and we can do better to have it be optional
where appropriate, but in spite of what some of the vocal folks say, it has
been a big boon to D to have a GC, and it gets increasingly annoying to have
to deal with folks insisting that the GC should be excised from everywhere
and avoided as much as possible.

So, if no one speaks up about how it's actually great to have a GC, it
starts seeming like we all think that D shouldn't have a GC, which isn't the
case at all.

- Jonathan M Davis
Jan 03 2018
parent reply Dan Partelly <i i.com> writes:
On Wednesday, 3 January 2018 at 22:28:15 UTC, Jonathan M Davis 
wrote:



 So, if no one speaks up about how it's actually great to have a 
 GC, it starts seeming like we all think that D shouldn't have a 
 GC, which isn't the case at all.

 - Jonathan M Davis


Having GC is awesome, it's like driving a luxury car with all the 
comfort and safety on highways.  But also there is need for raw 
powerful cars which  can be driven off-roads, accepting the 
risks, to haul metal and lumber to civilization, to build 
infrastructure.

Now my perception is that D tries hard to be both, with some 
regrettable consequences. Started as a GC language with language 
features which depend on GC, and a std which was done for a GC 
language and has dependency on GC. But it also envied
the cars which can be driven off roads, so it allowed GC to be 
disabled. At the cost of being unable to use parts of the 
language, and whole parts of std. Then it got even more envious 
and got a -betterC mode whose raison d'etre is unclear, apart 
from some people saying it's Walter's toy, which crippled D even 
more, and made std a dubious proposition until someone goes 
through it step by step and see the traps.
This could have been solved in 2 ways imo (hindsight )

1. Commit to GC , implement state of the art collector and be 
happy ever after
2. Go 0 abstraction route. Keep core language independent of GC 
and have std not depending on it. Then add GC support with the 
ability to completely disable it with a compiler switch from 
runtime.
Jan 04 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 08:09:27 UTC, Dan Partelly wrote:


 Now my perception is that D tries hard to be both, with some 
 regrettable consequences. Started as a GC language with 
 language features which depend on GC, and a std which was done 
 for a GC language and has dependency on GC. But it also envied
 the cars which can be driven off roads, so it allowed GC to be 
 disabled. At the cost of being unable to use parts of the


Envy? Hardly. Being able to disable D's GC was a feature from 
early on. Phobos has been modified over the years to make it more 
compatible with that scenario, as was widely requested.



 language, and whole parts of std. Then it got even more envious 
 and got a -betterC mode whose raison d'etre is unclear, apart 
 from some people saying it's Walter's toy, which crippled D 
 even more, and made std a dubious proposition until someone 
 goes through it step by step and see the traps.


The reason for -betterC is quite clear (and again, has nothing to 
do with envy): to make it easier to port C (and eventually C++) 
code to D, and to make D easier to use in environments where the 
runtime is a burden (e.g. OS kernels). It does not "cripple" D.
Jan 04 2018
parent reply Dan Partelly <i i.com> writes:
On Thursday, 4 January 2018 at 08:28:31 UTC, Mike Parker wrote:
abled. At the cost of being unable to use parts of the

 Envy? Hardly. Being able to disable D's GC was a feature from 
 early on. Phobos has been modified over the years to make it 
 more compatible with that scenario, as was widely requested.


I used envy colloquially.
Yes, disabling GC might have been a feature early on. But not 
early on enough to not have core language features depending on 
it, and not early enough to have a std not depending on it. 
Modifying the std to be more compatible with this scenario is 
indeed happening, but as you say it is a process which started 
years ago, and its still dragging on, and no clear docs with what 
works and what not.



 The reason for -betterC is quite clear (and again, has nothing 
 to do with envy): to make it easier to port C (and eventually 
 C++) code to D, and to make D easier to use in environments 
 where the runtime is a burden (e.g. OS kernels). It does not 
 "cripple" D.


Rust has a OS being written right now. Does D has ? Anyone ever 
wanted to use D to write a OS kernel, I doubt it. Is anyone 
seriously thinking today to port their *working* and maintained C 
code bases to D, possibly introducing new bugs in the process ? 
(yes some people like Walter did, Im aware of this. But I doubt 
this will have any serious adoption)

Id rather use a nice language as D to write new software, not to 
port old **working**   tools which are only maintained and not 
developed to it. I see no sense for that.
Jan 04 2018
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:


 Id rather use a nice language as D to write new software, not 
 to port old **working**   tools which are only maintained and 
 not developed to it. I see no sense for that.


And the reality of having ported the DMD frontend to D and that 
Walter is porting the DMC frontend to D is here to just tell us 
that such things are worth sometimes...

/P
Jan 04 2018
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:

 Rust has a OS being written right now. Does D has ? Anyone ever 
 wanted to use D to write a OS kernel, I doubt it.


Yes, a group started on it,  but I don't think it reached 
completion. Anyway, you see traces of interest around the 
internet, e.g. http://wiki.osdev.org/D_Bare_Bones

But the argument is fair, as long as Walter and Andrei are trying 
to position D as an alternative to C and C++. Then D should be 
evaluated on those terms.

However, Rust won't fare well in a head-to-head comparison 
either, because of the issues with back-pointers.
Jan 04 2018
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad 
wrote:

 However, Rust won't fare well in a head-to-head comparison 
 either, because of the issues with back-pointers.


Could you explain this?
Jan 04 2018
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 January 2018 at 10:49:49 UTC, Dgame wrote:

 On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim 
 Grøstad wrote:

 However, Rust won't fare well in a head-to-head comparison 
 either, because of the issues with back-pointers.


 Could you explain this?


You often want back-pointers for performance reasons, but Rust 
default pointer model isn't as accepting to cycles. So you either 
have to change your design or loose the benefits that the 
compiler provides, at which point C++ is more convenient, but it 
depends on what you try to do.
Jan 04 2018
parent Dgame <r.schuett.1987 gmail.com> writes:
On Thursday, 4 January 2018 at 11:04:51 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 4 January 2018 at 10:49:49 UTC, Dgame wrote:

 On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim 
 Grøstad wrote:

 However, Rust won't fare well in a head-to-head comparison 
 either, because of the issues with back-pointers.


 Could you explain this?


 You often want back-pointers for performance reasons, but Rust 
 default pointer model isn't as accepting to cycles. So you 
 either have to change your design or loose the benefits that 
 the compiler provides, at which point C++ is more convenient, 
 but it depends on what you try to do.


As far as I remember you can use pointers as you normally do if 
you use them in unsafe blocks. Not that I ever tried.
Jan 04 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:


 Rust has a OS being written right now. Does D has ? Anyone ever 
 wanted to use D to write a OS kernel


https://github.com/xomboverlord/xomb
https://github.com/PowerNex/PowerNex
https://github.com/JinShil/stm32f42_discovery_demo

But they don't seem to compare to 
https://github.com/redox-os/redox or 
https://github.com/helena-project/tock

My interest in D is primarily to be able to use it for ARM 
Cortex-M microcontrollers.  Unfortunately, Rust is kicking D's 
butt in that domain (https://japaric.github.io/discovery/).  But 
I just don't enjoy programming in Rust like I do in D.  So, I'm 
trying to see what I can do to reduce the coupling between the 
compiler and the runtime so I can use D in a more pay-as-you-go 
fashion.  One of my first PRs in that regard was pulled recently 
(https://github.com/dlang/dmd/pull/7395) and I have a few more 
ideas along those lines.  But, I still have a lot to learn.

Mike
Jan 04 2018
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:

 Rust has a OS being written right now. Does D has ? Anyone ever 
 wanted to use D to write a OS kernel, I doubt it.


https://github.com/PowerNex/PowerNex
https://github.com/Rikarin/Trinix



 Id rather use a nice language as D to write new software, not 
 to port old **working**   tools which are only maintained and 
 not developed to it. I see no sense for that.


But others do ;-)
Jan 04 2018
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:


 Yes, disabling GC might have been a feature early on. But not 
 early on enough to not have core language features depending on 
 it, and not early enough to have a std not depending on it. 
 Modifying the std to be more compatible with this scenario is 
 indeed happening, but as you say it is a process which started 
 years ago, and its still dragging on, and no clear docs with 
 what works and what not.


I fundamentally disagree with the idea that core features 
shouldn't depend on the GC. I love that they do. As for Phobos, I 
also don't expect it to be completely GC-free. If there are parts 
of it that can be but aren't, then perhaps a PR?


 Rust has a OS being written right now. Does D has ? Anyone ever 
 wanted to use D to write a OS kernel, I doubt it.


There have been at least three kernels in D that I know of, the 
most recent being PowerNex. However, I'm unaware of any that are 
non-hobby projects.


Is anyone
 seriously thinking today to port their *working* and maintained 
 C code bases to D, possibly introducing new bugs in the process 
 ? (yes some people like Walter did, Im aware of this. But I 
 doubt this will have any serious adoption)


I can't answer for Walter, but my understanding is yes, there 
are. He and Andrei have communication with interests outside of 
these forums.

The whole point of -betterC is to *avoid* the introduction of new 
bugs. It allows you to port your C code directly to D with very 
minimal changes. You can convert a function to D, compile the 
object, link the program, and make sure it works as expected. It 
allows you to continue to distribute/use your program before it 
is fully ported and to verify that it works as expected. Walter's 
use of it is a real-world use case that shows how useful it is.


 Id rather use a nice language as D to write new software, not 
 to port old **working**   tools which are only maintained and 
 not developed to it. I see no sense for that.


So, how does the existence of -betterC stop you from writing new 
software? I'm using D without -betterC just fine.
Jan 04 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 03, 2018 at 03:28:15PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]

 The problem is that there are some very vocal folks who complain about
 the GC, and then that often leads to folks thinking that there's a
 serious problem with the fact that D has a GC, when arguably, that
 isn't true at all. There are pros and cons to using a GC, there are
 some circumstances where it's not appropriate, and we can do better to
 have it be optional where appropriate, but in spite of what some of
 the vocal folks say, it has been a big boon to D to have a GC, and it
 gets increasingly annoying to have to deal with folks insisting that
 the GC should be excised from everywhere and avoided as much as
 possible.
 
 So, if no one speaks up about how it's actually great to have a GC, it
 starts seeming like we all think that D shouldn't have a GC, which
 isn't the case at all.


[...]

+1.

Even though I'm well aware of the current GC's limitations, and have
implemented various workarounds in my own code, I totally agree that it
has been great to have a GC in D.  It frees up a big chunk of my mental
capacity while coding to actually think about the problem domain, rather
than being drained by constantly needing to think about memory
management issues, like I have to when writing C/C++ code.  It makes for
faster development time, and less bugs (heck, it eliminates an entire
class of bugs that commonly plague C/C++ code).

The performance cost is usually not even noticeable unless you're
writing (1) memory-intensive, CPU-intensive code, or (2) real-time code
like medical appliance controllers where people may die if the code
doesn't respond within 1ms, or (3) 3D game engines where people may die
if they miss an animation frame or two, though only virtually. :-P

When the GC *does* become a source of performance concerns, I've found
that in 99% of the cases all it takes is to call GC.disable and schedule
your own GC.collect at strategic points in your code.  In one particular
memory-intensive, CPU-intensive program I wrote, all I needed was to
make a 3-line change:

	...
	GC.disable;
	...
	if (++counter % 1_000_000 == 0) // or whatever number you wish
		GC.collect;

and I was able to obtain performance improvements upwards of 40%.

Furthermore, upon closer inspection, eliminating array allocations in
one specific hotspot in my inner loop by reusing a static buffer won me
another 15-20% performance improvement, again a rather small code
change, and standard practice to reduce GC load.

All it took was to run a profiler to identify the hotspots, and fix the
few places in the code where it actually mattered (and usually, such
places only need a minor change).  The rest of the code was perfectly
fine using the GC just as it is. There was no need to completely excise
the GC, rewrite all of my code to use ref-counting or *shudder*
malloc/free, or any of the extreme stuff that the vocal minority seems
to advocate for.

I'm not saying there aren't use cases where you *do* want to use  nogc
and completely avoid the GC ( nogc is there for a reason), but that
these use cases aren't all as common as some people would have us think.
The majority of application code won't even notice a difference, even
with the current supposedly poor GC.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
Jan 03 2018
prev sibling parent reply codephantom <me noyb.com> writes:
On Tuesday, 2 January 2018 at 00:34:57 UTC, Nerve wrote:

 I would simply add that the strongest vocalizations come from 
 those with objections. The silent majority that is perfectly 
 okay with GC and gets huge development complexity reductions 
 thanks to it rarely spare the energy to argue againts the 
 constant GC complaints.


Well, consider the silent 'minority' too, who still think that 
increasing performance, and reducing demands on resources, still 
matter, a lot, and that we shouldn't just surrender this just to 
make programmers more 'productive' (i.e so they can ship slower 
GC code, more quickly).

Or are you saying there is no overhead associated with GC?
Or if there is, are you saying it never matters..ever?

Or are you saying GC does not impose extra demand on resources?
Or if it does, are you saying it never matters..ever?

What it really comes down to though, is language designers 
ensuring that any language that defines itself as a 'modern 
systems programming language', gives control 'to the programmer', 
and not the other way around.

We've had over a decade of this crazy unconstrained growth in 
bloat (slower code, and more of it), in the world of software 
developement. So, perhaps we should start paying more attention 
to the vocal minority.
Jan 01 2018
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 January 2018 at 04:43:42 UTC, codephantom wrote:

 Well, consider the silent 'minority' too, who still think that 
 increasing performance, and reducing demands on resources, 
 still matter, a lot, and that we shouldn't just surrender this 
 just to make programmers more 'productive' (i.e so they can 
 ship slower GC code, more quickly).


I think most of the people in this minority (which actually I 
think was a majority a few years back) has given up on D as a 
production language.  I am certainly in that group.  It is 
starting to be a bit late to change direction now IMO. I mean, it 
is still possible, but that would require a mentality shift, 
which has been surprisingly difficult to establish.

Given the increased availability of memory in computers I think 
an application language with built in compiler-supported arena 
allocator will be a big win, but the only mainstream language 
that is going for this seems to be Golang. (Go is an application 
language, not a systems language).



 What it really comes down to though, is language designers 
 ensuring that any language that defines itself as a 'modern 
 systems programming language', gives control 'to the 
 programmer', and not the other way around.


Right now, I think only C++ and Rust fits the "modern system 
programming" description… GC and refcounting is for application 
level programming, so it shouldn't even be on the table as a core 
solution for that domain.

But D seems to be content with application level programming and 
that's ok too, but a bit misleading if you also say that you aim 
to be the best language for low level programming… I don't really 
think it is possible to be good at both without a massive budget.

You have to pick what you want to be good at. And that is the 
main problem with the evolution of D; a lack of commitment to a 
specific niche.
Jan 02 2018
parent reply Dan Partelly <i i.com> writes:
On Tuesday, 2 January 2018 at 11:53:38 UTC, Ola Fosheim Grøstad 
wrote:

 You have to pick what you want to be good at. And that is the 
 main problem with the evolution of D; a lack of commitment to a 
 specific niche.


It has multiple personalities, but unlike C++ all of them are 
discordant with each other. Perhape's Alexandrescu's remark [1] 
that D suffer from a historical lack of vision is true on more 
than one sense. Still, D is close ..

[1] 
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why
Jan 03 2018
parent reply Tony <tonytdominguez aol.com> writes:
Why would someone choose to use a language with a Garbage 
Collector and then complain that the language has a Garbage 
Collector?
Jan 03 2018
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 January 2018 at 19:42:28 UTC, Tony wrote:

 Why would someone choose to use a language with a Garbage 
 Collector and then complain that the language has a Garbage 
 Collector?


People always complain about garbage collectors that freeze up 
the process. Irrespective of the language. It's the antithesis of 
low level programming…
Jan 03 2018
parent reply Tony <tonytdominguez aol.com> writes:
On Wednesday, 3 January 2018 at 21:11:06 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 3 January 2018 at 19:42:28 UTC, Tony wrote:

 Why would someone choose to use a language with a Garbage 
 Collector and then complain that the language has a Garbage 
 Collector?


 People always complain about garbage collectors that freeze up 
 the process. Irrespective of the language. It's the antithesis 
 of low level programming…


Why would they choose D for low level programming when they knew 
before they chose it that it had a Garbage Collector? It seems 
like their programming language decision methodology  was flawed. 
To me,  the only people who should be complaining about D's 
garbage collector are people who don't use D, not people who do. 
But maybe that is the case, the people who complain about the 
Garbage Collector in this D forum are not using D.
Jan 03 2018
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 January 2018 at 22:37:54 UTC, Tony wrote:

 Why would they choose D for low level programming when they 
 knew before they chose it that it had a Garbage Collector?


Because it was/is a work-in-progress when they first got 
interested in it, and it was also advertised as a replacement for 
C and C++.  It was also assumed that one could expect significant 
improvements on the GC as the language matured. But of course, 
computers also get more and more memory to scan…



 who do. But maybe that is the case, the people who complain 
 about the Garbage Collector in this D forum are not using D.


Both. Some use D, but not the GC after initialization. Some 
wanted to use D (in production), but has put that on hold and are 
just waiting to see where it is heading. Some gave up on D for 
low level programming and turned to other languages.

So yes and no. ;-)
Jan 03 2018