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 C#. -- 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 see it as a better C#. The GC is great to have. Even better is 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 over C++ as it does C# and Java. Currently D has much better 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). I've been writing a voxel engine in C#. Writing anything high performance in C# becomes non-idiomatic, you're locked into OOP and performance sucks. D offers far more features C# and Java. As a result, I think D would have a greater appeal on those audiences. For example, writing vector structs in C# requires you to 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. Furthermore, C# and Java deeply emphasise the OOP paradigm. They're not very expressive languages. D can do everything C#'s 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. Also, there is not much in the way of getting around C#'s GC. 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 such as C# and Java and present itself as a general purpose language. I think it will draw more people from the C#/Java crowd 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 over C++ as it does C# and Java. Currently D has much better 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.
 I've been writing a voxel engine in C#. Writing anything high 
 performance in C# becomes non-idiomatic, you're locked into OOP 
 and performance sucks.

 D offers far more features C# and Java. As a result, I think D 
 would have a greater appeal on those audiences.
The big issues with Java and C# are the required 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.
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]
 The big issues with Java and C# are the required infrastructure=20
 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:
 
[…]
 The big issues with Java and C# are the required 
 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.
C# and F# also have a lot going for them, I suspect you used it 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.
 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.
C# and F# also have a lot going for them, I suspect you used it 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.
No. I didn't mean C# per se. What I mean is 'dotnet' (the attempt my MSFT to port C# to other platforms.) I have to sit and wait 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 language. I do like C#, so I'm not against that, but making 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 more or less with the syntax of C,C++,Java,C#, I cannot 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 and a header file). Then a C++ to C# shim. Then a C# to C++ low-level shim. Then a high level C# wrapper. Then an Excel function wrapper written in C#. Now you want me to add a new 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 working on C#. For Python we could easily use PyD (which we have 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.
 I've been writing a voxel engine in C#. Writing anything high 
 performance in C# becomes non-idiomatic, you're locked into OOP 
 and performance sucks.
 Furthermore, C# and Java deeply emphasise the OOP paradigm. 
 They're not very expressive languages. D can do everything C#'s 
 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.
 D offers far more features C# and Java. As a result, I think D 
 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 
 such as C# and Java and present itself as a general purpose 
 language. I think it will draw more people from the C#/Java 
 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, C# or Go in application development except where the code is 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. So I happily use Java and C# at work, only dealing with C++ for 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. Microsoft has been busying adopting lessons from Midori into C#, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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