www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Quora: Why hasn't D started to replace C++?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei
Jan 30
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...] I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer? Just yesterday I was experimenting with ldc while reviewing a Phobos PR, and it showed that LDC was well able to reduce iteration over a range down to a native asm loop of the same order of efficiency as an equivalent C++ loop. So, the cost of D (arguably better) abstractions simply *isn't there*. Both languages compile to the *same* native code. Where's C++'s "enormous performance advantage?" I'm not seeing it, except in this article, and, presumably, in the author's imagination. And of course, in the comments section there's the obligatory reference to the Tango/Phobos split in D1. Eye-roll. That one never gets old, it seems, even though it's already ancient history that the modern D community has mostly forgotten about. The internet is good for disseminating information, and also great for prolonging ignorance. Enough of this nonsense. Let me get back to coding... in D. :-D T -- What is Matter, what is Mind? Never Mind, it doesn't Matter.
Jan 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 January 2018 at 21:02:13 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...] I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer?
Well, I understand what you mean, but there are more performance related options for C++ than for any other language at the moment. I don't use them, most people don't, but they exist. So for people that care a lot about throughput there basically is no other "complete" alternative...
Jan 30
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 09:26:30PM +0000, Ola Fosheim Grøstad via Digitalmars-d
wrote:
 On Tuesday, 30 January 2018 at 21:02:13 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu via
 Digitalmars-d wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...] I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer?
Well, I understand what you mean, but there are more performance related options for C++ than for any other language at the moment. I don't use them, most people don't, but they exist. So for people that care a lot about throughput there basically is no other "complete" alternative...
Specific examples, please. What are some examples of these "performance related options"? T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Jan 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 January 2018 at 21:30:06 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 09:26:30PM +0000, Ola Fosheim Grøstad 
 via Digitalmars-d wrote:
 Specific examples, please. What are some examples of these 
 "performance related options"?
Supported concurrency options and tuning etc.
Jan 30
prev sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
Thats not completly true, last time I tried some of best c++ version from
http://benchmarksgame.alioth.debian.org/. I was able to write much
idiomatic D code which was faster than c++ witch use some specific
libraries and so on. So my experience is that D is same or faster than C++

On Tue, Jan 30, 2018 at 10:26 PM, Ola Fosheim Gr=C3=B8stad via Digitalmars-=
d <
digitalmars-d puremagic.com> wrote:

 On Tuesday, 30 January 2018 at 21:02:13 UTC, H. S. Teoh wrote:

 On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu via
 Digitalmars-d wrote:

 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...] I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer?
Well, I understand what you mean, but there are more performance related options for C++ than for any other language at the moment. I don't use them, most people don't, but they exist. So for people that care a lot about throughput there basically is no other "complete" alternative...
Jan 30
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 January 2018 at 21:43:45 UTC, Daniel Kozak wrote:
 Thats not completly true, last time I tried some of best c++ 
 version from http://benchmarksgame.alioth.debian.org/. I was 
 able to write much idiomatic D code which was faster than c++ 
 witch use some specific libraries and so on. So my experience 
 is that D is same or faster than C++
I'm not thinking about those. I'm thinking about supported tooling that makes you more productive when writing code with high throughput.
Jan 30
next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
Yes, than you are right

On Tue, Jan 30, 2018 at 10:49 PM, Ola Fosheim Gr=C3=B8stad via Digitalmars-=
d <
digitalmars-d puremagic.com> wrote:

 On Tuesday, 30 January 2018 at 21:43:45 UTC, Daniel Kozak wrote:

 Thats not completly true, last time I tried some of best c++ version fro=
m
 http://benchmarksgame.alioth.debian.org/. I was able to write much
 idiomatic D code which was faster than c++ witch use some specific
 libraries and so on. So my experience is that D is same or faster than C=
++

 I'm not thinking about those. I'm thinking about supported tooling that
 makes you more productive when writing code with high throughput.
Jan 30
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 09:49:46PM +0000, Ola Fosheim Grøstad via
Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 21:43:45 UTC, Daniel Kozak wrote:
 Thats not completly true, last time I tried some of best c++ version
 from http://benchmarksgame.alioth.debian.org/. I was able to write
 much idiomatic D code which was faster than c++ witch use some
 specific libraries and so on. So my experience is that D is same or
 faster than C++
I'm not thinking about those. I'm thinking about supported tooling that makes you more productive when writing code with high throughput.
That's not what the article says. The article says, and I quote: C++’s enormous performance advantage (extremely efficient native code) Meaning, the "enormous performance advantage" is because of "extremely eefficient native code". I don't argue that C++ has extremely efficient native code. But so has D. So the claim that C++ has an "enormous performance advantage" over D is specious. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Jan 30
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 Meaning, the "enormous performance advantage" is because of 
 "extremely eefficient native code".  I don't argue that C++ has 
 extremely efficient native code. But so has D. So the claim 
 that C++ has an "enormous performance advantage" over D is 
 specious.
Well, it isn't relevant for those people who would adopt D anyway. Of course, C++ and Java have some advantages by being so large that there is a market for commercial specialty solutions and services... Although most C++ and Java programmers use tooling that is essentially free (well except perhaps the IDE), so for most of them it won't matter. Even when smaller languages try to implement such tooling/features there isn't a large enough user base to harness the implementation (since even for big languages the actual user base for those features are low), so it is very hard for smaller languages to branch into those special niches unless the whole language feature set is geared towards a specific niche... but that harms adoption too...
Jan 30
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 30, 2018 at 10:12:07PM +0000, Ola Fosheim Grøstad via Digitalmars-d
wrote:
 On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 Meaning, the "enormous performance advantage" is because of
 "extremely eefficient native code".  I don't argue that C++ has
 extremely efficient native code. But so has D. So the claim that C++
 has an "enormous performance advantage" over D is specious.
Well, it isn't relevant for those people who would adopt D anyway.
[...] Ha! Exactly! It's just as Walter has said before: our time is better spent making D better for those who are already using D, or who are *genuinely* interested in adopting D, rather than bending over backwards trying to please the crowd that, after you fix their current complaint, will only move on to the next excuse not to use D. T -- Life is complex. It consists of real and imaginary parts. -- YHL
Jan 30
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 30 January 2018 at 23:36:59 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 10:12:07PM +0000, Ola Fosheim Grøstad 
 via Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 [...]
Well, it isn't relevant for those people who would adopt D anyway.
[...] Ha! Exactly! It's just as Walter has said before: our time is better spent making D better for those who are already using D, or who are *genuinely* interested in adopting D, rather than bending over backwards trying to please the crowd that, after you fix their current complaint, will only move on to the next excuse not to use D. T
Created a new thread?
Jan 31
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 31 January 2018 at 18:16:40 UTC, 12345swordy wrote:
 On Tuesday, 30 January 2018 at 23:36:59 UTC, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 10:12:07PM +0000, Ola Fosheim Grøstad 
 via Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 [...]
Well, it isn't relevant for those people who would adopt D anyway.
[...] Ha! Exactly! It's just as Walter has said before: our time is better spent making D better for those who are already using D, or who are *genuinely* interested in adopting D, rather than bending over backwards trying to please the crowd that, after you fix their current complaint, will only move on to the next excuse not to use D. T
Created a new thread?
It's a forum quirk.
Jan 31
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 "extremely eefficient native code".  I don't argue that C++ has 
 extremely efficient native code. But so has D. So the claim 
 that C++ has an "enormous performance advantage" over D is 
 specious.
We also need to keep in mind that for a small segment of C++ programmers it is important to be able to use CPU/SoC/hardware vendor backed compilers so that they can ship optimized code the day a new CPU is available. So there is a distinct advantage there for people who don't aim for consumer CPUs. Most programmers don't care as much, since adoption of new CPUs is slow enough for GCC/Clang to catch up in time. Anyway, as C++ is taking more and more of C's niche, this issue can be more an more "threatening". E.g. hardware vendors that now only ship C compilers might in the future only ship C++ compilers... I don't know exactly where this is going, but it is possible that C++ could become hard to displace for hardware oriented programming. Seems like more an more embedded programming is moving to C++ from C.
Jan 30
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 30 January 2018 at 22:43:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 30 January 2018 at 21:49:39 UTC, H. S. Teoh wrote:
 "extremely eefficient native code".  I don't argue that C++ 
 has extremely efficient native code. But so has D. So the 
 claim that C++ has an "enormous performance advantage" over D 
 is specious.
We also need to keep in mind that for a small segment of C++ programmers it is important to be able to use CPU/SoC/hardware vendor backed compilers so that they can ship optimized code the day a new CPU is available. So there is a distinct advantage there for people who don't aim for consumer CPUs. Most programmers don't care as much, since adoption of new CPUs is slow enough for GCC/Clang to catch up in time. Anyway, as C++ is taking more and more of C's niche, this issue can be more an more "threatening". E.g. hardware vendors that now only ship C compilers might in the future only ship C++ compilers... I don't know exactly where this is going, but it is possible that C++ could become hard to displace for hardware oriented programming. Seems like more an more embedded programming is moving to C++ from C.
BMW has a few talks from 2017 talking about them and the remaining car manufacturers finally moving away from C into C++11 (on a 2nd talk they refer C++14). They are also taking care that car electronic standard certifications move to C++. Sony did a similar one regarding embedded electronics. CodePlay just started a similar work for MISRA. So with those companies only now leaving C and moving into C++, it will take at least a decade before they consider something else. And lets not forget Arduino, ESP286 and ESP32 are making wonders for the kids to jump into C++ as their first language.
Jan 30
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 06:27:05 UTC, Paulo Pinto wrote:
 And lets not forget Arduino, ESP286 and ESP32 are making 
 wonders for the kids to jump into C++ as their first language.
That's interesting, MS got a lot of traction for BASIC by making it available in ROM on basically (no pun intended) all 8-bit computers in the 80s. To most young programmers there was no other language than BASIC (and machine language).
Jan 31
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2018 04:02 PM, H. S. Teoh wrote:
 On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu via
Digitalmars-d wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...] I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer? Just yesterday I was experimenting with ldc while reviewing a Phobos PR, and it showed that LDC was well able to reduce iteration over a range down to a native asm loop of the same order of efficiency as an equivalent C++ loop. So, the cost of D (arguably better) abstractions simply *isn't there*. Both languages compile to the *same* native code. Where's C++'s "enormous performance advantage?" I'm not seeing it, except in this article, and, presumably, in the author's imagination. And of course, in the comments section there's the obligatory reference to the Tango/Phobos split in D1. Eye-roll. That one never gets old, it seems, even though it's already ancient history that the modern D community has mostly forgotten about. The internet is good for disseminating information, and also great for prolonging ignorance. Enough of this nonsense. Let me get back to coding... in D. :-D
At best responses would go on Quora, not here. Thanks! -- Andrei
Jan 30
parent reply thedeemon <dlang thedeemon.com> writes:
On Tuesday, 30 January 2018 at 22:38:20 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...]
 At best responses would go on Quora, not here. Thanks! -- Andrei
That's a question from 2014. I wonder if anybody would see those answers.
Jan 30
next sibling parent mate <aiueo aiueo.aiueo> writes:
On Wednesday, 31 January 2018 at 04:55:02 UTC, thedeemon wrote:
 On Tuesday, 30 January 2018 at 22:38:20 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
[...]
 At best responses would go on Quora, not here. Thanks! -- 
 Andrei
That's a question from 2014. I wonder if anybody would see those answers.
The top 2 answers seem to have been posted in the last two weeks, and they show 14.7k and 12.8k views respectively.
Jan 30
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2018-01-31 at 04:55 +0000, thedeemon via Digitalmars-d wrote:
 On Tuesday, 30 January 2018 at 22:38:20 UTC, Andrei Alexandrescu=20
 wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
=20 [...]
At best responses would go on Quora, not here. Thanks! -- Andrei
=20 That's a question from 2014. I wonder if anybody would see those=20 answers.
But that is the problem with Quora, Stackoverflow, and all similar sites =E2=80=93 and Google, etc. Statements and code fragments made far in = the past become reified as facts hindering evolution of knowledge because Google finds them and they are on Quora, Stackoverflow, etc. It is critically important to address the questions and answers that have become wrong over time, to ensure people who search for stuff find things that are true at the time of the search. Old stuff needs flagging as old and out of date. --=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
Jan 31
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2018 1:02 PM, H. S. Teoh wrote:
 Where's C++'s "enormous performance advantage?"  I'm not seeing it,
 except in this article, and, presumably, in the author's imagination.
I know C, C++, and D code generation semantics. There is only one case where C/C++ can fundamentally generate better code than D. That's where C/C++ have undefined behavior when signed integers overflow, and slightly better code can be generated for it. D has defined behavior for this (2's complement), and so does Rust. The performance enhancement can be obtained if you use unsigned integers instead, and besides, the advantage is very slight, and comes with a large amount of confusion for even experienced programmers. Not worth it.
Jan 30
prev sibling next sibling parent reply Andrew Benton <Andrew.Benton675 gmail.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
I think that the largest issue there is probably the marketing and advocacy. When Rust was about the same share as D, it had much better marketing. Someone was running their twitter channel and working to make the language much more visible. D flat out doesn't have that. If I had to pick a second issue, it's that the ecosystem story is hard compared to other languages. New programmers aren't certain what to choose or how to get their environment up and running. Compared against Rust, Go, and Java we have horrible ecosystem fragmentation. E.g. three compilers, two separate languages for dub
Jan 30
next sibling parent reply Benny <benny.luypaert rhysoft.com> writes:
On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton 
wrote:
 If I had to pick a second issue, it's that the ecosystem story 
 is hard compared to other languages.  New programmers aren't 
 certain what to choose or how to get their environment up and 
 running.  Compared against Rust, Go, and Java we have horrible 
 ecosystem fragmentation.  E.g. three compilers, two separate 
 languages for dub
* three compilers And 3 different installation method's depending on the platform. Windows: DMD installer, LDC manually extract zip and setup path, GDC ... Now not all platforms are better. Go with its default compiler and cGo are also two different beasts. But both perform in regards to performance close to the point that you can rely on the main compiler as production compiler. The same can not be said about DMD and LDC where the performance differences can be huge. Let me add a few other issues to your list: * Library Auto generated libraries where all functions are dumped into massive one pagers. https://dlang.org/phobos/std_datetime_date.html Is this readable when the first two pages are this: jan feb mar apr may jun jul aug sep oct nov dec sun mon tue wed thu fri sat Const "jump to" lists intermixed between the documentation. No clear function calls: const pure nothrow nogc property safe ubyte daysInMonth(); Const Pure nothrow nogc property safe ubyte ... and FINALLY the actual function call your looking for: daysInMonth(); Now the question becomes without looking at the example!!! Is this part of Date, Datetime, ... You can not tell because the way you jump to page anchors and with a bit of scrolling, you lose where you are. Everything Date belongs into a Date Subpage with a method/function Index page. And that method/function Index page links to separated pages for EACH method. You know the extra advantage: It makes finding information from a search engine like Google way more easy and less clutter / clean. No issue for people who read this manual hundred of times or know the function calls from there head. But it just ugly and unclean. ...................................... The real problem is that anybody can find 100's of issues that are simply unproductive or make the language look like a mess. And they get reported all the time but there is nobody to work on them. When the company line is: Do it yourself or pay somebody to do it. Guess what the first reaction of a lot of people is. *miep* *miep* *snooof* ... and you hear nothing from them anymore. A few may struggle, get into arguments and then they give up. And the rest simply complains about trolls who come to complain all the time and do not do the work. D is highly individualized as a language with actually very little corporation between the 100's of project, that get abandoned when the only developer runs out of time or moves to a differed language. I put a lot of money in several FOSS projects and it always feel like trowing money into a bottomless pit. Very few projects show where there money is being spend, let me correct that, not a single FOSS project where i put money into has every published where the money really gets spend. The closed that i ever got was Crystal where Manas.tech gives a yearly report of there time spend, money intake, ... https://crystal-lang.org/2017/12/19/this-is-not-a-new-years-resolution.html Its the core issue with D. * Why replace C++ with D when C++ does all the same with just a bit more effort but in exchange you get access to way more community, development, tools, support. * Why replace Rust with D when Rust is more actively developed, has better tooling support, focuses on drawing in new people, has key selling points that its drones keep repeating over and over again. * Why replace any language with D... We can talk until we turn blue and wast ages discussing the issues. But very few outsiders will put in the voluntary effort on a language where most doubt its future. That includes me ( and i know people will jump on this as being a troll comment ). There is a reason why i am focusing on learning Rust for my next project and not D. Despite Rust its more complex designs, its the whole package that is simply better organised. And do not take this that i am a rust troll. While yes, D gets used by some big companies on specific projects, the reality is that this seems to stem more from one developer in that company using D and not a real interest to use it company wide. D simply has too few people, no real goal, is a mishmash of different people with mostly individualized goals, a lacking and unclear foundation, lacking in paid developers. In simple terms, what D accomplished in 20 years time, is being overturned C++ taking the same features, Rust developing at a very fast rate, Swift same, Go same ... and with a mass of choice to people, if one does not stand out. This really remind me of a Knight Tale: "You have been weighed, you have been measured, and you have been found wanting". I said it before, i tried getting into D for over a year and keep running into just stupid issues with DMD regressions, editor plugins that do not work, unfinished or unsupported projects, just badly designed documentation layouts, ... just everywhere lacking. And with the amount of time trying to get things working, reporting issues on github, ... sigh ... so much time better spend on other languages. I told before if there is no leadership to focus resources and the main developers are more focused on adding more features to the compiler that is already overflowing, then how do you expect to see things solved? Let me say this again: I like D but unless you are years into D as a developer its just frustrating to deal with the constant issues. And please ... do like always, cut my post into small parts and start criticizing and attacking the author that he needs to "put more effort into it or pay". Or some other bullshit. And then complain how people troll the forum because they complain and not do anything to solve it. Tired of reading the same rhetoric as are the people who think posts like this are troll posts.
Jan 31
next sibling parent reply Benny <benny.luypaert rhysoft.com> writes:
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 Let me say this again
*uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved.
Jan 31
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Wed, 31 Jan 2018 10:55:56 +0000, Benny wrote:

 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 Let me say this again
*uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved.
I wouldn't call it a waste of time. I've been noting problems people run into consistently, though I haven't done anything about any of them yet. And that's the thing, when someone says either do it yourself or pay someone, it's because that is often the only way to get something done in a small volunteer organization (not just programming projects). I came to D because it will help me with a couple of projects I wanted to do; if I stop to work on something else, I'm stopping what I wanted to do. So most of the time, I'm going to prioritize my problems. Some people have made the compiler and/or tooling their projects; others will put a hold on what they're doing to fix small issues. Not many will stop working on their stuff to do major things for someone else. (Maybe some sort of community challenge could help(?)) When money is spent, it tends to go to compiler/language development because that helps everybody; if only 60% of people use some tool, only 60% of people benefit from that work. There comes a time when the ROI is worth it, but those spending money don't seem to think we're there yet. Anyway, mostly because of your recent posts I'm going to take a look at DlangIDE. If we can package a cross-platform IDE+compiler+dub as a single download and you're ready to go, that might make it easier to give D a try, even if most people would later set up something else; at least you'd only deal with the problems after you've decided it's worth it.
Jan 31
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 31 January 2018 at 12:03:22 UTC, rjframe wrote:
 On Wed, 31 Jan 2018 10:55:56 +0000, Benny wrote:
[...]
 Anyway, mostly because of your recent posts I'm going to take a 
 look at DlangIDE. If we can package a cross-platform 
 IDE+compiler+dub as a single download and you're ready to go, 
 that might make it easier to give D a try, even if most people 
 would later set up something else; at least you'd only deal 
 with the problems after you've decided it's worth it.
Yes, would be very good! And than ad a series of short example programs, to this one-stop-download, maybe party from Adam's arsd. Like: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d And the examples from D-Lang Tour. So you only push a button [try D], and get a running environment to play around.
Jan 31
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 12:34:01 UTC, Martin 
Tschierschke wrote:
 On Wednesday, 31 January 2018 at 12:03:22 UTC, rjframe wrote:
 On Wed, 31 Jan 2018 10:55:56 +0000, Benny wrote:
[...]
 Anyway, mostly because of your recent posts I'm going to take 
 a look at DlangIDE. If we can package a cross-platform 
 IDE+compiler+dub as a single download and you're ready to go, 
 that might make it easier to give D a try, even if most people 
 would later set up something else; at least you'd only deal 
 with the problems after you've decided it's worth it.
Yes, would be very good! And than ad a series of short example programs, to this one-stop-download, maybe party from Adam's arsd. Like: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d And the examples from D-Lang Tour. So you only push a button [try D], and get a running environment to play around.
Like this? https://tour.dlang.org/tour/en/dub/mir It's a small series since today. Any help with filling the blank content or new pages is welcome. See https://forum.dlang.org/post/acovehcwaxjykmhekuwh forum.dlang.org for adding new libraries to run.dlang.io
Jan 31
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 31 January 2018 at 18:35:50 UTC, Seb wrote:
[...]
 Like: 
 https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d
 And the examples from D-Lang Tour.

 So you only push a button [try D], and get a running 
 environment to play around.
Like this? https://tour.dlang.org/tour/en/dub/mir It's a small series since today. Any help with filling the blank content or new pages is welcome. See https://forum.dlang.org/post/acovehcwaxjykmhekuwh forum.dlang.org for adding new libraries to run.dlang.io
This looks very promising! Have not been on the dang tour page for several month, it shows an amazing progress!! Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. On the other side a voting mechanism in the forum would be very useful, so readers can mark a post as valuable maybe to be be displayed in a special feed. I know this is difficult because the forum has more than only the web frontend. But why not translate the [I recommend to read this]-Button into a mail or post, with the content ... **recommend** this. And probably back? from short mail only with **KEYWORD**. It would fill up the mailboxes of the readers, but it would be easier to count than this "me too ++" posts.
Feb 01
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 01 Feb 2018 11:11:20 +0000, Martin Tschierschke wrote:


 Idea: There should be some kind of news ticker for all enhancements and
 important decisions, maybe at first just via twitter  with a special
 #tag  beside #dlang where all updates are announced. And a place on the
 homepage, where this feed is displayed separately.
The announce forum gets most things; if you're not reading it you'll want to (between that and the changelog for the compiler and library, that's most activity). A twitter bot to pull all announce posts from core committers might not be a bad idea.
Feb 01
next sibling parent Seb <seb wilzba.ch> writes:
On Thursday, 1 February 2018 at 11:40:32 UTC, rjframe wrote:
 On Thu, 01 Feb 2018 11:11:20 +0000, Martin Tschierschke wrote:


 Idea: There should be some kind of news ticker for all 
 enhancements and important decisions, maybe at first just via 
 twitter  with a special #tag  beside #dlang where all updates 
 are announced. And a place on the homepage, where this feed is 
 displayed separately.
The announce forum gets most things; if you're not reading it you'll want to (between that and the changelog for the compiler and library, that's most activity). A twitter bot to pull all announce posts from core committers might not be a bad idea.
Shouldn't be too hard: https://github.com/CyberShadow/DFeed/issues/97
Feb 01
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 1 February 2018 at 11:40:32 UTC, rjframe wrote:
 On Thu, 01 Feb 2018 11:11:20 +0000, Martin Tschierschke wrote:


 Idea: There should be some kind of news ticker for all 
 enhancements and important decisions, maybe at first just via 
 twitter  with a special #tag  beside #dlang where all updates 
 are announced. And a place on the homepage, where this feed is 
 displayed separately.
The announce forum gets most things; if you're not reading it you'll want to (between that and the changelog for the compiler and library, that's most activity). A twitter bot to pull all announce posts from core committers might not be a bad idea.
Not could - it's now is: https://forum.dlang.org/post/tzyleprmwjmdnjhhpnub forum.dlang.org
Feb 02
parent rjframe <dlang ryanjframe.com> writes:
On Fri, 02 Feb 2018 20:04:33 +0000, Seb wrote:

 Not could - it's now is:
 https://forum.dlang.org/post/tzyleprmwjmdnjhhpnub forum.dlang.org
Sometimes y'all get things done so quickly I'm surprised everybody's a volunteer. --Ryan
Feb 02
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 1 February 2018 at 11:11:20 UTC, Martin Tschierschke 
wrote:
 Idea: There should be some kind of news ticker for all 
 enhancements and important decisions, maybe at first just via 
 twitter  with a special #tag  beside #dlang where all updates 
 are announced. And a place on the homepage, where this feed is 
 displayed separately.
I had hoped the blog would be used for that purpose. Obviously it is not. From what I've seen, the D Language Twitter account mostly tweets to announce new blog posts. The subreddit is another place these announcements could go, but that seems to get little attention as well. The view seems to be that there should only be announcements of the really big stuff. My opinion is that it's better to err on the side of too many announcements rather than too few.
Feb 01
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 1 February 2018 at 12:04:11 UTC, bachmeier wrote:

 I had hoped the blog would be used for that purpose. Obviously 
 it is not.
And it won't be. I had vaguely imagined using it for semi-regular news updates from the core D team, but I realized early on that isn't going to pan out.
 From what I've seen, the D Language Twitter account mostly 
 tweets to announce new blog posts.
Stepping up twitter usage is one of my priorities for this year. The blog tweets are automated every time I publish a new blog post. I'm slowly increasing my twitter time investment, responding and retweeting #dlang tweets when it fits. I plan to start tweeting out smaller news items there that aren't big enough for blog posts. I'll keep an eye on the forums for news, and cast a net outside the core community now and again. I encourage anyone who sees something they think D_Programming should tweet out to email me and let me know. Or tweet about it with #dlang. I'm scanning Twitter every couple of days right now. I also have an announcement coming on the blog very soon regarding using Twitter to fix bugs.
Feb 01
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/1/2018 3:11 AM, Martin Tschierschke wrote:
 Idea: There should be some kind of news ticker for all enhancements and 
 important decisions, maybe at first just via twitter  with a special #tag  
 beside #dlang where all updates are announced. And a place on the homepage, 
 where this feed is displayed separately.
It's already there on the right side of https://dlang.org/
Feb 01
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright wrote:
 On 2/1/2018 3:11 AM, Martin Tschierschke wrote:
 Idea: There should be some kind of news ticker for all 
 enhancements and important decisions, maybe at first just via 
 twitter  with a special #tag  beside #dlang where all updates 
 are announced. And a place on the homepage, where this feed is 
 displayed separately.
It's already there on the right side of https://dlang.org/
 with a special #tag  beside #dlang
The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more.
Feb 02
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke 
wrote:
 On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright 
 wrote:
 On 2/1/2018 3:11 AM, Martin Tschierschke wrote:
 Idea: There should be some kind of news ticker for all 
 enhancements and important decisions, maybe at first just via 
 twitter  with a special #tag  beside #dlang where all updates 
 are announced. And a place on the homepage, where this feed 
 is displayed separately.
It's already there on the right side of https://dlang.org/
 with a special #tag  beside #dlang
The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more.
The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration.... and yes, a quarterly report is enough. /Paolo
Feb 02
parent Martin Tschierschke <mt smartdolphin.de> writes:
On Friday, 2 February 2018 at 08:39:58 UTC, Paolo Invernizzi 
wrote:
 On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke
[...]
 Maybe there should be a blog post, with some kind of status 
 report every .. weeks or .. month? Telling more about the 
 focus of the D foundation, statistics of downloads, number of 
 fixed bugs, partly similar to Adams week in D but more 
 official. I think the content of such a post may find its way 
 into more mainstream IT magazines, if marked as official d 
 foundation  press release even more.
The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration.... and yes, a quarterly report is enough. /Paolo
Yes, looks very good!
Feb 02
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 31 January 2018 at 10:55:56 UTC, Benny wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 Let me say this again
*uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved.
It's quite easy to tell when criticism is made in good or bad faith, and at this point I'm going to reply to every rant in bad faith on here about how terrible D is with "Post issue numbers" and nothing else. If you have a legitimate problem, make an issue at issues.dlang.org
Jan 31
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 14:22:03 UTC, Jack Stouffer 
wrote:
 It's quite easy to tell when criticism is made in good or bad 
 faith
Is it? Why do so many people have problems with it then? Stupidity?
 and at this point I'm going to reply to every rant in bad faith 
 on here about how terrible D is with "Post issue numbers" and 
 nothing else. If you have a legitimate problem, make an issue 
 at issues.dlang.org
Ok, and now you are entering a messy space, define "legitimate"? I think the most important issue he raised was how project management is either under-communicated or conducted. Either way he sends a strong signal that he is one person (of many) that D failed to convert even though he was motivated and able. I don't think that is his problem... as he has many other options, but it most certainly could be an indicator of a project challenge. By neglecting that you also neglect what could be a source for process improvement. Development processes need continuous improvement. They don't happen by themselves, they need attention throughout the lifespan of the project. It is a matter of priorities, of course, but that is not a question of "legitimate", that is a question of "ranking". For some reason this ranks below colourful error-messages. I don't know the reasoning behind that ranking, so I am not going to argue whether that is the right priorities, but it _looks_ odd, so something is either under-communicated or maybe he was right about management related issues. I don't know. Whatever spot D is in right now in comparison to other projects, good or bad, most certainly isn't because of a lack of marketing. Marketing would only bring in more demanding users and more such not "legitimate" issues would be raised. People expect less friction today than they did 10 years ago. To some extent Microsoft, Google, Jetbrains and others have handed out slick freebies and conditioned programmers to be more demanding. That is the dynamics of the current "market".
Jan 31
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 31 January 2018 at 17:02:06 UTC, Ola Fosheim 
Grøstad wrote:
 Is it?  Why do so many people have problems with it then? 
 Stupidity?
Perhaps the D front page can say "Now with 1 Standard Library!" ;)
 Ok, and now you are entering a messy space, define 
 "legitimate"?  I think the most important issue he raised was 
 how project management is either under-communicated or 
 conducted.
The best programmers won't necessarily be the best at project management or communication. That's ok...provided people better suited at project management or communication can and do contribute their skills. For instance, Mike Parker's work on the D blog has been a great improvement in communication the past year or two.
Jan 31
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 18:05:30 UTC, jmh530 wrote:
 contribute their skills. For instance, Mike Parker's work on 
 the D blog has been a great improvement in communication the 
 past year or two.
Yep, to have a living blog is very important IMHO.
Jan 31
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 18:05:30 UTC, jmh530 wrote:
 contribute their skills. For instance, Mike Parker's work on 
 the D blog has been a great improvement in communication the 
 past year or two.
Yep, having a living blog is very important I think. It is always something I look at when visiting project website, just to assess where the project is moving.
Jan 31
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 31 January 2018 at 17:02:06 UTC, Ola Fosheim 
Grøstad wrote:
 Ok, and now you are entering a messy space, define "legitimate"?
Actionable, clear, and made with the intent to better the language/ecosystem and not just to complain.
 Development processes need continuous improvement.
And we have been. I would rate our QA tooling to be 3x better now than when I started.
 For some reason this ranks below colourful error-messages.
That's just something that Walter was able to bang out in an hour, should have been done years ago, and was excited about. There's tons of work being done on GH that's never talked about here in the forums.
 Whatever spot D is in right now in comparison to other 
 projects, good or bad, most certainly isn't because of a lack 
 of marketing.
We clearly have a lot of work to do on messaging when many of the Quora answers are using eight year old information as condemnation.
 People expect less friction today than they did 10 years ago.
 To some extent Microsoft, Google, Jetbrains and others have 
 handed out slick freebies and conditioned programmers to be 
 more demanding.
True. D would be a in great place if everything worked out of the box if people wanted an IDE. But the post I was replying to first noted issues with the ecosystem six days ago, and has already rage quit over it.
Jan 31
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 31 January 2018 at 19:00:57 UTC, Jack Stouffer 
wrote:
 For some reason this ranks below colourful error-messages.
That's just something that Walter was able to bang out in an hour
Yet he recently, months after starting, complained that "technical debt", specifically citing coloring error messages, was eating enough of his time to cause a forum lamentation.
Jan 31
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 19:54:05 UTC, Adam D. Ruppe 
wrote:
 On Wednesday, 31 January 2018 at 19:00:57 UTC, Jack Stouffer 
 wrote:
 For some reason this ranks below colourful error-messages.
That's just something that Walter was able to bang out in an hour
Yet he recently, months after starting, complained that "technical debt", specifically citing coloring error messages, was eating enough of his time to cause a forum lamentation.
... and Mike did put _a lot_ of effort in pushing colorful error messages: https://github.com/dlang/dmd/projects/2
Jan 31
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 31 January 2018 at 19:59:23 UTC, Seb wrote:
 ... and Mike did put _a lot_ of effort in pushing colorful 
 error messages:
Yes, that was a direct result of that forum post I alluded to. It isn't something he (or most anyone else, in my experience) really cares about, but he felt if he did it then many Walter wouldn't waste any more time on it.
Jan 31
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 31, 2018 at 08:05:37PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 On Wednesday, 31 January 2018 at 19:59:23 UTC, Seb wrote:
 ... and Mike did put _a lot_ of effort in pushing colorful error
 messages:
Yes, that was a direct result of that forum post I alluded to. It isn't something he (or most anyone else, in my experience) really cares about, but he felt if he did it then many Walter wouldn't waste any more time on it.
In fact, I find the colors distracting. Pretty? Certainly. But helpful? Not really, at least not for me. I'd rather stick with just B&W. But all things considered, it's a pretty minor issue, and one that's not worth the time to complain about. (Haha, and look what I just did. :-P) T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Jan 31
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 1:19 PM, H. S. Teoh wrote:
 I'd rather stick with just B&W.
dmd -color=off file.d
Jan 31
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 31, 2018 at 05:16:21PM -0800, Walter Bright via Digitalmars-d wrote:
 On 1/31/2018 1:19 PM, H. S. Teoh wrote:
 I'd rather stick with just B&W.
dmd -color=off file.d
Thanks! Though, as I said, it doesn't bother me quite enough to want to go through the effort of explicitly specifying that. It's just that, if it were up to me, I wouldn't bother putting in the time and energy to implement such kinds of cosmetic features. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Jan 31
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 5:58 PM, H. S. Teoh wrote:
 cosmetic features.
I tough lesson I've learned is that cosmetics matter, a lot. Sometimes much more than substance. There's no getting away from it.
Jan 31
parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright wrote:
 On 1/31/2018 5:58 PM, H. S. Teoh wrote:
 cosmetic features.
I tough lesson I've learned is that cosmetics matter, a lot. Sometimes much more than substance. There's no getting away from it.
This is one reason I recommend markdown for docs. Cosmetics is what markdown does best. People *like* looking at it and editing it. It's like typing an email or a forum comment. Other reasons I recommend it are: * everyone already knows it (it's at github, stackoverflow, and reddit), * it's fairly easy to write (as easy as possible while still looking good), * there's an open spec (CommonMark), and * writing new language-specific markup formats appears to be something that's not done anymore. There's javadoc, texinfo, doxygen, docbook, groff --- all very ... *mature* technologies. In modern projects: Rust uses markdown, Python uses reST, Git uses asciidoc --- all general-purpose non- language-specific lightweight markup formats. The only reason I can think of for *not* using markdown for project docs is if your project is another competing lightweight markup format.
Feb 01
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 19:28 +0000, John Gabriele via Digitalmars-d
wrote:
 On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright wrote:
 On 1/31/2018 5:58 PM, H. S. Teoh wrote:
 cosmetic features.
=20 I tough lesson I've learned is that cosmetics matter, a lot.=20 Sometimes much more than substance. There's no getting away=20 from it.
I agree but only if s/Markdown/AsciiDoctor/g
 This is one reason I recommend markdown for docs. Cosmetics is=20
 what markdown does best. People *like* looking at it and editing=20
 it. It's like typing an email or a forum comment.
=20
 Other reasons I recommend it are:
=20
    * everyone already knows it (it's at github, stackoverflow, and=20
 reddit),
=20
    * it's fairly easy to write (as easy as possible while still=20
 looking good),
=20
    * there's an open spec (CommonMark), and
=20
    * writing new language-specific markup formats appears to be=20
 something that's not done anymore. There's javadoc, texinfo,=20
 doxygen, docbook, groff --- all very ... *mature* technologies.=20
 In modern projects: Rust uses markdown, Python uses reST, Git=20
 uses asciidoc --- all general-purpose non- language-specific=20
 lightweight markup formats.
=20
 The only reason I can think of for *not* using markdown for=20
 project docs is if your project is another competing lightweight=20
 markup format.
Markdown was created to write a few HTML pages. AsciiDoc (and thus AsciiDoctor) was invented to be a front end to the DocBook/XML toolchain. Thus Markdown is for a few small very simple webpages, AsciiDoctor is for creating any form of document from a page to a book. They are similar where Markdown has functionality, but AsciiDoctor has so much more, and most people end up finding they want all the extras. XeLaTeX and Sphinx/ReStructuredText are the competition for AsciiDoctor. Markdown is lacking in functionality people will find they need to use. --=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
Feb 02
parent John Gabriele <jgabriele fastmail.fm> writes:
On Friday, 2 February 2018 at 14:30:25 UTC, Russel Winder wrote:
 On Thu, 2018-02-01 at 19:28 +0000, John Gabriele via 
 Digitalmars-d wrote:
 On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright 
 wrote:
 On 1/31/2018 5:58 PM, H. S. Teoh wrote:
 cosmetic features.
I tough lesson I've learned is that cosmetics matter, a lot. Sometimes much more than substance. There's no getting away from it.
I agree but only if s/Markdown/AsciiDoctor/g
 This is one reason I recommend markdown for docs. Cosmetics is 
 what markdown does best. People *like* looking at it and 
 editing it. It's like typing an email or a forum comment.
 
 Other reasons I recommend it are:
 
    * everyone already knows it (it's at github, stackoverflow, 
 and
 reddit),
 
    * it's fairly easy to write (as easy as possible while still
 looking good),
 
    * there's an open spec (CommonMark), and
 
    * writing new language-specific markup formats appears to be
 something that's not done anymore. There's javadoc, texinfo,
 doxygen, docbook, groff --- all very ... *mature* technologies.
 In modern projects: Rust uses markdown, Python uses reST, Git
 uses asciidoc --- all general-purpose non- language-specific
 lightweight markup formats.
 
 The only reason I can think of for *not* using markdown for 
 project docs is if your project is another competing 
 lightweight markup format.
Markdown was created to write a few HTML pages. AsciiDoc (and thus AsciiDoctor) was invented to be a front end to the DocBook/XML toolchain. Thus Markdown is for a few small very simple webpages, AsciiDoctor is for creating any form of document from a page to a book. They are similar where Markdown has functionality, but AsciiDoctor has so much more, and most people end up finding they want all the extras. XeLaTeX and Sphinx/ReStructuredText are the competition for AsciiDoctor. Markdown is lacking in functionality people will find they need to use.
Note that markdown is a small sharp tool in your toolbox: for writing easily readable (in plain text) docs, easily converted to html. For more than that, tools like [Pandoc](http://pandoc.org): * convert markdown to html but also to a bunch of other formats as well, and * support extra markdown functionality like tables, definition lists, footnotes, and citations. Don't know how if handles making an index. Also, note that it's not uncommon to write a short script that stitches together a handful of markdown docs into a website or other larger composite doc. I even wrote one myself: <http://www.unexpected-vortices.com/sw/rippledoc/index.html>. There may be others listed at <https://github.com/jgm/pandoc/wiki/Pandoc-Extras>.
Feb 07
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 31, 2018 17:16:21 Walter Bright via Digitalmars-d 
wrote:
 On 1/31/2018 1:19 PM, H. S. Teoh wrote:
 I'd rather stick with just B&W.
dmd -color=off file.d
I have to wonder if my settings are right. I've never noticed any color in error messages. Messing around with some errors right now, the only color I see is that "Error:" is in red, and some of the text is bolded, so it's white instead of the grey that text is normally on my console. Maybe my console's settings aren't interacting with the color stuff very well. - Jonathan M Davis
Jan 31
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 6:14 PM, Jonathan M Davis wrote:
 I have to wonder if my settings are right. I've never noticed any color in
 error messages. Messing around with some errors right now, the only color I
 see is that "Error:" is in red, and some of the text is bolded, so it's
 white instead of the grey that text is normally on my console. Maybe my
 console's settings aren't interacting with the color stuff very well.
Nah, it's just the code in dmd: if (username == "Jonathan") color = off; // muwa-ha-ha-hah!
Jan 31
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 31, 2018 19:01:46 Walter Bright via Digitalmars-d 
wrote:
 On 1/31/2018 6:14 PM, Jonathan M Davis wrote:
 I have to wonder if my settings are right. I've never noticed any color
 in error messages. Messing around with some errors right now, the only
 color I see is that "Error:" is in red, and some of the text is bolded,
 so it's white instead of the grey that text is normally on my console.
 Maybe my console's settings aren't interacting with the color stuff
 very well.
Nah, it's just the code in dmd: if (username == "Jonathan") color = off; // muwa-ha-ha-hah!
Clearly, there are downsides to actually knowing the people who work on the compiler. ;) - Jonathan M Davis
Jan 31
prev sibling parent Jan Knepper <jan digitalmars.com> writes:
On 01/31/2018 10:01 PM, Walter Bright wrote:
 On 1/31/2018 6:14 PM, Jonathan M Davis wrote:
 I have to wonder if my settings are right. I've never noticed any 
 color in
 error messages. Messing around with some errors right now, the only 
 color I
 see is that "Error:" is in red, and some of the text is bolded, so it's
 white instead of the grey that text is normally on my console. Maybe my
 console's settings aren't interacting with the color stuff very well.
Nah, it's just the code in dmd:    if (username == "Jonathan")        color = off;    // muwa-ha-ha-hah!
<ROFL>
Feb 06
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 31, 2018 at 07:14:57PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
 On Wednesday, January 31, 2018 17:16:21 Walter Bright via Digitalmars-d 
 wrote:
 On 1/31/2018 1:19 PM, H. S. Teoh wrote:
 I'd rather stick with just B&W.
dmd -color=off file.d
I have to wonder if my settings are right. I've never noticed any color in error messages. Messing around with some errors right now, the only color I see is that "Error:" is in red, and some of the text is bolded, so it's white instead of the grey that text is normally on my console. Maybe my console's settings aren't interacting with the color stuff very well.
[...] I thought that *is* the color support that was added? If you're expecting IDE-style syntax highlighting, I think you're setting your expectations a little high for something that ostensibly was banged out in a couple of hours. :-D T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Jan 31
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 1 February 2018 at 02:24:44 UTC, H. S. Teoh wrote:
 I thought that *is* the color support that was added?  If 
 you're expecting IDE-style syntax highlighting, I think you're 
 setting your expectations a little high for something that 
 ostensibly was banged out in a couple of hours.
Nope, the dmd compiler will highlight code between `` in its outputted error messages. dmd already knows how to lex D code (obviously) and even has a highlighter for ddoc, so it just pipes it through that existing function. Not all error messages had the `` around its code though. That's what Mike did in most his PRs.
Jan 31
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, February 01, 2018 02:42:52 Adam D. Ruppe via Digitalmars-d 
wrote:
 On Thursday, 1 February 2018 at 02:24:44 UTC, H. S. Teoh wrote:
 I thought that *is* the color support that was added?  If
 you're expecting IDE-style syntax highlighting, I think you're
 setting your expectations a little high for something that
 ostensibly was banged out in a couple of hours.
Nope, the dmd compiler will highlight code between `` in its outputted error messages. dmd already knows how to lex D code (obviously) and even has a highlighter for ddoc, so it just pipes it through that existing function. Not all error messages had the `` around its code though. That's what Mike did in most his PRs.
I haven't see any syntax highlighting in any error messages. The closest I've seen is a type name or symbol name being in white instead of grey when it's mentioned explicitly by name outside of code snippets, but no code snippets have been anything but grey (which is the default text color for the console). So, either none of the errors I've gotten are marked up with `` correctly, or there's something with my setup which makes it so that the coloring doesn't work. - Jonathan M Davis
Jan 31
prev sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 21:19:50 UTC, H. S. Teoh wrote:
 On Wed, Jan 31, 2018 at 08:05:37PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:
 On Wednesday, 31 January 2018 at 19:59:23 UTC, Seb wrote:
 ... and Mike did put _a lot_ of effort in pushing colorful 
 error messages:
Yes, that was a direct result of that forum post I alluded to. It isn't something he (or most anyone else, in my experience) really cares about, but he felt if he did it then many Walter wouldn't waste any more time on it.
In fact, I find the colors distracting. Pretty? Certainly. But helpful? Not really, at least not for me. I'd rather stick with just B&W. But all things considered, it's a pretty minor issue, and one that's not worth the time to complain about. (Haha, and look what I just did. :-P) T
BTW run.dlang.io supports DMD's colorized error messages since a while too, e.g. https://run.dlang.io/is/neLaOB If anyone minds, send a PR to https://github.com/dlang-tour/core/blob/master/public/static/css/ansi.css
Jan 31
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 11:59 AM, Seb wrote:
 ... and Mike did put _a lot_ of effort in pushing colorful error messages:
Yes, and he did a nice job of it. The results are attractive, worthwhile, and resolves a specific complaint people had about dmd's error messages.
Jan 31
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 19:00:57 UTC, Jack Stouffer 
wrote:
 That's just something that Walter was able to bang out in an 
 hour, should have been done years ago, and was excited about.
So it isn't a big deal, but IMO that should be left to an IDE or shell. Back to the argument about cPython vs PyPy/dmd vs ldc. You want the reference compiler to be relatively simple and leave the unnecessary complications to the production compiler. So if DMD's backend was simple and only was a bare minimum implementation of the semantics then having multiple compilers would be comparable to the Python situation. PyPy is probably way too complicated to act as a reference and it would be difficult for Python to move if it had been the reference. Some might say that DMD is too complicated to act as a reference as well, and that D has a problem moving because of it. If that is true, and I think it is, then the logical conclusion would be to make the DMD codebase simpler and leave performance to LDC. Like Python does with PyPy.
Jan 31
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2018 05:55 AM, Benny wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 Let me say this again
*uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved.
A few of the points were actionable. I've asked folks to look into the documentation matters. Thanks, and keep them coming. -- Andrei
Jan 31
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 I told before if there is no leadership to focus resources and 
 the main developers are more focused on adding more features to 
 the compiler that is already overflowing, then how do you 
 expect to see things solved?
Yes, that is probably the main issue. Where D is going with memory management is still not clear after... many years. It is also not clear whether D is trying to carve its own niche or is going after C/C++/Rust, different people state very different goals. So it is difficult to imagine where D is heading. At the moment it is basically easier to just stand by and watch while using more narrowly focused languages in production.
 Let me say this again: I like D but unless you are years into D 
 as a developer its just frustrating to deal with the constant 
 issues.
So basically the same issues as C++.
 Tired of reading the same rhetoric as are the people who think 
 posts
 like this are troll posts.
People who pretend to be self-confident, but aren't, tend to go with that rhetoric. *shrugs*
Jan 31
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 * three compilers
Not sure why that's a bad thing. They all have their ups and downs: - dmd SUPER fast compilation - ldc multiarch + good optimization + cross-compilation - gdc multiarch + good optimization (in many cases better than LLVM) + cross-compilation + GNU Doesn't the download page explain this? https://dlang.org/download.html If not or you have other reasons why this is a problem, please let us know and/or open an issue. FWIW there are dozens (maybe even hundreds) of C++ compilers and no one complains about that.
 And 3 different installation method's depending on the platform.

 Windows: DMD installer, LDC manually extract zip and setup 
 path, GDC ...
That's only an issue on Windows. For Posix there's the official install.sh script [1]. [1] https://dlang.org/install.html There's WIP to provide a similar script for Windows [2], but man, I haven't used a Windows machine in the last seven years - or in other words: it's a serious effort to develop something you have no idea about, can't test locally and you don't need. BTW in my experience, the people using Windows are the ones who complain the loudest and fix the least. I guess that's the crash of different philosophy: MS / Corporate world vs. Unix / Open Source world. I bet that it would take a experienced Windows developers two or three hours to write such a script (or add support for installing ldc to the installer). [2] https://github.com/dlang/installer/pull/275
 Let me add a few other issues to your list:

 * Library
1) Feedback is very important to us, but please add open issues for these things to Bugzilla. Otherwise they get easy lost and not everyone is reading every message on the NG. Not everything obvious to you, is obvious to others. For example, for a long time it wasn't obvious to me that it's bothering people as I prefer "one pagers" - it makes searching for symbols easy 2) Are you aware that there's also the ddox build? https://dlang.org/library/std/datetime/date.html It's just not the default yet, because of some issues. However, it has been there for a long time and you can switch between both modes with the version switch on the top right.
 You know the extra advantage: It makes finding information from 
 a search engine like Google way more easy and less clutter / 
 clean.
Have you tried the search bar at the ddox build?
 The real problem is that anybody can find 100's of issues that 
 are simply unproductive or make the language look like a mess. 
 And they get reported all the time but there is nobody to work 
 on them.
Maybe for other languages, but for D they don't. There are about ~30 still open issues reported in 2017 for dlang.org and they are mostly just specification things [1]. [1] https://issues.dlang.org/buglist.cgi?component=dlang.org&list_id=219211&product=D&resolution=---
 When the company line is: Do it yourself or pay somebody to do 
 it. Guess what the first reaction of a lot of people is.
Well, the time of volunteers is limited and can you blame anyone if he prefers to work on things he enjoys instead of fixing your UX problems which aren't any problems for him? That being said, tons of bugs are fixed in every release and dlang.org is getting better almost every day: https://dlang.org/changelog/pending.html The website repo is one of the lowest traffic repos, 28 PRs have been merged just in the last seven days: https://github.com/dlang/dlang.org/pulse The activity is a lot higher for Phobos and DMD: https://github.com/dlang/phobos/pulse (50 merged PRs in the last seven days) https://github.com/dlang/dmd/pulse (41 merged PRs in the last seven days
 D is highly individualized as a language with actually very 
 little corporation between the 100's of project, that get 
 abandoned when the only developer runs out of time or moves to 
 a differed language.
Yes, obviously the current situation isn't ideal, but it's not too bad either and we have found one good, but probably not so well-known yet way to tackle this: the dlang-community organization on GH (https://github.com/dlang-community). A lot of important, but more or less abandoned repositories have been adopted, s.t. there's a common place to submit bug fixes and feature PRs and its ensured by CIs that they are always in a good state, e.g. always compile with the latest DMD. And companies start to like this concept too, e.g. see this recent discussion where Sociomantic volunteered to step in and do a proper release process for dfmt: https://github.com/dlang-community/dfmt/issues/320
 I put a lot of money in several FOSS projects and it always 
 feel like trowing money into a bottomless pit. Very few 
 projects show where there money is being spend,
This is about to change soon for D. There's WIP to use OpenCollective The announcement should happen soon. Stay tuned!
 While yes, D gets used by some big companies on specific 
 projects, the reality is that this seems to stem more from one 
 developer in that company using D and not a real interest to 
 use it company wide.

 D simply has too few people, no real goal, is a mishmash of 
 different people with mostly individualized goals, a lacking 
 and unclear foundation, lacking in paid developers.
Again, of course, the situation isn't ideal, but there are a few changes about to happen soon. Here's a spoiler: 1) Andrei does an excellent job at managing his students [1] and there work over the last couple of months has been tremendous. As the experiment with UPB was very successful, there will be more projects like this one and global scholarship 2) The vision document will finally get updated (there have been a few delays due to holiday, illnesses etc.) https://wiki.dlang.org/Vision/2017H2 3) More community input (I'm preparing a State of D survey atm) 4) More active voting by the community on important issues 5) Better documentation and overview on what the foundation is doing Currently under discussion/work: 6) Using OpenCollective for tracking expenses openly 7) Offering membership packages for companies 8) Doing bi-annual Kickstarter compaigns for important issues to the community (e.g. "fix shared") (more things are WIP in stealth-mode)
 I said it before, i tried getting into D for over a year and 
 keep running into just stupid issues with DMD regressions,
We have setup a project tester a few months ago that tests the most popular projects on GH on every PR.
 editor plugins that do not work, unfinished or unsupported 
 projects, just badly designed documentation layouts, ... just 
 everywhere lacking. And with the amount of time trying to get 
 things working, reporting issues on github, ... sigh ... so 
 much time better spend on other languages.
Well, you gotta choose - draining your brain with Rust or enjoying working with D and investing the your drain-brain time into fixing small usability issues ;-)
 I told before if there is no leadership to focus resources and 
 the main developers are more focused on adding more features to 
 the compiler that is already overflowing, then how do you 
 expect to see things solved?
As mentioned above, there's. However, it's not very visible as a lot of work happens in stealth-mode atm and only a tiny bit makes it to the DBlog: https://dlang.org/blog/category/core-team https://dlang.org/blog/category/d-foundation
Jan 31
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 [...]
Not sure why that's a bad thing. They all have their ups and downs: [...]
That's the most refreshing post on D future since a long time. Thanks, really. /Paolo
Jan 31
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
[...]
 This is about to change soon for D. There's WIP to use 
 OpenCollective
 The announcement should happen soon.
 Stay tuned!
[...]
 Here's a spoiler:

 1) Andrei does an excellent job at managing his students [1] 
 and there work over the last couple of months has been 
 tremendous. As the experiment with UPB was very successful, 
 there will be more projects like this one and global scholarship

 2) The vision document will finally get updated (there have 
 been a few delays due to holiday, illnesses etc.)

 https://wiki.dlang.org/Vision/2017H2

 3) More community input (I'm preparing a State of D survey atm)

 4) More active voting by the community on important issues

 5) Better documentation and overview on what the foundation is 
 doing

 Currently under discussion/work:

 6) Using OpenCollective for tracking expenses openly
 7) Offering membership packages for companies
 8) Doing bi-annual Kickstarter compaigns for important issues 
 to the community (e.g. "fix shared")
[...]
 As mentioned above, there's. However, it's not very visible as 
 a lot of work happens in stealth-mode atm and only a tiny bit 
 makes it to the DBlog:

 https://dlang.org/blog/category/core-team
 https://dlang.org/blog/category/d-foundation
Thank you for your post, very interesting background information. I like 7) and 8) very much! ( 8) needs 4) )
Jan 31
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
It would be really nice if we could know about current WIP a little bit 
more... And regularly.
Jan 31
prev sibling next sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:

 And 3 different installation method's depending on the 
 platform.

 Windows: DMD installer, LDC manually extract zip and setup 
 path, GDC ...
That's only an issue on Windows. For Posix there's the official install.sh script [1]. [1] https://dlang.org/install.html
I've never seen that page. Would've helped me to see it earlier. The D download page should include a blurb with a link to that install page. I tried going to github.com/dlang/dlang.org, finding the download page, and adding a blurb+link to install.html above those `curl ... install.sh` commands, but that download.dd page is written in a format I'm not familiar with. It's difficult to read, and appears quite clumsy to write as well. It surprises me that D docs are written in that ddoc macro format --- especially for standalone docs like the download page. I think people unfamiliar with D have a perception of D as being this older language from times past, before C++11, and using ddoc for docs instead of markdown contributes to this perception. Let me know if you'd like help in translating D website and doc pages from ddoc to markdown.
Jan 31
next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 1/31/18 9:13 AM, John Gabriele wrote:
 On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:

 And 3 different installation method's depending on the platform.

 Windows: DMD installer, LDC manually extract zip and setup path, GDC ...
That's only an issue on Windows. For Posix there's the official install.sh script [1]. [1] https://dlang.org/install.html
I've never seen that page. Would've helped me to see it earlier. The D download page should include a blurb with a link to that install page. I tried going to github.com/dlang/dlang.org, finding the download page, and adding a blurb+link to install.html above those `curl ... install.sh` commands, but that download.dd page is written in a format I'm not familiar with. It's difficult to read, and appears quite clumsy to write as well. It surprises me that D docs are written in that ddoc macro format --- especially for standalone docs like the download page. I think people unfamiliar with D have a perception of D as being this older language from times past, before C++11, and using ddoc for docs instead of markdown contributes to this perception. Let me know if you'd like help in translating D website and doc pages from ddoc to markdown.
I'm working on adding Markdown support to DDoc. If my changes are accepted it could make these kinds of edits easier, without having to change the whole website at once. Ages ago I helped redesign the website, which involved messing with DDoc macros. I have to agree that DDoc macros aren't always the friendliest.
Jan 31
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 31 January 2018 at 16:13:51 UTC, John Gabriele 
wrote:

 I've never seen that page. Would've helped me to see it 
 earlier. The D download page should include a blurb with a link 
 to that install page.

 I tried going to github.com/dlang/dlang.org, finding the 
 download page, and adding a blurb+link to install.html above 
 those `curl ... install.sh` commands, but that download.dd page 
 is written in a format I'm not familiar with. It's difficult to 
 read, and appears quite clumsy to write as well.

 It surprises me that D docs are written in that ddoc macro 
 format --- especially for standalone docs like the download 
 page. I think people unfamiliar with D have a perception of D 
 as being this older language from times past, before C++11, and 
 using ddoc for docs instead of markdown contributes to this 
 perception. Let me know if you'd like help in translating D 
 website and doc pages from ddoc to markdown.
You can click "Improve this page" in the upper right corner to make things easier. The INSTALL_SCRIPT macro at the bottom is something I don't have time to dig into, so I filed a bug instead. Shouldn't take long for someone with an understanding of ddoc to make the change. https://issues.dlang.org/show_bug.cgi?id=18344 Please add any comments there if my statement/solution are incorrect.
Jan 31
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 16:13:51 UTC, John Gabriele 
wrote:
 I've never seen that page. Would've helped me to see it 
 earlier. The D download page should include a blurb with a link 
 to that install page.
They are there - hover over them: https://imgur.com/a/JvZwI I submitted it without hovering initially: https://github.com/dlang/dlang.org/pull/1697 And the install.sh page was added in this PR: https://github.com/dlang/dlang.org/pull/1936 Please let us know what would help you to find this page quicker.
Jan 31
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 31, 2018 at 05:20:59PM +0000, Seb via Digitalmars-d wrote:
 On Wednesday, 31 January 2018 at 16:13:51 UTC, John Gabriele wrote:
 I've never seen that page. Would've helped me to see it earlier. The
 D download page should include a blurb with a link to that install
 page.
They are there - hover over them: https://imgur.com/a/JvZwI I submitted it without hovering initially: https://github.com/dlang/dlang.org/pull/1697 And the install.sh page was added in this PR: https://github.com/dlang/dlang.org/pull/1936 Please let us know what would help you to find this page quicker.
Wow. I set out *deliberately* looking for that link, and couldn't find it until I looked at your screenshot. I definitely wouldn't have found it if I didn't even know it was there. I'm no UI consultant, but that link definitely needs to be made more visible. Is the hover thing really *necessary*? For something this important, I'd say it's a bad idea to hide it behind a hover (I use keyboard navigation, and so wouldn't even have noticed it, though I concede that I'm a rare case :-P). But then I don't know the original reasoning behind making it hover. T -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard
Jan 31
next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 17:30:54 UTC, H. S. Teoh wrote:
 Wow.  I set out *deliberately* looking for that link, and 
 couldn't find it until I looked at your screenshot. I 
 definitely wouldn't have found it if I didn't even know it was 
 there.

 I'm no UI consultant, but that link definitely needs to be made 
 more visible.  Is the hover thing really *necessary*?  For 
 something this important, I'd say it's a bad idea to hide it 
 behind a hover (I use keyboard navigation, and so wouldn't even 
 have noticed it, though I concede that I'm a rare case :-P). 
 But then I don't know the original reasoning behind making it 
 hover.
Let's try to change this! https://github.com/dlang/dlang.org/pull/2154
Jan 31
prev sibling parent John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 31 January 2018 at 17:30:54 UTC, H. S. Teoh wrote:
 On Wed, Jan 31, 2018 at 05:20:59PM +0000, Seb via Digitalmars-d
 
 Please let us know what would help you to find this page 
 quicker.
Wow. I set out *deliberately* looking for that link, and couldn't find it until I looked at your screenshot. I definitely wouldn't have found it if I didn't even know it was there.
I just discovered that the individual os-specific dmd downloads *also* have links associated with them. Seb, I've added a comment to your PR 2154. Thanks.
Jan 31
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 31 January 2018 at 16:13:51 UTC, John Gabriele 
wrote:
 On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 That's only an issue on Windows.
 For Posix there's the official install.sh script [1].

 [1] https://dlang.org/install.html
I've never seen that page. Would've helped me to see it earlier. The D download page should include a blurb with a link to that install page.
It's actually pretty new. I had created an issue in December to add it and wilzbach created it.
Jan 31
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 31 January 2018 at 16:13:51 UTC, John Gabriele 
wrote:
 I've never seen that page. Would've helped me to see it 
 earlier. The D download page should include a blurb with a link 
 to that install page.
BTW that's why opening issues is so important: - everyone has a different experience, knowledge and mindset - feedback is very important PR to always display the icons: https://github.com/dlang/dlang.org/pull/2154
Jan 31
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2018-01-31 at 16:13 +0000, John Gabriele via Digitalmars-d
wrote:
 [=E2=80=A6]
 this older language from times past, before C++11, and using ddoc=20
 for docs instead of markdown contributes to this perception. Let=20
 me know if you'd like help in translating D website and doc pages=20
 from ddoc to markdown.
I am sure Markdown is find for single page HTML pages, but for bigger documents that need to render to HTML or PDF (or other e-publishing formats) surely AsciiDoctor and XeLaTeX are the only choices. --=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
Feb 01
parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Thursday, 1 February 2018 at 11:06:09 UTC, Russel Winder wrote:
 On Wed, 2018-01-31 at 16:13 +0000, John Gabriele via 
 Digitalmars-d wrote:
 […]
 this older language from times past, before C++11, and using 
 ddoc
 for docs instead of markdown contributes to this perception. 
 Let
 me know if you'd like help in translating D website and doc 
 pages
 from ddoc to markdown.
I am sure Markdown is find for single page HTML pages, but for bigger documents that need to render to HTML or PDF (or other e-publishing formats) surely AsciiDoctor and XeLaTeX are the only choices.
It's trivial to put multiple markdown files together into a large doc, if that's desired. Just put a bunch of .md files together into the same directory and run your markdown processor on them. They can link to each other in the [normal way](./other-file.html#normal-way). Markdown provides a simple, practical, modern, and commonly-known way to get docs written fast and by anyone who wants to pop in and improve them. There's no easier way to write plain text docs that look as good. Sorry, can't recall if I already mentioned this, but D suffers from a perception that it's "old", or "the language that tried and failed to replace C++". Something simple like markdown for its docs sends a clear message that D is modern and knows when to pivot to new and better ways after the old ways are not serving it anymore. Incidentally, choosing an established standard like markdown is a good way to short-circuit bikeshedding about "it what ways should ddoc be updated to include some markdown features?". Just pick standard CommonMark markdown and you're done. One last note and I'll (try to!) stop: it's difficult enough to get good writers to help with docs. Much more so when they've got to first learn your own language-specific markup (which is only useful with your project).
Feb 01
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 19:41 +0000, John Gabriele via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 It's trivial to put multiple markdown files together into a large=20
 doc, if that's desired. Just put a bunch of .md files together=20
 into the same directory and run your markdown processor on them.=20
 They can link to each other in the [normal=20
 way](./other-file.html#normal-way).
Auto generation of contents pages, and indexes? Tables? Nested lists? The CommonMark crib sheet says nothing. AsciiDoctor has all of them, though I prefer XeLaTeX. =20
 Markdown provides a simple, practical, modern, and commonly-known=20
 way to get docs written fast and by anyone who wants to pop in=20
 and improve them. There's no easier way to write plain text docs=20
 that look as good.
AsciiDoctor.
 Sorry, can't recall if I already mentioned this, but D suffers=20
 from a perception that it's "old", or "the language that tried=20
 and failed to replace C++". Something simple like markdown for=20
 its docs sends a clear message that D is modern and knows when to=20
 pivot to new and better ways after the old ways are not serving=20
 it anymore.
Markdown is so last decade. Ditto AsciiDoctor. XeLateX so last millenium. The question is choosing the right tool for the job, not pandering to hipster fashionistas. Clearly one reviews new ways and moves to them if that provides a better way forward, but the goal is more important that the technology. There are the autogenerated reference pages. JavaDoc, Doxygen, all have their upside and downside. D has DDOC, is it fit for purpose? Should it be replaced (by Doxygen) or evolved? Maybe Markdown fits here, but without table support you end up hacking stuff. cf. vast tracts of early JavaDoc stuff. For the documents no created by scanning the source code, you want something like Markdown, AsciiDoc, ReStructuredText, XeLaTeX. I think Sphinx/ReStructuredText actually can do both from code generated reference and other documents =E2=80=93 it does for many projects as well a= s Python. I happen to rate AsciiDoc far better than Markdown as a lightweight text markup, though actually I prefer XeLaTeX. However, simply trading emails about "I think X is best" is not going to get anyone anywhere. Only when someone actually does something is there movement forward. So unless some actually creates a demo of the (Markdown|AsciiDoctor|XeLaTeX) system nothing will change. Of course if Walter and/or Andrei don't like it, it will be wasted effort.
 Incidentally, choosing an established standard like markdown is a=20
 good way to short-circuit bikeshedding about "it what ways should=20
 ddoc be updated to include some markdown features?". Just pick=20
 standard CommonMark markdown and you're done.
s/Markdown/AsciiDoctor/g
 One last note and I'll (try to!) stop: it's difficult enough to=20
 get good writers to help with docs. Much more so when they've got=20
 to first learn your own language-specific markup (which is only=20
 useful with your project).
This is a good and strong point, that has been raised in many other places I frequent. One group changed from their custom DocBook/XML to Sphinx because someone did stuff rather than talking about it. AsciiDoctor would clearly have been a better solution, evolution using the DocBook toolchain, but they went for the revolution because people put effort into it to make the decision happen. The core point is how are you going to get pull requests from people to update and evolve the documentation. An esoteric, indeed unique, markup language is clearly the wrong choice. --=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
Feb 02
parent John Gabriele <jgabriele fastmail.fm> writes:
On Friday, 2 February 2018 at 14:25:53 UTC, Russel Winder wrote:
 On Thu, 2018-02-01 at 19:41 +0000, John Gabriele via 
 Digitalmars-d wrote:
 
[…]
 It's trivial to put multiple markdown files together into a 
 large doc, if that's desired. Just put a bunch of .md files 
 together into the same directory and run your markdown 
 processor on them. They can link to each other in the [normal 
 way](./other-file.html#normal-way).
Auto generation of contents pages, and indexes? Tables? Nested lists? The CommonMark crib sheet says nothing. AsciiDoctor has all of them, though I prefer XeLaTeX.
CommonMark is the less featureful common denominator markdown. For myself, to get TOC's and tables I use [Pandoc](http://pandoc.org/). But I see your point. For larger complete documents like books, you want tools that can handle all the things that books require. But, afaik, we're talking about 2 specific needs here: 1. documenting code in a way that gets extracted and rendered into html 2. dlang.org doc webpages with a secret 3rd need: you want contributors to be willing to write and update these.
 Markdown provides a simple, practical, modern, and 
 commonly-known way to get docs written fast and by anyone who 
 wants to pop in and improve them. There's no easier way to 
 write plain text docs that look as good.
AsciiDoctor.
Everyone already knows and uses Markdown. It's so common that it gets used in plain text forums like this one, sometimes without folks even knowing they're using it. For short plain text docs that may be converted to html, markdown has won and is the easiest on-ramp for some writer who has a few minutes and is willing to write some doc-comments for a function (or a confusing passage in the docs) that they just stumbled over.
 Sorry, can't recall if I already mentioned this, but D suffers 
 from a perception that it's "old", or "the language that tried 
 and failed to replace C++". Something simple like markdown for 
 its docs sends a clear message that D is modern and knows when 
 to pivot to new and better ways after the old ways are not 
 serving it anymore.
Markdown is so last decade. Ditto AsciiDoctor. XeLateX so last millenium. The question is choosing the right tool for the job, not pandering to hipster fashionistas. Clearly one reviews new ways and moves to them if that provides a better way forward, but the goal is more important that the technology.
I wouldn't say markdown is last decade (not sure if you're joking). More like it's simply become part of the background at this point since it's so commonly used. But I agree about not pandering to fashion. The goal is to make it as easy as possible to document your code and have tools render it as html for users to make use of, as well as making it easy as possible for potential contributors to jump in and make edits/improvements. I think markdown is the best way to acheive that goal.
 There are the autogenerated reference pages. JavaDoc, Doxygen, 
 all have their upside and downside. D has DDOC, is it fit for 
 purpose? Should it be replaced (by Doxygen) or evolved? Maybe 
 Markdown fits here, but without table support you end up 
 hacking stuff. cf. vast tracts of early JavaDoc stuff.
Pandoc extends CommonMark and has tables, definiton lists, and a couple of other things worth imitating. Regarding tables, it supports three styles (again, the default easy-on-the-eyes style, plus a couple others --- see their docs). See <http://pandoc.org/MANUAL.html#tables>.
 Incidentally, choosing an established standard like markdown 
 is a good way to short-circuit bikeshedding about "it what 
 ways should ddoc be updated to include some markdown 
 features?". Just pick standard CommonMark markdown and you're 
 done.
s/Markdown/AsciiDoctor/g
AsciiDoctor appears to be tuned for writing long docs like books. Markdown beats it on looks, convenience, and popularity --- exactly the things you want to attract folks to writing more comment docs and web pages.
 One last note and I'll (try to!) stop: it's difficult enough 
 to get good writers to help with docs. Much more so when 
 they've got to first learn your own language-specific markup 
 (which is only useful with your project).
This is a good and strong point, that has been raised in many other places I frequent. One group changed from their custom DocBook/XML to Sphinx because someone did stuff rather than talking about it. AsciiDoctor would clearly have been a better solution, evolution using the DocBook toolchain, but they went for the revolution because people put effort into it to make the decision happen. The core point is how are you going to get pull requests from people to update and evolve the documentation. An esoteric, indeed unique, markup language is clearly the wrong choice.
I don't understand your comment there. I group DDoc, Docbook XML, DDoc, Texinfo, groff, etc. all in the same esoteric unique markup languages camp. If I wanted to make a small change to a half-page doc comment, and it was written in ddoc, I'd be pleased as punch to convert the two or three paragraphs to markdown first. Someone might even write a ddoc2md converter. Heck, someone on the pandoc mailing list might even be willing to knock together a pandoc input reader for reading ddoc (Pandoc could then be used to convert ddoc to markdown).
Feb 07
prev sibling next sibling parent kinke <kinke libero.it> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 * three compilers
Not sure why that's a bad thing. They all have their ups and downs: - dmd SUPER fast compilation - ldc multiarch + good optimization + cross-compilation - gdc multiarch + good optimization (in many cases better than LLVM) + cross-compilation + GNU
Off topic, but I'm not aware of _many_ cases, so please let us know whenever you encounter something that GDC optimizes significantly better than LDC.
Jan 31
prev sibling next sibling parent Benny <benny.luypaert rhysoft.com> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 Here's a spoiler:

 1) Andrei does an excellent job at managing his students [1] 
 and there work over the last couple of months has been 
 tremendous. As the experiment with UPB was very successful, 
 there will be more projects like this one and global scholarship

 2) The vision document will finally get updated (there have 
 been a few delays due to holiday, illnesses etc.)

 https://wiki.dlang.org/Vision/2017H2

 3) More community input (I'm preparing a State of D survey atm)

 4) More active voting by the community on important issues

 5) Better documentation and overview on what the foundation is 
 doing

 Currently under discussion/work:

 6) Using OpenCollective for tracking expenses openly
 7) Offering membership packages for companies
 8) Doing bi-annual Kickstarter compaigns for important issues 
 to the community (e.g. "fix shared")
Thank you Seb and the other. Sorry for going off the rails but i do like D a lot. Its the only reason i keep coming back for the same punishment time and time again. It simply gets so frustrating at times what feels like running into a stone wall. Maybe the real issue is not the issues that need to be solved but the lack of "news". The blogs are very interesting and i applaud them. But is it maybe not time to have a real news section on the site where project status updates are provided. We are not talking blogs but smaller news snipes that do not take a lot of time, so people who do not spend there life on the forum or other locations feel like there is indeed movement. It can also help in the actual marketing.
Jan 31
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:

 Yes, obviously the current situation isn't ideal, but it's not 
 too bad either and we have found one good, but probably not so 
 well-known yet way to tackle this: the dlang-community 
 organization on GH (https://github.com/dlang-community).
 A lot of important, but more or less abandoned repositories 
 have been adopted, s.t. there's a common place to submit bug 
 fixes and feature PRs and its ensured by CIs that they are 
 always in a good state, e.g. always compile with the latest DMD.
Wait, have libdparse et al. been abandoned? What happened to Brian?
Feb 01
parent reply rjframe <dlang ryanjframe.com> writes:
On Fri, 02 Feb 2018 01:42:08 +0000, Meta wrote:

 On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 
 Yes, obviously the current situation isn't ideal, but it's not too bad
 either and we have found one good, but probably not so well-known yet
 way to tackle this: the dlang-community organization on GH
 (https://github.com/dlang-community).
 A lot of important, but more or less abandoned repositories have been
 adopted, s.t. there's a common place to submit bug fixes and feature
 PRs and its ensured by CIs that they are always in a good state, e.g.
 always compile with the latest DMD.
Wait, have libdparse et al. been abandoned? What happened to Brian?
I don't think the intended interpretation is that all projects there were abandoned; many projects important to the D ecosystem have been moved there, which includes some otherwise-abandoned projects.
Feb 01
parent Seb <seb wilzba.ch> writes:
On Friday, 2 February 2018 at 02:33:30 UTC, rjframe wrote:
 On Fri, 02 Feb 2018 01:42:08 +0000, Meta wrote:

 On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 
 Yes, obviously the current situation isn't ideal, but it's 
 not too bad
 either and we have found one good, but probably not so 
 well-known yet
 way to tackle this: the dlang-community organization on GH
 (https://github.com/dlang-community).
 A lot of important, but more or less abandoned repositories 
 have been
 adopted, s.t. there's a common place to submit bug fixes and 
 feature
 PRs and its ensured by CIs that they are always in a good 
 state, e.g.
 always compile with the latest DMD.
Wait, have libdparse et al. been abandoned? What happened to Brian?
I don't think the intended interpretation is that all projects there were abandoned; many projects important to the D ecosystem have been moved there, which includes some otherwise-abandoned projects.
Yes, sorry for the poor wording of less abandoned". I picked it for Brian's project because it used to take ~1-2 months for a simple bug fix to get in. Now it can be merged within a day. No worries, Brian is still developing his tools (e.g. https://github.com/dlang-community/dfmt/pull/318), but other people do more active development on/with his awesome libs at "upstream".
Feb 01
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 [...]
Not sure why that's a bad thing. They all have their ups and downs: [...]
Since some want Quora engagement, I thought I'd mention this thread I just stumbled upon, while doing an unrelated google search for Nim, that had some mentions of D: https://www.quora.com/in/Of-the-emerging-systems-languages-Rust-D-Go-and-Nim-which-is-the-strongest-language-and-why May be worth reading, or someone here might want to add their own answer.
Apr 03
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 3 April 2018 at 16:21:18 UTC, Joakim wrote:
 On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
 On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 [...]
Not sure why that's a bad thing. They all have their ups and downs: [...]
Since some want Quora engagement, I thought I'd mention this thread I just stumbled upon, while doing an unrelated google search for Nim, that had some mentions of D: https://www.quora.com/in/Of-the-emerging-systems-languages-Rust-D-Go-and-Nim-which-is-the-strongest-language-and-why May be worth reading, or someone here might want to add their own answer.
There is quite a number of rust fans.
Apr 03
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/31/18 5:35 AM, Benny wrote:

 Auto generated libraries where all functions are dumped into massive one 
 pagers.
 
 https://dlang.org/phobos/std_datetime_date.html
 
 Is this readable when the first two pages are this:
 
 jan
 feb
 mar
 apr
 may
 jun
 jul
 aug
 sep
 oct
 nov
 dec
 sun
 mon
 tue
 wed
 thu
 fri
 sat
 
 Const "jump to" lists intermixed between the documentation.
 
 No clear function calls:
 
 const pure nothrow  nogc  property  safe ubyte daysInMonth();
 
 Const
 Pure
 nothrow
  nogc
  property
  safe
 ubyte ...
 
 and FINALLY the actual function call your looking for: daysInMonth();
This is an issue that was recently introduced. Until dconf2017 (May of last year), all of std.datetime was in one file. But while the code was split into logical units, the documentation was not. Unfortunately, it needs a lot of attention to make sure the docs are written to cater to the new split design.
 And please ... do like always, cut my post into small parts and start 
 criticizing and attacking the author that he needs to "put more effort 
 into it or pay". Or some other bullshit. And then complain how people 
 troll the forum because they complain and not do anything to solve it. 
 Tired of reading the same rhetoric as are the people who think posts 
 like this are troll posts.
We are always here to help with issues in D, and constructive criticism is welcome and appreciated! But I don't know how to help you with the "D sucks, everyone should use some other language" issue. It's not part of my knowledgebase. -Steve
Jan 31
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
 Auto generated libraries where all functions are dumped into 
 massive one pagers.
This is why I just forked the documentation (well, I tried to get it upstream but I think upstream is a brick wall and not worth trying anymore) http://dpldocs.info/std.datetime.date That's still not amazing, but it is a lot easier to navigate and link. It also has search: http://dpldocs.info/locate?q=daysInMonth
 No clear function calls:
http://dpldocs.info/experimental-docs/std.datetime.date.Date.daysInMonth.html So I also show that info because it is somewhat important to understand the contract, but I tried to present it so the name and position among its parents and siblings is clear. Of course, I argue part of the problem is I'm sure I'm not the only one who has decided to just fork rather than try to keep wrestling with upstream...
Jan 31
parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe 
wrote:
 {snip} (well, I tried to get it upstream but I think upstream 
 is a brick wall and not worth trying anymore)
That is very concerning to hear.
Jan 31
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 31, 2018 at 09:07:39PM +0000, John Gabriele via Digitalmars-d wrote:
 On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe wrote:
 
 {snip} (well, I tried to get it upstream but I think upstream is a
 brick wall and not worth trying anymore)
That is very concerning to hear.
FWIW, here's my POV regarding "upstream", speaking as one who has no prior (or current!) personal connection with anyone involved with D development at the time, and who got granted commit access to Phobos only because one day I and another person whom I do not wish to name (who was at the time also not connected to "upstream") were complaining on the forum about lack of response to Phobos PRs, and *somebody*, presumably Andrei (but this is speculation on my part, as I was never actually told what happened exactly), decided to hand us the keys to the kingdom, so to speak, to see what we'd do with it. I didn't merge anything for about a month or more afterwards, not out of intimidation or anything like that, but just feeling unqualified to make decisions of that sort just yet. I continued submitting PRs like an "outsider" for a while, and only later began to build up enough confidence to start merging PRs. Even today, I contribute to D development purely out of my own interest, both in terms of technical interest, interest in seeing D improve because I use it for numerous personal projects, and also some amount of personal fulfilment in being able to contribute to something bigger than just my own projects. The way I see it, is that the majority of PRs that get merged are in the category of small, incremental changes, things like bugfixes, small improvements to existing features, the odd useful tool here and there, that sort of thing. Larger-scale changes do tend to take a lot more work (and persistence!) to push through, not because of any active policy or motive that hinder such changes, but primarily because as a volunteer-driven project, it's not very often that someone from among the volunteers would: (1) Have the time to spend reviewing a large and complicated change; (2) Have enough expertise in the affected area(s) of the project to feel confident enough to make decisions about it; (3) Have all of the above plus the interest to actually *want* to wade into the depths of a large changeset, which implies the commitment to continue interacting with the submitter until it's merged or rejected, rather than do something else that's (a) more self-contained and easier to review, (b) can be done in a short amount of time that fits into their current stretch of free time, and (c) still contributes something positive to the project. Large-scale changes do happen every now and then, such as Daniel Murphy's monumental effort in translating dmd's original C++ source into D, leading to the bootstrapping compiler we have today. But these require a lot more effort and coordination with key decision makers, usually Walter & Andrei, and it really helps if you can convince one or both of them to take your side. A "small fry" like myself wouldn't dare to push the merge button on changes of this kind of magnitude, since it could have drastic consequences that I can't foresee due to not having a full grasp of the full scale of what is being changed. Plus, sometimes somebody else *did* raise valid points of concern against the PR, so I would hold off merging until the concern is addressed and that person approves of the updated change. And in a large changeset, there can be a large number of such concerns, which requires a lot of back-and-forth before a decision can be reached. Anyway, as far as Adam's dpldocs are concerned, the way I see it is this (and I'm saying this not as someone making the decision, but as a mostly-disinterested observer): Around the time it was first proposed, there are already two other competing documentation systems: - The ddoc system, the original, and still in heavy use at the time, up till today; - Sonke's newer one-page-per-function ddox system (which today has been partly integrated, but still not fully the default yet because of various issues that I didn't look too much into). Having 3 different competing documentation systems is really crowded for this space, so for any of them to stand a chance, it has to be either already entrenched (ddoc), or else must offer significant advantages over its competitors. More importantly, its proponent(s) would have to convince Andrei or Walter of said significant advantages, since that's what will tip the scale (obviously, its proponents must believe it has significant advantages otherwise they wouldn't have proposed it in the first place -- but the deciding factor is whether Andrei and/or Walter think likewise). And IIRC, Andrei had already bought into the ddox system by then (the process of merging it might have already begun, I'm not 100% certain), so dpldocs was already starting from a disadvantaged position, whatever merits it may have on its own. And I'll be frank that sometimes Andrei can take some effort to convince, and it takes a certain amount of dogged persistence (and thick-skin) to get through to him sometimes. And it doesn't help that he has so much on his plate, and generally doesn't have enough time to dedicate to all the decisions waiting upon him to make, so sometimes it can be frustrating trying to get through to him. So to get through, dpldocs would need show a major advantage over ddoc and ddox, and Adam (and whoever else) would need to be persistent enough to convince Andrei to approve of it, and then it would require the effort to integrate it into everything else that's currently being used for generating docs on dlang.org -- since obviously, it wouldn't do for a new doc system to get merged, only for everyone to find that parts of dlang.org are now broken, or not working as well as before, or Phobos doc builds now have new issues, etc.. AFAICT, none of this is any deliberate roadblock or "brickwalling" to stop alternative proposals from being accepted, but it's mostly just due to circumstantial situations that arose, for better or for worse, as part of how D came to be what it is today. In that sense, I don't blame Adam from deciding to fork instead -- given the circumstances, that's certainly the path of least resistance, unfortunate as it is. With ddoc still entrenched as the de facto documentation system, and with ddox already merged and continuing to be improved with the view of becoming the new default docs (not my personal preference, but that's the direction it's headed), any alternative proposals would have a pretty tough uphill fight to get through. It's unfortunate, but I don't think it's unreasonable either -- as I said, if it would not bring new, compelling advantages to the table, then it's pretty hard to justify all the work it would take to merge it and then maintain it afterwards. At least, it would be pretty tough to convince Andrei about this. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Jan 31
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 3:38 PM, H. S. Teoh wrote:
 A "small fry" like myself wouldn't dare
 to push the merge button on changes of this kind of magnitude, since it
 could have drastic consequences that I can't foresee due to not having a
 full grasp of the full scale of what is being changed.
https://youtu.be/amclN9RG49c?t=146
Jan 31
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2018 06:38 PM, H. S. Teoh wrote:
 And I'll be frank that sometimes Andrei
 can take some effort to convince, and it takes a certain amount of
 dogged persistence (and thick-skin) to get through to him sometimes.
 And it doesn't help that he has so much on his plate, and generally
 doesn't have enough time to dedicate to all the decisions waiting upon
 him to make, so sometimes it can be frustrating trying to get through to
 him.
Thanks for the critique. I'm trying to get better organized at being less of a bottleneck every day. Regarding the documentation system, at a high level it's clear that working to improve the established solutions is often a sensible and productive way to go about things. This is not core language so we have no important backward compatibility issues. A distinct documentation system seeking to replace the existent ones would need to present a strong motivation. I would be hard pressed to recall that we were presented with a good case that we rejected without due consideration. Andrei
Feb 01
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Wednesday, 31 January 2018 at 23:38:22 UTC, H. S. Teoh wrote:
 And IIRC, Andrei had already bought into the ddox system by 
 then (the process of merging it might have already begun, I'm 
 not 100% certain), so dpldocs was already starting from a 
 disadvantaged position, whatever merits it may have on its own.
  And I'll be frank that sometimes Andrei can take some effort 
 to convince, and it takes a certain amount of dogged 
 persistence (and thick-skin) to get through to him sometimes. 
 And it doesn't help that he has so much on his plate, and 
 generally doesn't have enough time to dedicate to all the 
 decisions waiting upon him to make, so sometimes it can be 
 frustrating trying to get through to him.
 
 T
In DConf 2016 Andrei literally said "I'm in charge of too many things. Please get me fired!" [1]. Sadly, it doesn't seem like much firing has happened since then. :-( [1] https://www.youtube.com/watch?v=4oDK91E3VKs&feature=youtu.be&t=9m42s
Feb 02
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 02, 2018 at 03:06:57PM +0000, Mark via Digitalmars-d wrote:
 On Wednesday, 31 January 2018 at 23:38:22 UTC, H. S. Teoh wrote:
[...]
 And I'll be frank that sometimes Andrei can take some effort to
 convince, and it takes a certain amount of dogged persistence (and
 thick-skin) to get through to him sometimes. And it doesn't help
 that he has so much on his plate, and generally doesn't have enough
 time to dedicate to all the decisions waiting upon him to make, so
 sometimes it can be frustrating trying to get through to him.
[...] It seems that what I said above caused a bit of a stir. So let me clarify that it was not intended to be a personal critique of Andrei, and I apologize if it came across that way. It was more intended as a friendly dig on, shall we say, one of his more endearing personality traits -- strong opinions on technical issues and the guts to stick to them. And to his credit, I don't know if somebody else in his shoes would be able to do better than he does now. Having to make sometimes tough decisions, e.g., rejecting work that somebody put a lot of effort into for the sake of the larger picture, while under the pressure of so many other responsibilities, is not something I envy. We should be glad Andrei is willing to shoulder this burden, since otherwise D would not be where it is today.
 In DConf 2016 Andrei literally said "I'm in charge of too many things.
 Please get me fired!" [1]. Sadly, it doesn't seem like much firing has
 happened since then. :-(
[...] It has, to some extent. But the fundamental problem remains that more manpower is needed so that he can be freed up to do the more important things. Having to personally review all new public symbols added to Phobos, for example, just doesn't seem scalable in the long run. But, as Andrei himself said, the last time he left that decision to somebody else, there was a noticeable deterioration in the quality of code in Phobos. So we need not only more manpower, but also more *trusted* manpower; people who share the same views as Andrei, whom he can trust to make the right decisions without his intervention. T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Feb 02
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 2 February 2018 at 18:17:30 UTC, H. S. Teoh wrote:
 On Fri, Feb 02, 2018 at 03:06:57PM +0000, Mark via

 It has, to some extent. But the fundamental problem remains 
 that more manpower is needed so that he can be freed up to do 
 the more important things.  Having to personally review all new 
 public symbols added to Phobos, for example, just doesn't seem 
 scalable in the long run.  But, as Andrei himself said, the 
 last time he left that decision to somebody else, there was a 
 noticeable deterioration in the quality of code in Phobos.  So 
 we need not only more manpower, but also more *trusted* 
 manpower; people who share the same views as Andrei, whom he 
 can trust to make the right decisions without his intervention.
There's no silver bullet to this, and it's indeed a very difficult task. Having done this for a lot of my life, my advice is simply to keep that always present in every decision, and, sometime, be more permissive in the short term decisions, to just archive that more important long term goal. Growing (and discovering!), talents it's indeed a job by itself. /P
Feb 02
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-02 at 10:17 -0800, H. S. Teoh via Digitalmars-d wrote:
=20
[=E2=80=A6]
 It has, to some extent. But the fundamental problem remains that more
 manpower is needed so that he can be freed up to do the more
 important
 things.  Having to personally review all new public symbols added to
 Phobos, for example, just doesn't seem scalable in the long
 run.  But,
 as Andrei himself said, the last time he left that decision to
 somebody
 else, there was a noticeable deterioration in the quality of code in
 Phobos.  So we need not only more manpower, but also more *trusted*
 manpower; people who share the same views as Andrei, whom he can
 trust
 to make the right decisions without his intervention.
Hummm=E2=80=A6 could it be that Andrei did not define the task appropriatel= y, train the person appropriately, and mentor the person appropriately. Management has to be able to delegate and achieve required results without doing the work themselves. --=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
Feb 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/2/2018 11:08 AM, Russel Winder wrote:
 Hummm… could it be that Andrei did not define the task appropriately,
 train the person appropriately, and mentor the person appropriately.
 Management has to be able to delegate and achieve required results
 without doing the work themselves.
Of course. But all that is far easier said than done. Andrei and I are not born managers, we are learning as we go. So I ask for your indulgence and understanding where we fall short.
Feb 02
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 2 February 2018 at 21:14:12 UTC, Walter Bright wrote:
 On 2/2/2018 11:08 AM, Russel Winder wrote:
 Hummm… could it be that Andrei did not define the task 
 appropriately,
 train the person appropriately, and mentor the person 
 appropriately.
 Management has to be able to delegate and achieve required 
 results
 without doing the work themselves.
Of course. But all that is far easier said than done. Andrei and I are not born managers, we are learning as we go. So I ask for your indulgence and understanding where we fall short.
Would it be easier for hire a proven manager(Or at least look for mangers that are able to volunteer)?
Feb 02
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-02 at 21:21 +0000, 12345swordy via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Would it be easier for hire a proven manager(Or at least look for=20
 mangers that are able to volunteer)?
What the D Foundation needs is a CEO who is a good CEO. Good CTOs rarely make good CEO, though it is possible. =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
Feb 04
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 4 February 2018 at 18:00:22 UTC, Russel Winder wrote:
 What the D Foundation needs is a CEO who is a good CEO. Good 
 CTOs
 rarely make good CEO, though it is possible.
Well, I don't think making some hard decisions about memory management, which is the most apparent issue with D, is a CTO/CEO problem. It is more an issue of not being willing to make some sacrifices in order to gain momentum. If "better C" is the new strategy, then that is fine, if that means you will make "better C" the main focus, going lean. If it means that you have essentially forked into two main directions... then it just makes it even harder to gain momentum.
Feb 04
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 4 February 2018 at 18:00:22 UTC, Russel Winder wrote:
 On Fri, 2018-02-02 at 21:21 +0000, 12345swordy via 
 Digitalmars-d wrote:
 
[…]
 Would it be easier for hire a proven manager(Or at least look 
 for mangers that are able to volunteer)?
What the D Foundation needs is a CEO who is a good CEO. Good CTOs rarely make good CEO, though it is possible.
ok..maybe we can agree on that ..at least ;-) "The software product itself is valuable but is not the key to understanding open source. The process is what matters most." - Steven Weber (The Political Economy of Open Source Software)
Feb 04
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-02 at 13:14 -0800, Walter Bright via Digitalmars-d
wrote:
 On 2/2/2018 11:08 AM, Russel Winder wrote:
 Hummm=E2=80=A6 could it be that Andrei did not define the task
 appropriately,
 train the person appropriately, and mentor the person
 appropriately.
 Management has to be able to delegate and achieve required results
 without doing the work themselves.
=20 Of course. But all that is far easier said than done.
It is a learned skill for most people, very few people can do it without training or at least mentoring.
 Andrei and I are not born managers, we are learning as we go. So I
 ask for your=20
 indulgence and understanding where we fall short.
Who is your management mentor? It is making your job harder if you are trying to teach yourselves purely from experience. Been there done that, made much better progress after reading: https://www.amazon.com/Leading-Self-Directed-Teams-Kimball-Fisher/dp/00 71349243 and even better having the use of a mentor. Admittedly though this was office-based not distributed team work. =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
Feb 03
parent reply psychoticRabbit <meagain meagain.com> writes:
On Saturday, 3 February 2018 at 15:33:01 UTC, Russel Winder wrote:
 Who is your management mentor? It is making your job harder if 
 you are trying to teach yourselves purely from experience. Been 
 there done that, made much better progress after reading:
In my experience, there is nothing worse than a 'learnt' manager ;-) People either have the gift, or they do not. Most do not. (if they have the gift, then improving their skills is a good thing - otherwise they are best doing something they are good at).
Feb 03
parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2018-02-04 at 01:53 +0000, psychoticRabbit via Digitalmars-d
wrote:
=20
 [=E2=80=A6]
 In my experience, there is nothing worse than a 'learnt' manager=20
 ;-)
I disagree.
 People either have the gift, or they do not. Most do not.
Again I disagree.
 (if they have the gift, then improving their skills is a good=20
 thing - otherwise they are best doing something they are good at).
The point here is that organisations should not be structured via management as the metric =E2=80=93 good technical people should not have to move to management in order to be promoted. Promoting good technical people to positions of management is rarely a good move, sometimes it works, but not as often as the system is set up to require. Likewise a good CTO rarely makes a good CEO.=20 What The D Foundation needs is a CEO who is a good CEO. =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
Feb 04
prev sibling next sibling parent reply Michael <michael toohuman.io> writes:
On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton 
wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
I think that the largest issue there is probably the marketing and advocacy. When Rust was about the same share as D, it had much better marketing. Someone was running their twitter channel and working to make the language much more visible. D flat out doesn't have that. If I had to pick a second issue, it's that the ecosystem story is hard compared to other languages. New programmers aren't certain what to choose or how to get their environment up and running. Compared against Rust, Go, and Java we have horrible ecosystem fragmentation. E.g. three compilers, two separate languages for dub
I agree that marketing is a pretty serious problem for D. Many people just aren't aware of it. Even for people who do not program in the newer languages, Rust and Go are already well known to anybody who uses C# or C/C++ or Java, and even many Python or JavaScript programmers. D is often looked over and not visible enough on people's radars for them to even notice it, which is hugely disappointing as I've no doubt many would come to realise that it offers much of what they're looking for. Marketing is definitely failing the language here, but considering we don't have some huge company backing D, it's doing fairly well on its own. I just worry it's not enough to rely on word-of-mouth because it doesn't seem to be enough. Personally I don't find the ecosystem to be a huge problem any more than C++'s is a problem. I can install DMD and LDC and, if/when I want/need to, I can tell rdmd to build using LDC. I am glad to have options, as I don't feel that they hinder my use of D.
Jan 31
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2018-01-31 at 13:14 +0000, Michael via Digitalmars-d wrote:
=20
[=E2=80=A6]
 I agree that marketing is a pretty serious problem for D. Many=20
 people just aren't aware of it. Even for people who do not=20
 [=E2=80=A6]
Some suggestions: More people putting more good projects using D on GitLab, BitBucket, Launchpad, and GitHub. People writing more articles using D in publications such as CVu and Overload, etc. People putting more sessions into conferences such as ACCU using D =E2=80= =93 there hasn't been a single D-related session since Andrei's keynote at ACCU 2016. My own small contribution is to answer all the ACCU C++ Code Critiques with answers that say do not use C++, but use Python, D, Go, Rust, so as to get more non-C++ into C++ programmers minds. Clearly hardened C++ folk look only to C++ and never consider any language other than assembly language, but a lot of currently C++ folk are not hardened to the C++-only mindset. And ACCU is about programming with an emphasis on C++. This is clearly a great place for D content. D-only conferences, as (C++|Go|Rust)-only ones, have their place, but their main role is to reinforce the community. Marketing requires people to take the message outside the community. ACCU conferences and journals provide an excellent place to market D to people outside the D community. =20 This year ACCU has some good Rust content. I wanted some Go content but it seems they are as reluctant to come to a polyglto conference as D people seem to be. :-( --=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
Feb 01
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 February 2018 at 11:20:00 UTC, Russel Winder wrote:
 On Wed, 2018-01-31 at 13:14 +0000, Michael via Digitalmars-d 
 wrote:
 
[…]
 I agree that marketing is a pretty serious problem for D. Many 
 people just aren't aware of it. Even for people who do not […]
Some suggestions: More people putting more good projects using D on GitLab, BitBucket, Launchpad, and GitHub. People writing more articles using D in publications such as CVu and Overload, etc. People putting more sessions into conferences such as ACCU using D – there hasn't been a single D-related session since Andrei's keynote at ACCU 2016.
Ali gave a keynote at C++Now(?) last year(?).
Feb 01
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 11:49 +0000, Nicholas Wilson via Digitalmars-d
wrote:
 [=E2=80=A6]
=20
 Ali gave a keynote at C++Now(?) last year(?).
I think it was. What is needed though is follow ups. ACCU, C++Now, etc. all need a steady trickle of sessions. --=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
Feb 01
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 February 2018 at 12:03:43 UTC, Russel Winder wrote:
 On Thu, 2018-02-01 at 11:49 +0000, Nicholas Wilson via 
 Digitalmars-d wrote:
 […]
 
 Ali gave a keynote at C++Now(?) last year(?).
I think it was. What is needed though is follow ups. ACCU, C++Now, etc. all need a steady trickle of sessions.
Indeed, I will be giving a talk at IWOCL (an OpenCL conference) a week after DConf, promoting DCompute to the numerics folk.
Feb 01
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 12:06 +0000, Nicholas Wilson via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 Indeed, I will be giving a talk at IWOCL (an OpenCL conference) a=20
 week after DConf, promoting DCompute to the numerics folk.
Please send this in to ACCU 2019 during the CfP 2018-10-?? to 2018-11- ?? as a 90 minute full session. If the committee do not like the proposal, I will override their faulty decision. (We have a (small but vocal) group of games people at ACCU who think C++ is the one true way of doing fast computations.) =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
Feb 01
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 February 2018 at 12:22:56 UTC, Russel Winder wrote:
 On Thu, 2018-02-01 at 12:06 +0000, Nicholas Wilson via 
 Digitalmars-d wrote:
 
[…]
 Indeed, I will be giving a talk at IWOCL (an OpenCL 
 conference) a week after DConf, promoting DCompute to the 
 numerics folk.
Please send this in to ACCU 2019 during the CfP 2018-10-?? to 2018-11- ?? as a 90 minute full session. If the committee do not like the proposal, I will override their faulty decision. (We have a (small but vocal) group of games people at ACCU who think C++ is the one true way of doing fast computations.)
OK, will do. Might need to work on getting some more content to fill out the time but should be doable. Hopefully by then DCompute will support Vulkan, assuming that I can get consensus to get Vulkan as part of the SPIR-V backend for LLVM.
Feb 01
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 12:55 +0000, Nicholas Wilson via Digitalmars-d
wrote:
 [=E2=80=A6]
=20
 OK, will do. Might need to work on getting some more content to=20
 fill out the time but should be doable. Hopefully by then=20
 DCompute will support Vulkan, assuming that I can get consensus=20
 to get Vulkan as part of the SPIR-V backend for LLVM.
Excellent. ACCU 90 minute sessions are intended as 60 mins presentation + 30 mins Q&A. However many presenters go for the more interactive approach of dealing with points as they arise. The more interactive sessions go down very well. The alternative is a 90 minute workshop where people come and do stuff. Many presenters structure them as 20 mins intro and 60 mins of writing software or doing some activity in groups and 10 mins of sharing experiences. These go down well. For a really deep dive, there is the "long workshop" which is 180 mins. However the last few of these we had didn't work too well, the workshop lost too many people at the 90 min break. --=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
Feb 01
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton 
wrote:
 E.g. three compilers
Every other compiled language (and a lot of scripting ones) uses the fact of multiple compilers for the language as a sign of adoption and ecosystem growth. I've only ever seen people complain about D in this area. Never once have I seen someone argue that the existence of PyPy hurts Python or gogcc hurts Go.
Jan 31
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 13:54:25 UTC, Jack Stouffer 
wrote:
 I've only ever seen people complain about D in this area. Never 
 once have I seen someone argue that the existence of PyPy hurts 
 Python or gogcc hurts Go.
Well, I've seen that people think that MS C++ is keeping C++ back because it failed to keep up, so people couldn't write portable code using the latest features... PyPy and gogcc doesn't hurt Python and Go because the reference interpreters/compilers are mature, stable and cannot take more manpower... Apples and oranges, does not compare well.
Jan 31
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 5:54 AM, Jack Stouffer wrote:
 On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton wrote:
 E.g. three compilers
Every other compiled language (and a lot of scripting ones) uses the fact of multiple compilers for the language as a sign of adoption and ecosystem growth. I've only ever seen people complain about D in this area. Never once have I seen someone argue that the existence of PyPy hurts Python or gogcc hurts Go.
Back when D had only one compiler, dmd, people complained it had only one compiler. Now that it has three, they complain that it has three. Sometimes, ya just gotta ignore people.
Jan 31
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2018-01-31 at 13:54 +0000, Jack Stouffer via Digitalmars-d
wrote:
 On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton=20
 wrote:
 E.g. three compilers
=20 Every other compiled language (and a lot of scripting ones) uses=20 the fact of multiple compilers for the language as a sign of=20 adoption and ecosystem growth.
Definitely.
 I've only ever seen people complain about D in this area. Never=20
 once have I seen someone argue that the existence of PyPy hurts=20
 Python or gogcc hurts Go.
D should be proud of having a reference compiler, a GCC-based one, and an LLVM-based one. This is a Good Thing=E2=84=A2, let no-one undermine 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=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
Feb 01
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Thursday, 1 February 2018 at 11:21:37 UTC, Russel Winder wrote:
 D should be proud of having a reference compiler, a GCC-based 
 one, and an LLVM-based one. This is a Good Thingâ„¢, let no-one 
 undermine this.
Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ). Let alone 'conflicts': Example: Install DMD ( what has its own DUB ) but also install LDC ( what has its own DUB), now lets say both version have different dub versions. Yes, this happened to me and it conflicted with some of the Editor plugins their build process because the wrong "version" of dub got selected during the build process. Its not really a bug but a issue that can trip people ( lost a hour on that one ). Other issues can be that it makes conversations difficult. When new people read DMD, LDC, GDC in these forums, you can just as well be speaking Mandarin ( Chinese ). Suggestion: Is it maybe not better to have one "front-end" compiler visible that people download Example: D run main.d D run main.d --compiler ldc ( not installed? Auto download and compile using dub ) D run main.d --compiler ldc --options -o3 D run main.d --compiler gdc ( not installed? Auto ...) D package install web-d Seen this layout with a some other compilers where everything is clean integrated. - Compiler ( default ) -- Run -- Test - Package -- Install -- Remove -- Update - Tools --- Format --- Check - Language server? No dub, no ldc, gdc, no confusion, just one clean interface. What happens behind the interface is nobody there business. It just presents better. Dub already does half this work with the compiler option but its a package manager not the "face of D". Hard to explain... Anyway, too much off-topic?
Feb 01
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Nothing wrong with choice as long as that choice does not=20
 introduces issues. Currently there are 3 compilers but also 3=20
 different ways to install ( depending on the platform ). DMD has=20
 a installer, LDC needs a manual copy job + path creation, GDC did=20
 not even bother with ( sorry ).
For me: aptitude install ldc aptitude install gdc aptitude install dmd-bin aptitude install dub Seems to work fine, and no conflicts. [=E2=80=A6] --=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
Feb 01
parent reply Benny <benny.luypaert rhysoft.com> writes:
On Thursday, 1 February 2018 at 15:47:50 UTC, Russel Winder wrote:
 For me:

 aptitude install ldc
 aptitude install gdc
 aptitude install dmd-bin
 aptitude install dub

 Seems to work fine, and no conflicts.

 […]
Please try Windows and then come back ;)
Feb 01
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 17:25 +0000, Benny via Digitalmars-d wrote:
 On Thursday, 1 February 2018 at 15:47:50 UTC, Russel Winder wrote:
 For me:
=20
 aptitude install ldc
 aptitude install gdc
 aptitude install dmd-bin
 aptitude install dub
=20
 Seems to work fine, and no conflicts.
=20
 [=E2=80=A6]
=20 Please try Windows and then come back ;)
Uuurrr=E2=80=A6 no. Those people who choose to use a system such as Windows= , for which no-one is providing packaging, have a responsibility to: a) raise the problems; and b) help fix raised problems. --=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
Feb 02
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via Digitalmars-d wrote:
 On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d wrote:
 
[…]
 Nothing wrong with choice as long as that choice does not 
 introduces issues. Currently there are 3 compilers but also 3 
 different ways to install ( depending on the platform ). DMD has 
 a installer, LDC needs a manual copy job + path creation, GDC did 
 not even bother with ( sorry ).
For me: aptitude install ldc aptitude install gdc aptitude install dmd-bin aptitude install dub Seems to work fine, and no conflicts.
[...] Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-) T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Feb 01
next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 1 February 2018 at 16:17:45 UTC, H. S. Teoh wrote:
 On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via 
 Digitalmars-d wrote:
 On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d 
 wrote:
 
[…]
 Nothing wrong with choice as long as that choice does not 
 introduces issues. Currently there are 3 compilers but also 
 3 different ways to install ( depending on the platform ). 
 DMD has a installer, LDC needs a manual copy job + path 
 creation, GDC did not even bother with ( sorry ).
For me: aptitude install ldc aptitude install gdc aptitude install dmd-bin aptitude install dub Seems to work fine, and no conflicts.
[...] Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-) T
curl https://i.dlang.io/install.sh | bash -s dmd ~/dlang/install.sh ldc ~/dlang/install.sh gdc Works on all Posix systems Now to use LDC as default: . ~/dlang/install.sh -a ldc Didn't we have this discussion yesterday already? See also: https://dlang.org/install.html
Feb 01
parent reply psychoticRabbit <meagain meagain.com> writes:
On Thursday, 1 February 2018 at 17:13:52 UTC, Seb wrote:
 curl https://i.dlang.io/install.sh | bash -s dmd
Yeah..let's all run an untrusted shell script (with unknown contents), right off the web. Will people never learn?
Feb 01
parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Friday, 2 February 2018 at 02:15:55 UTC, psychoticRabbit wrote:
 On Thursday, 1 February 2018 at 17:13:52 UTC, Seb wrote:
 curl https://i.dlang.io/install.sh | bash -s dmd
Yeah..let's all run an untrusted shell script (with unknown contents), right off the web. Will people never learn?
Relax and take a break. You can still download the script, review and then run it as required.
Feb 01
next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 2 February 2018 at 02:25:47 UTC, Arun Chandrasekaran 
wrote:
 On Friday, 2 February 2018 at 02:15:55 UTC, psychoticRabbit 
 wrote:
 On Thursday, 1 February 2018 at 17:13:52 UTC, Seb wrote:
 curl https://i.dlang.io/install.sh | bash -s dmd
Yeah..let's all run an untrusted shell script (with unknown contents), right off the web. Will people never learn?
Relax and take a break. You can still download the script, review and then run it as required.
First I had a typo there - it should have been
 curl https://dlang.io/install.sh | bash -s dmd
(I type to much text on my tiny phone screen these days). Apart from as Arun correctly pointed out, going the two step route of doing your audit locally: --- wget https://dlang.io/install.sh vi install.sh # do your audit bash install.sh --- Also: - note that install.sh will download the official D keyring (https://dlang.org/gpg_keys.html), with which all binaries + the script itself are signed, s.t. it can verify binaries + updates to the script. - it's a fairly common practice, e.g. https://www.rustup.rs
Feb 01
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 2 February 2018 at 02:25:47 UTC, Arun Chandrasekaran 
wrote:
 On Friday, 2 February 2018 at 02:15:55 UTC, psychoticRabbit 
 wrote:
 On Thursday, 1 February 2018 at 17:13:52 UTC, Seb wrote:
 curl https://i.dlang.io/install.sh | bash -s dmd
Yeah..let's all run an untrusted shell script (with unknown contents), right off the web. Will people never learn?
Relax and take a break. You can still download the script, review and then run it as required.
Yeah...it's not like I'm unfamiliar with that concept ;-) But many (perhaps most) are not. btw. Oh.. and I do hope that debian/apache webserver they use cannot be hacked... cause I've heard you can do some interesting stuff on people systems with shell scripts ;-)
Feb 01
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/01/2018 11:17 AM, H. S. Teoh wrote:
 On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via Digitalmars-d
wrote:
 For me:

 aptitude install ldc
 aptitude install gdc
 aptitude install dmd-bin
 aptitude install dub

 Seems to work fine, and no conflicts.
[...] Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-)
Extracting the archive and just...using the compiler inside...always worked fine for me on every Windows and Linux I ever tried.
Feb 05
prev sibling next sibling parent Nerve <nervecenter7 gmail.com> writes:
On Thursday, 1 February 2018 at 15:27:02 UTC, Benny wrote:
 Suggestion:

 Is it maybe not better to have one "front-end" compiler visible 
 that people download

 Example:

 D run main.d
 D run main.d --compiler ldc ( not installed? Auto download and 
 compile using dub )
 D run main.d --compiler ldc --options -o3
 D run main.d --compiler gdc ( not installed? Auto ...)

 D package install web-d

 Seen this layout with a some other compilers where everything 
 is clean integrated.

 - Compiler ( default )
 -- Run
 -- Test

 - Package
 -- Install
 -- Remove
 -- Update

 - Tools
 --- Format
 --- Check
 - Language server?

 No dub, no ldc, gdc, no confusion, just one clean interface. 
 What happens behind the interface is nobody there business. It 
 just presents better.

 Dub already does half this work with the compiler option but 
 its a package manager not the "face of D". Hard to explain...

 Anyway, too much off-topic?
DUB can fill this role quite well. What it needs is clearer documentation on how to switch compilers. Better yet, outright compiler switches from the command line to designate a compiler, compile debug code, or run unittest code. On another note, I do want to put in my two cents about this controversial thread, and the continuing GC threads that pop up. People that use D find it highly productive and performant in their domains. C and C++ programmers, ostensibly the target audience of D, continue to reject GC as some kind of albatross they'll never get over. dlang.org needs front-page, clear as day examples of the speed benefits of optimized D code. Show that there is minimal or no impact from the GC is most modern use cases (i.e. within components of a web framework, within a database, within a desktop application). Compare performance of real solutions. And, if it can be done, show how maximally performant embedded code with no GC can be run on constrained real-time hardware with a significant gain in code readability. tl;dr EXAMPLES EXAMPLES EXAMPLES SHOW the world why the GC is not only not a big deal, but a good thing, and STOP trying to TELL them by playing defense in discussion threads around the Internet.
Feb 01
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-02-01 at 08:17 -0800, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via
 Digitalmars-d wrote:
=20
[=E2=80=A6]
 For me:
=20
 aptitude install ldc
 aptitude install gdc
 aptitude install dmd-bin
 aptitude install dub
=20
 Seems to work fine, and no conflicts.
=20 [...] =20 Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-)
I see two obvious inferences: a) use a platform with a good packaging system, and good packaging team. b) if you cannot use a such a system, raise the problem and then get involved in fixing it. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Feb 02
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
T,

Arguing things on this list serves no purpose other than to rehearse
arguments. The place to say things about stuff on Quora is on Quora as
Walter, Laeeth, and I have done in this case.

On Tue, 2018-01-30 at 13:02 -0800, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jan 30, 2018 at 03:45:44PM -0500, Andrei Alexandrescu via
 Digitalmars-d wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++
=20 [...] =20 I actually agree with all of his points, except one: C++'s "enormous performance advantage"?! Is he being serious? Or is his view biased by dmd's, erm, shall we say, "suboptimal" optimizer? =20 Just yesterday I was experimenting with ldc while reviewing a Phobos PR, and it showed that LDC was well able to reduce iteration over a range down to a native asm loop of the same order of efficiency as an equivalent C++ loop. So, the cost of D (arguably better) abstractions simply *isn't there*. Both languages compile to the *same* native code. Where's C++'s "enormous performance advantage?" I'm not seeing it, except in this article, and, presumably, in the author's imagination. =20 And of course, in the comments section there's the obligatory reference to the Tango/Phobos split in D1. Eye-roll. That one never gets old, it seems, even though it's already ancient history that the modern D community has mostly forgotten about. The internet is good for disseminating information, and also great for prolonging ignorance. =20 Enough of this nonsense. Let me get back to coding... in D. :-D =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
Jan 31
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
For me personally, there are some really nasty bugs regarding default attributes ( nogc/ safe) that prevent me from using D in personal code projects. Examples being: Destroy can't be called in safe and nogc context even it is the base class destructor is marked with safe and nogc. Among other base object functions. https://dlang.org/phobos/object.html This bug requires a DIP to fix(I was thinking about writing up one, but I am not sure if I should do that). I don't want new features, I just want to fix the current existing bugs. Alex
Jan 31
prev sibling next sibling parent reply Ali <fakeemail example.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
The kinda small discussion on ycombinator https://news.ycombinator.com/item?id=16270841
Jan 31
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 31 January 2018 at 21:42:47 UTC, Ali wrote:
 The kinda small discussion on ycombinator
 https://news.ycombinator.com/item?id=16270841
Interesting... most of them don't grok C++, D, Java or Go... Hope people don't look to ycombinator for answers.
Jan 31
prev sibling next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
The Betamax Problem When you introduce something new, how do you know that it is going to be compelling enough for people to move from whatever it is they are doing and use your new thing? It is not an easy question to answer but in the realm of programming languages it's a very tough question, because people are going to have to learn a whole new language, and its going to come with costs and potentially unquantifiable risks for any company that attempts to shift to that language. So whatever it is you are offering has to be tremendously compelling compared to what is already there. An important question is what problem set does D solve? It's very hard to sell a language to industry without convincingly answering that question. If you are selling them a 'better' language - that's a tougher sell. If you are selling a solution to a particular problem set - you stand better a chance. For a manager to consider D as the successor to C++, it doesn't just have to be a better language design than C++, it has to have the best language design of any compiled language and demonstrate the best performance. Is the former really true? Are various language features that have been inherited from C++/Java the best way forward? For instance does D have the best approach to object oriented programming, or templates? Or any important set of features you care to mention? Are there things that C++ does better than D? How straightforward is it to get great performance from D? Is how do you 'tune' your D code for high performance obvious or well documented? If the answers to any of the above questions is a negative for D, that's a serious problem if what you want to do is replace C++, because C++ is already a solid well know language and the competition from new programming languages is extremely tough, and because its only going to get easier to create programming languages this competition will get tougher. To finish the Betamax story, when CD came along, people dropped cassette tapes like hot potatoes and DVDs killed VHS stone dead. Does D represent a similar leap from C++? I'm not saying that D is Betamax. I'm just giving food for thought.
Feb 07
next sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
The Betamax Problem
I don't think the analogy holds. With VHS and betamax, you just put in the tape and watch your movie. Most people didn't care very much what the name on the machine said --- both types of machines had the same buttons. In contrast to that, programmers are very particular about the languages they use (which includes tooling, community, module repos, available books).
 An important question is what problem set does D solve? It's 
 very hard to sell a language to industry without convincingly 
 answering that question. If you are selling them a 'better' 
 language - that's a tougher sell. If you are selling a solution 
 to a particular problem set - you stand better a chance.
My impression is that the object is not necessarily to sell D to industry, but rather to sell it to developers. Developers choose what they want to learn and use at home and in side projects. Then at work some tools here and there get written in it. Then some customer-facing projects. Before you know it, it's been "sold to industry". I think, as of last year, D has upped its sales (to developers) game: * fully open-sourced dmd * GDC slated for inclusion into GCC * there's been talk of adding some markdown features to ddoc. Cosmetic, yes; sells D well to developers, emphatically yes. I'm not sure how long dub has been around, but having an easy to use CPAN-alike (online module repo) is HUGE. Dub is great for sales. The better dub and the repo gets, the more attractive D gets.
Feb 07
parent reply Ralph Doncaster <nerdralph github.com> writes:
On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele 
wrote:
 I'm not sure how long dub has been around, but having an easy 
 to use CPAN-alike (online module repo) is HUGE. Dub is great 
 for sales. The better dub and the repo gets, the more 
 attractive D gets.
I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto
Feb 08
next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 8 February 2018 at 15:29:08 UTC, Ralph Doncaster 
wrote:
 On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele 
 wrote:
 I'm not sure how long dub has been around, but having an easy 
 to use CPAN-alike (online module repo) is HUGE. Dub is great 
 for sales. The better dub and the repo gets, the more 
 attractive D gets.
I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto
The opposite situation you may see, when searching for mysql: You will get 9 packages listed. Which should I take? If you click on everyone, you will realize, that some of them are forks of other. And the version number of mysql-native at the top, just recently increased so strong, that it makes a different. The minimum additional information which should be listed - I think - is the number of downloads and GitHub stars. I know that there is work behind the scene to find some kind of weighted sort, this would be cool, but just displaying the GitHub voting might help a lot.
Feb 08
parent reply Bo <bo41 bo0041.com> writes:
On Thursday, 8 February 2018 at 15:56:16 UTC, Martin Tschierschke 
wrote:
 You will get 9 packages listed. Which should I take?
 If you click on everyone, you will realize, that some of them 
 are forks of other.
 And the version number of mysql-native at the top, just 
 recently increased so strong, that it makes a different.
 The minimum additional information which should be listed - I 
 think - is the number of downloads and GitHub stars.

 I know that there is work behind the scene to find some kind of 
 weighted sort, this would be cool, but just displaying the 
 GitHub voting might help a lot.
The answer to that is simply pick: null. Two depend on vibe.d core. Several others have not been updated. As you stated several are forks. And not a single one is a official D supported package. For basic technology as database's: Mysql, PostgreSQL, Sqlite, Firebird, MongoDB you expect this to be under the standard library for D, with official support. The reason why scripting languages do good in user adaptation is simply because they offer all the necessary dependencies as official libraries. Any language that depends on 3th party developers to provide this support can never have a standardized structure and forces people into making choices they may regret. Add also a total lack of quality control. Extra fun: etc.c.sqlite3
Feb 09
parent Mark <smarksc gmail.com> writes:
On Friday, 9 February 2018 at 13:21:09 UTC, Bo wrote:
 For basic technology as database's: Mysql, PostgreSQL, Sqlite, 
 Firebird, MongoDB you expect this to be under the standard 
 library for D, with official support.

 The reason why scripting languages do good in user adaptation 
 is simply because they offer all the necessary dependencies as 
 official libraries.

 Any language that depends on 3th party developers to provide 
 this support can never have a standardized structure and forces 
 people into making choices they may regret. Add also a total 
 lack of quality control.
Does C++ have such support in its standard library?
Feb 09
prev sibling parent Mengu <mengukagan gmail.com> writes:
On Thursday, 8 February 2018 at 15:29:08 UTC, Ralph Doncaster 
wrote:
 On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele 
 wrote:
 I'm not sure how long dub has been around, but having an easy 
 to use CPAN-alike (online module repo) is HUGE. Dub is great 
 for sales. The better dub and the repo gets, the more 
 attractive D gets.
I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto
i think it is the ecosystem. we do not have a better ecosystem to offer and accommodate c++ developers. by ecosystem i mean, things that take the pain out of a c++ developer and make them solely focus on their code. we don't have an IDE, we don't have one perfect, portable GUI library, we don't have a better build system, we don't even have a migration guide for them. (d for c++ developers page does not count) we only have a better and easier language. that's all we have. otherwise i do not think c++ developers are sadomasochists that would do this torture to themselves. :)
Feb 09
prev sibling parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
The Betamax Problem When you introduce something new, how do you know that it is going to be compelling enough for people to move from whatever it is they are doing and use your new thing? It is not an easy question to answer but in the realm of programming languages it's a very tough question, because people are going to have to learn a whole new language, and its going to come with costs and potentially unquantifiable risks for any company that attempts to shift to that language. So whatever it is you are offering has to be tremendously compelling compared to what is already there.
A great deal of confusion in the world arises from failing to make distinctions between things that appear to be the same but really aren't when you look closely. Also, in about 1870 odd there was a revolution in economic thought that took place more or less simultaneously in Vienna, Lausanne and Cambridge. The Marginal Revolution had yet to be fully digested in the way people think about social phenomena. My director of studies at Cambridge, Lord Eatwell, Labour spokesman in the House of Lords, was known for his devotion to the work of Pierro Sraffa, a man known principally for a rather hostile book review of a book by Hayek and a rather slim book of his own, Production of Commodities by Means of Commodities, a book that tried to draw insights about the economy from a model with two goods, corn and gold. And I think considering firms as homogeneous, with the same cultural values and facing the same situation will be about as insightful as I think Sraffa's work ended up being - not very. Life is risk. It's risky to get out of bed in the morning, but it's also risky not to get out of bed. And it's true that an agent acting on behalf of someone else - ie a manager who has no stake in the business - will often think about things first in terms of not taking a decision that might lead him to be blamed. But most firms are not large enterprises, and in the US small and medium sized firms over time create more than 100% of job growth, last I checked. And a manager who is also at least to some extent a principal ie an owner in the business knows that to be conservative in a time of change is not necessarily prudent, and it may well also not be the profit maximising choice. As someone who is both a manager and a part owner I disagree that a new technology choice needs to be overwhelmingly compelling to be considered. And I don't get paid to make decisions about things that are easily quantifiable - what for you need me for if the numbers are straightforward? The reality is that firms are very different, in a dynamic industry even within the same sector they are different. And at any one time there are a bunch of people close to trying D or more. You don't need to persuade everyone to grow. You just need to persuade a few more people to tip over the margin. And there are often plenty of safe ways to take risks. You just need to make sure you have a plan B. Listen to Manu's talk for a real example of what I mean. And note that he said Finns are very conservative.
 An important question is what problem set does D solve? It's 
 very hard to sell a language to industry without convincingly 
 answering that question. If you are selling them a 'better' 
 language - that's a tougher sell. If you are selling a solution 
 to a particular problem set - you stand better a chance.
But really who is selling D to anyone? We are very far from that stage right now. Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope. People who had earned the authority to decide became aware of the language end decided to use it. And they did so because for them it solved their particular problems better then anything else they could think of.
 For a manager to consider D as the successor to C++, it doesn't 
 just have to be a better language design than C++, it has to 
 have the best language design of any compiled language and 
 demonstrate the best performance.
Why? Best in what way? Best for whom and for what kind of problems? I completely disagree with that. It needs just to be better in the situation then the conceivable alternatives. And situations and challenges are really quite different between firms. Is the former really true?
 Are various language features that have been inherited from 
 C++/Java the best way forward? For instance does D have the 
 best approach to object oriented programming, or templates? Or 
 any important set of features you care to mention? Are there 
 things that C++ does better than D? How straightforward is it 
 to get great performance from D? Is how do you 'tune' your D 
 code for high performance obvious or well documented?

 If the answers to any of the above questions is a negative for 
 D, that's a serious problem if what you want to do is replace 
 C++, because C++ is already a solid well know language and the 
 competition from new programming languages is extremely tough, 
 and because its only going to get easier to create programming 
 languages this competition will get tougher.

 To finish the Betamax story, when CD came along, people dropped 
 cassette tapes like hot potatoes and DVDs killed VHS stone 
 dead. Does D represent a similar leap from C++?

 I'm not saying that D is Betamax. I'm just giving food for 
 thought.
You can turn your scepticism on anything, and the value of the exercise really depends on the results. But doubt on its own isn't necessarily a good guide to the future in my experience. In particular with D because the benefit doesn't I think come from any single feature but from the totality of the gestalt of what it's like to work in D compared to other languages. I think that if you want to understand the adoption of new technologies then Clayton Christensen's Innovators Dilemma has considerable insight. Up to a point Crossing the Chasm and companion books too. I think by Moore.
Feb 07
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc wrote:
 On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
 wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
[...] But really who is selling D to anyone? We are very far from that stage right now. Did someone sell D to Microsoft COM team, Remedy or to Weka? Nope. People who had earned the authority to decide became aware of the language end decided to use it. And they did so because for them it solved their particular problems better then anything else they could think of. [...]
This would be relevant if Microsoft actually followed up on that, but it was an one shot prototype, done by one of their employees. Nothing followed up from there. Instead what happened was UWP, C++/CX extensions and now with the effort lead by Kenny Kerr, C++/WinRT implemented in C++17.
Feb 09
prev sibling parent reply Bo <bo41 bo0041.com> writes:
On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc wrote:
 But really who is selling D to anyone? We are very far from 
 that stage right now.  Did someone sell D to Microsoft COM 
 team, Remedy or to Weka? Nope.  People who had earned the 
 authority to decide became aware of the language end decided to 
 use it.  And they did so because for them it solved their 
 particular problems better then anything else they could think 
 of.
The question one needs to ask is more: how long ago have those developers decided to use D and why is the technology not more widespread in those companies. If D solved the issues in those companies, you expect to see a increased switch to a language. And yet most of those companies use D in one project and it stays in that one project. That means other developers do not switch, management has no task to introduce it elsewhere and the project is more or less supported by the developer that pushed for the technology.
Feb 09
parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 9 February 2018 at 13:08:25 UTC, Bo wrote:
 On Thursday, 8 February 2018 at 03:36:17 UTC, Laeeth Isharc 
 wrote:
 But really who is selling D to anyone? We are very far from 
 that stage right now.  Did someone sell D to Microsoft COM 
 team, Remedy or to Weka? Nope.  People who had earned the 
 authority to decide became aware of the language end decided 
 to use it.  And they did so because for them it solved their 
 particular problems better then anything else they could think 
 of.
The question one needs to ask is more: how long ago have those developers decided to use D and why is the technology not more widespread in those companies. If D solved the issues in those companies, you expect to see a increased switch to a language.
That conclusion relies on the assumption that programmers / managers / tech leads / CTOs choose programming languages based on technical merits alone. While there are certainly people who do that, in my experience they are in a small minority. There's inertia, tribalism, sunk cost fallacy, fear of the unknown, fear of change, lack of wanting to invest time in a new technology, "if it ain't broke don't fix it" (touted many a time by people who either ignore security exploits or justify it saying it's not the language's fault but bad programmers), popularity, herd mentality, ... Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed. Atila
 And yet most of those companies use D in one project and it 
 stays in that one project. That means other developers do not 
 switch, management has no task to introduce it elsewhere and 
 the project is more or less supported by the developer that 
 pushed for the technology.
Feb 09
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 09, 2018 14:01:02 Atila Neves via Digitalmars-d wrote:
 Unit tests are a great idea, right? Try convincing a group of 10
 programmers who have never written one and don't know anyone else
 who has. I have; I failed.
The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse. - Jonathan M Davis
Feb 09
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 9 February 2018 at 14:49:27 UTC, Jonathan M Davis 
wrote:
 On Friday, February 09, 2018 14:01:02 Atila Neves via 
 Digitalmars-d wrote:
 Unit tests are a great idea, right? Try convincing a group of 
 10 programmers who have never written one and don't know 
 anyone else who has. I have; I failed.
The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse. - Jonathan M Davis
That's... new. Cognitive dissonance never ceases to amaze me. Atila
Feb 09
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 9 February 2018 at 14:49:27 UTC, Jonathan M Davis 
wrote:
 On Friday, February 09, 2018 14:01:02 Atila Neves via 
 Digitalmars-d wrote:
 Unit tests are a great idea, right? Try convincing a group of 
 10 programmers who have never written one and don't know 
 anyone else who has. I have; I failed.
The amazing thing is when a programmer tries to argue that having unit tests makes your code worse - not that they take too long to write or that they don't want to bother with them or any that - that they somehow make the code worse. - Jonathan M Davis
Actually, it can make lazy programmers write worse code if they write code to satisfy the tests instead of writing code according to the spec...
Feb 09
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2018 6:49 AM, Jonathan M Davis wrote:
 The amazing thing is when a programmer tries to argue that having unit tests
 makes your code worse - not that they take too long to write or that they
 don't want to bother with them or any that - that they somehow make the code
 worse.
It's not amazing at all :-) The reasons people give to not try something new are hardly ever the actual reasons. People will make up on the spot reasons that they think you want to hear or that sound good. Their actual reasons they keep to themselves because they don't sound good. If you talk with someone enough you'll eventually figure out their actual reasons.
Feb 09
prev sibling next sibling parent Mark <smarksc gmail.com> writes:
On Friday, 9 February 2018 at 14:01:02 UTC, Atila Neves wrote:
 Unit tests are a great idea, right? Try convincing a group of 
 10 programmers who have never written one and don't know anyone 
 else who has. I have; I failed.

 Atila
You should have tried to convince them to do TDD. ;)
Feb 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2018 6:01 AM, Atila Neves wrote:
 Unit tests are a great idea, right? Try convincing a group of 10 programmers
who 
 have never written one and don't know anyone else who has. I have; I failed.
Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests. D's unit testing system didn't even need to be very good. It just had to be *easy*. And that changed everything.
Feb 09
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 09, 2018 13:39:22 Walter Bright via Digitalmars-d wrote:
 On 2/9/2018 6:01 AM, Atila Neves wrote:
 Unit tests are a great idea, right? Try convincing a group of 10
 programmers who have never written one and don't know anyone else who
 has. I have; I failed.
Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests. D's unit testing system didn't even need to be very good. It just had to be *easy*. And that changed everything.
Yeah. git did the same thing for me for source control. Before, I almost never did anything with source control with my personal projects, because it was too much of a pain to set up; you basically had to set up a server to talk to (even if it was on the same machine), whereas with git, it's just git init . and you have a repository. Now, all my source code goes in a git repo unless it's just a quick test that I'm going to throw away when I'm done. And the fact that places like github and bitbucket make it so easy to create repos online means that a lot of my stuff is online too, whereas if I had to use something like SVN, I'd probably have next to nothing in source control. And the way that D handles unit tests has had the same effect. If I were doing all of my personal projects n C++, I don't know how many would be unit tested. Anything really serious would be, but the extra effort of setting something up to be able to have unit tests is enough that anything simple would probably never have any tests, because it would be too much effort for me to bother. Having unit tests built-in is definitely a game changer. - Jonathan M Davis
Feb 09
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
 If I were
 doing all of my personal projects n C++, I don't know how many would be unit
 tested.
I know how many. Zero.
Feb 09
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 09, 2018 19:50:48 Walter Bright via Digitalmars-d wrote:
 On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
 If I were
 doing all of my personal projects n C++, I don't know how many would be
 unit tested.
I know how many. Zero.
If I were writing something like std.datetime in C++, I'd go to the trouble of writing unit tests, and I've written unit testing frameworks for C++ before for work. So, I don't think that it would necessarily be zero, but it's certainly true that I'd be a lot less willing to go to the effort, and I almost certainly wouldn't bother for smaller projects. - Jonathan M Davis
Feb 09
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 09, 2018 at 01:39:22PM -0800, Walter Bright via Digitalmars-d wrote:
 On 2/9/2018 6:01 AM, Atila Neves wrote:
 Unit tests are a great idea, right? Try convincing a group of 10
 programmers who have never written one and don't know anyone else
 who has. I have; I failed.
Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests.
Yeah, it is so simple you feel ashamed for not writing them. Which in turn generates a positive feedback loop where your unittests uncovers bugs early (rather than 2 months later when your customer's box blows up), so you feel motivated to write more tests, and your code quality continues improving.
 D's unit testing system didn't even need to be very good. It just had
 to be *easy*. And that changed everything.
Speaking of unittests... currently we have a problem: import std.regex; void main() {} Compiling with -unittest: real 0m1.137s user 0m0.994s sys 0m0.141s Compiling without -unittest: real 0m0.528s user 0m0.458s sys 0m0.069s The problem: compiling with -unittest causes Phobos unittests to be instantiated, even if the user isn't compiling Phobos directly. Proposal: unittests should only be compiled if the module it's found in is being compiled (i.e., among the modules listed on the command-line), even with -unittest. This won't break anything, because as long as user projects compile all of their modules explicitly, -unittest will still work as before. I'd guess practically all user projects will do this. (There may be a few exceptions, e.g., if a module contains only templates, but IIRC even then you still have to list the module on the command-line, otherwise some templates won't instantiate correctly.) It will improve compilation times and reduce executable bloat -- unittests from external libraries that are only linked, not compiled, won't be included. It also makes more sense -- if I'm using a 3rd party library, why should I care to run *their* unittests? I'm only interested in testing my own code. What do you think? T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Feb 09
parent Nick Sabalausky <a a.a> writes:
On Friday, 9 February 2018 at 22:38:23 UTC, H. S. Teoh wrote:
 Proposal: unittests should only be compiled if the module it's 
 found in is being compiled (i.e., among the modules listed on 
 the command-line), even with -unittest.

 if I'm using a 3rd party library, why should I care to run 
 *their* unittests?  I'm only interested in testing my own code.

 What do you think?
Currently being discussed in another thread, but that's an emphatic "YES, definitely". I proposed that awhile back and there was a bunch of hemming and hawing and ultimately nothing, but I really hope something will come of it this time.
Feb 09
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-09 at 13:39 -0800, Walter Bright via Digitalmars-d
wrote:
 On 2/9/2018 6:01 AM, Atila Neves wrote:
 Unit tests are a great idea, right? Try convincing a group of 10
 programmers who=20
 have never written one and don't know anyone else who has. I have;
 I failed.
=20 Unit tests are one of the great success stories of D. I believe it was a success=20 because it was so simple to add unit tests to the code, and to run those tests. =20 D's unit testing system didn't even need to be very good. It just had to be=20 *easy*. And that changed everything.
Confirmatory evidence is that Rust does the same thing. --=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
Feb 11
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2018 2:16 AM, Russel Winder wrote:
 Confirmatory evidence is that Rust does the same thing.
D has an outsized influence that extends way beyond just D users :-) Consider all the D features that somehow were "completely independently" discovered years later by C++! Even little ones like char16_t, char32_t, and being able to separate digits with single quotes, and larger ones like static if and ranges.
Feb 11
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 February 2018 at 23:00:40 UTC, Walter Bright wrote:
 Even little ones like char16_t, char32_t, and being able to 
 separate digits with single quotes, and larger ones like static 
 if and ranges.
D's support for ranges is probably the single most important reason why I choose to use D. (lot's of other very good reasons too, but not as important as ranges). When I look at other languages now, the first thing I want to know is, does it have integral support for ranges?? "ranges .. improve safety when compared with iterators because they never allow invalid pairs of iterators." http://www.informit.com/articles/printerfriendly/1407357
Feb 11
parent reply Ali <fakeemail example.com> writes:
On Monday, 12 February 2018 at 04:59:10 UTC, psychoticRabbit 
wrote:
 On Sunday, 11 February 2018 at 23:00:40 UTC, Walter Bright 
 wrote:
 Even little ones like char16_t, char32_t, and being able to 
 separate digits with single quotes, and larger ones like 
 static if and ranges.
D's support for ranges is probably the single most important reason why I choose to use D. (lot's of other very good reasons too, but not as important as ranges). When I look at other languages now, the first thing I want to know is, does it have integral support for ranges?? "ranges .. improve safety when compared with iterators because they never allow invalid pairs of iterators." http://www.informit.com/articles/printerfriendly/1407357
C++ is expected to add ranges based on this library https://github.com/ericniebler/range-v3
Feb 11
parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 12 February 2018 at 05:45:13 UTC, Ali wrote:
 C++ is expected to add ranges based on this library
 https://github.com/ericniebler/range-v3
Yes, but given the significance of C++, it really should be leading.. not following (at snails pace). C++ simply has too much legacy stuff to contend with..and that will continue to hold it back.. forever. The best C++ can do, is (slowly) think about copying what others are doing..to the extent C++ can handle it, and to the extent the 'committees' agree to doing it. C++ is like a Jackson Pollock painting - I look at it, and think to myself...wtf! Of course it's all in the eye of the beholder.
Feb 12
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 12 February 2018 at 09:04:57 UTC, psychoticRabbit 
wrote:
 The best C++ can do, is (slowly) think about copying what 
 others are doing..to the extent C++ can handle it, and to the 
 extent the 'committees' agree to doing it.
Well, most languages are like that... including D.
Feb 12
prev sibling next sibling parent reply Ali <fakeemail example.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
my modest opinion about this D currently is a small player, that have an attractive proposition for some * it is like C++ (that is close to the power of C++) but simpler * it have some unique advanced feature related to meta programming D's best hope is to be a bigger player, it is unrealistic to replace c++ Any improvement made to D will help make it a bigger player And while some D features can be better advertised (like Design by Contract, DbC is a big deal, and few other languages are know to have it) I think D need to constantly add features, the idea that D is big enough, or that it needs more idioms rather than features, is in my opinion wrong D need to constantly add features, because all of it competitions are constantly adding features As D add features, it may have a breakthrough, at some point
Feb 07
parent Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Thursday, 8 February 2018 at 00:09:47 UTC, Ali wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
my modest opinion about this D currently is a small player, that have an attractive proposition for some * it is like C++ (that is close to the power of C++) but simpler * it have some unique advanced feature related to meta programming D's best hope is to be a bigger player, it is unrealistic to replace c++ Any improvement made to D will help make it a bigger player And while some D features can be better advertised (like Design by Contract, DbC is a big deal, and few other languages are know to have it) I think D need to constantly add features, the idea that D is big enough, or that it needs more idioms rather than features, is in my opinion wrong D need to constantly add features, because all of it competitions are constantly adding features As D add features, it may have a breakthrough, at some point
Maybe features help, but there's also just a natural process of maturation that we don't notice because it happens slowly. In 2014 when I started using D it wasn't unusual for the compilers to segfault. And since I didn't know D, or even modern compilers, their flags etc (beyond a bit of work in visual studio in the late 90s, I mostly learnt to program C on 8 bit CP/M, which was a bit different then),it was quite a confusing experience. I couldn't have recommended D to somebody else then. The documentation also was not very accessible to people who didn't think formally and were used to Python material. I tried working with one chap, a trader who knew a bit of python and he was absolutely terrified of the D documentation. The situation there is also rather better today. Then again, how can I trust the compiler. It means something that Liran at Weka said they haven't had any data corruption bugs, because data on they scale tends to find problems and bring them to the fore. From what I have seen, big changes, much more than is generally appreciated are often not a consequence only of one big causal factor, but lots of little things aligned and coming together. However if you want a big thing just consider growth in data set sizes and storage capacity and related that to trends in processor power and memory speed. Guido says python is fast enough because you are bottlenecked on I/O and network. But in my office I have a test infiniband network where the 40 Gbps switch cost about 600 quid (that's old technology now). NVMe drives do pretty decent throughput. Json parsing is not the cleverest thing one can do with data but how does that compare with the throughput from just a couple of nvme drives? And according to the ACM a fundamental assumption that held true since the dawn of computing is in the process of being overturned. With storage class memory and newer network technology (there's a road map to get to 1Tbps) the bottleneck from here isnt storage or network - it's CPU. I guess that won't hurt the adoption of D. Not tomorrow, but slowly over time.
Feb 07
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! Feature D C C++ C# Java (and this was bacvk in ===================================== Garbage Collection Yes No No Yes Yes Functions ========= Function delegates Yes No No Yes No Function overloading Yes No Yes Yes Yes Out function parameters Yes Yes Yes Yes No Nested functions Yes No No No No Function literals Yes No No No No Dynamic closures Yes No No No No Covariant return types Yes No Yes No No Arrays ====== Lightweight arrays Yes Yes Yes No No Resizeable arrays Yes No No No No Arrays of bits Yes No No No No Built-in strings Yes No No Yes Yes Array slicing Yes No No No No Array bounds checking Yes No No Yes Yes Associative arrays Yes No No No No Strong typedefs Yes No No No No Aliases Yes Yes Yes No No OOP === Object Oriented Yes No Yes Yes Yes Multiple Inheritance No No Yes No No Interfaces Yes No Yes Yes Yes Operator overloading Yes No Yes Yes No Modules Yes No Yes Yes Yes Dynamic class loading No No No No Yes Inner classes No No No No Yes Covariant return types Yes No Yes No No Performance =========== Inline assembler Yes Yes Yes No No Direct access to hardware Yes Yes Yes No No Lightweight objects Yes Yes Yes Yes No Explicit memory allocation control Yes Yes Yes No No Independent of VM Yes Yes Yes No No Direct native code gen Yes Yes Yes No No Templates Yes No Yes No No Reliability =========== Design by Contract Yes No No No No Unit testing Yes No No No No Static construction order Yes No No Yes Yes Guaranteed initialization Yes No No Yes Yes RAII Yes No Yes Yes No Exception handling Yes No Yes Yes Yes try-catch-finally blocks Yes No No Yes Yes Thread synchronization primitives Yes No No Yes Yes Compatibility ============= Algol-style syntax Yes Yes Yes Yes Yes Enumerated types Yes Yes Yes Yes No Support all C types Yes Yes No No No Long double floating point Yes Yes Yes No No Complex and Imaginary Yes Yes No No No Direct access to C Yes Yes Yes No No Use existing debuggers Yes Yes Yes No No Struct member alignment control Yes Yes Yes No No Generates standard object files Yes Yes Yes No No Macro preprocessor No Yes Yes No No Other ===== Conditional compilation Yes Yes Yes Yes No
Feb 10
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! Feature D C C++ C# Java (and this was bacvk in =====================================
(correction to above line) Feature D C C++ C# Java (and this was back in 2003) ..2003 ..gee.. that was what..15 years ago.
Feb 10
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit 
wrote:
 On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
 wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! Feature D C C++ C# Java (and this was bacvk in =====================================
(correction to above line) Feature D C C++ C# Java (and this was back in 2003) ..2003 ..gee.. that was what..15 years ago.
Well, it isn't correct in 2018...
Feb 10
parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 February 2018 at 00:15:32 UTC, Ola Fosheim Grostad 
wrote:
 On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit 
 wrote:
 On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
 wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! Feature D C C++ C# Java (and this was bacvk in =====================================
(correction to above line) Feature D C C++ C# Java (and this was back in 2003) ..2003 ..gee.. that was what..15 years ago.
Well, it isn't correct in 2018...
Hence the reason why D hasn't started to replace C++. i.e C++ continues to evolve.. (except that D got many things right, in the first instance - and so D can focus on more important matters ;-)
Feb 10
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! "I am appalled at the monstrous messes that computer scientists can produce under the name of ‘improvements’. It is to efforts such as C++ that I here refer. These artifacts are filled with frills and features but lack coherence, simplicity, understandability and implementability. If computer scientists could see that art is at the root of the best science, such ugly creatures could never take birth." "Since C is low level and object orientation is an inherently high level concept the result is conceptually incoherent." [ R.P.Mody - C in Education and Software Engineering - 1991 ]
Feb 11
parent reply German Diago <germandiago gmail.com> writes:
On Sunday, 11 February 2018 at 14:33:33 UTC, psychoticRabbit 
wrote:
 On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
 Alexandrescu wrote:
 https://www.quora.com/Why-hasnt-D-started-to-replace-C++

 Andrei
Why indeed! "I am appalled at the monstrous messes that computer scientists can produce under the name of ‘improvements’. It is to efforts such as C++ that I here refer. These artifacts are filled with frills and features but lack coherence, simplicity, understandability and implementability. If computer scientists could see that art is at the root of the best science, such ugly creatures could never take birth."
If it is not implementable (it is complex, I agree), why there are 3 major compilers? I think the future should go towards simplification a bit more for the idiomatic code. But there are features you cannot ignore in low-level languages: asm embedding, bit control, reference vs value, due to register efficiency and others. So I do not think it is such a *super bad* choice. In day-to-day life you need these things.
Feb 11
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 11 February 2018 at 15:07:00 UTC, German Diago wrote:
 If it is not implementable (it is complex, I agree), why there 
 are 3 major compilers?
At least 4: Intel, Microsoft, GCC and Clang. Then you have EDG and IBM, probably more.
Feb 11