Re: Vision document for H1 2018

[Ali via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level 
priority - locking down the language definition. This is in 
recognition of the fact that we need a precise definition of 
the language going forward.



Thanks,

Andrei


If I compare 2018H1 vision, to 2017H2 vision
I see that 3 out of 6 objectives are carry over from 2017

I think this needs more explanation, and maybe the vision 
document, should becomes more of a road map document


A vision by some definitions in management, is the organization 
dream, it doesn't have to be completely realistic


A road map, is more like a plan, that is realistically achievable

Again, I think, if 3 out 6 items are from last year, it seems 
unlikely all 6 will complete this year, and it seems more likely 
most of those will carry over to next year, and it becomes 
unclear which of those 6 will actually be implemented this year

Re: Vision document for H1 2018

[Kagamin via Digitalmars-d-announce]

On Friday, 16 March 2018 at 21:38:30 UTC, rumbu wrote:
Do you know anything else in the .net library than LINQ where 
extension methods (somehow equivalent to UFCS) are abused? I 
thought that something happened in the .net world while I was 
asleep, that's why I just searched my local copy of .net core 
and there are exactly 198 extension methods. I would not call 
these "big".


It's big because linq is perceptionally big in itself similar to 
how std.algorithm is big. It's also design pattern in C#: if you 
want a complex interface method with simplified overloads, you 
don't declare interface with many overloads, you declare one 
interface method that takes all parameters and a number of 
simplified extension methods that forward to interface, Unity 
container and Rhino mocks are designed this way.


Last time I checked, .net Console was an enormous static class 
with three Stream objects behind the scenes.


That's also how D console IO works.

When I said that phobos looks like a mess compared to .net lib 
I referred especially to the poor choice of names (eg. 
RedBlackTree vs SortedDictionary) and lack of essential stuff 
(eg. happy to have levenshteinDistance built in, but I cannot 
sort correctly two strings in any other language than English).


That's true, naming is a little complex.

Re: Vision document for H1 2018

[Kagamin via Digitalmars-d-announce]

On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:
I thought C# was like Java and does not allow free procedures. 
Can you give an example of C# procedural-style IO?


All methods of Console class.

Re: Vision document for H1 2018

[Joakim via Digitalmars-d-announce]

On Sunday, 18 March 2018 at 10:28:58 UTC, Radu wrote:

On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:

On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
You have to remember that the really big first client of 
betterC(++) was DMD, porting DMD from C++ was a big 
undertaking. Right now both DMD and LDC use a form of 
betterC, so it is critical to have it finalized.


This is entirely wrong. DMD and LDC rely extern(C++), but this 
has nothing to do with -betterC whatsoever.


Both compilers link and initialise the runtime as normal (and 
then disable the GC at runtime).


 — David


I stand corrected. I remembered something about druntime being 
used but last time I checked front end code was filled with 
strcpm and strlen, wrongly assumed that druntime was not used. 
Oh well...


You're not completely wrong about this: the dmd frontend uses 
almost nothing from druntime, not counting extern(C) declarations 
that are really from the local libc, and nothing from Phobos. 
However, I think it still requires druntime to be linked against 
because of some compiler-generated symbols and the like.  Also, 
LDC using the D frontend has allowed a few Phobos dependencies to 
creep in.


So where you were wrong is in saying dmd/ldc use betterC, which 
is an extreme that precludes linking against druntime or Phobos 
at all, though you could still use extern(C) declarations alone 
from the stdlib. What you may have been thinking of is Walter's 
plan to move the dmd backend to D written with betterC, because 
he'd like to use that same D backend with his C/C++ compiler 
frontends written in C/C++ and he wants to dogfood betterC there.


You weren't wrong that the dmd frontend is very much written in a 
betterC style, it just isn't fully usable with betterC yet.


Still, probably D compilers will benefit from fixing mangling 
bugs and allow more integration with C++ std, right?


Sure, David was simply pointing out that the betterC and 
extern(C++) efforts are orthogonal and that one doesn't imply the 
other: the ddmd frontend is an example of this, extensively using 
extern(C++) but not enabling betterC.

Re: Vision document for H1 2018

[Radu via Digitalmars-d-announce]

On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:

On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
You have to remember that the really big first client of 
betterC(++) was DMD, porting DMD from C++ was a big 
undertaking. Right now both DMD and LDC use a form of betterC, 
so it is critical to have it finalized.


This is entirely wrong. DMD and LDC rely extern(C++), but this 
has nothing to do with -betterC whatsoever.


Both compilers link and initialise the runtime as normal (and 
then disable the GC at runtime).


 — David


I stand corrected. I remembered something about druntime being 
used but last time I checked front end code was filled with 
strcpm and strlen, wrongly assumed that druntime was not used. Oh 
well...


Still, probably D compilers will benefit from fixing mangling 
bugs and allow more integration with C++ std, right?

Re: Vision document for H1 2018

[bauss via Digitalmars-d-announce]

On Friday, 16 March 2018 at 19:08:47 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/16/2018 02:35 PM, Tony wrote:

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:
Are you sure that you are talking about phobos and not 
tango? :)

I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are 
big on extension methods. Also tango uses object oriented 
console IO, while phobos and .net framework use procedural 
style for it.


I thought C# was like Java and does not allow free procedures. 
Can you give an example of C# procedural-style IO?




It doesn't (last I used it), buy you CAN mark individual member 
functions to be usable UFCS-like. IIRC, I think it might have 
to be static member function.


It's been awhile, so I don't remember it exactly, but it's 
something like this:


class Bar {}

class Foo {
static void SomeFunc(extention Bar bar, int num) {...}
}

class MyApp {
static void Run() {
Bar bar = new Bar();
bar.SomeFunc(2);
}
}


Actually it's like:

static void SomeFunc(this Bar bar, int num) { ... }

Re: Vision document for H1 2018

[Greatsam4sure via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address. 
Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet. Heck, *I'm* a 
C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to 
be multi-purpose. Because of that, D users (and potential D 
users) are *highly* diverse. Everybody here has their own 
use-cases, their own needs and priorities, and their own list 
of things they want fixed yesterday.


In a group this diverse, there just simply *isn't* much on the 
D wishlist that's crucially important to a *majority*, because 
we all need completely different things.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise. Some of the things 
most important to me for D to improve you probably wouldn't 
care one bit about - and that's ok. We work on different sorts 
of things.


Improved betterC is something I would find very nice if I ever 
have time or opportunity to get back into embedded software. 
But outside of that, yea, it doesn't impact me much more than 
it does for you.


But here's the rub: In this crowd here, probably far more than 
most languages, we all have such wildly varying needs that 29% 
*is* what qualifies as significant around here. Most wishlist 
items are going to have similarly non-majority numbers. And 
they have to pick *something* to focus on. Luckily, as the 
vision document clearly states, there are *several* such 
"somethings" the dlang foundation is committing to working on.




The D language is a marvel. It just nice using it. It is a 
superior language.
It is pure joy programming in D. D language is mature enough to 
write up to 90% of all form of application. The problem I have 
seen thus far is the tools. The tools don't work especially on 
Windows.



The only working ide on Windows is visual-D but tied to visual 
studio. Personally don't like visual studio, it look to old for 
my likely. The plugin for eclipse,visual studio code and intellij 
are really lacking behind.



I having trying to setup code-d up in vs code for more than six 
months now to get auto completion but to no success. I have spent 
countless hours on the internet search for a solution but did not 
find any. I just get all kinds of errors. My next plane is to by 
a Linux system. So to me D is a beautiful language with no 
beautiful tools so not usable to me yet.


All you need to set up dmd on Windows is to download it and 
install.it is less than 2mins, you are good to go. Running your 
code in command line is painless with dub. But who want to write 
a millions of lines of code using plan text editors without code 
hinting, auto complete and superior debuging?


I love D language so much. The language is true mature now. Fix 
the following problem


* Get the plugin for intellij, eclipse and vs code working 
especially on Windows

* Proper documentation for the various packages and library
*Make installation process as easy as installing dmd
*Books that touch all capability of the D langauge with real like 
application. Programming in D is good but it must be enchance 
further



D language must be easy to program on all pupular ide. All you 
need to write c# code in vs code is just two or three extension. 
There is code hinting, auto complete etc. Why will I not use C# 
in vs code? I have no reason. Good language with good tools- 
anybody will give it a trier



Walter and all the team have done a good job. But give me more 
pride to sell D to all my colleagues. Programmers are known to be 
proud of their language, they must have very good reasons to 
switch. People switch from one languge to another because the new 
language just easy their pain.


All the members of the D community must come together and face 
really and work together to move the language further to make D 
the number one langauge which is what D supposed to be.



Working individually have move us here but working collectively 
will definitely make us the best. We must give people on all 
platform- windows, Mac, Linux,intellij,exclipse, netbeam,vs code, 
visual studio etc good reasons to use D besides the beaulty and 
power of the language.


Love D 

Re: Vision document for H1 2018

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, March 16, 2018 21:37:44 Void-995 via Digitalmars-d-announce 
wrote:
> Every time I'm thinking that something is impossible to be
> elegantly and/or easily done even in D - someone proves me wrong.
>
> And common, I just had that little spark of motivation to look
> into DMD, what is my purpose in life now?

Fan it into flames and go learn it so that you can fix or improve other
stuff that might come up? ;)

Of course, depending on what you know and are interested in, doing stuff
like writing useful libraries and putting them up on code.dlang.org can be
of huge benefit even if you never do anything for dmd, druntime, or Phobos.
In some ways, that's probably our biggest need. But regardless, if you're
interested in helping out the D ecosystem, there are plenty of options.

- Jonathan M Davis

Re: Vision document for H1 2018

[Void-995 via Digitalmars-d-announce]

On Friday, 16 March 2018 at 15:58:25 UTC, Steven Schveighoffer 
wrote:

On 3/12/18 10:57 AM, Void-995 wrote:

On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:
On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis 
wrote:
Now, I actually understand ranges and am very glad that 
they're there, but as a D newbie, they were annoying, 
because they were unfamiliar.


Ranges are D's monads. The only thing missing is the burrito 
tutorials.


I always thought the best spice in D is UFCS. If only there 
would be one for local symbols (but that needs either 
foundation's decision or I need to write my first DIP and do 
something instead of just crying silently into my sleeve).


alias I(alias X) = X;

void main()
{
   int y = 5;
   int bar(int x) { return y * x; }
   // auto z = 6.bar; // error
   auto z = 6.I!bar; // OK
}

https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

-Steve


Every time I'm thinking that something is impossible to be 
elegantly and/or easily done even in D - someone proves me wrong.


And common, I just had that little spark of motivation to look 
into DMD, what is my purpose in life now?

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:
Are you sure that you are talking about phobos and not tango? 
:)

I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big 
on extension methods. Also tango uses object oriented console 
IO, while phobos and .net framework use procedural style for it.



Do you know anything else in the .net library than LINQ where 
extension methods (somehow equivalent to UFCS) are abused? I 
thought that something happened in the .net world while I was 
asleep, that's why I just searched my local copy of .net core and 
there are exactly 198 extension methods. I would not call these 
"big".


The Tango remark was just a pun (R.I.P.), since it looked 90% 
similar to .net. And what would make Tango unusable with UFCS? Is 
it not written in D?


Last time I checked, .net Console was an enormous static class 
with three Stream objects behind the scenes.


When I said that phobos looks like a mess compared to .net lib I 
referred especially to the poor choice of names (eg. RedBlackTree 
vs SortedDictionary) and lack of essential stuff (eg. happy to 
have levenshteinDistance built in, but I cannot sort correctly 
two strings in any other language than English).

Re: Vision document for H1 2018

[Dukc via Digitalmars-d-announce]

On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:


I thought C# was like Java and does not allow free procedures. 
Can you give an example of C# procedural-style IO?


Well, this is not IO, but:

public struct DivInt
{   public int quot;
public int rem;
}

public static class Utility
{   public static DivInt Div(this int dividee, int divisor)
{   int quot;
int rem;
quot = Math.DivRem(dividee, divisor, out rem);

//always round down
if(rem < 0)
{   quot--;
rem += divisor;
}
return new DivInt{quot = quot, rem = rem};
}
}

Could be used in some way like:
int quotient;
int remainder;
if (true)
{   var divResult = (x + y).Div(ASlowFunction());
quotient = divResult.quot;
remainder = divResult.rem;
}


If you say it sucks that one has to declare an utility class just 
to be nominally object-oriented, I agree.

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/16/2018 02:35 PM, Tony wrote:

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big on 
extension methods. Also tango uses object oriented console IO, while 
phobos and .net framework use procedural style for it.


I thought C# was like Java and does not allow free procedures. Can you 
give an example of C# procedural-style IO?




It doesn't (last I used it), buy you CAN mark individual member 
functions to be usable UFCS-like. IIRC, I think it might have to be 
static member function.


It's been awhile, so I don't remember it exactly, but it's something 
like this:


class Bar {}

class Foo {
static void SomeFunc(extention Bar bar, int num) {...}
}

class MyApp {
static void Run() {
Bar bar = new Bar();
bar.SomeFunc(2);
}
}

Re: Vision document for H1 2018

[Tony via Digitalmars-d-announce]

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:
Are you sure that you are talking about phobos and not tango? 
:)

I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big 
on extension methods. Also tango uses object oriented console 
IO, while phobos and .net framework use procedural style for it.


I thought C# was like Java and does not allow free procedures. 
Can you give an example of C# procedural-style IO?

Re: Vision document for H1 2018

[David Nadlinger via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
You have to remember that the really big first client of 
betterC(++) was DMD, porting DMD from C++ was a big 
undertaking. Right now both DMD and LDC use a form of betterC, 
so it is critical to have it finalized.


This is entirely wrong. DMD and LDC rely extern(C++), but this 
has nothing to do with -betterC whatsoever.


Both compilers link and initialise the runtime as normal (and 
then disable the GC at runtime).


 — David

Re: Vision document for H1 2018

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/12/18 10:57 AM, Void-995 wrote:

On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:

On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:
Now, I actually understand ranges and am very glad that they're 
there, but as a D newbie, they were annoying, because they were 
unfamiliar.


Ranges are D's monads. The only thing missing is the burrito tutorials.


I always thought the best spice in D is UFCS. If only there would be one 
for local symbols (but that needs either foundation's decision or I need 
to write my first DIP and do something instead of just crying silently 
into my sleeve).


alias I(alias X) = X;

void main()
{
   int y = 5;
   int bar(int x) { return y * x; }
   // auto z = 6.bar; // error
   auto z = 6.I!bar; // OK
}

https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

-Steve

Re: Vision document for H1 2018

[Kagamin via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big 
on extension methods. Also tango uses object oriented console IO, 
while phobos and .net framework use procedural style for it.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 16 March 2018 at 07:58:33 UTC, Dmitry Olshansky wrote:

Playing captain the obvious but this is COPY not slice.


Shh. Don't tell my customers that.



D had slices since 2000s, pointing to any kind of memory.


Mmm..D showing off.. as always ;-)

Re: Vision document for H1 2018

[Walter Bright via Digitalmars-d-announce]

On 3/15/2018 3:48 AM, Radu wrote:
Lastly, the objective is a bit vague - there is no scope attached to it, maybe 
this needs clarifications. Even if it means fixing all the logged bugs related 
to it, it is a great step, at least for me.


For reference, here are all the betterC bugs:

https://issues.dlang.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED=betterC%2C%20_type=allwords_id=220294_format=advanced

If there are any betterC bugs filed in Bugzilla and not listed there, please tak 
them with the "betterC" keyword so they will be. Any unfiled bugs => file them, 
of course!

Re: Vision document for H1 2018

[Dmitry Olshansky via Digitalmars-d-announce]

On Friday, 16 March 2018 at 01:45:57 UTC, psychoticRabbit wrote:

On Thursday, 15 March 2018 at 18:39:08

public static class Utils
{
public static T[] Slice(this T[] arr, int start, int len)
{
T[] slice  = new T[len];
Array.Copy(arr, start, slice, 0, len);
return slice;
}
}


Playing captain the obvious but this is COPY not slice. Slices in 
D share underlying array, something that C# recently recognized 
as special Span class that may point to GC heap or off-heap 
memory.


D had slices since 2000s, pointing to any kind of memory.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 18:39:08 UTC, rumbu wrote:
My quote is out of context. Somebody asked surprised why C# 
developers are interested in D. For me (mainly a C# developer), 
this is the main reason: native compilation (and this includes 
memory management). I highlighted the fact that the C# team 
keep implementing D specific ideas in each new version, so 
don't be surprised if your list of D exclusive features becomes 
smaller with each new C# iteration. My complaint was the fact 
that D drops features or push them into library solutions.


That was me ;-)

Yeah..native compilation is so nice..it's hard to resist.
And so is a good GC implementation (does D have one of those ??)

btw. run your C# or Java program for long enough, and it's 
essentially native compiled anyway. When I run some of my java 
programs, I still don't know how 'native compilation' would make 
it go any faster (noticably). Same goes for my C# Windows Forms 
apps..they just fly...native compilation wouldn't add much.


btw C# has had slices since day 1. Just required an extra 
forklift or two - as opposed to taking it off the nearby shelf.


-
using System;
using System.IO;

public class Program
{
public static int Main()
{
int[] arr = { 1, 2, 3, 4, 5 };
int[] sliceOfArr = arr.Slice(2, 3);

Console.WriteLine(string.Join(", ", arr));
Console.WriteLine(string.Join(", ", sliceOfArr));

return 0;
}
}

public static class Utils
{
public static T[] Slice(this T[] arr, int start, int len)
{
T[] slice  = new T[len];
Array.Copy(arr, start, slice, 0, len);
return slice;
}
}

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 21:10:47 UTC, flamencofantasy wrote:

On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:

I doubt that this was the blocker because C# had 
ArraySegment since .net framework 2.0 (2006), which is 
exactly a slice, but doesn't have the syntactic sugar for it.


If it doesn't have the syntactic sugar how is it "exactly a 
slice"?


This was about the fact that slices were a stopper for a D .net 
implementation.


The direct translation of the code here 
(https://dlang.org/articles/d-array-article.html#introducing-slices) is:


int[] a = new int[5];
var b = new ArraySegment(a, 0, 2);
var c = new ArraySegment(a, 3, 2);
c[0] = 4;
c[1] = 5;
c.CopyTo(b);

Surprise, the a content is the same as in D - [4,5,0,4,5].

I will stop my fallacy here, I promise this is the last post 
bragging about array segments, I feel some tension piling up on D 
forums and I don't want to contribute to it. My mistake was the 
use of the word "exactly".

Re: Vision document for H1 2018

[flamencofantasy via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:

I doubt that this was the blocker because C# had 
ArraySegment since .net framework 2.0 (2006), which is 
exactly a slice, but doesn't have the syntactic sugar for it.


If it doesn't have the syntactic sugar how is it "exactly a 
slice"?




The current C# proposal introduces a syntactic sugar similar to 
D (using ":" instead of "..") and extends the concept to stack 
arrays, because ArraySegment was limited to managed arrays.


If it's limited to managed arrays how is it "exactly a slice"?

Please stop repeating this fallacy, I have already corrected you 
once in another thread where you made the same claim about 
ArraySegment. I am also a C# developer and I can assure you that 
ArraySegment has very little in common with a D slice.

It is a segment of an array of type T only! That's it!
You can't construct it from stack, static, native, memory-mapped 
or any other memory, and you can't coerce the type. Because it 
doesn't have the 'syntactic sugar' it is unusable for all 
practical purposes!

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 17:17:47 UTC, Dukc wrote:

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


I do write a commerical project in C#. But I have an opposite 
feeling: The day D will easily compile to Javascript and be 
able to fully interface with it, my wish to use C# will drop 
pretty much instantly. I'm not even sure I would choose C# over 
-BetterC D!


It can already compile to Javascript using LDC/Emscripten, 
which is impressive, but you cannot interface with its strings 
and classes without glue code, except perhaps with some 
trickery. I have already tried doing some but so far for no 
avail.


And that's not to say that C# would be a bad language. I didn't 
hesistate to pick it over writing Javascript directly, and I 
don't think Java or Python would be superior for my tastes 
either. But it still isn't even a close match against D.


First, C# feels like it's hiding details from me, it kind of 
wants to maintain an ivory tower illusion. It's very hard, if 
possible at all, to control memory management. Libraries often 
feel like they're dependant on IDE (Visual Studio), not just 
the language.


Second, iterating in C# feels last-century standard. I like 
LINQ, but it still is like Phobos with only forward ranges, 
strange names and no thought put on avoiding needless heap 
allocations. And it's foreach loop can't iterate by ref, which 
means I often tend to iterate as if I was using C.


Third, expressive power suffers alot from lack of powerful 
templates, Voldemort types and var keyword being much more 
constrained in use than auto.


My quote is out of context. Somebody asked surprised why C# 
developers are interested in D. For me (mainly a C# developer), 
this is the main reason: native compilation (and this includes 
memory management). I highlighted the fact that the C# team keep 
implementing D specific ideas in each new version, so don't be 
surprised if your list of D exclusive features becomes smaller 
with each new C# iteration. My complaint was the fact that D 
drops features or push them into library solutions.

Re: Vision document for H1 2018

[Dukc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


I do write a commerical project in C#. But I have an opposite 
feeling: The day D will easily compile to Javascript and be able 
to fully interface with it, my wish to use C# will drop pretty 
much instantly. I'm not even sure I would choose C# over -BetterC 
D!


It can already compile to Javascript using LDC/Emscripten, which 
is impressive, but you cannot interface with its strings and 
classes without glue code, except perhaps with some trickery. I 
have already tried doing some but so far for no avail.


And that's not to say that C# would be a bad language. I didn't 
hesistate to pick it over writing Javascript directly, and I 
don't think Java or Python would be superior for my tastes 
either. But it still isn't even a close match against D.


First, C# feels like it's hiding details from me, it kind of 
wants to maintain an ivory tower illusion. It's very hard, if 
possible at all, to control memory management. Libraries often 
feel like they're dependant on IDE (Visual Studio), not just the 
language.


Second, iterating in C# feels last-century standard. I like LINQ, 
but it still is like Phobos with only forward ranges, strange 
names and no thought put on avoiding needless heap allocations. 
And it's foreach loop can't iterate by ref, which means I often 
tend to iterate as if I was using C.


Third, expressive power suffers alot from lack of powerful 
templates, Voldemort types and var keyword being much more 
constrained in use than auto.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 12:23:19 UTC, Kagamin wrote:


No, FWIW phobos uses more or less the same programming 
solutions as .net framework, the claim that they are different 
is an uninformed opinion.


Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.

Re: Vision document for H1 2018

[Kagamin via Digitalmars-d-announce]

On Monday, 12 March 2018 at 03:31:36 UTC, Laeeth Isharc wrote:

C# slices look great.


Dunno, when I wanted a slice in C#, I wrote a prettier one. C# 
could get stuff done 20 years ago already, ugly slices and native 
compilation won't add anything to it.


If Phobos looks like a mess to C# programmers, so much the 
worse for C# programmers.


No, FWIW phobos uses more or less the same programming solutions 
as .net framework, the claim that they are different is an 
uninformed opinion.

Re: Vision document for H1 2018

[Radu via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:
First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address.


What is that issue? Runtime? It can be solved with minimal 
runtime that one can write in an evening, compare it to betterC 
effort that has no end in sight.


Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet.


I'm afraid a sufficient option for them is proper C++ superset, 
betterC is only the first excuse, but not last.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise.


FWIW DLL support was always good enough for me.


It is much more than runtime or no runtime.

First of all, that goal (better interoperability) has been on the 
foundation priority list for several years, it is about time to 
"finish it up".


You have to remember that the really big first client of 
betterC(++) was DMD, porting DMD from C++ was a big undertaking. 
Right now both DMD and LDC use a form of betterC, so it is 
critical to have it finalized.


Second, it is a really good tool for validating a constraint 
environment, running D code with minimal runtime and compiler 
guarantees is very good thing to have in a system level 
programming language.


Third, since it was introduced, it really helped better 
abstracting compiler internals and removing dependencies between 
compiler and runtime. People don't solve problems they don't 
have, hence introducing a new restriction added some stress that 
shaped a better version of D. As stated, D is a *system level 
programming language*, this means that ultimately needs to offer 
tools for embedded developers and OS kernel driver writers. 
betterC is one of those tools, and ultimately is part of the 
philosophy of pay-as-you-go, or a driving force to be better at 
it. Also, I think it fits nicely into "turtles all the way down" 
approach, as it makes the language orthogonal and more glued 
together vs. offering some vague advice on how to approach 
constraint systems, it provides rules and methods of enforcement.


Lastly, the objective is a bit vague - there is no scope attached 
to it, maybe this needs clarifications. Even if it means fixing 
all the logged bugs related to it, it is a great step, at least 
for me.

Re: Vision document for H1 2018

[timotheecour via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:
First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address.


What is that issue? Runtime? It can be solved with minimal 
runtime that one can write in an evening, compare it to betterC 
effort that has no end in sight.


Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet.


I'm afraid a sufficient option for them is proper C++ superset, 
betterC is only the first excuse, but not last.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise.


FWIW DLL support was always good enough for me.


indeed, fixing DLL support (eg on OSX, where they're broken) is 
arguably more important (and less effort, given the larger scope 
of betterC) than betterC, as you can integrate D and C (or C++) 
projects via DLL's.
Whereas betterC does solve integrating C/C++ with D (eg requires 
C++ code to be ported to D which betterC doesn't magically do)

Re: Vision document for H1 2018

[Kagamin via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:
First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address.


What is that issue? Runtime? It can be solved with minimal 
runtime that one can write in an evening, compare it to betterC 
effort that has no end in sight.


Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet.


I'm afraid a sufficient option for them is proper C++ superset, 
betterC is only the first excuse, but not last.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise.


FWIW DLL support was always good enough for me.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Tuesday, 13 March 2018 at 23:20:22 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/11/2018 11:31 PM, Laeeth Isharc wrote:


C# slices look great.


I wonder if that might open the door for D on the CLR. I know 
that was attempted once a long way back, but was deemed 
infeasible and abandoned. IIRC, inability to implement slices 
was the main blocker.


I doubt that this was the blocker because C# had ArraySegment 
since .net framework 2.0 (2006), which is exactly a slice, but 
doesn't have the syntactic sugar for it.


The current C# proposal introduces a syntactic sugar similar to D 
(using ":" instead of "..") and extends the concept to stack 
arrays, because ArraySegment was limited to managed arrays.


As I remember one of the main blockers was in fact the module 
system which does not map to the namespace concept in C#

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/11/2018 11:31 PM, Laeeth Isharc wrote:


C# slices look great.


I wonder if that might open the door for D on the CLR. I know that was 
attempted once a long way back, but was deemed infeasible and abandoned. 
IIRC, inability to implement slices was the main blocker.

Re: Vision document for H1 2018

[Meta via Digitalmars-d-announce]

On Tuesday, 13 March 2018 at 01:23:39 UTC, psychoticRabbit wrote:

hey... I have 25+ years experience as a systems administator.

i.e I'm very, very used to doing very complex things. complex, 
is my day at the office.


But even I couldn't get my head around how to compile D from 
source on Windows ;-)


I do have it compling just fine on my freebsd system, and 
multiple different linux's I use. But Windows? Forget it. 
Someone will need to explain in detail how that is actually 
done - I no longer have the patience for working that one out.


As a counterpoint, I _did_ manage to compile DMD, Phobos and 
Druntime on Windows as a lowly university student using only the 
instructions from the wiki, and I'm no genius. It _is_ possible 
and not very difficult as long as you follow the instructions to 
the letter.


Of course this was also before you needed to have HOST_DC defined 
in your path, and the repo layout was a bit different, but it's 
not an insurmountable problem. And if you run into problems, you 
can come here or go on IRC to ask for help.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Monday, 12 March 2018 at 19:09:42 UTC, Dennis wrote:

On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
This post may not be all that helpful, but I feel the need to 
voice the frustrations with my experience. Sorry for the 
pointless/off-topic rant.


Thank you for this post, I found this actually really 
insightful. I'm also (relatively) inexperienced, a Windows 
user, and I have time/motivation for contributing. Your post is 
very relatable to me. But while you actually tried to compile 
dmd, I kind of pushed it aside after seeing how much there is 
involved in setting it up, predicting a big hassle like you 
describe. I really wish it could be as simple as cloning the 
repository and running a command on Windows.


hey... I have 25+ years experience as a systems administator.

i.e I'm very, very used to doing very complex things. complex, is 
my day at the office.


But even I couldn't get my head around how to compile D from 
source on Windows ;-)


I do have it compling just fine on my freebsd system, and 
multiple different linux's I use. But Windows? Forget it. Someone 
will need to explain in detail how that is actually done - I no 
longer have the patience for working that one out.

Re: Vision document for H1 2018

[ag0aep6g via Digitalmars-d-announce]

On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
I wanted to try and add some colouring[2] to dmd's error 
messages (sounds easy enough right?), so I have a quick look 
and see all I need to do is add some backticks around certain 
parts of the error message[3, as an example]. So I add my 
backticks into one error I can easily trigger, build it using 
my powershell script, and then all I see is that an exception 
(I think it was actually a RangeError) was thrown, and the 
stack trace was just a bunch of addresses without any text. (I 
don't have that build of dmd.exe anymore, and most of dmd has 
been colourised by now, so I can't get an accurate copy-paste 
of what happened or try to reproduce it.)


I decided "that's not supposed to happen", and tried to 
colourise a few other error messages... but I got the exact 
same result. I try to take an already coloursised error 
message, copy and paste it to another file, and try again to no 
avail.


At that point I decided that it's probably yet another issue 
with my build environment that I'll have to try an work out, 
but if I can't even get something 'trivial' such as colouring 
in messages working without frustration, then I can't be 
bothered to put in any more effort with trying to do anything 
else (I'd rather not be stuck only being able to do 
documentation changes), since, at least in my experience, I'm 
probably just too inexperienced, and I just keep hitting road 
blocks and endless frustrations.


If all you did was adding backticks to error messages, you might 
have been hitting issue 18403 [1]. That bug caused Windows DMD to 
crash whenever it tried printing a colored error message. It's 
very possible that you did nothing wrong, and you just had bad 
luck.


When you can't make sense of something like that, posting here in 
the forum is often worthwhile (Learn or General, though; not 
Announce). It's still pretty common that newcomers find bugs. 
More experienced members of the community can help determine if 
you're hitting one. If it's not a bug, they can help fixing 
things on your end.



[1] https://issues.dlang.org/show_bug.cgi?id=18403

Re: Vision document for H1 2018

[Dennis via Digitalmars-d-announce]

On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:
This post may not be all that helpful, but I feel the need to 
voice the frustrations with my experience. Sorry for the 
pointless/off-topic rant.


Thank you for this post, I found this actually really insightful. 
I'm also (relatively) inexperienced, a Windows user, and I have 
time/motivation for contributing. Your post is very relatable to 
me. But while you actually tried to compile dmd, I kind of pushed 
it aside after seeing how much there is involved in setting it 
up, predicting a big hassle like you describe. I really wish it 
could be as simple as cloning the repository and running a 
command on Windows.

Re: Vision document for H1 2018

[SealabJaster via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:
What could be done from your perspective to make the setup 
easier?


(This is from the perspective of a novice programmer, who hasn't 
really interacted with open source projects much)


When I first tried to compile dmd+druntime+phobos quite a while 
ago, I found the information on the wiki about building on 
windows[1] pretty unhelpful (in fact I never managed get all 3 to 
compile properly), though that seems to have gotten a lot better 
now (especially that it tells you how to structure your 
directories, which from what I remember you just had to piece 
together and guess from what the wiki commands were doing 
originally). Luckily the two contributions I made back then 
didn't require me to actually have any of that working...


As a spoiled Windows user, I like convenience, and I like things 
being easy to do. For me, trying to simply build everything was a 
frustrating task that took up a few days of time (reminder, this 
*was* quite a bit ago before the Windows part of the wiki was 
updated, and I was/still am pretty new to working on projects 
that aren't my own).


One of the more frustrating yet annoyingly simple issues I was 
having was that the version of Make in my PATH (GNU Make at a 
guess) wasn't able to use win32.mak, which led to me getting 
confused and frustrated for a day or two before I figured 
out(can't remember how exactly) that I had to use Digital Mars' 
make... I don't think there's any clear text on the wiki that 
says "For Windows, you *need* to use Digital Mars' make to use 
win32.mak".


After I changed to using Digital Mars' Make, I ran into another 
annoying but very simple issue. The wiki says to use "make 
-fwin32.mak release", ok fine:

```
PS D:\Coding\D\Tools\dlang\dmd2\src\dmd\src> make -fwin32.mak 
release

Error: can't read makefile 'win32'
```

Turns out all I had to do was put a space between '-f' and 
'win32.mak'. Thankfully I only wasted about 30mins at most 
figuring that out. Didn't make it any less frustrating though.


Around the time I was adding std.traits.isCopyable to Phobos, I 
thought to myself "Maybe I can at least get the testing stuff to 
work!"... So I go to the wiki and see something along the lines 
of "make -fposix.mak std/traits.test" and thought that win32.mak 
would have the same functionality - however it doesn't, and only 
has a target to unittest the entirety of Phobos, giving me the 
impression Windows seems to just be a footnote compared to Posix 
platforms. ('make -f win32.mak dscanner' is another example). For 
isCopyable, it was easier for me to just develop it in it's own 
file, move it into std.traits, and hope the auto-tester could 
build it.


I think I did manage to get "make -f win32.mak unittest" (for 
phobos) to work at one point, but a test that included sockets 
failed (I think it was a test between paired sockets, and one of 
them timed out). This of course made it feel pointless to use, 
since it'd just always fail.


One last example of a very tiny issue, is that for DMD, the 
makefiles you use to build it are in, for example 
'dmd2/src/dmd/src/win32.mak', instead of 'dmd2/src/dmd/win32.mak' 
making it a bit inconsistent with 
druntime('dmd2/src/druntime/win32.mak') and 
phobos('dmd2/src/phobos/win32.mak').


There were certainly a bunch more tiny issues and bumps I had 
when trying to build things my first time around that I can't 
remember, whether it be due to my own incompetency or due to 
issues with the wiki/win32.mak, and after the two changes I made 
to Phobos I just had no will to continue, and gave up for a while.


I genuinely feel it'd have been easier for me to just load up 
Ubuntu on a VM and go from there, instead of developing on 
Windows.


One thing I'd would have liked, as a Windows/lazy user, and as a 
beginner, is a single file/tool that would've helped me setup and 
build everything (like that setup.sh you linked, except it's a 
Bash script...)


And in a perfect world, we wouldn't need 3 different makefiles 
(win32.mak, win64.mak, and posix.mak), but instead there'd either 
be a single makefile, or some other tool is used to provide a 
cross-platform way to access the current features of posix.mak. I 
understand that this isn't an easy issue to solve though, hence 
the "in a perfect world" (you could also say, in a perfect world, 
everyone develops on a Posix platform! ;)).


Then I recently gathered up the will to want to contribute again, 
and decided to make a Powershell script that does exactly that 
for me which actually turned out to work pretty well, I can build 
all 3 projects without too much hassle, and without having to 
remember all those annoying pitfalls e.g. "-f win32.mak instead 
of -fwin32.mak", something I would've liked to have in the first 
place. Or so I thought.


I wanted to try and add some colouring[2] to dmd's error messages 
(sounds easy enough right?), so I have a quick look and see all I 
need to do is add some 

Re: Vision document for H1 2018

[Void-995 via Digitalmars-d-announce]

On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:
On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis 
wrote:
Now, I actually understand ranges and am very glad that 
they're there, but as a D newbie, they were annoying, because 
they were unfamiliar.


Ranges are D's monads. The only thing missing is the burrito 
tutorials.


I always thought the best spice in D is UFCS. If only there would 
be one for local symbols (but that needs either foundation's 
decision or I need to write my first DIP and do something instead 
of just crying silently into my sleeve). I really found few 
usages for that, like using methods of class on data types that 
stored inside ranges inside that class. Image data being glued to 
each other in different lists like data in SQL among tables. Not 
like an show stopper, but after I rewrote part of my application 
into D - a lot of stuff become so much more elegant and easy to 
read and maintain. UFCS would help with readability in cases like 
I had tons.

Re: Vision document for H1 2018

[bachmeier via Digitalmars-d-announce]

On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:
Now, I actually understand ranges and am very glad that they're 
there, but as a D newbie, they were annoying, because they were 
unfamiliar.


Ranges are D's monads. The only thing missing is the burrito 
tutorials.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote:


I'm comparing two open source projects, both hosted on github. 
Both available in the same supermarket. It seems that one of 
them is easy to reach to, the other one is on the top shelf and 
you need a forklift to reach it. And when you bring the 
forklift, you find out that you need two additional excavators 
running on a special kind of fuel which is not available in 
your country.


I'm comparing the contributing experience, because almost every 
time when someone complains about something, is invited to 
contribute himself.


yeah, but if you know in advance, that you need a fork lift to 
reach it, and that you'll also need two additional excavators 
running on a special kind of fuel, which is not available in your 
country...then..and only then.. are your expectations in line 
with reality ;-)


but people come to D, thinking they can just walk over to the 
shelf and take it.

(because that's often what they are used to).

Some of us are actually used to the very opposite - i.e you 
always have make that extra effort, even to do the most simple 
things. But that effort just seems normal to us.


I agree, there needs to be more middle ground, which both types 
will benefit from in the end.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Monday, 12 March 2018 at 04:48:43 UTC, psychoticRabbit wrote:



but I think comparing things in the C# world, to things in the 
D world, does not make a lot of sense, really.


It's like comparing my local corner shop to some worldwide 
supermarket chain.




I'm comparing two open source projects, both hosted on github. 
Both available in the same supermarket. It seems that one of them 
is easy to reach to, the other one is on the top shelf and you 
need a forklift to reach it. And when you bring the forklift, you 
find out that you need two additional excavators running on a 
special kind of fuel which is not available in your country.


I'm comparing the contributing experience, because almost every 
time when someone complains about something, is invited to 
contribute himself.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote:


You don't need to have subsystem for Linux to use bash.  Just 
the standard git client for Windows is enough.




Happy to find out about this. It's not like using git bash 
everyday on Windows to know this by default.


sh setup.sh
[...]
make -> Command error: undefined switch '-C'

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Monday, 12 March 2018 at 03:37:11 UTC, Laeeth Isharc wrote:


cd test
make all -j8
Command error: undefined switch '-j8'


Why are you adding -j8 ? Does it say to do so in the 
instructions ? Try without it.  (I can't test here as typing 
from my phone).


https://wiki.dlang.org/DMD_development

Of course, it works without the -j8 switch, but the documentation 
doesn't say that multiple threads option is only available on 
Linux.

Re: Vision document for H1 2018

[Seb via Digitalmars-d-announce]

On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote:
On Monday, March 12, 2018 03:37:11 Laeeth Isharc via 
Digitalmars-d-announce wrote:

On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:
> [...]

Why are you adding -j8 ? Does it say to do so in the 
instructions ? Try without it.  (I can't test here as typing 
from my phone).


When dealing with building on Windows, it would definitely pay 
to read the instructions and not assume anything about make, 
since unfortunately, the Windows build uses the digital mars 
make, which is severely limited in comparison to the BSD make 
or GNU make.


- Jonathan M Davis


That's only partially true and the reason for the error. GNU/BSD 
make is required to run the DMD testsuite.
BTW removal of DigitalMars Make has been officially approved 
since a long time, but it's blocked since it's so hard to make 
changes to the auto-tester.

Re: Vision document for H1 2018

[Jonathan M Davis via Digitalmars-d-announce]

On Monday, March 12, 2018 03:31:36 Laeeth Isharc via Digitalmars-d-announce 
wrote:
> If Phobos looks like a mess to C# programmers, so much the worse
> for C# programmers.  However I doubt they this is true in the
> general case.  It's better in many ways, but different and
> unfamiliar and everything unfamiliar is disconcerting in the
> beginning.

Yeah, I remember when I was first dealing with D years ago, and the range
stuff that was in there was totally unfamiliar, and it annoyed me, because I
just wanted the iterators that I was familiar with so that I could easily do
what I wanted to do. Granted, it was worse to figure all of that out then,
since the documentation was much worse (e.g. at the time, there was a
compiler bug that made it so that auto return functions did not show up in
the documentation, so all of std.algorithm explicitly listed the return
types, making it downright scary), but still, at the time, I just didn't
want to deal with figuring out the unfamiliar concept, so it annoyed me.
Now, I actually understand ranges and am very glad that they're there, but
as a D newbie, they were annoying, because they were unfamiliar. I think
that I'd approach it all very differently now, since at the time, I was in
college and just generally a far less experienced programmer, but I think
that many of us tend to look for what we expect when learning a new language
or library, and when that's not what we get, it can be disconcerting to
begin with.

Phobos is very unique in its approach with ranges, likely making it a major
learning experience for anyone from any language, but AFAIK, the only
language with a comparable approach in its standard library is C++, and I'd
definitely expect it to be somewhat alien to the average C# or Java
programmer - at least to begin with. D does things differently, so anyone
learning it is just going to have to expect to deal with a learning curve.
How steep a curve that is is going to depend on the programmer's experience
and background, but it's going to be there regardless.

- Jonathan M Davis

Re: Vision document for H1 2018

[Jonathan M Davis via Digitalmars-d-announce]

On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce 
wrote:
> On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:
> > On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:
> >> [...]
> >
> > Yes, I'm the typical lazy convenient Windows user scared of the
> > terminal window.
> >
> >> [...]
> >
> > I am happy for Posix users. Theoretically the process is the
> > same on Windows.
> >
> >> [...]
> >
> > This will need Linux subsystem as a Windows feature installed.
> > Bash scripts do not work on Windows. Or other third party
> > applications that are not listed as prerequisites on wiki.
> >
> >> [...]
> >
> > make -fwin32.mak release
> > Error: don't know how to make 'release'
> >
> > Ok, let's skip this, make it without "release".
> >
> > Now test it:
> >
> > cd test
> > make all -j8
> > Command error: undefined switch '-j8'
>
> Why are you adding -j8 ? Does it say to do so in the instructions
> ? Try without it.  (I can't test here as typing from my phone).

When dealing with building on Windows, it would definitely pay to read the
instructions and not assume anything about make, since unfortunately, the
Windows build uses the digital mars make, which is severely limited in
comparison to the BSD make or GNU make.

- Jonathan M Davis

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


Hey.. I feel your pain.. I like things to be easy too ;-)

but I think comparing things in the C# world, to things in the D 
world, does not make a lot of sense, really.


It's like comparing my local corner shop to some worldwide 
supermarket chain.


What's the point in going into the local corner shop and 
complaing that they don't stock this or that, but the supermarket 
down the road does. Or complaining that they charge $4 for a loaf 
of bread, when down the road at the supermarket it only costs 
$2.50.


You have to compare apples with apples, not apples with shiny red 
toffee apples ;-)

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

[...]


Yes, I'm the typical lazy convenient Windows user scared of the 
terminal window.



[...]


I am happy for Posix users. Theoretically the process is the 
same on Windows.



[...]


This will need Linux subsystem as a Windows feature installed. 
Bash scripts do not work on Windows. Or other third party 
applications that are not listed as prerequisites on wiki.



[...]


make -fwin32.mak release
Error: don't know how to make 'release'

Ok, let's skip this, make it without "release".

Now test it:

cd test
make all -j8
Command error: undefined switch '-j8'


Why are you adding -j8 ? Does it say to do so in the instructions 
? Try without it.  (I can't test here as typing from my phone).

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


And personally, depending on the problem, C# is better to 
program in than D. I still don't know why C# programmers are 
willing to give up C# and prefer to use D.

C# is vastly surperior for what it does.



Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.


I suppose that every C# programmer is enthusiastic on the first 
contact with the D language, but fails to keep his enthusiasm 
when he sees Phobos. C# programmer's mind is locked in the OOP 
world and Phobos looks like a mess from his point of view.


The problem is that D stagnates and in the same time C# 
evolves. Sometimes I feel like the C# language team is using D 
as inspiration for the new features, starting with C# 7.0, a 
lot of D concepts were introduced in the language: local 
functions, '_' as digit separator, binary literals, ref 
returns, tuples, templates, immutability. Guess what the next 
version of C# has on the table: slices.


In the same time, D delegates new features (and sometime 
existing ones) to library implementation, instead of assume 
them in the language syntax.


My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


It's a good thing not bad that other languages are inspired by 
what works.  Languages aren't in a vicious battle to the death, a 
Hobbesian war of all against all.  If C# gets better, that's 
great!


I don't think D is stagnating at all - on the contrary, it's 
amazing to see the ecosystem flourishing, no matter where you 
look - documentation, adoption, libraries, commercial adoption.


I think it's reasonable to disagree with the strategic decision 
made to move capabilities from compiler to libraries.  But you 
really have to make an argument about why you disagree if you are 
you expect to be persuasive because there is a thought-through 
argument for the choices made, which I am sure you must be 
familiar with.


I don't think it matters much whether you are right about what 
happens to C# programmer interest in D dies as soon as C# native 
cross-platform is ready because D is quite an ambitious language 
and doesn't need to depend on adoption from any one community to 
continue growing at an impressive rate.  As it happens though, as 
an empirical matter I doubt it.


C# slices look great.  I wanted to use them for generating 
wrappers for our analytics.  Not that easy for that purpose, from 
what I could see.  Looks like the primitives are stack only, and 
I tried to figure out how to use them elsewhere and gave up 
because it wasn't that easy.


If Phobos looks like a mess to C# programmers, so much the worse 
for C# programmers.  However I doubt they this is true in the 
general case.  It's better in many ways, but different and 
unfamiliar and everything unfamiliar is disconcerting in the 
beginning.

Re: Vision document for H1 2018

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


Funnily enough, becoming a significant contributor to the 
ecosystem - compiler or Phobos - demonstrably does not require 
even a complete graduation from high school or any industrial 
programming experience.  I know of what I speak, but I don't say 
who as it's not for me to say.


I was in Munich over new year and I asked someone else who has 
been a star contributor how he got involved.  It was really easy 
for him to start contributing, so he did.  But different people 
find different things easy.


You don't need to have subsystem for Linux to use bash.  Just the 
standard git client for Windows is enough.


I agree the Windows experience could be easier upfront.  Still, 
it's better than it used to be and next year it will be better 
again.


You can't really compare the C# ecosystem to the D ecosystem 
because they are organised around different principles.  Yes, the 
pain is upfront with D, and it's not for everyone.  However on 
the basis of rational calculation the pain in learning something 
new is a small part of the total cost of the technology choice 
and for some people by far not the most relevant question.


And it's an advantage in hiring because the D community filters 
for people who have a tolerance for discomfort upfront.


It would be wonderful to be able to wave a wand and make all of 
life's little frustrations disappear.  But in my experience, 
that's not what is possible - one picks from the choices 
available and the new ones one thinks up.  People have a tendency 
to think that leadership has more power to just change things 
then is actually the case.


I'm going to be building standard developer images from scratch 
programmatically.  Transform froma Windows  ISO into  a VM 
image.Maybe I could open source those scripts and then it's 
easier to get to the bottom of any install and build problems and 
one can replicate difficulties.

Re: Vision document for H1 2018

[Frank Brassard via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.
As an aside, I had to translate a special-use decompression 
algorithm from C# to D, and it was a near seamless transition. 
I'm trying to persuade some of my C# compatriots to try D because 
of that experience.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

I assume you are using Windows?


Yes, I'm the typical lazy convenient Windows user scared of the 
terminal window.



Setup on Posix is really simple.
git clone all three repos + run make.


I am happy for Posix users. Theoretically the process is the same 
on Windows.




There's also a bash script to automate this:

https://github.com/dlang/tools/blob/master/setup.sh


This will need Linux subsystem as a Windows feature installed. 
Bash scripts do not work on Windows. Or other third party 
applications that are not listed as prerequisites on wiki.




From what I heard it's a bit tricky on Windows. I only tried 
with wine and that worked out-of-the-box for me. Execute the 
DMD installer, set PATH, DM_HOME and HOST_DC and then run the 
win32 makefiles work fine.


make -fwin32.mak release
Error: don't know how to make 'release'

Ok, let's skip this, make it without "release".

Now test it:

cd test
make all -j8
Command error: undefined switch '-j8'




What could be done from your perspective to make the setup 
easier?


From my perspective I would like to have an working setup, not 
necessary easier. But if interested, to contribute to C# 
compiler, you just need to open roslyn.sln in Visual Studio, make 
your modification, run the test suite, commit, you're done.

Re: Vision document for H1 2018

[Seb via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


Don't forget that "open source" != non-profit. For the C# 
compiler there's a dedicated team of full-time developers.


Also to be fair, the activity on dmd isn't that low either though 
the last week was a one with low-traffic:


https://github.com/dlang/dmd/pulse

Typically ~40 PRs get merged per PR for dmd alone:

https://auto-tester.puremagic.com/chart.ghtml?projectid=1

With druntime + phobos, it's a lot more.

The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


I assume you are using Windows?
Setup on Posix is really simple.
git clone all three repos + run make.

There's also a bash script to automate this:

https://github.com/dlang/tools/blob/master/setup.sh

From what I heard it's a bit tricky on Windows. I only tried with 
wine and that worked out-of-the-box for me. Execute the DMD 
installer, set PATH, DM_HOME and HOST_DC and then run the win32 
makefiles work fine.


What could be done from your perspective to make the setup easier?

Re: Vision document for H1 2018

[Aravinda VK via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last 
week 72 pull requests form 24 contributors were merged on 
~master. And this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is 
a no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh 
copy of dmd or phobos.


I contributed to phobos for the first time for the release 
2.079.0. Experience was smooth and also I learnt many new things 
from the review comments. I was able to follow wiki page to 
compile phobos or compile one specific module. Please let us know 
the issue faced, so that wiki can be improved.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:
And this clarifies the source of your confusion. The D 
programming language is an open source project, not a 
for-profit company. D is not the language you're looking for.


There are 3 years since C# is also open source project. Last week 
72 pull requests form 24 contributors were merged on ~master. And 
this is only for Roslyn (the C# compiler).


The difference (at least for me) is that contributing to C# is a 
no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh copy 
of dmd or phobos.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:


I am sure that lots of D members will be quick to point out, 
that C# is run by a commercial company and D has only open 
source contributors. Now why did you not contribute! /sarcasm




I'd like to point out, that C# is run by a commercial company and 
D has only open source contributors.


For that matter, so is Rust (a 1/2 billion $ organisation, at 
least), run by sjw's who will 'attack' (as opposed to 'point 
out') anyone that speaks out against anything. As for cross 
platform, have you tried running Rust in Windows XP?


Anyway.. I'm going back to the sandbox, to play with my own toys.

Re: Vision document for H1 2018

[bachmeier via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:

With the usual response here: "Why do you not fix it yourself 
or pay for it". Maybe because most people who come want to use 
the tools and be productive and not spend their time fixing up 
those tools.


I've never seen anyone write that. Most likely you saw someone 
post something that looks similar, but has a dramatically 
different meaning. The usual response is "If you want something 
done, you're going to have to do it yourself or pay someone to do 
it for you, or else it won't get done."


Its a mentality issue that some do not get here. In order to 
grow you need consumers for your product. If you force or whine 
to them to fix the issues, they leave. When they leave you lose 
potential growth. That loss in growth means losing potential 
members that can fix and want to fix the issues.


And this clarifies the source of your confusion. The D 
programming language is an open source project, not a for-profit 
company. D is not the language you're looking for.

Re: Vision document for H1 2018

[R via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
Because, even the language creators seem to not recognize this, 
D looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd 
without any (major) change.


Most people do not have issues with the core language of D. You 
can come from any of the above mentioned languages ( like C, C++, 
Rust, PHP, Python, Nim, ... ) and get going with D. That is what 
attracted me in the first place. The language looks good but the 
moment you actually start using D its issue after issue.


With the usual response here: "Why do you not fix it yourself or 
pay for it". Maybe because most people who come want to use the 
tools and be productive and not spend their time fixing up those 
tools.


Its a mentality issue that some do not get here. In order to grow 
you need consumers for your product. If you force or whine to 
them to fix the issues, they leave. When they leave you lose 
potential growth. That loss in growth means losing potential 
members that can fix and want to fix the issues.


One can call it selfish but every language is based upon this 
principle. No growth and community of lots of selfish users means 
no other members to fix the issues. It is the 9 Circles of Hell.


I suppose that every C# programmer is enthusiastic on the first 
contact with the D language, but fails to keep his enthusiasm 
when he sees Phobos. C# programmer's mind is locked in the OOP 
world and Phobos looks like a mess from his point of view.


+1!

It has the language mostly right but its everything around it 
that is simply a mess. When one compares that to Rust. They are 
not having constant discussion about replacing cargo ( as dub in 
D has issues ). They do not need to have multiple documentation 
generators. The cross platform is simple and fast. Same applies 
to Go. And C# ... Resources simple are more focused and enhance 
the whole platform as such. D is like a children sandbox where 
everybody is playing with their own toys. So when other complain 
about the mess of the playground, the responds by some is just as 
typical.



The problem is that D stagnates and in the same time C# evolves.


I am sure that lots of D members will be quick to point out, that 
C# is run by a commercial company and D has only open source 
contributors. Now why did you not contribute! /sarcasm


Sometimes I feel like the C# language team is using D as 
inspiration for the new features, starting with C# 7.0, a lot 
of D concepts were introduced in the language: local functions, 
'_' as digit separator, binary literals, ref returns, tuples, 
templates, immutability. Guess what the next version of C# has 
on the table: slices.


Yep ... Things are moving faster in the .net camp thanks to the 
focus on .net Core and the RyuJit.


Here is a fun one, with Blazer now being part of the official 
.net.


https://github.com/aspnet/blazor

Blazer = C# code runable in the browser using WebAssembly.

In the same time, D delegates new features (and sometime 
existing ones) to library implementation, instead of assume 
them in the language syntax.


My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


Personally i am waiting to see CoreRT finalized:

https://github.com/dotnet/corert

-> CppCodeGen/C++
-> RyuJIT codegen
-> Webasm

Its already working and getting better by the day.

Other languages are moving forwards at blazing speeds and D seems 
to put it priorities on adding new exiting features. Where as a 
large part of the outcry is the issues with the library, lacking 
editors support, cross platform issues, ...

Re: Vision document for H1 2018

[nkm1 via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


BetterC is probably mostly useful for writing libraries (that can 
be used from D
or other languages). So these 29% of respondents are perhaps more 
important

than just their percentage suggests.

Re: Vision document for H1 2018

[Joakim via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:
betterc is just another way of supporting that crowd..and it's 
a very big crowd.


Yeah, 29% of the crowd.


29% of the existing D crowd who answered the survey, which means 
around 150 people, or about how many download one compiler, dmd, 
in an average hour of the day:


http://erdani.com/d/downloads.daily.png

Meanwhile, Walter wrote a blog post about his betterC efforts 
last year, and it was the third-most liked link from dlang.org on 
reddit over the last year, with 226 net likes:


https://www.reddit.com/domain/dlang.org/top/?sort=top=year

No. 2?  Another article about using D without the GC.

Now, as I've said on the forum several times, I personally don't 
care for @nogc or betterC: I don't use them.  I'm sure many 
existing D users don't either.  However, as those reddit stats 
show, there is interest from _outside_ the D community for them.


When it comes to strategic decisions like this to bring in new 
users from outside the community, you cannot depend on polling 
users within the community to figure it out.  Argue against 
betterC really bringing in new users if you want, but arguing 
that it doesn't help existing users is missing the point.


I'm not sure how successful betterC will be in pulling in those 
users, as I'm not a C/C++ programmer and don't know what they 
want, but the popularity of those links suggests the D foundation 
is on the right track.


Your problem is not betterc, but something else. So focus on 
that instead.


You're right, my problem isn't BetterC, it's the fact that 
Foundation can't get its priorities right. BetterC is a symptom.


The Foundation's priorities are not simply serving the existing 
users but growing the userbase.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
My opinion is that the day when C# will compile to native (on 
any platform), the C# developer interest in D will drop 
instantly.


OT:

Interestingly, my uni is still stuck in the OOP paradigm, and is 
now teaching intro to OOP using .NET Core, cause it's now cross 
platform, and people can also used VS code, which also cross 
platform.


but running > dotnet myprogram (.dll)

is just an awful experience ;-)

although, that's how java works to.. and java is probably the 
most widely used language of all.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


And personally, depending on the problem, C# is better to 
program in than D. I still don't know why C# programmers are 
willing to give up C# and prefer to use D.

C# is vastly surperior for what it does.



Because, even the language creators seem to not recognize this, D 
looks like C# with *native compilation*, the syntax is 95% 
identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd without 
any (major) change.


I suppose that every C# programmer is enthusiastic on the first 
contact with the D language, but fails to keep his enthusiasm 
when he sees Phobos. C# programmer's mind is locked in the OOP 
world and Phobos looks like a mess from his point of view.


The problem is that D stagnates and in the same time C# evolves. 
Sometimes I feel like the C# language team is using D as 
inspiration for the new features, starting with C# 7.0, a lot of 
D concepts were introduced in the language: local functions, '_' 
as digit separator, binary literals, ref returns, tuples, 
templates, immutability. Guess what the next version of C# has on 
the table: slices.


In the same time, D delegates new features (and sometime existing 
ones) to library implementation, instead of assume them in the 
language syntax.


My opinion is that the day when C# will compile to native (on any 
platform), the C# developer interest in D will drop instantly.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 05:41:02 UTC, Dylan Graham wrote:


I regret some of things I said. I'm sorry for any offence 
caused, specifically towards members of the DLF.




I don't think you need to regret saying anything. You've 
demonstrated a willingness to engage in a conversation that we 
can *all* learn from.


I also doubt anyone actually got offended ;-)

.. we're all pretty strong minded here.

But I get back to my point about "programmer" portability.

Other developers of newer languages just don't seem to get that.

And it's hardly surprising that D would be focused in some way, 
on languages used by the vast majority of programmers 
(C/C++/Java/C#... and dare I say it..python)


That is D's great strength. (and betterc is just a part of it - 
and not one that particulary interests me).


Because D resources are rather contstrained, betterc gets more 
push back than it really should. But the main take away point I 
get from that vision statement, is a greater focus on increasing 
contributions - which is really what D needs more than anything 
(apart from a correct and complete language specification).

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address. 
Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet. Heck, *I'm* a 
C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to 
be multi-purpose. Because of that, D users (and potential D 
users) are *highly* diverse. Everybody here has their own 
use-cases, their own needs and priorities, and their own list 
of things they want fixed yesterday.


In a group this diverse, there just simply *isn't* much on the 
D wishlist that's crucially important to a *majority*, because 
we all need completely different things.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise. Some of the things 
most important to me for D to improve you probably wouldn't 
care one bit about - and that's ok. We work on different sorts 
of things.


Improved betterC is something I would find very nice if I ever 
have time or opportunity to get back into embedded software. 
But outside of that, yea, it doesn't impact me much more than 
it does for you.


But here's the rub: In this crowd here, probably far more than 
most languages, we all have such wildly varying needs that 29% 
*is* what qualifies as significant around here. Most wishlist 
items are going to have similarly non-majority numbers. And 
they have to pick *something* to focus on. Luckily, as the 
vision document clearly states, there are *several* such 
"somethings" the dlang foundation is committing to working on.


You do have a good point. One of my likes for D was its 
flexibility, so it was very hypocritical of me to argue for what 
I did.


I regret some of things I said. I'm sorry for any offence caused, 
specifically towards members of the DLF.


I wish that DLL support was referenced in the vision document. I 
actually like most of what's been said in it, especially the 
@safe, @nogc and editor support. I also see Benjamin Thaut (if 
you're reading this - awesome work!) making progress on DLL 
support, I just wish the foundation could help him out a bit.

Re: Vision document for H1 2018

[Timothee Cour via Digitalmars-d-announce]

IMO this should be the priority:

1. blockers (things that can't be worked around at all or not without
jumping through a lot of hoops)
2. everything else

dmd still doesn't support shared libraries on OSX (cf
https://issues.dlang.org/show_bug.cgi?id=12190)

That prevents a whole category of use cases (eg D plugins called from
C++ or from D)





On Sat, Mar 10, 2018 at 8:06 PM, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce  wrote:
> On 03/10/2018 05:47 AM, Dylan Graham wrote:
>>
>> On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
>>>
>>>
>>> According to the State of D Survey, 71% of the respondents don't care
>>> about betterC. Why is betterC on the priority list?
>>
>>
>> Yeah. Why should D worry about tying itself into C when it can't even
>> interface with itself through DLLs?
>
>
> First of all, betterC is about far more than interfacing with C. In fact,
> interop with C isn't really what betterC is about at all - that's a separate
> aspect of the language. (And those C/C++ users who still haven't come to D -
> for many of them the holdout is *because* of the issues betterC aims to
> address. Make no mistake, for all the stockholm syndrome in the C and C++
> worlds, there *are* a lot people openly wanting to jump ship but don't have
> a sufficient option yet. Heck, *I'm* a C/C++ -> D convert.)
>
> But more importantly:
>
> The D language itself is specifically designed and intended to be
> multi-purpose. Because of that, D users (and potential D users) are *highly*
> diverse. Everybody here has their own use-cases, their own needs and
> priorities, and their own list of things they want fixed yesterday.
>
> In a group this diverse, there just simply *isn't* much on the D wishlist
> that's crucially important to a *majority*, because we all need completely
> different things.
>
> Personally, better DLL support have little to no impact on me. Obviously it
> does for you, and I sympathise. Some of the things most important to me for
> D to improve you probably wouldn't care one bit about - and that's ok. We
> work on different sorts of things.
>
> Improved betterC is something I would find very nice if I ever have time or
> opportunity to get back into embedded software. But outside of that, yea, it
> doesn't impact me much more than it does for you.
>
> But here's the rub: In this crowd here, probably far more than most
> languages, we all have such wildly varying needs that 29% *is* what
> qualifies as significant around here. Most wishlist items are going to have
> similarly non-majority numbers. And they have to pick *something* to focus
> on. Luckily, as the vision document clearly states, there are *several* such
> "somethings" the dlang foundation is committing to working on.

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents don't care 
about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it can't even 
interface with itself through DLLs?


First of all, betterC is about far more than interfacing with C. In 
fact, interop with C isn't really what betterC is about at all - that's 
a separate aspect of the language. (And those C/C++ users who still 
haven't come to D - for many of them the holdout is *because* of the 
issues betterC aims to address. Make no mistake, for all the stockholm 
syndrome in the C and C++ worlds, there *are* a lot people openly 
wanting to jump ship but don't have a sufficient option yet. Heck, *I'm* 
a C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to be 
multi-purpose. Because of that, D users (and potential D users) are 
*highly* diverse. Everybody here has their own use-cases, their own 
needs and priorities, and their own list of things they want fixed 
yesterday.


In a group this diverse, there just simply *isn't* much on the D 
wishlist that's crucially important to a *majority*, because we all need 
completely different things.


Personally, better DLL support have little to no impact on me. Obviously 
it does for you, and I sympathise. Some of the things most important to 
me for D to improve you probably wouldn't care one bit about - and 
that's ok. We work on different sorts of things.


Improved betterC is something I would find very nice if I ever have time 
or opportunity to get back into embedded software. But outside of that, 
yea, it doesn't impact me much more than it does for you.


But here's the rub: In this crowd here, probably far more than most 
languages, we all have such wildly varying needs that 29% *is* what 
qualifies as significant around here. Most wishlist items are going to 
have similarly non-majority numbers. And they have to pick *something* 
to focus on. Luckily, as the vision document clearly states, there are 
*several* such "somethings" the dlang foundation is committing to 
working on.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 02:02:15 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:


i.e. How can the D Foundation encourage new additional 
resoures to focus on things that also matter to the community.





and btw. the mention about strengthing the use of DIPS, does 
just that.


there are many improvement to 'process' that can be done to 
encourage more people to contribute to D.


This is not about betterc at all, really.


Then it does seem like things will improve. I hope there will be 
more surveys in the future and I'm very happy with the new DIP 
process.


My original argument was that BetterC is a mismanagement of 
resources, and I still stand by that.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:


i.e. How can the D Foundation encourage new additional resoures 
to focus on things that also matter to the community.





and btw. the mention about strengthing the use of DIPS, does just 
that.


there are many improvement to 'process' that can be done to 
encourage more people to contribute to D.


This is not about betterc at all, really.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote:


That sentence was to counter psychoticRabbit. I didn't mean it 
literally. If you've read my earlier posts, it's not BetterC I 
have an issue with, it's the allocation of time.




Well that should have been the basis of your original argument.

i.e. How can the D Foundation encourage new additional resoures 
to focus on things that also matter to the community.


Instead, you started by attacking the D Foundation for allocating 
resources to betterc.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:50:22 UTC, Mike Parker wrote:

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:



The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


Please read my post from earlier:

https://forum.dlang.org/post/chsqspkoxbcdqjcqb...@forum.dlang.org

The survey *will* have an influence on what gets priority in 
the future, but it certainly can't be seen as representing the 
majority of D programming interests.




Good. That's definitely for the better.



It is not a dictatorship (read this sentence over and over 
till you get it).


No one is forcing you to use BetterC and its existence doesn't 
change anything about how you can use the language. Obviously, 
there are a number of areas that need work. The survey can help 
decide which of those to put resources into first, but it 
doesn't mean that other things deemed important have to be 
dropped.


That sentence was to counter psychoticRabbit. I didn't mean it 
literally. If you've read my earlier posts, it's not BetterC I 
have an issue with, it's the allocation of time.


As you said, hopefully the survey will help clear up these issues 
with D.

Re: Vision document for H1 2018

[Mike Parker via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:



The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


Please read my post from earlier:

https://forum.dlang.org/post/chsqspkoxbcdqjcqb...@forum.dlang.org

The survey *will* have an influence on what gets priority in the 
future, but it certainly can't be seen as representing the 
majority of D programming interests.





It is not a dictatorship (read this sentence over and over till 
you get it).


No one is forcing you to use BetterC and its existence doesn't 
change anything about how you can use the language. Obviously, 
there are a number of areas that need work. The survey can help 
decide which of those to put resources into first, but it doesn't 
mean that other things deemed important have to be dropped.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:46:09 UTC, Dylan Graham wrote:


Rust was more popular and who could use that?
Rust is popular because of its ideas, not because it pandered.



I don't see "programmer" portability as being pandering.

It common sense.

Rust is good, in that it seeks to do something different. I like 
that.


But I live in the real world, and need to switch between 
languages often.


Language theory is nice and all that, but "programmer" 
portability is paramount for me.. not popular ideas.


And Rust is popular... with Rust programmers.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:41:33 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:


I'm not sure what you mean at that last sentence.


I mean, cause D is so compatible with C/C++/Java/C# - that you 
can easily switch between them.


Whereas as Go and Rust have their own thing going, making those 
languages really difficult in terms of "programmer" portability.


C++ became popular cause C programmers could easily use it.
Java became popular cause C/C++ programmers could easily use it.
C# became popular cause C/C++/Java programmers could easily use 
it.


D is gradually becoming popular cause C/C++/Java/C# programmers 
can easily use it.


Rust was more popular and who could use that?
Rust is popular because of its ideas, not because it pandered.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.



And also the minority. A lesson that humanity has to learn over 
and over again.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:45:01 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.



And also the minority. A lesson that humanity has to learn over 
and over again.


Despite the fact that D struggles to interface with itself yet 
the priorities of the foundation are to make D easily interface 
with C? I don't care if they listen to the minority, but make 
sure your priorities are in line before doing so. I think BetterC 
will be something useful in the future, not now.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:


I'm not sure what you mean at that last sentence.


I mean, cause D is so compatible with C/C++/Java/C# - that you 
can easily switch between them.


Whereas as Go and Rust have their own thing going, making those 
languages really difficult in terms of "programmer" portability.


C++ became popular cause C programmers could easily use it.
Java became popular cause C/C++ programmers could easily use it.
C# became popular cause C/C++/Java programmers could easily use 
it.


D is gradually becoming popular cause C/C++/Java/C# programmers 
can easily use it.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:21:27 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.

There is a lesson the be learned in this somewhere...



Again, D is not run by some corporation.

Nor is it a democracy - where majority rule. (read this 
sentence over and over till you get it)


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


It is not a dictatorship (read this sentence over and over till 
you get it).

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:
 And "scripting" language like PHP, that everybody 
criticizes just keeps growing and gained 11% market share in 
the last 7 years ( at now 83% ). Where as D its gain has been 
minimalist thanks to people leaving almost as fast as it gain.




Well, according to the TIOBE Index, C was the language of 2017.

Java is almost always on top, followed by C, followed closely by 
C++.


And it's not just 'old timers' using those languages... surely.

And scripting language can pretty much replace any other 
scripting language.


It's the 'real' programming languages that matter ;-)

And D's not doing to badly at all...despite betterc

https://www.tiobe.com/tiobe-index/d/

(although I wonder what happended back in 2009 ??)

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


Every day D becomes more like C++ 2.0, why can't it just be D?


Oddly enough, I think this is D's strength.


I really don't.

Golang tried to draw the line, and look where that got it. Now 
it's a limited language for a specific domain  (at least until 
Go 3.0).


Rust decided (and Go to some extent), to introduce foreign 
syntax that was vastly different to what the majority of 
programmers are familiar with, and, it makes it difficult to 
transistion to because its syntax is so unlike the syntax most 
people will continue to have to work with.


D's strength, is that most C/C++/Java/C# programmers can just 
jump right in and use it. And, they can continue to go back and 
forth without syntax related psychosis developing.


betterc is just another way of supporting that crowd..and it's 
a very big crowd.


Yeah, 29% of the crowd.

Your problem is not betterc, but something else. So focus on 
that instead.


You're right, my problem isn't BetterC, it's the fact that 
Foundation can't get its priorities right. BetterC is a symptom.


And personally, depending on the problem, C# is better to 
program in than D. I still don't know why C# programmers are 
willing to give up C# and prefer to use D.

C# is vastly surperior for what it does.


I'm my current use-case, D is 'vastly superior'. I wouldn't have 
switched to D if there was no reason to.



D is also particulary useful for some problems.

Better to use both, not one or the other.

Thanks to not being Go or Rust, you can do that - cause 
concepts, syntax  etc, are really compatible with both.


I'm not sure what you mean at that last sentence.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.

There is a lesson the be learned in this somewhere...



Again, D is not run by some corporation.

Nor is it a democracy - where majority rule. (read this sentence 
over and over till you get it)


It's a language that develops because people are sufficiently 
motivated to put in the time to develop what interests them.


Have your say and leave it at that. Stop attacking the work 
others are doing.


And stop your discriminatory use of the phrase 'old timers'.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to 
leech off C/C++? Other languages like Rust and C# only have 
basic function calling C (FFI/PInvoke) yet are way more 
popular. I get the feeling that most of the C++ programmers 
who would come to D have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for 
BetterC.


And what's with the language design, anyway? D has been 
designed with features that C++ programmers don't want, then 
now the D Language Foundation is wasting effort to change the 
language to rope those programmers in? If D was meant to be 
C++ 2.0, shouldn't it have been designed that way from the 
start?


I came to D from a C# background. I was looking a language 
that had a GC, was awesome to program in and was very fast. 
Why can't D own up to these facts, rather than becoming a 
leech of C++?


Every day D becomes more like C++ 2.0, why can't it just be D?


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


Yeah. It quite seems like that. Maybe after BetterC will the 
foundation get its priorities right.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


Didn't BetterC start before the poll was issued? I hope that more 
polls like this are created in the future so that the leadership 
knows where it's priorities are based upon community demands.


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.


Kind of ironic when D keeps pushing for more features hoping 
that it will attract C++ developers and the young kid on the 
block Rust is already eating up that market. And "scripting" 
language like PHP, that everybody criticizes just keeps growing 
and gained 11% market share in the last 7 years ( at now 83% ). 
Where as D its gain has been minimalist thanks to people 
leaving almost as fast as it gain.


There is a lesson the be learned in this somewhere...


I wholeheartedly agree, but I believe this direction is because 
that the "C++ old timers" are in the leadership. I don't think 
there are "too many" in the community.


I also wish to point out that I'm not attacking Walter or Alex; I 
love the language they've created, but I'm fairly annoyed with 
their allocation of resources. They need to stick by the language 
they've created.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


Every day D becomes more like C++ 2.0, why can't it just be D?


Oddly enough, I think this is D's strength.

Golang tried to draw the line, and look where that got it. Now 
it's a limited language for a specific domain  (at least until Go 
3.0).


Rust decided (and Go to some extent), to introduce foreign syntax 
that was vastly different to what the majority of programmers are 
familiar with, and, it makes it difficult to transistion to 
because its syntax is so unlike the syntax most people will 
continue to have to work with.


D's strength, is that most C/C++/Java/C# programmers can just 
jump right in and use it. And, they can continue to go back and 
forth without syntax related psychosis developing.


betterc is just another way of supporting that crowd..and it's a 
very big crowd.


Your problem is not betterc, but something else. So focus on that 
instead.


And personally, depending on the problem, C# is better to program 
in than D. I still don't know why C# programmers are willing to 
give up C# and prefer to use D.

C# is vastly surperior for what it does.

D is also particulary useful for some problems.

Better to use both, not one or the other.

Thanks to not being Go or Rust, you can do that - cause concepts, 
syntax  etc, are really compatible with both.

Re: Vision document for H1 2018

[R via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to 
leech off C/C++? Other languages like Rust and C# only have 
basic function calling C (FFI/PInvoke) yet are way more 
popular. I get the feeling that most of the C++ programmers who 
would come to D have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for BetterC.


And what's with the language design, anyway? D has been 
designed with features that C++ programmers don't want, then 
now the D Language Foundation is wasting effort to change the 
language to rope those programmers in? If D was meant to be C++ 
2.0, shouldn't it have been designed that way from the start?


I came to D from a C# background. I was looking a language that 
had a GC, was awesome to program in and was very fast. Why 
can't D own up to these facts, rather than becoming a leech of 
C++?


Every day D becomes more like C++ 2.0, why can't it just be D?


Point to the wall on the left side. That is what your talking to. 
D its focus on C++ as a bad plan has been made pushed by many 
people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again by 
asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And yet, 
its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many people 
here are C++ old timers ( yes, there are exceptions ) and they 
only think in that direction.


Kind of ironic when D keeps pushing for more features hoping that 
it will attract C++ developers and the young kid on the block 
Rust is already eating up that market. And "scripting" language 
like PHP, that everybody criticizes just keeps growing and gained 
11% market share in the last 7 years ( at now 83% ). Where as D 
its gain has been minimalist thanks to people leaving almost as 
fast as it gain.


There is a lesson the be learned in this somewhere...

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit 
wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:

[Omitted]


I also would like to point out that I don't care if some 
open-source developers decide to create BetterC in their free 
time. More power to them. It doesn't concern me.


What does concern me is that BetterC is the focus of the *D 
Language Foundation*. Why isn't interfacing with D more important?


I'm becoming more and more skeptical of the future of D.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.


That's really all there is to it.

That's how the open source community works.

Top down, corporate direction, simply does not apply here.

One day you (or some other D programmer) might need betterC - 
who knows - and it'll be there for you - cause someone else was 
motivated to do it.


Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to leech 
off C/C++? Other languages like Rust and C# only have basic 
function calling C (FFI/PInvoke) yet are way more popular. I get 
the feeling that most of the C++ programmers who would come to D 
have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for BetterC.


And what's with the language design, anyway? D has been designed 
with features that C++ programmers don't want, then now the D 
Language Foundation is wasting effort to change the language to 
rope those programmers in? If D was meant to be C++ 2.0, 
shouldn't it have been designed that way from the start?


I came to D from a C# background. I was looking a language that 
had a GC, was awesome to program in and was very fast. Why can't 
D own up to these facts, rather than becoming a leech of C++?


Every day D becomes more like C++ 2.0, why can't it just be D?

Re: Vision document for H1 2018

[Meta via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level 
priority - locking down the language definition. This is in 
recognition of the fact that we need a precise definition of 
the language going forward.



Thanks,

Andrei


Establish the DIP as a clear, solid means to get a language 
enhancement going


Very excited about this one. Hopefully some faith can be restored 
in the process.

Re: Vision document for H1 2018

[Aurélien Plazzotta via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Just ignore it. And don't forget the primary betterC's goal.
It was never designed to please some C developers to take profit 
from D without dealing with D full runtime but to help migrating 
from historical C/C++ compiler backend to a fully D native 
compiler backend.


The objective is to obtain bootstraping and get rid of all other 
language's dependencies, which will be a huge advantage and 
advertising for D use and in extenso, D community and 
penetration-market.


Convincing C developpers to try out betterC is "just" a temporary 
(and positive) side-effect.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:
I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?


perhaps this question can be one of many, that the community ask 
the members of the D foundation, on stage, during the Q and A at 
the upcoming Dconf ;-)


there will be a roasting.. won't there?

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:


I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?


I think cause interoperating with C/C++, as well as encouraging 
migrating C/C++ code over D..has always been a key objective for 
Andrei and Walter (as least that's the impression I get - as a 
relative newcomer to D).


So I doesn't surprise me that it would be (remain) a priority for 
the D foundation, which they (and others) represent.


All power to em...

Although... I'm just not convinced that C programmers will give 
up C, and C++ programmers will give up C++ ... well... certainly 
I don't see any mass migration on the horizon of my crystal ball.


Everyone will end up programming in C++, Java, or .NET .. says 
the crystal ball.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.


That's really all there is to it.

That's how the open source community works.



I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


who cares what 'the majority' want... I mean really.

stuff em!

(ohh... that was in jest.. don't take that seriously)

Re: Vision document for H1 2018

[Mike Parker via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


1. The vision document was started before the survey and the 
survey isn't closed, so the survey results don't factor into it 
yet.


2. The survey results will serve as a set of guidelines for 
future directions, not as a set of absolute directives. It wasn't 
a controlled survey and it doesn't reflect the entire D community.


3. Work on BetterC was started a long time ago and isn't going to 
be abandoned over night.


If something shows up as high priority in the survey, then it 
makes sense to evaluate its impact and see how we can devote more 
resources to it going forward. If something shows up as low 
priority, then we have to take a number of factors into account, 
(e.g. Is it being worked on already? Are there commercial 
interests who *do* consider it a priority? Etc.).


In other words, when setting goals post-survey, the results will 
factor into the decisions, but they won't necessarily be the 
deciding factor. The survey is a means of getting community input 
in one place, as opposed to scattered across the forums and 
reddit comments.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.


That's really all there is to it.

That's how the open source community works.

Top down, corporate direction, simply does not apply here.

One day you (or some other D programmer) might need betterC - who 
knows - and it'll be there for you - cause someone else was 
motivated to do it.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it can't 
even interface with itself through DLLs?

Re: Vision document for H1 2018

[Dukc via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


I believe it's because it's so important for the 29% who care. If 
you're doing an module for project written in another language 
and don't want to introduce DRuntime yet, or are compiling to 
JavaScript for example, --BetterC can be a lot more helpful than 
killing autodecoding or whatever.

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1



According to the State of D Survey, 71% of the respondents don't 
care about betterC. Why is betterC on the priority list?

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


nice.

andd that 'langauge specification' is really important too.. or 
people will drift towards languages that 'are' properly specified.


None of us like to be surprised by what the compiler does. The 
spec should tell it what to do.


and...just don't implement a 'no hugs' policy, or I'm outta here 
;-)

Re: Vision document for H1 2018

[rikki cattermole via Digitalmars-d-announce]

On 10/03/2018 10:43 AM, Andrei Alexandrescu wrote:
Hello, the vision document of the Founation for the first six months of 
2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level priority - 
locking down the language definition. This is in recognition of the fact 
that we need a precise definition of the language going forward.



Thanks,

Andrei


I was going to edit the document and argue for it (but procedure has 
been a bit different this time), shared libraries.


From what I saw in 2017 and pre 2016 too they are the number one 
implementation issue of D that drives people away. Almost everything 
else can be worked around.


Now that we have @nogc exceptions, and are going pay-as-you-go for 
runtime, this is the biggest thing holding us back IMO.


We need clear use cases with example code that works cross-platform.

With D-host, With C-host, merged with host, unmerged to host. Stuff like 
that.

Re: Vision document for H1 2018

[Joakim via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level 
priority - locking down the language definition. This is in 
recognition of the fact that we need a precise definition of 
the language going forward.



Thanks,

Andrei


Very nice, love how concrete this document has become, including 
listing the members of the core team, especially compared to the 
vague early vision statements.


One note about @nogc: I've seen complaints about the -vgc reports 
on reddit, that they're not very useful for mixed @nogc usage, 
where the GC is used for part of the codebase, not sure if 
something can be done about that.