Re: Why D is not popular enough?
On 8/1/2016 11:31 AM, Emre Temelkuran wrote: For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP, JScript, JVM Languages. Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that i can't remember. I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i first heard about D after 2005 when i was 14-15 years old. I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community. Why people need NodeJS, Typescript etc, when there is already better looking lang? Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed? I am a C++ expert who has looked at D in the past. Perhaps my reasons for not programming in D may be taken as some of the reasons why D "is not popular enough". My opinions are not meant to start a flame war, even if some of my insights may be harsh to those who do use D. They will hopefully give some idea of why and where D went wrong in trying to appeal to the general intelligent programmer as a programming language. 1) Until very recently the documentation for D has been very substandard. I do notice better documentation both on the web site now and a few more books on D as a programming language. For a very long time after D was created, even after version 2 was created, there was essentially no decent documentation at all. If you are trying to promote the use of a computer language to the general public you must create first-rate documentation and explanation of your computer language from the very beginning. Without this first-rate documentation your programming language, no matter how good it might be, is just a toy to those who want to play around with it and try it out. This is the case that D promoted for a very long time, so the expectation that D was going to become popular to the programming public with such poor documentation was just foolish. C took off as a programming language for the general programming when Kernigan and Ritchie wrote their classic book and C++ took off as a programming language for the general public when Stroustrop and subsequently Lippman wrote their classuc books. While I think that Alexandrescu's book is decent it is not written at the level of these others. 2) While I greatly respect the programming abilities of Mr. Bright and Mr. Alexandrescu and their hard work in creating and improving D, having followed both from the C++ world, the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the beginning. C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. 3) D has suffered greatly because it has had too many moving targets as if constant change to something slightly better is going to endear programmers to using a computer language. Programmers need stability. The needed to know that if they are using a programming language they are getting a particular standard at a particular time with particular libraries that work. They also need backward compatibility when things change. D appears to have presented an almost constantly moving target to this programmer, where adding/changing some feature is much more important than fixing problems and providing stability. 4) As a C++ programmer largely interested in C++ template programming, C++ concepts etc., and potential compile-time/run-time introspection, I have never found a compelling reason to use D rather than C++. I do recognize that C++'s template syntax is difficult and abstruse but I do not and have never seen where D improves upon these matters in any serious and rigorous way. This may be because the documentation about these areas in D is either very light or almost completely lacking. Even in Mr. Alexandrescu's book the discussion of these areas was very light in my estimation. So whatever D has to offer in these areas, if there are really impovements, is either lacking in the D documentation or does not really exist for me. Edward Diener
Re: Downloadable spec for D version 2
On 11/20/2012 10:04 PM, G. wrote: On Tuesday, 20 November 2012 at 02:27:08 UTC, Edward Diener wrote: Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ? The HTML version is in the ZIP with dmd... Thanks !
Re: Downloadable spec for D version 2
On 11/20/2012 9:53 AM, Dan wrote: On Tuesday, 20 November 2012 at 02:27:08 UTC, Edward Diener wrote: Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ? I got it from amazon for kindle for $0.99. http://www.amazon.com/D-Programming-Language-Specification-ebook/dp/B005CCQPKK/ref=sr_1_1?s=books&ie=UTF8&qid=1353422974&sr=1-1&keywords=d+programming+language+specification If you don't have a kindle you could still read with amazon cloud reader - but this is not great because no search or copy/paste. However, you can download and convert the amazon format to mobi and probably pdf with calibre which is a great tool. So the D Language Spec version 2 is only in Kindle format, and not in PDF or HTML anyplace it can be downloaded ?
Downloadable spec for D version 2
Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ?
Re: What's C's biggest mistake?
Walter Bright wrote: http://www.reddit.com/r/programming/comments/ai9uc/whats_cs_biggest_mistake/ This reminds me of the Java idiots when Java first came out. They discussed C endlessly trying to prove Java's supremacy as the new premier language, and either completely ignored that C++ existed or acted as if C++ was a computer language nobody actually used as opposed to that paragon of an up to date programming excellence circa 1996, the C programming language. Think how you will feel in 10 years when others belittle the D programming language, compared to other languages around in 2019, and are always referring to D version 1. While I admire much of the work you have done in creating D, it does not take much for an intelligent programmer to realize that your own view of C++ is jaundiced and heavily affected by what you perceive as D's improvements over C++. As a suggestion, which I don't expect you to take, you would do much better in viewing C++ in a more reasonable light while touting features of D which you feel is an improvement.
Re: contravariant argument types: wanna?
Lutger wrote: Andrei Alexandrescu wrote: ... I am considering discussing all of the above in detail in TDPL, but I am afraid that some refugees from other languages will be shocked. Please, it's much more important to write a good book than to avoid possibly offending the sensibilities of potential readers. Besides, anymore willing to take a risk with D will surely be open to learning something new. My sensibilities are deeply offended by your first sentence.
Re: Type unions in D
Justin Johansson wrote: Jeremie Pelletier Wrote: As for the max of an empty set, you can just return zero. Well you could return -1, 99 or any arbitrary integer for that matter; just that it doesn't make sense to do that from a pure maths perspective. Mathematicians have spent centuries trying to make number systems consistent. The invention (or discovery**) of "i", the square-root of minus-one, was a major major break-through. In similar vein, it's nice if the type systems we use for programming follow from a consistent set of axioms. ;-) Your return situation is what an 'optional' template is made for. The entire idea about 'optional' is that you should be able to always return a value for a type which is not a valid value for that type. Some other languages use a built-in value, like 'None' in Python, to solve the problem. C++ and D can use an 'optional' template to solve this problem. See optional in Boost for the C++ answer. I believe Andrei is working on a similar solution for D.
Re: How Nested Functions Work, part 1
Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescu wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that "Function pointers and delegates may merge into a common syntax and be interchangeable with each other," so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Why do you think pointer to member function was a "departure from C++'s usual approach" ? Don't pay for what you don't use, low-key approach to under-the-wraps magic. The pointer to member type is the most elaborate of all C++ built-in types. If I don't use it, I don't see how I am paying for it. Bjarne mentioned in one of his books of having considered the C++ version of a delegate as a language construct ( taking the address of an object's member function ) sometime in the design of C++ and having rejected it. I can not remember the reason but it was evidently considered. I'm not saying it was a decision made in ignorance. IMHO it was, however, a wrong decision, and experience with pointer to member functions (i.e., few even know how to write one down) supports that hypothesis. Hooking an object to a C++ pointer to member functions is not really rocket science syntax . That they are inflexible in reusable cases, and need the scaffolding that at least boost::function/boost::bind provides to be really reuable is a given. It is easy in retrospect to say that C++ should have gone with the delegate concept, as C# and D have done, but remember that C++'s origins were many years ago in a Bell lab far away. I don't think pointer to member function is a disas
Re: How Nested Functions Work, part 1
Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescu wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that "Function pointers and delegates may merge into a common syntax and be interchangeable with each other," so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code ! Actually it could be said that C++'s exercise with pointers to member functions, which unifies a variety of functions (virtual, nonvirtual, in a host of multiple inheritance scenario), although KISS-motivated for the user, was at the same time a departure from C++'s usual approach, and a disastrous one. Why do you think pointer to member function was a "departure from C++'s usual approach" ? Bjarne mentioned in one of his books of having considered the C++ version of a delegate as a language construct ( taking the address of an object's member function ) sometime in the design of C++ and having rejected it. I can not remember the reason but it was evidently considered. I don't think pointer to member function is a disaster, just sometimes difficult to use, and of course very limiting. I agree I would have still liked a delegate to be part of the C++ language instead of pointer to member function, since the former is much more flexible. But std::function/std::bind ( boost::function/boost::bind or boost::lambda ) solves that problem nicely at the expense of a little more syntax but with great flexibility in binding.
Re: How Nested Functions Work, part 1
Andrei Alexandrescu wrote: Edward Diener wrote: Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescu wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that "Function pointers and delegates may merge into a common syntax and be interchangeable with each other," so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language. IMHO it's ok if there are two types, as long as function is implicitly convertible to delegate. Function pointers have the advantage that they are only one word in size, can be assigned to atomically, and help interfacing with C callback APIs. Good point ! That would be fine also. The basic issue is to allow a single syntactical construct to encompass all callables in order to simplify code design. But I am still theoretically in favor of the single type, purely from KISS principles. The single delegate type subsumes the function pointer type. As far as the size savings, of course some small amount of memory can be saved. As far as the assigned speed, if the delegate type in D is as I suppose a language, and not a library, implementation, the language ( compiler ) can be smart enough to know that the programmer is assigning a function pointer to the delegate and make the speedier atomic assignment. What I imagine will happen in D is that when an updated delegate type allows itself to be initialized with a function pointer, the vast majority of D programmers will use delegate for all callables and the function pointer will remain simply an artefact of the language. Then D can eventually get rid of it ! This is analogous to the transition that will happen in C++ from function pointers/member function pointers to std::function in C++0x. Of course I never expect C++ to get rid of anything because some person in 3009, going back to code 100 years old and still supported by C++30x, still uses function pointers/member function pointers and the C++ standard committee deems it impermissible to break that code !
Re: How Nested Functions Work, part 1
Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 9:45 AM, Andrei Alexandrescu wrote: Jarrett Billingsley wrote: Well repeat should probably always take a delegate since most likely, you're going to be passing it a lambda. However I agree that it would be very, very nice to be able to make APIs take just delegates and allow functions to be implicitly cast to them. You can already make your own thunks, but they're not going to be as efficient as something that actually works on an ABI level. Did someone file a bug report on this? Surprisingly, it doesn't seem like it. Walter himself, in the spec, said that "Function pointers and delegates may merge into a common syntax and be interchangeable with each other," so I just assume that no one has found it necessary to make a report. Maybe there should be. I suggested this a long time back on this NG, and I am sure many others have also. A function pointer should essentially be a delegate whose object is null. That is essentially the way delegates are in .Net. In C++, boost::Function can encompass any C++ callable type so there is little theoretical reason why D should not encompass all callable types into a delegate. Having to program for any callable type, in a functional callable or signal/slots library, by dealing with the two signature variations of a function pointer and a delegate rather than a single common signature is a real PITA in an advanced programming language.
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. "I know what I'm doing", I thought. But later, when reading the code, I found it very helpful to know that my "a" could be changed when invoking "fun". As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? C#'s requirement is just stupid.
Re: Why Java Doesn't Need Operator Overloading (and Very Few Languages Do, Really)
Paul D. Anderson wrote: Sounds like someone needs a strong dose of D!! http://java.dzone.com/articles/why-java-doesnt-need-operator The comments bounce between "operator overloading is always bad because you can do idiotic things with it" and "operator overloading is essential because sometimes you really need it". How about a language where operator overloading is available for the cases where you do really need it, but isn't available in general? Hmmm... Java's lack of operator overloading is the most idiotic language decision which I have ever encountered. The arguments against operator overloading are equivalent to "if we allow feature X, programmers might not use it the way we have decided it should be used, therefore we won't allow it". "Idiotic" is not even a strong enough word to describe the retrograde thinking of the Java fanatics, and Sun, who have decided to tell programmers what is good for them, whether they want to swallow that pill or not. Java is the only major language I use which does not have operator overloading. C++, Python, Ruby, C#, and D all have operator overloading. Among other things this means that while 1 + 2 in Java is valid, if I write a BigInteger Java class I must write: BigInteger a = 1; BigInteger b = 2; BigInteger c = a.Add(b); or some such other nonsense rather than the completely natural BigInteger c = a + b;. To say that the lack of operator overloading in Java somehow makes the language "better" or "clearer to use" is so ludicrous it needs no further comment. Eventually Java will add operator overloading, since Sun's fanaticism is clearly earning them a quick exit into buyout land ( if not IBM today it will be someone else tomorrow ). Then everyone from the Java fanatic camp will smile and say "wasn't that a brilliant decision Sun made", as if it hadn't been made by everyone else ages ago. Sorry for the non-D related diatribe but someone else started this thread and I can't help remarking how stupid a language must be in this day and time which does not support operator overloading for ease of syntax use.
Re: __FUNCTION__
Andrei Alexandrescu wrote: Edward Diener wrote: Andrei Alexandrescu wrote: Edward Diener wrote: I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities. D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point. The whole debate about "compile-time" and "run-time" reflection is irrelevant as long as one can invoke it without having to inject code into an already existing construct. It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it. Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs. Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules. So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return. This is a long discussion, but in brief any runtime reflection engine needs some sort of compile-time metadata infrastructure. Some languages don't make that accessible within the language itself. Runtime reflection has been explored extensively, its possibilities and limitations are pretty well understood, I hardly smothered a yawn reading all you wrote. It was written because I have inevitably seen discussions about language reflection mechanisms end with talk about really neat new compile-time facilities which bring one no closer to real run-time reflection than before. Compile-time reflection is much less understood and hides many more exciting possibilities. With the advances in compiler technology implemented by Walter, we have a chance to tackle reflection in a systematic manner. Good ! I look forward to seeing it and using it in D.
Re: __FUNCTION__
Andrei Alexandrescu wrote: Edward Diener wrote: I argued for this in the past on this NG but still no one seems to have picked up the idea that a full reflection library for D, supported fully by the compiler, would be a great thing. It would also allow RAD programming with D outside of the functionality one could use in 3rd party tools designed around full run-time reflection capabilities. D2 will have reflection. (Walter doesn't know yet. He thinks D3 will have reflection.) It will be compile-time reflection because only run-time reflection only is missing the point. The whole debate about "compile-time" and "run-time" reflection is irrelevant as long as one can invoke it without having to inject code into an already existing construct. It must work through run-time code which can ask such reflection questions as: enumerate for me all of the classes in a particular module etc., or enumerate for me all the functions in a class etc. . It must work by allowing code from outside of a construct to query that construct and get its accessible constructs. How that run-time code is written, whether using "compile-time" reflection using templates, or run-time classes accessible from a library whose reflection data is produced by the D compiler, is not important from the user's point of view as long as the user has the access he wants and can write relatively clean and clear code to get it. Of course from within any given construct one should also be able to write code in a clear manner which accesses the inner constructs. Access to constructs via reflection should follow the same protection features as any other code, so that public constructs are always accessible but private constructs are only accessible following their normal rules. So I do not know what you mean by "only run-time reflection only is missing the point" but certainly the ability to use reflection at run-time is vitally important from outside of a construct to any 3rd party tool which wants to introspect already existing constructs and create objects from those constructs based on the information run-time reflection can return.
Re: __FUNCTION__
Andrei Alexandrescu wrote:
BCS wrote:
Hello Andrei,
Nick Sabalausky wrote:
Stdout.formatln("{}", __FUNCTION__);
I think instead of __FUNCTION__ we'll define a much more comprehensive
static reflection facility.
for the above case I think __FUNCTION__ is as good as it will get.
Define it as a human readable identifier rather than reflection.
You will have it as a human readable identifier too. The problem with
__FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
happened to __STRUCT__, __MODULE__ et al?) can go forever.
These macros are the wrong idea. As you say the bare macros can go on
forever. What is really needed in a reflection library is the ability to
'reflect' all D constructs, and you would get much more than just the
name in such a library.
So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix
solution whereas a real reflection library gives so much more.
I argued for this in the past on this NG but still no one seems to have
picked up the idea that a full reflection library for D, supported fully
by the compiler, would be a great thing. It would also allow RAD
programming with D outside of the functionality one could use in 3rd
party tools designed around full run-time reflection capabilities.
