www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Moving back to .NET

reply Adam <Adam and.Eve> writes:
My experiences with D recently have not been fun.

The language itself has a top notch feature rich set. The 
implementation, excluding bugs, feels a bit boxy and old school. 
.NET has a unified approach and everything seems to fit together 
nicely and feels consistent. The abomination of dmd, though, is 
it's error messages. Most of them are meaningless and you have to 
dive down 2 or 3 levels of assumptions to figure out what they 
mean. It's not too bad but because of the poor tool set it makes 
it difficult to debug apps.

Visual D, a mighty attempt to bring some sanity to D in windows, 
is simply to unpolished to work well. It brings the looks of 
Visual Studio but not the feel of how VS works so well with .NET. 
I spend over an order of magnitude more time trying to fix D bugs 
than I do in .NET. Unfortunately this makes it infeasible to 
continue to use D.

For example, I build a ~10k line app in under a week in .NET, 
with gui and everything. In D I'm still working on getting the 
libraries build. Even with all the power D has, what good is it 
if you can't get off the starting line. Some will write this off 
making some assumption, So be it.

.NET is a bliss to work in, D is drudgery. If only MS would build 

all those who have worked hard on D, someone has to do it. For 
me, .NET is like heaven, D is like hell: It's almost exclusively 
due to the error messages and IDE. I know many here will write 
off such complaints, So be it.

My main concern with .NET is portability and performance. I am 
going to give in to the portability and just assume Mono is good 
enough. Performance wise, I'd prefer D, but .NET is performant 
enough for most apps. Maybe in a few years things will change, I 
can't wait that long. Sorry guys! (not that you will miss me)

Remember, no reason to have the sharpest sword if you can't wield 
it.
Sep 20 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/20/2015 01:32 PM, Adam wrote:

 For me, .NET is like heaven, D is like hell: It's almost exclusively due
 to the error messages and IDE.


Off the top of your head, can you list a few of the worst error messages 
you've encountered?

Also, what are the most important features VisualD is lacking?


Andrei
Sep 20 2015
next sibling parent reply anonymous <anonymous example.com> writes:
On Sunday 20 September 2015 19:39, Andrei Alexandrescu wrote:


 Off the top of your head, can you list a few of the worst error messages 
 you've encountered?


Not Adam, but this is on the top of my head as it just happened:

http://stackoverflow.com/questions/32681660/compiler-thinks-enum-values-are-starting-at-129
Sep 20 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/20/2015 01:46 PM, anonymous wrote:

 On Sunday 20 September 2015 19:39, Andrei Alexandrescu wrote:


 Off the top of your head, can you list a few of the worst error messages
 you've encountered?


 Not Adam, but this is on the top of my head as it just happened:

 http://stackoverflow.com/questions/32681660/compiler-thinks-enum-values-are-starting-at-129


Filed it here: https://issues.dlang.org/show_bug.cgi?id=15090 -- Andrei
Sep 20 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2015 12:04 PM, Andrei Alexandrescu wrote:

 Filed it here: https://issues.dlang.org/show_bug.cgi?id=15090 -- Andrei


Fix: https://github.com/D-Programming-Language/dmd/pull/5106
Sep 20 2015
prev sibling next sibling parent anonymous2 <a b.cd> writes:
On Sunday, 20 September 2015 at 17:39:46 UTC, Andrei Alexandrescu 
wrote:

 On 09/20/2015 01:32 PM, Adam wrote:

 For me, .NET is like heaven, D is like hell: It's almost 
 exclusively due
 to the error messages and IDE.


 Off the top of your head, can you list a few of the worst error 
 messages you've encountered?

 Also, what are the most important features VisualD is lacking?


 Andrei


my favourite:

void foo(ref int a) {}

void main() {
   foo(42);
}

DMD64 D Compiler v2.068.2-b1:
  Error: function a.foo (ref int a) is not callable using argument 
types (int)

Issue:
https://issues.dlang.org/show_bug.cgi?id=11529
maybe there are more related issues in the bug tracker.

Based on a quick look in the C++ frontend some time ago, this 
should be quite simple to fix by inserting a check for 'rvalue as 
ref'  before the error message is printed. At the moment I have 
no time to figure out how dmd works and to implement this. May 
there are some edge cases, too.
Sep 20 2015
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 20 September 2015 at 17:39:46 UTC, Andrei Alexandrescu 
wrote:

 Off the top of your head, can you list a few of the worst error 
 messages you've encountered?


Fine in release mode, error in debug mode:

struct S { int value; }

void main(string[] args) {
     Array!S stuff = [S(3), S(1), S(2)];
     stuff[].sort!((ref S a, ref S b) => a.value < b.value);
}

std/range/package.d(7180,24): Error: 
'std.range.SortedRange!(RangeT!(Array!(S)), 
__lambda2).SortedRange.dbgVerifySorted' is not nothrow
std/algorithm/sorting.d(982,29): Error: template instance 
std.range.assumeSorted!(__lambda2, RangeT!(Array!(S))) error 
instantiating
main.d(75,9):  instantiated from here: sort!(function (ref S a, 
ref S b) => a.value < b.value, cast(SwapStrategy)0, 
RangeT!(Array!(S)))

     Bit
Sep 20 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2015 6:49 PM, bitwise wrote:

 On Sunday, 20 September 2015 at 17:39:46 UTC, Andrei Alexandrescu wrote:

 Off the top of your head, can you list a few of the worst error messages
 you've encountered?


 Fine in release mode, error in debug mode:

 struct S { int value; }

 void main(string[] args) {
      Array!S stuff = [S(3), S(1), S(2)];
      stuff[].sort!((ref S a, ref S b) => a.value < b.value);
 }

 std/range/package.d(7180,24): Error:
'std.range.SortedRange!(RangeT!(Array!(S)),
 __lambda2).SortedRange.dbgVerifySorted' is not nothrow
 std/algorithm/sorting.d(982,29): Error: template instance
 std.range.assumeSorted!(__lambda2, RangeT!(Array!(S))) error instantiating
 main.d(75,9):  instantiated from here: sort!(function (ref S a, ref S b) =>
 a.value < b.value, cast(SwapStrategy)0, RangeT!(Array!(S)))


Please post to bugzilla.
Sep 20 2015
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Monday, 21 September 2015 at 02:38:46 UTC, Walter Bright wrote:

 On 9/20/2015 6:49 PM, bitwise wrote:

 [...]


 Please post to bugzilla.


Yeah, sorry. I am kinda lazy with these things.

https://issues.dlang.org/show_bug.cgi?id=15091

     Bit
Sep 20 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2015 8:12 PM, bitwise wrote:

 https://issues.dlang.org/show_bug.cgi?id=15091


Thanks!
Sep 20 2015
prev sibling next sibling parent reply Israel <tl12000 live.com> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 My experiences with D recently have not been fun.

 The language itself has a top notch feature rich set. The 
 implementation, excluding bugs, feels a bit boxy and old 
 school. .NET has a unified approach and everything seems to fit 
 together nicely and feels consistent. The abomination of dmd, 
 though, is it's error messages. Most of them are meaningless 
 and you have to dive down 2 or 3 levels of assumptions to 
 figure out what they mean. It's not too bad but because of the 
 poor tool set it makes it difficult to debug apps.

 Visual D, a mighty attempt to bring some sanity to D in 
 windows, is simply to unpolished to work well. It brings the 
 looks of Visual Studio but not the feel of how VS works so well 
 with .NET. I spend over an order of magnitude more time trying 
 to fix D bugs than I do in .NET. Unfortunately this makes it 
 infeasible to continue to use D.

 For example, I build a ~10k line app in under a week in .NET, 
 with gui and everything. In D I'm still working on getting the 
 libraries build. Even with all the power D has, what good is it 
 if you can't get off the starting line.

 Remember, no reason to have the sharpest sword if you can't 
 wield it.


The problem is that you seem to be accustomed to an IDE of which 
D is not tied to.
That would limit (as you put it) its portability. But at the same 
time you want a unified tool-set?

Ask any of the vim/emacs users here and they will tell you 
otherwise.
Sep 20 2015
parent reply Temtaime <temtaime gmail.com> writes:
I also hate errors when a lambda contains some errors.

[ 1 ].countUntil!(a => a == undeclared_something);

Error: template std.algorithm.searching.countUntil cannot deduce 
function from argument types !((a) => a == undefined)(int[])
Sep 20 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2015 5:00 PM, Temtaime wrote:

 I also hate errors when a lambda contains some errors.

 [ 1 ].countUntil!(a => a == undeclared_something);

 Error: template std.algorithm.searching.countUntil cannot deduce function from
 argument types !((a) => a == undefined)(int[])


Please post to bugzilla.
Sep 20 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 21 September 2015 at 02:38:28 UTC, Walter Bright wrote:

 On 9/20/2015 5:00 PM, Temtaime wrote:

 I also hate errors when a lambda contains some errors.

 [ 1 ].countUntil!(a => a == undeclared_something);

 Error: template std.algorithm.searching.countUntil cannot 
 deduce function from
 argument types !((a) => a == undefined)(int[])


 Please post to bugzilla.


https://issues.dlang.org/show_bug.cgi?id=14885
https://issues.dlang.org/show_bug.cgi?id=10679

It is 2015 and we don't have line number in stack traces.
Sep 21 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 September 2015 at 18:33:39 UTC, deadalnix wrote:

 https://issues.dlang.org/show_bug.cgi?id=14885


This was recently fixed this week:
http://arsdnet.net/this-week-in-d/sep-20.html

https://github.com/D-Programming-Language/druntime/pull/1354


 https://issues.dlang.org/show_bug.cgi?id=10679


I don't think this one is valid though maybe I'm wrong. But the 
instruction pointer would be on the next instruction.
Sep 21 2015
parent Yazan D <invalid email.com> writes:
On Mon, 21 Sep 2015 19:07:32 +0000, Adam D. Ruppe wrote:


 https://issues.dlang.org/show_bug.cgi?id=10679


 
 I don't think this one is valid though maybe I'm wrong. But the
 instruction pointer would be on the next instruction.


You are correct and I realized this later on and 'fixed' it in
druntime: https://github.com/D-Programming-Language/druntime/
commit/8822115bc8d52fa61c15cef38fe77349f18747b9. I will close this now.
Sep 21 2015
prev sibling parent reply default0 <Kevin.Labschek gmx.de> writes:
On Monday, 21 September 2015 at 00:01:01 UTC, Temtaime wrote:

 I also hate errors when a lambda contains some errors.

 [ 1 ].countUntil!(a => a == undeclared_something);

 Error: template std.algorithm.searching.countUntil cannot 
 deduce function from argument types !((a) => a == 
 undefined)(int[])


I agree, the error should contain better reasoning as to why the 
function cannot be deduced. Since Phobos uses templates pretty 
heavily, and sometimes has a decent set of pre-conditions, 
tracking down which condition exactly is failing is hard. 
Printing the template condition and the expression in it that 
caused the instantiation to fail would be tremendously helpful!
Sep 21 2015
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 21 September 2015 at 13:03:20 UTC, default0 wrote:

 On Monday, 21 September 2015 at 00:01:01 UTC, Temtaime wrote:

 I also hate errors when a lambda contains some errors.

 [ 1 ].countUntil!(a => a == undeclared_something);

 Error: template std.algorithm.searching.countUntil cannot 
 deduce function from argument types !((a) => a == 
 undefined)(int[])


 I agree, the error should contain better reasoning as to why 
 the function cannot be deduced. Since Phobos uses templates 
 pretty heavily, and sometimes has a decent set of 
 pre-conditions, tracking down which condition exactly is 
 failing is hard. Printing the template condition and the 
 expression in it that caused the instantiation to fail would be 
 tremendously helpful!


The problem is that the compiler doesn't know which version of 
the template constraints you meant to invoke.

e.g.

void foo(Bar)(Bar b) if (isSomething!Bar) { ... }

and

void foo(Bar)(Bar b) if (isSomethingElse!Bar) { ... }

The best thing the compiler can do is say `Error: Bar != 
isSomething and Bar != isSomethingElse`. Which is basically what 
its doing right now.
Sep 21 2015
prev sibling next sibling parent reply Sean Campbell <sycam.inc gmail.com> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 Visual D, a mighty attempt to bring some sanity to D in 
 windows, is simply to unpolished to work well. It brings the 
 looks of Visual Studio but not the feel of how VS works so well 
 with .NET. I spend over an order of magnitude more time trying 
 to fix D bugs than I do in .NET. Unfortunately this makes it 
 infeasible to continue to use D.

 For example, I build a ~10k line app in under a week in .NET, 
 with gui and everything. In D I'm still working on getting the 
 libraries build. Even with all the power D has, what good is it 
 if you can't get off the starting line. Some will write this 
 off making some assumption, So be it.

 .NET is a bliss to work in, D is drudgery. If only MS would 

 offense to all those who have worked hard on D, someone has to 
 do it. For me, .NET is like heaven, D is like hell: It's almost 
 exclusively due to the error messages and IDE.


I know what he means about visual D, it can be quite difficult to 
work with and doesn't seem very polished. That being said xamarin 
studio with the mono-D plugin is just opposite, or at least in my 
own experience and it supports both windows and *NIX.
Sep 20 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/09/15 1:01 PM, Sean Campbell wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 Visual D, a mighty attempt to bring some sanity to D in windows, is
 simply to unpolished to work well. It brings the looks of Visual
 Studio but not the feel of how VS works so well with .NET. I spend
 over an order of magnitude more time trying to fix D bugs than I do in
 .NET. Unfortunately this makes it infeasible to continue to use D.

 For example, I build a ~10k line app in under a week in .NET, with gui
 and everything. In D I'm still working on getting the libraries build.
 Even with all the power D has, what good is it if you can't get off
 the starting line. Some will write this off making some assumption, So
 be it.

 .NET is a bliss to work in, D is drudgery. If only MS would build a D

 who have worked hard on D, someone has to do it. For me, .NET is like
 heaven, D is like hell: It's almost exclusively due to the error
 messages and IDE.


 I know what he means about visual D, it can be quite difficult to work
 with and doesn't seem very polished. That being said xamarin studio with
 the mono-D plugin is just opposite, or at least in my own experience and
 it supports both windows and *NIX.


+1EGOOGOLPLEX aka a very large number that doesn't matter

I do enjoy Mono-D use it to stream and all!
Sep 20 2015
prev sibling next sibling parent reply PovGuy <PovGuy nowhere.it> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 My experiences with D recently have not been fun.

 The language itself has a top notch feature rich set. The 
 implementation, excluding bugs, feels a bit boxy and old 
 school. .NET has a unified approach and everything seems to fit 
 together nicely and feels consistent. The abomination of dmd, 
 though, is it's error messages. Most of them are meaningless 
 and you have to dive down 2 or 3 levels of assumptions to 
 figure out what they mean. It's not too bad but because of the 
 poor tool set it makes it difficult to debug apps.

 Visual D, a mighty attempt to bring some sanity to D in 
 windows, is simply to unpolished to work well. It brings the 
 looks of Visual Studio but not the feel of how VS works so well 
 with .NET. I spend over an order of magnitude more time trying 
 to fix D bugs than I do in .NET. Unfortunately this makes it 
 infeasible to continue to use D.

 For example, I build a ~10k line app in under a week in .NET, 
 with gui and everything. In D I'm still working on getting the 
 libraries build. Even with all the power D has, what good is it 
 if you can't get off the starting line. Some will write this 
 off making some assumption, So be it.

 .NET is a bliss to work in, D is drudgery. If only MS would 

 offense to all those who have worked hard on D, someone has to 
 do it. For me, .NET is like heaven, D is like hell: It's almost 
 exclusively due to the error messages and IDE. I know many here 
 will write off such complaints, So be it.

 My main concern with .NET is portability and performance. I am 
 going to give in to the portability and just assume Mono is 
 good enough. Performance wise, I'd prefer D, but .NET is 
 performant enough for most apps. Maybe in a few years things 
 will change, I can't wait that long. Sorry guys! (not that you 
 will miss me)

 Remember, no reason to have the sharpest sword if you can't 
 wield it.


D is community driven. It's what people want it to be.

One thing: don't expect to master it in two weeks, particularly 
if you want it to be like your motherland language, like your 
comfort zone. From your conclusion it looks like you want to stay 
in your comfort zone, that's up to you but don't give up like 
this.

Give a chance on D on your free time to understand it. 
Particularly because the standard library let you incredibly free 
to choose between data oriented, oop, fp programming and in all 
the cases the algorithms will be compatible...that's really a 
**major** aspect of D (reflected in the standard lib).
Sep 21 2015
parent PovGuy <PovGuy nowhere.it> writes:
On Monday, 21 September 2015 at 14:00:42 UTC, PovGuy wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 [...]


 D is community driven. It's what people want it to be.

 One thing: don't expect to master it in two weeks, particularly 
 if you want it to be like your motherland language, like your 
 comfort zone. From your conclusion it looks like you want to 
 stay in your comfort zone, that's up to you but don't give up 
 like this.

 Give a chance on D on your free time to understand it. 
 Particularly because the standard library let you incredibly 
 free to choose between data oriented, oop, fp programming and 
 in all the cases the algorithms will be compatible...that's 
 really a **major** aspect of D (reflected in the standard lib).


https://www.youtube.com/watch?v=jUQwJmQGWtU
Sep 21 2015
prev sibling next sibling parent reply Maxim Fomin <mxfomin gmail.com> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 My experiences with D recently have not been fun.
 ...
 My main concern with .NET is portability and performance. I am 
 going to give in to the portability and just assume Mono is 
 good enough. Performance wise, I'd prefer D, but .NET is 
 performant enough for most apps. Maybe in a few years things 
 will change, I can't wait that long. Sorry guys! (not that you 
 will miss me)


OK, the frustration is understandable. D is good enough to 
impress in short-run but has problems damaging itself in the long 
run. This leads to impression -> frustration cycle.

However, one point regarding portability. It is wrong to target 
cross - platform project by *assuming* that Mono is good enough. 
Either you need portability and you care what Mono does, or you 
don't. But then it is irrelevant what happens in Linux.

By the way, it seems you started from .Net from the very 
beginning. It is unclear why you considered D in such 
circumstances (of course, except portability, but it seems you 
actually don't need it).

Last point. You mentioned performance. Did you run benchmarks?
Sep 21 2015
parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 My experiences with D recently have not been fun.





 My main concern with .NET is portability and performance. I am 
 going to give in to the portability and just assume Mono is 
 good enough. Performance wise, I'd prefer D, but .NET is 
 performant enough for most apps. Maybe in a few years things 
 will change, I can't wait that long. Sorry guys! (not that you 
 will miss me)


 OK, the frustration is understandable. D is good enough to 
 impress in short-run but has problems damaging itself in the 
 long run. This leads to impression -> frustration cycle.


Well, that may or may not be true.  But someone who finds the 
error messages offputting isn't a good exemplar of putative 
deficiencies that show up in the long run, because these are part 
of the initial learning curve and after a year or two or 
experience it's really unlikely to be a main factor in 
determining choice of framework.  Whereas it's understandable 
that in the beginning it can be a big source of frustration.  And 
if you leave the Microsoft ecosystem, I am not sure that D fares 
so badly in relation to a certain C family language that has had 
a big influence.

He didn't say how long he had been using D for, but as others 
point out one underestimates how much one knows in relation to 
existing languages, and forgets that it is a degree of work over 
months and years to learn something new...

A better example of long run deficiencies might be the guy here 
who tried to use D at work for embedded systems, which involved 
making his own runtime etc, and who gave up, at least for a 
while, in frustration.  On the other hand, it's always tough to 
try to be the first to do something, especially when your career 
is at stake.


 Either you need portability and you care what Mono does, or you 
 don't.


Commercial decisions are often a matter of tradeoffs.  Eg for 
internal enterprise software you might find it valuable to be 
able to run on both linux and windows, but you can always make it 
a service on windows if linux is too much trouble.
Sep 21 2015
parent Maxim Fomin <mxfomin gmail.com> writes:
On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc 
wrote:

 On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:


 OK, the frustration is understandable. D is good enough to 
 impress in short-run but has problems damaging itself in the 
 long run. This leads to impression -> frustration cycle.


 Well, that may or may not be true.  But someone who finds the 
 error messages offputting isn't a good exemplar of putative 
 deficiencies that show up in the long run, because these are 
 part of the initial learning curve and after a year or two or 
 experience it's really unlikely to be a main factor in 
 determining choice of framework.  Whereas it's understandable 
 that in the beginning it can be a big source of frustration.


I do not consider error messages as long run issue (it is 
discussed in the thread and I didn't mentioned it, so it might 
caused impression that I agree with complains about error 
messages).


 And if you leave the Microsoft ecosystem, I am not sure that D 
 fares so badly in relation to a certain C family language that 
 has had a big influence.


If Microsoft ecosystem is left out then my opinion regarding 
comparison with Microsoft system is obviously irrelevant. 
Comparing with other languages I found D is decently good.


 He didn't say how long he had been using D for, but as others 
 point out one underestimates how much one knows in relation to 
 existing languages, and forgets that it is a degree of work 
 over months and years to learn something new...


I always could not understand complaints regarding D hard 



 Either you need portability and you care what Mono does, or 
 you don't.


 Commercial decisions are often a matter of tradeoffs.  Eg for 
 internal enterprise software you might find it valuable to be 
 able to run on both linux and windows, but you can always make 
 it a service on windows if linux is too much trouble.


Sounds like 'lazy' portability: if app is portable - than good, 
if not - ok, we can leave with it:)
Sep 22 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:


 It's almost exclusively due to the error messages and IDE. I 
 know many here will write off such complaints, So be it.


The thing is that a lot of people who use D don't mind the lack 
of IDE support. One reason is that D doesn't need it as badly as 
e.g. Java or C++. Once you are comfortable with the idea of 
component programming, there's less need for an IDE. I don't know 
about .NET, but Java programs consist usually of classes that are 
somehow interwoven. In D you'd go for independent components that 
you can later stick together like Lego. I usually write new 
components as tiny projects with unit tests etc., and plug them 
into the big project once I'm happy with them. In this way, you 
don't work on the big project all the time, mostly on small 
components you add to the big project later.


 Remember, no reason to have the sharpest sword if you can't 
 wield it.


Another reason is that for D programmers the power of D outweighs 
the lack of IDE support. While you may have an easy life with 

to do certain things, to be confined by committee decisions etc., 
is worse in the long run. So D people prefer to learn how to 
wield the sharpest sword, although it may take some time. It's 
like everything in life, really, if you take the hard way, you'll 
get more out of it in the long run.

So don't give up. Maybe D will come to the rescue one day, when 
you hit a brick wall with .NET ;)

PS As to error messages, you'll soon know the "usual suspects".
Sep 22 2015
next sibling parent reply Maxim Fomin <mxfomin gmail.com> writes:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 to be confined by committee decisions etc.,


D has committee (Walter & Andrei). Some of their decisions 
frustrate D users too.
Sep 22 2015
parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote:

 On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 to be confined by committee decisions etc.,


 D has committee (Walter & Andrei). Some of their decisions 
 frustrate D users too.


Sure, but in many cases D allows you to work around decisions you 
don't like. Plus, you can actively contribute, make suggestions 
and prove your case. The length of some threads shows that 
Walter, Andrei and others involved in the development take input 
seriously and answer questions and give the reasons for their 
decisions.

That a language needs people who make the final decision about 
something is necessary. That these decisions are not always to 
everyone's liking is inevitable. Given the contradictory nature 
of requirements in programming, it's only logical that one cannot 
cater for both sides all the time. D has a long list of requested 
features that actually made it into the language quite fast, 
unlike other languages that beat about the bush for years, before 
they finally incorporate something users really do want. So the 
general approach is sound, however, due to a lack of resources, 
not all is well, e.g. PRs stay in the pipe too long. But as I 
said before, it's only from D that users expect perfection, other 
languages are accepted as they are, warts and all.
Sep 22 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:

 too long. But as I said before, it's only from D that users 
 expect perfection, other languages are accepted as they are, 
 warts and all.


I don't think that is true. It has been common among C++ users to 
build custom libraries with very little use of the standard 
library. C++ has never been accepted with warts and all. It is 
just C++ was the only option next to C, so people have rolled 
their own _gradually_ moving from C towards the C++ feature set.

Like, I wrote my own array reference library in the spring, but I 
am now replacing it with a C++17 prototype array_view since an 
implementation is available from Microsoft now.

What has made C and C++ tolerable is that they are very adaptable 
languages with very few deliberate constraints and runtime 
requirements.  A problem for D today is that D1 was originally 
deliberately constrained, which made perfect sense when the 
language was small (just like it makes sense for Go today).  But 
D2 is deliberately open, yet D2 has added features without 
redefining the core language from D1 first. It is possible to fix 
it, by defining a minimal D language and move everything else to 
libraries, but not without breaking backwards compatibility.

C/C++ are stuck in the 70s as far as memory goes, but D is still 
undecided. Leaving the field totally open for Rust who is moving 
quite fast AFAICT.
Sep 22 2015
parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 22 September 2015 at 14:46:30 UTC, Ola Fosheim 
Grøstad wrote:

 On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:

 too long. But as I said before, it's only from D that users 
 expect perfection, other languages are accepted as they are, 
 warts and all.


 I don't think that is true.


I do, because every other (new) language is embraced as _the_ way 
to go, while in the D community even minor issues are blown out 
of proportion.


  A problem for D today is that D1 was originally deliberately 
 constrained, which made perfect sense when the language was 
 small (just like it makes sense for Go today).  But D2 is 
 deliberately open, yet D2 has added features without redefining 
 the core language from D1 first. It is possible to fix it, by 
 defining a minimal D language and move everything else to 
 libraries, but not without breaking backwards compatibility.


Then we need a transition strategy. I wouldn't mind refactoring 
my code in order to adapt it to changes that are for the better 
in the long run. However, I wouldn't want it to happen in a 
sudden way that would render all my code useless. Nobody would 
accept this.
Sep 22 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 22 September 2015 at 15:34:19 UTC, Chris wrote:

 Then we need a transition strategy. I wouldn't mind refactoring 
 my code in order to adapt it to changes that are for the better 
 in the long run. However, I wouldn't want it to happen in a 
 sudden way that would render all my code useless. Nobody would 
 accept this.


I agree, one could have an experimental compiler that accepts a 
modified subset of current D, yet is capable of linking with 
existing D code perhaps.
Sep 22 2015
prev sibling next sibling parent ref2401 <refactor24 gmail.com> writes:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:

 it's only from D that users expect perfection, other languages 
 are accepted as they are, warts and all.


it's true
Sep 22 2015
prev sibling parent reply Maxim Fomin <mxfomin gmail.com> writes:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:

 On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin 
 wrote:

 On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 to be confined by committee decisions etc.,


 D has committee (Walter & Andrei). Some of their decisions 
 frustrate D users too.


 Sure, but in many cases D allows you to work around decisions 
 you don't like. Plus, you can actively contribute, make 
 suggestions and prove your case. The length of some threads 
 shows that Walter, Andrei and others involved in the 
 development take input seriously and answer questions and give 
 the reasons for their decisions.


Well, in case of C/C++ there is also rationale for decision, but 
not in the forum form. But providing rationale is not helpful if 
there is disagreement.


 That these decisions are not always to everyone's liking is 
 inevitable. Given the contradictory nature of requirements in 
 programming, it's only logical that one cannot cater for both 
 sides all the time.


Definitely agree.
Sep 22 2015
parent reply Maxim Fomin <mxfomin gmail.com> writes:
On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote:

 On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:

 Sure, but in many cases D allows you to work around decisions 
 you don't like. Plus, you can actively contribute, make 
 suggestions and prove your case. The length of some threads 
 shows that Walter, Andrei and others involved in the 
 development take input seriously and answer questions and give 
 the reasons for their decisions.


 Well, in case of C/C++ there is also rationale for decision, 
 but not in the forum form. But providing rationale is not 
 helpful if there is disagreement.


To elaborate. If the issue is comparing chances of changing 
language in a user-oriented way of D and standardized languages, 
then it is definitely no. First of all, there is huge information 
gap between language hackers and users. Secondly, it is hard to 
beat the 'committee' argumentation even if they are wrong - they 
are simply to skilled and experienced.

Two examples. I am aware of only one case when Walter and Andrei 
agreed with community. It is epic bugzilla discussion [1] 
regarding contract programming. It took 60 comments to convince.

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

The second example is more recent dmd pull discussion regarding 
template linkage behavior (Walter + Martin vs. Kenji). After long 
discussion the outcome was that some rare but used feature was 
dropped for the sake of dmd internals convenience. Walter's 
argumentation was that the language feature was working by 
chance, so relying on it is a mistake (to be more precise, the 
question was whether to write new code to support feature in 
another context or to drop it and make code cleaner). After new 
release there were couple issues filed in bugzilla that 
complained about new behavior, but were closed as invalid (sorry, 
don't have link, recollect from memory).

So, my point is that D except communication channel is pretty 
much the same as standardized languages with respect to changing 
language. I would say there are better chances that some feature 
will suddenly be changed and backfire existing code rather than 
user will convince to tweak the existing features to make it user 
- friendly at the expense of internals complexity. I do admit 
that discussions of new features and simple enhancements provide 
better chances (discussion is about significant issues, not 
trivial enhancements - isn't it?).
Sep 22 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote:

 Two examples. I am aware of only one case when Walter and 
 Andrei agreed with community.


Well, but the community doesn't agree with itself either ;^) But 
Walter did add  nogc and changed his view on GC being a total 
non-issue, so obviously forum discussions have an effect on the 
decision-making process over time.


 So, my point is that D except communication channel is pretty 
 much the same as standardized languages with respect to 
 changing language.


I think the process changes a lot when you are working with an 
actual language spec for several years and get experimental 
implementations in compilers a long time before release. Add also 
the number of qualified eyeballs looking at proposals... I don't 
think the C++ designers have made many serious mistakes in the 
last few iterations (although it could happen again in C++17 ;^).

When the spec is the compiler, then you get the unfortunate 
effect that things that are easy to do go in, and things that are 
hard to do are rejected.

Anyway, some of these things are discussed in Stroustrup's 
keynote:

https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Stroustrup%20-%20CppCon%202015%20keynote.pdf
Sep 22 2015
parent Kagamin <spam here.lot> writes:
On Tuesday, 22 September 2015 at 18:30:35 UTC, Ola Fosheim 
Grøstad wrote:

 I think the process changes a lot when you are working with an 
 actual language spec for several years and get experimental 
 implementations in compilers a long time before release. Add 
 also the number of qualified eyeballs looking at proposals... I 
 don't think the C++ designers have made many serious mistakes 
 in the last few iterations (although it could happen again in 
 C++17 ;^).


Though there was a questionable change in C standard: 
introduction of timespec, which locally redefined meaning of 
time_t as a transparent type, along with legacy definition of 
time_t as an opaque type. Maybe legacy definition could be 
dropped, but it didn't happen.
Sep 23 2015
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote:


 Well, in case of C/C++ there is also rationale for decision, 
 but not in the forum form.




Yes, but you get it post facto and nobody listens to you anyway, 
it's like a parliament.


 But providing rationale is not helpful if there is 
 disagreement.




Well, what do you suggest then? To implement a different fork of 
D for every opinion / user request? Excuse me, but I cannot 
follow your rationale. It is only when there is disagreement that 
you have to provide a rationale. If there is general agreement 
you don't need to provide a rationale.


 To elaborate. If the issue is comparing chances of changing 
 language in a user-oriented way of D and standardized 
 languages, then it is definitely no. First of all, there is 
 huge information gap between language hackers and users.


Yes, but where do you draw the line between random requests 
(sometimes contradictory) and real long-term enhancements? As Ola 
said, the community often doesn't agree with itself.


 Secondly, it is hard to beat the 'committee' argumentation even 
 if they are wrong - they are simply to skilled and experienced.


Yes, it's hard to beat experience. However, if a feature - albeit 
useful - would break too much code, Walter takes a conservative 
stance, else D would lose most of its clients. We need a proper 
transition strategy.

[1] https://github.com/higgsjs/Higgs


 Two examples. I am aware of only one case when Walter and 
 Andrei agreed with community. It is epic bugzilla discussion 
 [1] regarding contract programming. It took 60 comments to 
 convince.

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

 The second example is more recent dmd pull discussion regarding 
 template linkage behavior (Walter + Martin vs. Kenji). After 
 long discussion the outcome was that some rare but used feature 
 was dropped for the sake of dmd internals convenience. Walter's 
 argumentation was that the language feature was working by 
 chance, so relying on it is a mistake (to be more precise, the 
 question was whether to write new code to support feature in 
 another context or to drop it and make code cleaner). After new 
 release there were couple issues filed in bugzilla that 
 complained about new behavior, but were closed as invalid 
 (sorry, don't have link, recollect from memory).

 So, my point is that D except communication channel is pretty 
 much the same as standardized languages with respect to 
 changing language. I would say there are better chances that 
 some feature will suddenly be changed and backfire existing 
 code rather than user will convince to tweak the existing 
 features to make it user - friendly at the expense of internals 
 complexity. I do admit that discussions of new features and 
 simple enhancements provide better chances (discussion is about 
 significant issues, not trivial enhancements - isn't it?).


There has been a lot of movement. E.g. when Higgs[1] couldn't 
beat C++'s performance, Walter and Andrei agreed (as far as I 
remember) that the current GC is indeed an issue as is full C++ 
compatibility. And there are other cases. I think the problem is 
that everybody has their own pet issues and follows only these - 
and if there is no movement, they get the impression that nothing 
ever happens (you know, toys, pram...). However, if you follow 
this forum over the years, you can see that there is movement due 
to user input.

The question is, do certain issues really keep you from using the 
language successfully and why? And is it an issue for a 
substantial part of other users?
Sep 23 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 23 September 2015 at 09:44:10 UTC, Chris wrote:

 Yes, it's hard to beat experience. However, if a feature - 
 albeit useful - would break too much code, Walter takes a 
 conservative stance, else D would lose most of its clients. We 
 need a proper transition strategy.


C++ seems to take a guideline + guideline support library (GSL) 
in order to "softly deprecate" the old feature set without 
actually deprecating it. I am not sure how well that goes, but 
GSL looks good to me.

When a language reach a certain complexity it probably is a 
mistake to add more features, new features have to be followed by 
instruction of how to make good use of them. In C++ there are too 
many ways to do the same thing, which is negative for code 
legibility.

His talk is online:

https://youtu.be/1OEu9C51K2A


 The question is, do certain issues really keep you from using 
 the language successfully and why? And is it an issue for a 
 substantial part of other users?


Another question is: what kind of competing solutions are 
emerging. Herb Sutter seems to have focused his cppcon talk on 
Rust style memory management in C++. The adoption of Rust does 
force the C++ designers to switch gears and hopefully the 
competition will create a push for better solutions.

That applies to D too, I think.

Rust also aims for commercial level stability for Rust 1.4. (I 
don't think they will be able to, but let's see.) This is also a 
threat for C++.
Sep 23 2015
parent reply ponce <contact gam3sfrommars.fr> writes:
On Wednesday, 23 September 2015 at 10:03:28 UTC, Ola Fosheim 
Grøstad wrote:

 Another question is: what kind of competing solutions are 
 emerging. Herb Sutter seems to have focused his cppcon talk on 
 Rust style memory management in C++. The adoption of Rust does 
 force the C++ designers to switch gears and hopefully the 
 competition will create a push for better solutions.


Nitpick: "Rust style memory management" aka scoped ownership 
originated in C++ AFAIK, with auto_ptr and Boost containers of 
owned objects.

Rust enforces it but did not invent it.
Sep 23 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 23 September 2015 at 11:54:09 UTC, ponce wrote:

 Nitpick: "Rust style memory management" aka scoped ownership 
 originated in C++ AFAIK, with auto_ptr and Boost containers of 
 owned objects.

 Rust enforces it but did not invent it.


It's been around a long time... C++ tend to absorb features, not 
invent them.

https://en.wikipedia.org/wiki/Substructural_type_system
Sep 23 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 The thing is that a lot of people who use D don't mind the lack 
 of IDE support. One reason is that D doesn't need it as badly 
 as e.g. Java or C++.


These are bad excuses.
Sep 22 2015
parent Chris <wendlec tcd.ie> writes:
On Tuesday, 22 September 2015 at 17:42:27 UTC, deadalnix wrote:

 On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 The thing is that a lot of people who use D don't mind the 
 lack of IDE support. One reason is that D doesn't need it as 
 badly as e.g. Java or C++.


 These are bad excuses.


Not an excuse, an explanation. Two different things.

Since the D community is not big nor backed by a huge 
corporation, people who want something have to work on it 
themselves. There simply is no other way.
Sep 23 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:


 It's almost exclusively due to the error messages and IDE. I 
 know many here will write off such complaints, So be it.


 The thing is that a lot of people who use D don't mind the lack 
 of IDE support.


IDE is not just a nice interface to write code. It's a way to 
organize files, AST based file browsing, github integration, and 
- the most important aspect for me - is the *integrated debugging 
support*. I'll never use dmd from command line and the lack of 
IDE support would be definitely a stopper for me.

The same people not minding the lack of IDE support are usually 
the Linux guys. Personally, I don't know any Windows developer 
masochistic enough to use the command line when an IDE is 
available for the task described above.
Sep 23 2015
next sibling parent reply Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 
 Personally, I don't know any Windows developer masochistic 
 enough to use the command line when an IDE is available for the 
 task described above.


Nice to meet you, rumbu!
Now you know one!

;-P

---
Paolo
Sep 23 2015
parent reply rumbu <rumbu rumbu.ro> writes:
On Wednesday, 23 September 2015 at 19:52:11 UTC, Paolo Invernizzi 
wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 
 Personally, I don't know any Windows developer masochistic 
 enough to use the command line when an IDE is available for 
 the task described above.


 Nice to meet you, rumbu!
 Now you know one!

 ;-P

 ---
 Paolo


Nice to meet you too, Paolo. Browsing through your posts, I saw 
that you are using "mainly Mono-D" :) Don't tell me that you are 
coloring the keywords in your code using a marker.
Sep 23 2015
next sibling parent reply Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 On Wednesday, 23 September 2015 at 19:52:11 UTC, Paolo 
 Invernizzi wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 
 Personally, I don't know any Windows developer masochistic 
 enough to use the command line when an IDE is available for 
 the task described above.


 Nice to meet you, rumbu!
 Now you know one!

 ;-P

 ---
 Paolo


 Nice to meet you too, Paolo. Browsing through your posts, I saw 
 that you are using "mainly Mono-D" :) Don't tell me that you 
 are coloring the keywords in your code using a marker.


Well, for the most-important-task you wrote, debugging, I still 
prefer the command line, but I admit, on linux/osx; under 
windows, VisualD is really a viable choice for debugging.

;-P

For git and file organization, nope, I still prefer to use them 
outside the IDE...

Cheers!
---
Paolo
Sep 23 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/09/2015 22:33, Paolo Invernizzi wrote:

 For git and file organization, nope, I still prefer to use them outside
 the IDE...

 Cheers!
 ---
 Paolo


But are you using command-line git, or a git graphical frontend like Git 
For Windows from Github?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
parent Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Friday, 25 September 2015 at 10:42:26 UTC, Bruno Medeiros 
wrote:

 On 23/09/2015 22:33, Paolo Invernizzi wrote:

 For git and file organization, nope, I still prefer to use 
 them outside
 the IDE...

 Cheers!
 ---
 Paolo


 But are you using command-line git, or a git graphical frontend 
 like Git For Windows from Github?


Command line git...

---
Paolo
Sep 26 2015
prev sibling next sibling parent reply Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 On Wednesday, 23 September 2015 at 19:52:11 UTC, Paolo 
 Invernizzi wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 
 Personally, I don't know any Windows developer masochistic 
 enough to use the command line when an IDE is available for 
 the task described above.


 Nice to meet you, rumbu!
 Now you know one!

 ;-P

 ---
 Paolo


 Nice to meet you too, Paolo. Browsing through your posts, I saw 
 that you are using "mainly Mono-D" :) Don't tell me that you 
 are coloring the keywords in your code using a marker.


"Not using an IDE" does not mean "programming with cat" - most 
text editors have syntax highlighting...

Anyways, I've also used to be one of these Windows developers 
masochistic enough to use the command line. I've used it back 

files by hand(deep down they resemble Ant, but Visual Studio 
seems to be writing all sorts of crap in there) and build the 
projects from the command line using MSBuild, but it was worth it 
because it means I could build seamlessly from Vim, and I could 
write deployment scripts that run on the server.

That being said - when I said "used to be" it's not because I'm 
no longer a "masochist", but because I'm no longer a Windows 
developer(so yes, I'm no longer a masochist...) - so you can say 
I was already in the Linux developer mindset and it's no surprise 
I preferred the command line. Even back then, I was disturbed by 
the fact that so many programmers feel uncomfortable with the 
idea of typing textual commands to make computers do things...
Sep 23 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 23 September 2015 at 22:12:47 UTC, Idan Arye wrote:

 On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 On Wednesday, 23 September 2015 at 19:52:11 UTC, Paolo 
 Invernizzi wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 
 Personally, I don't know any Windows developer masochistic 
 enough to use the command line when an IDE is available for 
 the task described above.


 Nice to meet you, rumbu!
 Now you know one!

 ;-P

 ---
 Paolo


 Nice to meet you too, Paolo. Browsing through your posts, I 
 saw that you are using "mainly Mono-D" :) Don't tell me that 
 you are coloring the keywords in your code using a marker.


 "Not using an IDE" does not mean "programming with cat" - most 
 text editors have syntax highlighting...

 Anyways, I've also used to be one of these Windows developers 
 masochistic enough to use the command line. I've used it back 

 .csproj files by hand(deep down they resemble Ant, but Visual 
 Studio seems to be writing all sorts of crap in there) and 
 build the projects from the command line using MSBuild, but it 
 was worth it because it means I could build seamlessly from 
 Vim, and I could write deployment scripts that run on the 
 server.

 That being said - when I said "used to be" it's not because I'm 
 no longer a "masochist", but because I'm no longer a Windows 
 developer(so yes, I'm no longer a masochist...) - so you can 
 say I was already in the Linux developer mindset and it's no 
 surprise I preferred the command line. Even back then, I was 
 disturbed by the fact that so many programmers feel 
 uncomfortable with the idea of typing textual commands to make 
 computers do things...


I, for one, was very excited when I found out that you could 
actually run VS builds from the command line rather than having 
to open up VS. And at my last job, I redid our build stuff so 
that we used cmake to generate the build stuff for both Linux and 
Windows so that we didn't have two build systems to maintain, and 
with that, the _only_ reason that I ever had to open up VS was to 
debug on Windows. It was great.

Unfortunately, at my current job, we're entirely Windows, so 
everything's a huge mess in VS rather than using cmake, and most 
of the devs are totally Windows devs, so they'd probably freak 
out at the idea that the .vcproj files are generated, and you 
don't edit any settings inside of VS. So, there's no way that I'm 
going to get the beauty of cmake again here. I'm forced to open 
up VS more - and we're using the muck that is TFS, which pretty 
much requires opening up VS to manage source control (though the 
TFS power tools help). So, unfortunately, I end up having VS open 
almost all the time now, even if I almost never use it for 
editing. Windows _really_ isn't for me, but when it's what's used 
at your job, you don't have much choice...

I do kind of wonder though what MS would do if the majority of 
Windows programmers really got a taste of how great the command 
line is and started complaining to MS en masse about how MS needs 
to have a proper command line - preferably even port over 
something like bash or zsh with all of the fantastic tools that 
come with that. I don't see any reason why they couldn't do that, 
but they're completely focused on GUIs and doing their own thing.

- Jonathan M Davis
Sep 24 2015
next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
wrote:

 I do kind of wonder though what MS would do if the majority of 
 Windows programmers really got a taste of how great the command 
 line is and started complaining to MS en masse about how MS 
 needs to have a proper command line - preferably even port over 
 something like bash or zsh with all of the fantastic tools that 
 come with that. I don't see any reason why they couldn't do 
 that, but they're completely focused on GUIs and doing their 
 own thing.

 - Jonathan M Davis


Probably nothing, since they have PowerShell

https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands
Sep 24 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/09/15 4:11 PM, Sebastiaan Koppe wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis wrote:

 I do kind of wonder though what MS would do if the majority of Windows
 programmers really got a taste of how great the command line is and
 started complaining to MS en masse about how MS needs to have a proper
 command line - preferably even port over something like bash or zsh
 with all of the fantastic tools that come with that. I don't see any
 reason why they couldn't do that, but they're completely focused on
 GUIs and doing their own thing.

 - Jonathan M Davis


 Probably nothing, since they have PowerShell

 https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands


Unfortunately yup that is there replacement.
Funny thing, the only people really using it are networkers. Not 
programmers. Who would have thought?
Sep 24 2015
next sibling parent reply jdeath <jdeath jdeath.com> writes:
On Friday, 25 September 2015 at 04:38:36 UTC, Rikki Cattermole 
wrote:

 On 25/09/15 4:11 PM, Sebastiaan Koppe wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
 wrote:

 I do kind of wonder though what MS would do if the majority 
 of Windows
 programmers really got a taste of how great the command line 
 is and
 started complaining to MS en masse about how MS needs to have 
 a proper
 command line - preferably even port over something like bash 
 or zsh
 with all of the fantastic tools that come with that. I don't 
 see any
 reason why they couldn't do that, but they're completely 
 focused on
 GUIs and doing their own thing.

 - Jonathan M Davis


 Probably nothing, since they have PowerShell

 https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands


 Unfortunately yup that is there replacement.
 Funny thing, the only people really using it are networkers. 
 Not programmers. Who would have thought?



you guys are nuts.
instead of thinking about this shit, you should think about how 
to make D usable for windows programmers.
don't think about linux crutsches. in my company people are not 
even willing to think about D, since it has stone age tools, few 
usable libraries and is changing at a rate that is incredible.
Sep 24 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/09/15 5:55 PM, jdeath wrote:

 On Friday, 25 September 2015 at 04:38:36 UTC, Rikki Cattermole wrote:

 On 25/09/15 4:11 PM, Sebastiaan Koppe wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis wrote:

 I do kind of wonder though what MS would do if the majority of Windows
 programmers really got a taste of how great the command line is and
 started complaining to MS en masse about how MS needs to have a proper
 command line - preferably even port over something like bash or zsh
 with all of the fantastic tools that come with that. I don't see any
 reason why they couldn't do that, but they're completely focused on
 GUIs and doing their own thing.

 - Jonathan M Davis


 Probably nothing, since they have PowerShell

 https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands


 Unfortunately yup that is there replacement.
 Funny thing, the only people really using it are networkers. Not
 programmers. Who would have thought?



 you guys are nuts.
 instead of thinking about this shit, you should think about how to make
 D usable for windows programmers.
 don't think about linux crutsches. in my company people are not even
 willing to think about D, since it has stone age tools, few usable
 libraries and is changing at a rate that is incredible.



Yeahhhh I totally only think about *nix.
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/platform.d

Even though my main pc is Windows and I use Cygwin.

I'm doing my best to fix this situation. It is not an easy one to do.
Sorry I get that you want it done *now*, but unless you are willing to 
help, it won't be done any faster.
Sep 24 2015
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 25 September 2015 at 05:55:08 UTC, jdeath wrote:

 you guys are nuts.
 instead of thinking about this shit, you should think about how 
 to make D usable for windows programmers.


I also write D on windows.


 don't think about linux crutsches. in my company people are not 
 even willing to think about D, since it has stone age tools, 
 few usable libraries and is changing at a rate that is 
 incredible.


Maybe D just isn't for them? No harm. It certainly requires early 
adopters and a leap of faith. That clashes with most businesses. 
I can't blame them.
Sep 25 2015
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 05:55:08 UTC, jdeath wrote:

 you guys are nuts.
 instead of thinking about this shit, you should think about how 
 to make D usable for windows programmers.
 don't think about linux crutsches. in my company people are not 
 even willing to think about D, since it has stone age tools, 
 few usable libraries and is changing at a rate that is 
 incredible.



There are people working on writing and supporting tools that fit 
better with the mindset of many Windows-centric devs (e.g. that's 
why we have VisualD). But for the most part, the kinds of folks 
who have been using D don't seem to care much about that sort of 
thing, and there's tons of other stuff to work on, so many of 
them work on other stuff. With open source projects, folks tend 
to work on what they care about or view as important. For some 
folks, that's IDEs and build tools and the like, but for many 
others, it's the language itself or libraries.

You can choose to use D or not, and you can choose to work on 
D-related stuff or not (which could be GUI-centric tools if 
that's what you care about), but just because you want something 
doesn't mean that that's what the other folks working on a 
project want or care about it, and just because the folks that 
you work with don't like where D is with Windows-centric tools 
doesn't mean that D is a lost cause. It just means that it 
doesn't fit what you're looking for right now.

- Jonathan M Davis
Sep 25 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 05:55:08 UTC, jdeath wrote:

 you guys are nuts.


Of course we are! Else we wouldn't embrace something that the 
mainstream shies away from and that doesn't make us rich. But can 
you rule it out that in 15 years the guys in your company will 
marvel at D saying "Fair f**ks to them guys, they kept on pushing 
it and now we have something really nice to work with"?


 instead of thinking about this shit, you should think about how 
 to make D usable for windows programmers.


You're welcome to write plugins for D. It's come up on this forum 
so many times that I don't care to remember, but the answer still 
is: You want it - do it yourself. D is not a restaurant like Java 

eat, open the fridge, get the ingredients and cook something.


 don't think about linux crutsches. in my company people are not 
 even willing to think about D, since it has stone age tools, 
 few usable libraries and is changing at a rate that is 
 incredible.



And would they really care, if D had all the nice tools? Or would 
they say that in VS there's a yellow button to compile and run 


As so often we're mixing the language with _tools_ for the 
language here.
Sep 25 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 25 September 2015 at 04:38:36 UTC, Rikki Cattermole 
wrote:

 On 25/09/15 4:11 PM, Sebastiaan Koppe wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
 wrote:

 I do kind of wonder though what MS would do if the majority 
 of Windows
 programmers really got a taste of how great the command line 
 is and
 started complaining to MS en masse about how MS needs to have 
 a proper
 command line - preferably even port over something like bash 
 or zsh
 with all of the fantastic tools that come with that. I don't 
 see any
 reason why they couldn't do that, but they're completely 
 focused on
 GUIs and doing their own thing.

 - Jonathan M Davis


 Probably nothing, since they have PowerShell

 https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands


 Unfortunately yup that is there replacement.
 Funny thing, the only people really using it are networkers. 
 Not programmers. Who would have thought?



This is not funny even for an Windows admin. Managing Microsoft 
Exchange is done 90% from command line, and our mail admin is 
complaining constantly for the lack of desktop tools (we even 
bought some gui tools for that). Luckily, the last Exchange 
version has a nice web interface for administration. Command line 
is limited for visual tasks like adding and resizing pictures of 
the employees in the address book, for example.

I don't buy this, command line is something obsolete compared to 
any gui/web interface, at least in Windows world.

Starting Visual Studio on my machine takes 2 seconds, i don't buy 
either the fact it's easier to write your own batch file to 
compile code instead of clicking some checkboxes or switching 
instantly between Debug/Release versions of your code. And I 
don't use dub, last time I checked, it's messing with my AppData 
folder. I prefer to press F6 to compile my code.
Sep 25 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 On Friday, 25 September 2015 at 04:38:36 UTC, Rikki Cattermole 
 wrote:

 On 25/09/15 4:11 PM, Sebastiaan Koppe wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M 
 Davis wrote:

 I do kind of wonder though what MS would do if the majority 
 of Windows
 programmers really got a taste of how great the command line 
 is and
 started complaining to MS en masse about how MS needs to 
 have a proper
 command line - preferably even port over something like bash 
 or zsh
 with all of the fantastic tools that come with that. I don't 
 see any
 reason why they couldn't do that, but they're completely 
 focused on
 GUIs and doing their own thing.

 - Jonathan M Davis


 Probably nothing, since they have PowerShell

 https://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands


 Unfortunately yup that is there replacement.
 Funny thing, the only people really using it are networkers. 
 Not programmers. Who would have thought?



 This is not funny even for an Windows admin. Managing Microsoft 
 Exchange is done 90% from command line, and our mail admin is 
 complaining constantly for the lack of desktop tools (we even 
 bought some gui tools for that). Luckily, the last Exchange 
 version has a nice web interface for administration. Command 
 line is limited for visual tasks like adding and resizing 
 pictures of the employees in the address book, for example.

 I don't buy this, command line is something obsolete compared 
 to any gui/web interface, at least in Windows world.


Perhaps you've been very lucky with the quality of the 
built-for-purpose GUI tools you've had to use?


 Starting Visual Studio on my machine takes 2 seconds,


What magic are you doing to achieve this? It has always taken >30 
seconds on mine.


 i don't buy either the fact it's easier to write your own batch 
 file to compile code instead of clicking some checkboxes or 
 switching instantly between Debug/Release versions of your code.


It's about trading a tiny amount of convenience for a much larger 
payoff in control, simplicity, extensibility and reproducibility. 
There's are middle ways as well, like using one of the many build 
tools out there, perhaps with some IDE integration if you really 
must.


 And I don't use dub, last time I checked, it's messing with my 
 AppData folder.


"I don't use this program, it's storing internally used data in 
the folder specifically designated for programs to store 
internally used data in" whut?
Sep 25 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 Starting Visual Studio on my machine takes 2 seconds,


 What magic are you doing to achieve this? It has always taken

30 seconds on mine.




LOL. On my work computer (which is no slouch), it takes something 
like two or three minutes to actually be usable, where it's 
frozen, saying "not responding." gvim, on the other hand, starts 
instantly.

- Jonathan M Davis
Sep 25 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis 
wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 Starting Visual Studio on my machine takes 2 seconds,


 What magic are you doing to achieve this? It has always taken

30 seconds on mine.




 LOL. On my work computer (which is no slouch), it takes 
 something like two or three minutes to actually be usable, 
 where it's frozen, saying "not responding." gvim, on the other 
 hand, starts instantly.

 - Jonathan M Davis


Yeah that >30 seconds was probably being generous. It's quite 
rare to see <60.
Sep 25 2015
parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 25 September 2015 at 09:05:31 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis 
 wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin 
 wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 Starting Visual Studio on my machine takes 2 seconds,


 What magic are you doing to achieve this? It has always taken

30 seconds on mine.




 LOL. On my work computer (which is no slouch), it takes 
 something like two or three minutes to actually be usable, 
 where it's frozen, saying "not responding." gvim, on the other 
 hand, starts instantly.

 - Jonathan M Davis


 Yeah that >30 seconds was probably being generous. It's quite 
 rare to see <60.


Sorry, I was wrong, below 2 seconds, measured using Passmark 
AppTimer:

Visual Studio 2013 Ultimate - 5 executions
C:\Program Files (x86)\Microsoft Visual Studio 
12.0\Common7\IDE\devenv.exe - 5 executions
1.3741
1.2808
1.3419
1.2802
1.3440


Silverlight client, Android client, various libs, 60 kloc) - 9 
seconds.

Windows 10 64 bit, Intel Core i7 3612QM, 16G RAM, SSD.

Now, comparing this to the timings you posted, I understand why 
you prefer to use the command line and text editors. Me, I don't 
have *any* reason to go back in time 20 years ago, I hate that 
black & white thing on my screen.
Sep 25 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/25/2015 12:45 PM, rumbu wrote:

 ... Me, I don't have *any* reason to go back in time
 20 years ago,


I'd advise to stop making those ridiculous and disrespectful statements. 
It's slightly annoying and does not add anything to your point.


 I hate that black & white thing on my screen.


You have made it very clear that your bar for calling something an "IDE" 
isn't syntax highlighting.
Sep 25 2015
parent rumbu <rumbu rumbu.ro> writes:
On Friday, 25 September 2015 at 11:13:38 UTC, Timon Gehr wrote:

 On 09/25/2015 12:45 PM, rumbu wrote:

 ... Me, I don't have *any* reason to go back in time
 20 years ago,


 I'd advise to stop making those ridiculous and disrespectful 
 statements. It's slightly annoying and does not add anything to 
 your point.


Is that more ridiculous or disrespectful than following 
statements?


 "I don't use this program, it's storing internally used data 
 in the
 folder specifically designated for programs to store 
 internally used
 data in" whut?




or


 Yeah I hate such programs too... even more than the ones that 
 create temporary files in >> the system temporary folder !!




I didn't start the gratuitous sarcasm. Even that's only truth in 
my words, there are more than 20 years since DOS era. And since 
Borland reinvented the IDE in the DOS world.
Sep 25 2015
prev sibling parent reply Dogbreath <tootie yahoo.com> writes:
On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis 
wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 Starting Visual Studio on my machine takes 2 seconds,


 What magic are you doing to achieve this? It has always taken

30 seconds on mine.




 LOL. On my work computer (which is no slouch), it takes 
 something like two or three minutes to actually be usable, 
 where it's frozen, saying "not responding." gvim, on the other 
 hand, starts instantly.

 - Jonathan M Davis


vs starts is usable in about 2 second for me also.  Try using a 
computer from the modern era with an SSD.
Oct 09 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 9 October 2015 at 21:17:16 UTC, Dogbreath wrote:

 On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis 
 wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin 
 wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 Starting Visual Studio on my machine takes 2 seconds,


 What magic are you doing to achieve this? It has always taken

30 seconds on mine.




 LOL. On my work computer (which is no slouch), it takes 
 something like two or three minutes to actually be usable, 
 where it's frozen, saying "not responding." gvim, on the other 
 hand, starts instantly.

 - Jonathan M Davis


 vs starts is usable in about 2 second for me also.  Try using a 
 computer from the modern era with an SSD.


LOL. I _do_ use a computer with an SSD.

- Jonathan M Davis
Oct 09 2015
parent reply Kagamin <spam here.lot> writes:
On Friday, 9 October 2015 at 21:24:52 UTC, Jonathan M Davis wrote:

 vs starts is usable in about 2 second for me also.  Try using 
 a computer from the modern era with an SSD.


 LOL. I _do_ use a computer with an SSD.


On my machine vs2013 starts in 3 seconds: core i5 3470, 8gb RAM 
(3gb in use, 3gb cached), HDD 7200 rpm.
Oct 12 2015
next sibling parent Kagamin <spam here.lot> writes:
Also antivirus scans all processes on start or so my colleague 
reports, I didn't confirm it myself.
Oct 12 2015
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 12 October 2015 at 10:25:49 UTC, Kagamin wrote:

 On Friday, 9 October 2015 at 21:24:52 UTC, Jonathan M Davis 
 wrote:

 vs starts is usable in about 2 second for me also.  Try using 
 a computer from the modern era with an SSD.


 LOL. I _do_ use a computer with an SSD.


 On my machine vs2013 starts in 3 seconds: core i5 3470, 8gb RAM 
 (3gb in use, 3gb cached), HDD 7200 rpm.


It may have something to do with the projects that we have, but 
regardless of the reason, VS is incredibly slow to start and has 
been on every machine that I've used at my current job. 
Obviously, YMMV given that some of the folks here are saying that 
it's incredibly slow, whereas others are saying that it's quite 
fast.

- Jonathan M Davis
Oct 12 2015
parent reply Kagamin <spam here.lot> writes:
On Monday, 12 October 2015 at 12:10:15 UTC, Jonathan M Davis 
wrote:

 It may have something to do with the projects that we have, but 
 regardless of the reason, VS is incredibly slow to start and 
 has been on every machine that I've used at my current job. 
 Obviously, YMMV given that some of the folks here are saying 
 that it's incredibly slow, whereas others are saying that it's 
 quite fast.


Well, loading a solution depends on its size, it's like 
databases. VS loads the solution quickly, then loads projects 
asynchronously. While they are loading you can press F6 to build 
the solution, use source control explorer etc.
Oct 12 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 12 October 2015 at 12:41:53 UTC, Kagamin wrote:

 On Monday, 12 October 2015 at 12:10:15 UTC, Jonathan M Davis 
 wrote:

 It may have something to do with the projects that we have, 
 but regardless of the reason, VS is incredibly slow to start 
 and has been on every machine that I've used at my current 
 job. Obviously, YMMV given that some of the folks here are 
 saying that it's incredibly slow, whereas others are saying 
 that it's quite fast.


 Well, loading a solution depends on its size, it's like 
 databases. VS loads the solution quickly, then loads projects 
 asynchronously. While they are loading you can press F6 to 
 build the solution, use source control explorer etc.


VS outright freezes with Windows saying that it's "not 
responding" for a couple of when I start it up. So, whatever it's 
up to, I can't do _anything_ with it for a couple of minutes. The 
rest of the box is usable while that happens, but not VS.

- Jonathan M Davis
Oct 12 2015
parent reply Kagamin <spam here.lot> writes:
Asynchronous loading was implemented in vs2013 (or 2012). vs2010 
loads projects synchronously and freezes until it's all done.
Oct 14 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 14 October 2015 at 09:16:14 UTC, Kagamin wrote:

 Asynchronous loading was implemented in vs2013 (or 2012). 
 vs2010 loads projects synchronously and freezes until it's all 
 done.


That's curious. I'm using VS 2013, but the solution and most of 
the projects are 2010. Maybe it retains the old behavior for 
older solutions/projects, and that's why it's freezing.

Regardless, it does seem kind of pathetic for it to take VS a 
couple of minutes to load some text files into memory and get 
things set up (whether it's synchronous or not). I'd be very 
surprised if it could not be improved, though the async load that 
I don't seem to be getting would certainly help.

- Jonathan M Davis
Oct 14 2015
prev sibling next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2015 09:53, John Colvin wrote:

 And I don't use dub, last time I checked, it's messing with my AppData
 folder.


 "I don't use this program, it's storing internally used data in the
 folder specifically designated for programs to store internally used
 data in" whut?


Yeah I hate such programs too... even more than the ones that create 
temporary files in the system temporary folder !!
</sarcasm>

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:


 And I don't use dub, last time I checked, it's messing with my 
 AppData folder.


 "I don't use this program, it's storing internally used data in 
 the folder specifically designated for programs to store 
 internally used data in" whut?


The AppData\Roaming folder is synchronized automatically on our 
domain controller (this is normal behaviour). Since dub is 
storing all dependencies in this folder and each user profile 
storage is limited, I'd prefer to have control over this space. 
More than that comparing thousands of source code files at each 
login/logout it's not a nice thing. When I login to another 
computer, all dub data is replicated on this computer.

I hardly consider source code files as "internal used data".

That's why I said it's messing with my AppData folder.
Sep 25 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/09/15 10:57 PM, rumbu wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:


 And I don't use dub, last time I checked, it's messing with my
 AppData folder.


 "I don't use this program, it's storing internally used data in the
 folder specifically designated for programs to store internally used
 data in" whut?


 The AppData\Roaming folder is synchronized automatically on our domain
 controller (this is normal behaviour). Since dub is storing all
 dependencies in this folder and each user profile storage is limited,
 I'd prefer to have control over this space. More than that comparing
 thousands of source code files at each login/logout it's not a nice
 thing. When I login to another computer, all dub data is replicated on
 this computer.

 I hardly consider source code files as "internal used data".

 That's why I said it's messing with my AppData folder.


I suppose because it is only effecting you more or less and it is not 
very hard to do, you could create a custom dub binary that uses 
AppData\Local instead.
Sep 25 2015
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 25 September 2015 at 10:57:23 UTC, rumbu wrote:

 On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:

 On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:


 And I don't use dub, last time I checked, it's messing with 
 my AppData folder.


 "I don't use this program, it's storing internally used data 
 in the folder specifically designated for programs to store 
 internally used data in" whut?


 The AppData\Roaming folder is synchronized automatically on our 
 domain controller (this is normal behaviour). Since dub is 
 storing all dependencies in this folder and each user profile 
 storage is limited, I'd prefer to have control over this space. 
 More than that comparing thousands of source code files at each 
 login/logout it's not a nice thing. When I login to another 
 computer, all dub data is replicated on this computer.


Fair enough, I guess this wasn't considered when dub was 
designed. Have you considered making a github issue for this 
(https://github.com/D-Programming-Language/dub)? It would be 
really great for people to be able to choose their own cache 
directory


 I hardly consider source code files as "internal used data".


Meh, don't see any important distinction.
Sep 25 2015
parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 25 September 2015 at 11:33:40 UTC, John Colvin wrote:

 Fair enough, I guess this wasn't considered when dub was 
 designed. Have you considered making a github issue for this 
 (https://github.com/D-Programming-Language/dub)? It would be 
 really great for people to be able to choose their own cache 
 directory


Already done 1,5 years ago: 
https://github.com/D-Programming-Language/dub/issues/229
Sep 25 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 25 September 2015 at 11:50:43 UTC, rumbu wrote:

 On Friday, 25 September 2015 at 11:33:40 UTC, John Colvin wrote:

 Fair enough, I guess this wasn't considered when dub was 
 designed. Have you considered making a github issue for this 
 (https://github.com/D-Programming-Language/dub)? It would be 
 really great for people to be able to choose their own cache 
 directory


 Already done 1,5 years ago: 
 https://github.com/D-Programming-Language/dub/issues/229


I posted a link to these few messages, hopefully we'll see some 
movement on it. Do you have a github account to participate on 
the discussion there? If your circumstances are as common as you 
say they are, it would useful to have your experience on board.
Sep 25 2015
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 25.09.2015 um 14:42 schrieb John Colvin:

 On Friday, 25 September 2015 at 11:50:43 UTC, rumbu wrote:

 On Friday, 25 September 2015 at 11:33:40 UTC, John Colvin wrote:

 Fair enough, I guess this wasn't considered when dub was designed.
 Have you considered making a github issue for this
 (https://github.com/D-Programming-Language/dub)? It would be really
 great for people to be able to choose their own cache directory


 Already done 1,5 years ago:
 https://github.com/D-Programming-Language/dub/issues/229


 I posted a link to these few messages, hopefully we'll see some movement
 on it. Do you have a github account to participate on the discussion
 there? If your circumstances are as common as you say they are, it would
 useful to have your experience on board.


This is also an issue at which anyone could have a go. It requires 
splitting up the single user path into configuration and package cache 
parts, but all in all it's a pretty simple change (everything related 
happens in dub.d).
Sep 25 2015
prev sibling parent ponce <contact gam3sfrommars.fr> writes:
On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:

 I don't buy this, command line is something obsolete compared 
 to any gui/web interface, at least in Windows world.


I don't get this, Windows shops have programmers and the 
command-line is used as much as everywhere.
Sep 25 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 

wrote:


On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
wrote:

 I do kind of wonder though what MS would do if the majority of 
 Windows programmers really got a taste of how great the command 
 line is and started complaining to MS en masse about how MS 
 needs to have a proper command line - preferably even port over 
 something like bash or zsh with all of the fantastic tools that 
 come with that. I don't see any reason why they couldn't do 
 that, but they're completely focused on GUIs and doing their 
 own thing.


MYSYS 2[1] is bash for Windows and has many Linux tools 
available, using packman to manage them. Then there's also git 
Bash[2], which is primarily focused on git but does provide other 
tools (nowhere near what's available for MSYS 2, though).

[1] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
[2] https://git-for-windows.github.io/
Sep 24 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 04:26:26 UTC, Mike Parker wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis

wrote:


 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
 wrote:

 I do kind of wonder though what MS would do if the majority of 
 Windows programmers really got a taste of how great the 
 command line is and started complaining to MS en masse about 
 how MS needs to have a proper command line - preferably even 
 port over something like bash or zsh with all of the fantastic 
 tools that come with that. I don't see any reason why they 
 couldn't do that, but they're completely focused on GUIs and 
 doing their own thing.


 MYSYS 2[1] is bash for Windows and has many Linux tools 
 available, using packman to manage them. Then there's also git 
 Bash[2], which is primarily focused on git but does provide 
 other tools (nowhere near what's available for MSYS 2, though).

 [1] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
 [2] https://git-for-windows.github.io/


I currently use the bash shell that gets installed with git (so I 
assume that that's the git bash that you mention), and it's a 
significant improvement over having to deal with what Windows 
provides, but it's still a far cry from actually having a 
full-blown *nix environment. I'll have to take a look at msys at 
some point, and maybe I should look at cygwin again (I had a 
number of problems with it when I tried it last, but that was 
several years ago now).

- Jonathan M Davis
Sep 25 2015
prev sibling next sibling parent ponce <contact gam3sfrommars.fr> writes:
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
wrote:

 Unfortunately, at my current job, we're entirely Windows, so 
 everything's a huge mess in VS rather than using cmake, and 
 most of the devs are totally Windows devs, so they'd probably 
 freak out at the idea that the .vcproj files are generated, and 
 you don't edit any settings inside of VS.


When we had around 100+ .vcxproj, I started making a static 
analyzer to check them.
At 150+, someone made a build tool with versionned dependencies 
that also generated .vcxproj. It was remarkably similar to DUB.
Sep 25 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
wrote:

 I, for one, was very excited when I found out that you could 
 actually run VS builds from the command line rather than having 
 to open up VS. And at my last job, I redid our build stuff so 
 that we used cmake to generate the build stuff for both Linux 
 and Windows so that we didn't have two build systems to 
 maintain, and with that, the _only_ reason that I ever had to 
 open up VS was to debug on Windows. It was great.

 Unfortunately, at my current job, we're entirely Windows, so 
 everything's a huge mess in VS rather than using cmake, and 
 most of the devs are totally Windows devs, so they'd probably 
 freak out at the idea that the .vcproj files are generated, and 
 you don't edit any settings inside of VS. So, there's no way 
 that I'm going to get the beauty of cmake again here. I'm 
 forced to open up VS more - and we're using the muck that is 
 TFS, which pretty much requires opening up VS to manage source 
 control (though the TFS power tools help).


TFS has a CLI client. Why would you automate builds if you can't 
automate getting fresh sources from source control?
Sep 25 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 14:29:33 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis 
 wrote:

 I, for one, was very excited when I found out that you could 
 actually run VS builds from the command line rather than 
 having to open up VS. And at my last job, I redid our build 
 stuff so that we used cmake to generate the build stuff for 
 both Linux and Windows so that we didn't have two build 
 systems to maintain, and with that, the _only_ reason that I 
 ever had to open up VS was to debug on Windows. It was great.

 Unfortunately, at my current job, we're entirely Windows, so 
 everything's a huge mess in VS rather than using cmake, and 
 most of the devs are totally Windows devs, so they'd probably 
 freak out at the idea that the .vcproj files are generated, 
 and you don't edit any settings inside of VS. So, there's no 
 way that I'm going to get the beauty of cmake again here. I'm 
 forced to open up VS more - and we're using the muck that is 
 TFS, which pretty much requires opening up VS to manage source 
 control (though the TFS power tools help).


 TFS has a CLI client. Why would you automate builds if you 
 can't automate getting fresh sources from source control?


I don't know what you mean by automating in this context. I'm not 
automating anything. This is all stuff that I'm doing as I 
develop, not stuff dealing with nightly builds or anything like 
that. Do you mean build from the command line? I did that at my 
previous job where we were using cmake and had made the directory 
structure very neat, and all of the VS stuff was separate from 
the actual code, since we didn't build in the source directories, 
but at my current job, everything was set up with VS by folks who 
use VS for everything, and the directory structure is a complete 
mess, making doing stuff from the command line a lot messier than 
it should be. I have done some TFS stuff from the command line 
but not a lot, since I'm stuck having the GUI open anyway, and I 
tend to touch TFS with kid gloves, because it seems to behave 
badly in general, and I have to be really careful that I don't do 
something like commit code from multiple branches at the same 
time or merge stuff badly.

What I really want to do is use git-tfs (and maybe even use that 
in an attempt to convince folks to switch to git from TFS), but 
for some reason, it doesn't work correctly with our repos - it 
doesn't pull in a lot of the files, making it unusable. The sad 
thing is that when they chose TFS a while back (before I was 
working there), the lead dev was pushing for Mercurial, but the 
other folks didn't listen, and he lost (even though he had 
Mercurial up and running very quickly, and they took over a week 
to sort out TFS). So, we could have had decent source control, 
but we're stuck with TFS instead - probably because most of the 
devs involved are too Windows-centric. And given how messy the 
TFS branching stuff is (e.g. it doesn't retain history when 
merging), I bet that using git or mercurial would save our build 
guy a ton of time, but he just wants to use TFS and thinks that 
it's great (probably because it's what he's used to, and it's 
from MS).

- Jonathan M Davis
Sep 25 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 14:54:53 UTC, Jonathan M Davis 
wrote:

 Do you mean build from the command line? I did that at my 
 previous job where we were using cmake and had made the 
 directory structure very neat, and all of the VS stuff was 
 separate from the actual code, since we didn't build in the 
 source directories, but at my current job, everything was set 
 up with VS by folks who use VS for everything, and the 
 directory structure is a complete mess, making doing stuff from 
 the command line a lot messier than it should be.


Doesn't msbuild build it? We have our projects set up with VS 
too, and it's built by msbuild just fine in a single command. In 
fact one of our developers builds the solution from command line 
too and he uses CLI TFS cilent.


 So, we could have had decent source control, but we're stuck 
 with TFS instead - probably because most of the devs involved 
 are too Windows-centric.


TFS is also a bug tracker integrated with source control, like 
Fossil.


 And given how messy the TFS branching stuff is (e.g. it doesn't 
 retain history when merging)


It shows commit history as a tree for me with branches where they 
came from.
Sep 25 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 15:21:34 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 14:54:53 UTC, Jonathan M Davis 
 wrote:

 Do you mean build from the command line? I did that at my 
 previous job where we were using cmake and had made the 
 directory structure very neat, and all of the VS stuff was 
 separate from the actual code, since we didn't build in the 
 source directories, but at my current job, everything was set 
 up with VS by folks who use VS for everything, and the 
 directory structure is a complete mess, making doing stuff 
 from the command line a lot messier than it should be.


 Doesn't msbuild build it? We have our projects set up with VS 
 too, and it's built by msbuild just fine in a single command. 
 In fact one of our developers builds the solution from command 
 line too and he uses CLI TFS cilent.


I don't know. I've never used msbuild (I've always used devenv 
when building from the command line), but I frequently need to 
build individual projects and not just the whole solution as 
well, so simply telling it to build everything wouldn't always be 
what I would need. I could definitely do it on the command line 
regardless, but I need the debugger often enough at this point, 
that I just leave VS open and use it to build and deal with TFS, 
though I do use gvim for editing.

At my last job, I could do almost everything in Linux and mostly 
just used Windows to make sure that the Windows build worked or 
occasionally to debug something if the app in question were for 
Windows (the libraries were cross-platform, but the applications 
weren't). So, I rarely needed VS, and building from the command 
line was simpler. Where I am now, I need VS for debugging often 
enough that it's less of a gain. I may try and figure out how to 
use TFS from the command line though and do more there instead.


 So, we could have had decent source control, but we're stuck 
 with TFS instead - probably because most of the devs involved 
 are too Windows-centric.


 TFS is also a bug tracker integrated with source control, like 
 Fossil.


Yes, but that still doesn't make it a good choice to use. There 
are plenty of other bug trackers (some of which are free). And 
even if you want to use TFS for your bug tracker, it actually 
supports git for source control. And given how truly horrible TFS 
is as source control, I don't understand how anyone could use it 
unless they're forced to or simply don't know better.


 And given how messy the TFS branching stuff is (e.g. it 
 doesn't retain history when merging)


 It shows commit history as a tree for me with branches where 
 they came from.


I don't know. I don't manage our branches, but I was told that 
the commit history was lost when merging. If that's not 
necessarily the case, maybe it has something to do with how our 
build guy does things. If so, that might have something to do 
with why git-tfs doesn't work with our repos. Our build guy could 
just be doing something weird that screws with things.

- Jonathan M Davis
Sep 25 2015
prev sibling parent Idan Arye <GenericNPC gmail.com> writes:
On Friday, 25 September 2015 at 15:21:34 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 14:54:53 UTC, Jonathan M Davis 
 wrote:

 Do you mean build from the command line? I did that at my 
 previous job where we were using cmake and had made the 
 directory structure very neat, and all of the VS stuff was 
 separate from the actual code, since we didn't build in the 
 source directories, but at my current job, everything was set 
 up with VS by folks who use VS for everything, and the 
 directory structure is a complete mess, making doing stuff 
 from the command line a lot messier than it should be.


 Doesn't msbuild build it? We have our projects set up with VS 
 too, and it's built by msbuild just fine in a single command. 
 In fact one of our developers builds the solution from command 
 line too and he uses CLI TFS cilent.


I've actually encountered some heavily configured Visual Studio 
projects that could be build from Visual Studio but not from 
MSBuild. Never got to dig deep enough to figure out why - I 
suspect it has something to do with the solution arrangement in 
one of them, and with VS plugins in another. Should be avoidable 
if one of the devs works with MSBuild from the start - but that 
was clearly not the case here.

At any rate, I still managed to create the illusion of building 
them from the command line by keeping a open instance of Visual 
Studio in the background and using devenv to make it compile them 
when I needed to. But this method will probably not work well if 
you want to automate these builds on a server...
Sep 25 2015
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Friday, 25 September 2015 at 14:54:53 UTC, Jonathan M Davis 
wrote:

 I bet that using git or mercurial would save our build guy a 
 ton of time, but he just wants to use TFS and thinks that it's 
 great (probably because it's what he's used to, and it's from 
 MS).

 - Jonathan M Davis


Look on the bright side: at least it's not clearcase!

-Wyatt
Sep 25 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 22:15:39 UTC, Wyatt wrote:

 On Friday, 25 September 2015 at 14:54:53 UTC, Jonathan M Davis 
 wrote:

 I bet that using git or mercurial would save our build guy a 
 ton of time, but he just wants to use TFS and thinks that it's 
 great (probably because it's what he's used to, and it's from 
 MS).


 Look on the bright side: at least it's not clearcase!


Fortunately, I've never had to deal with clearcase, so I can't 
really compare. Unfortunately, there are a number of horrible 
source control systems out there though - usually proprietary.

- Jonathan M Davis
Sep 25 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 Nice to meet you too, Paolo. Browsing through your posts, I saw 
 that you are using "mainly Mono-D" :) Don't tell me that you 
 are coloring the keywords in your code using a marker.


Heh, to install 6GB IDE for a syntax highlighter, which is only 
100 LOC, doesn't sound very good.
Sep 25 2015
next sibling parent reply jdeath <jdeath jdeath.net> writes:
On Friday, 25 September 2015 at 14:34:31 UTC, Kagamin wrote:

 On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 Nice to meet you too, Paolo. Browsing through your posts, I 
 saw that you are using "mainly Mono-D" :) Don't tell me that 
 you are coloring the keywords in your code using a marker.


 Heh, to install 6GB IDE for a syntax highlighter, which is only 
 100 LOC, doesn't sound very good.


it is s shame that you people don't start thinking about what you 
need to do so that developers can easily and quickly use D on 
windows. what are the most common used libraries, interfaces to 
other software ...
instead you incense yourselves on tools that no company will 
touch (well maybe - when the decision makers are drunk) and are 
about to loose a huge part of the developers.

well good luck in the future on commandline and linux.
Sep 25 2015
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 14:50:13 UTC, jdeath wrote:


 it is s shame that you people don't start thinking about what 
 you need to do so that developers can easily and quickly use D 
 on windows. what are the most common used libraries, interfaces 
 to other software ...
 instead you incense yourselves on tools that no company will 
 touch (well maybe - when the decision makers are drunk) and are 
 about to loose a huge part of the developers.

 well good luck in the future on commandline and linux.


You're obviously interested in D, else you wouldn't be here. It'd 
be nice to get some input from you. What do you need, which 
libraries are needed, what problems did you encounter? Chances 
are that there are other Windows developers here you could hook 
up with and create something useful.
Sep 25 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 14:50:13 UTC, jdeath wrote:

 On Friday, 25 September 2015 at 14:34:31 UTC, Kagamin wrote:

 On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 Nice to meet you too, Paolo. Browsing through your posts, I 
 saw that you are using "mainly Mono-D" :) Don't tell me that 
 you are coloring the keywords in your code using a marker.


 Heh, to install 6GB IDE for a syntax highlighter, which is 
 only 100 LOC, doesn't sound very good.


 it is s shame that you people don't start thinking about what 
 you need to do so that developers can easily and quickly use D 
 on windows. what are the most common used libraries, interfaces 
 to other software ...
 instead you incense yourselves on tools that no company will 
 touch (well maybe - when the decision makers are drunk) and are 
 about to loose a huge part of the developers.

 well good luck in the future on commandline and linux.


For the record: microsoft C++ compiler tools all have command 
line interface: the compiler (cl.exe), linker, librarian. I 

library (which is not even an executable program). You think, 
these microsoft tools are not used by companies?
Sep 25 2015
prev sibling parent bachmeier <no spam.com> writes:
On Friday, 25 September 2015 at 14:50:13 UTC, jdeath wrote:


 it is s shame that you people don't start thinking about what 
 you need to do so that developers can easily and quickly use D 
 on windows.


Who are you referring to by "you people"? The paid development 
team?

That's not how D development works at the moment. It's a shame 
that Windows developers repeatedly post in the forum about all 
the troubles that they have, yet are not willing to do anything 
about it. What you are looking for is a commercial solution. That 
is not, at the present time, what you will find here.
Sep 25 2015
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2015 15:34, Kagamin wrote:

 On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:

 Nice to meet you too, Paolo. Browsing through your posts, I saw that
 you are using "mainly Mono-D" :) Don't tell me that you are coloring
 the keywords in your code using a marker.


 Heh, to install 6GB IDE for a syntax highlighter, which is only 100 LOC,
 doesn't sound very good.


FYI Eclipse with DDT installed is about 350 MB in total. Plus 150 MB for 
a Java 8 JRE, if you don't have one already.

Mind you though, I think install size should be one of the least 
important factors to consider when choosing which IDE/editor to use...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
prev sibling next sibling parent jdeath <jdeath jdeath.com> writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:





 IDE is not just a nice interface to write code. It's a way to 
 organize files, AST based file browsing, github integration, 
 and - the most important aspect for me - is the *integrated 
 debugging support*. I'll never use dmd from command line and 
 the lack of IDE support would be definitely a stopper for me.

 The same people not minding the lack of IDE support are usually 
 the Linux guys. Personally, I don't know any Windows developer 
 masochistic enough to use the command line when an IDE is 
 available for the task described above.


+100

+all the missing libs and goodies - lousy db and gui etc.
and that's why i say good bye. good bye
Sep 23 2015
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 IDE is not just a nice interface to write code. It's a way to 
 organize files, AST based file browsing, github integration, 
 and - the most important aspect for me - is the *integrated 
 debugging support*. I'll never use dmd from command line and 
 the lack of IDE support would be definitely a stopper for me.


While it is easy to agree with you, I don't think a lack of IDE 
or even libraries is something one should expect to be addressed 
by the language developer. Those are issues one can find 
solutions to if D is suitable and different people have different 
taste. Go and Rust have been in the same boat. This is not a show 
stopper...

So I hope the focus stays on language semantics, syntax, runtime 
and memory management. Emacs with D-mode works ok for now, I 
think.
Sep 23 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/09/2015 22:02, Ola Fosheim Grøstad wrote:

 IDE is not just a nice interface to write code. It's a way to organize
 files, AST based file browsing, github integration, and - the most
 important aspect for me - is the *integrated debugging support*. I'll
 never use dmd from command line and the lack of IDE support would be
 definitely a stopper for me.


 While it is easy to agree with you, I don't think a lack of IDE or even
 libraries is something one should expect to be addressed by the language
 developer. Those are issues one can find solutions to if D is suitable
 and different people have different taste. Go and Rust have been in the
 same boat. This is not a show stopper...


Dunno if "expect" is the right word, but a language team that puts IDE 
support as part of its development effort, will have a big competitive 
advantage.

D is not on the same boat as Rust here. The Rust team is investing much 
more in toolchain support (beyond the compiler and basic tools). For 
example, they contracted an external developer to help them with 
debugger issues 
(https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html). 
And more than that, they are also now effecting plans to improve their 
tools (or create new ones) to support IDE functionality ( 
https://github.com/nrc/rfcs/blob/2410d2ce1682813ea79debbf13a99868e6a6b
8a/text/0000-ide.md 
)


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros 
wrote:

 Dunno if "expect" is the right word, but a language team that 
 puts IDE support as part of its development effort, will have a 
 big competitive advantage.


Indeed, when you are production ready having a top notch IDE 
becomes a big competitive advantage! I don't know if an IDE 
attracts people who work on compilers/debuggers though...


 and basic tools). For example, they contracted an external 
 developer to help them with debugger issues


Sure, excellent debugging support (lldb/gdb) is important.
Sep 25 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 13:13:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros 
 wrote:

 Dunno if "expect" is the right word, but a language team that 
 puts IDE support as part of its development effort, will have 
 a big competitive advantage.


 Indeed, when you are production ready having a top notch IDE 
 becomes a big competitive advantage! I don't know if an IDE 
 attracts people who work on compilers/debuggers though...


 and basic tools). For example, they contracted an external 
 developer to help them with debugger issues


 Sure, excellent debugging support (lldb/gdb) is important.


Having followed this forum for 2 or 3 years now, I doubt whether 
an IDE would attract people at this stage. If we had a 
full-fledged IDE, there would be other concerns (or excuses). D 
scares people away. It's too raw, too bare bones, everything is 
still moving like hot lava, and maybe people are intimidated by 
it, because they feel they might be considered bad programmers, 
if they don't know the ins and outs of it.

Yesterday someone said too me "You must know D inside out by 
now!" I replied "I know it well enough to know that I don't know 
it well enough." There's no end to D in terms of knowledge, in 
terms of learning about programming, and this scares people away. 
They prefer a set menu, they want rules and strict guidelines. 
They want to feel comfortable and secure in what they're doing. 

no traction. D openly shows what's going on under the hood, not 
just a nice facade. But nobody really wants to see that. The 
frequent demands for an IDE are a symptom of this.
Sep 25 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:

 full-fledged IDE, there would be other concerns (or excuses). D 
 scares people away. It's too raw, too bare bones, everything is 
 still moving like hot lava, and maybe people are intimidated by


Yes, stability is important for commercial development. I notice 
some people say that you can just lock yourself to a particular 
compiler, but this does not work. Not even for C++. Yesterday I 
had to upgrade to a more recent version of clang just to get a 
library to work, which used some C++14 features.

Yet, it would be a tragedy for D to freeze on backwards 
compatibility like C++ has done. Rust and D has the advantage 
that they can move forward faster than C++. Having lots of 
commerical development in D right now would just be a drag, IMO.

Though, I think a lighter version of D geared towards embedded 
and asm.js could be a good commercial option (no gc in release, 
no exceptions, no classes, no growable slices etc). Basically 
enter a market where there is less competition (just C and 
perhaps Rust).
Sep 25 2015
next sibling parent reply David DeWitt <dkdewitt gmail.com> writes:
On Friday, 25 September 2015 at 14:21:56 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:

 full-fledged IDE, there would be other concerns (or excuses). 
 D scares people away. It's too raw, too bare bones, everything 
 is still moving like hot lava, and maybe people are 
 intimidated by


 Yes, stability is important for commercial development. I 
 notice some people say that you can just lock yourself to a 
 particular compiler, but this does not work. Not even for C++. 
 Yesterday I had to upgrade to a more recent version of clang 
 just to get a library to work, which used some C++14 features.

 Yet, it would be a tragedy for D to freeze on backwards 
 compatibility like C++ has done. Rust and D has the advantage 
 that they can move forward faster than C++. Having lots of 
 commerical development in D right now would just be a drag, IMO.

 Though, I think a lighter version of D geared towards embedded 
 and asm.js could be a good commercial option (no gc in release, 
 no exceptions, no classes, no growable slices etc). Basically 
 enter a market where there is less competition (just C and 
 perhaps Rust).


Look at Node thats stuff changes like every hour yet ppl still 
use it.  Angular 2 is breaking stuff, React and React-Router is 
changing for the next release, Rust is still changing.  C++ cant 
really just up and break backwards compatibility  at this point.

I think some people do like the structure but if you look at 
something like Node then you can see some don't.  NPM is like the 
wild west.  Even though I don't use an IDE it is important to 
have a couple decent options.  Just like its nice to have a few 
options in anything.  I can goto Python or Java and prolly have a 
few options for web development, and just about anything.  I 
think we have a few decent IDE choices but they prolly just need 
work.  Do ppl really use and IDE with Go/Rust though?

I still think a good way to get more visibility for D is Youtube. 
  Thats free advertisement and there a numerous features of D and 
Vibe that would make great video series.  Also maybe latch on to 
other things that are hot.  People are learning stuff like React, 
Redux, Flux....  Make the backend API in Vibe or something and 
make a video series and github page on it.... Im learning redux 
for work and may try and do this.  Bottomline is its hard to get 
those "Enterprisy" developers to change their ways from their 
Java/.NET world. Just focus on making good s*** and ppl will come.
Sep 25 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 25 September 2015 at 14:27:25 UTC, David DeWitt wrote:

 Look at Node thats stuff changes like every hour yet ppl still 
 use it.


I'll never understand why anyone would use node.js. The only 
explanation is that they are hellbent on using javascript for 
everything? But I guess it is no worse than Php and Perl... so 
who am I to judge.


 Angular 2 is breaking stuff,


Angular 1 users complain loudly, but Google do what they want, 
and they had to change because of the competition from other 
frameworks.


 changing for the next release, Rust is still changing.


The adoption of Rust is not high AFAICT and library dependencies 
are not high either, but the Rust devs claim that Rust 1.4 will 
be "stable and suitable for commercial"? Who knows. I think the 
current attention is more a sign of people evaluating Rust than 
actual usage, but I could be wrong. I would wait at least 1 year 
before adopting it.


 anything.  I think we have a few decent IDE choices but they 
 prolly just need work.  Do ppl really use and IDE with Go/Rust 
 though?


Emacs? I think Dart got some attention because of their rather 
good Eclipse integration, but it did not lead to a lot of user 
contribution. I think the Dart IDE primarily attracted people 
looking to create apps and not infrastructure. Google eventually 
dropped the Dart IDE (and by that time it had some annoying 
regressions).

It says a lot that Google does not focus on IDE development for 
their own langauges, but only focus on the code that can feeds 
IDEs with semantic information. A good reason is that it is 
expensive to do well, comes with a never ending maintenance cost, 
and once you get traction commercial IDEs will blow you out of 
the water anyway... So, it's an all-for-nothing investment.

Unless the language is the IDE (e.g. graphical diagrams, REPL 
etc).
Sep 25 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 14:21:56 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:

 full-fledged IDE, there would be other concerns (or excuses). 
 D scares people away. It's too raw, too bare bones, everything 
 is still moving like hot lava, and maybe people are 
 intimidated by


 Yes, stability is important for commercial development. I 
 notice some people say that you can just lock yourself to a 
 particular compiler, but this does not work. Not even for C++. 
 Yesterday I had to upgrade to a more recent version of clang 
 just to get a library to work, which used some C++14 features.

 Yet, it would be a tragedy for D to freeze on backwards 
 compatibility like C++ has done. Rust and D has the advantage 
 that they can move forward faster than C++. Having lots of 
 commerical development in D right now would just be a drag, IMO.


The funny thing is that people demand that D be changed, else 
they won't use it. And at the same time they claim they don't use 
it, because it changes too fast.
Sep 25 2015
prev sibling next sibling parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:


 Having followed this forum for 2 or 3 years now, I doubt 
 whether an IDE would attract people at this stage. If we had a 
 full-fledged IDE, there would be other concerns (or excuses). D 
 scares people away. It's too raw, too bare bones, everything is 
 still moving like hot lava, and maybe people are intimidated by 
 it, because they feel they might be considered bad programmers, 
 if they don't know the ins and outs of it.


This is very insightful, and I think goes to the heart of things. 
  (Based on what I have observed, and my experience with working 
with someone who had exactly this feeling).

I don't think it's true these days that programmers who depend on 
an IDE and on a visual debugger are mediocre programmers[*], but 
definitely mediocre programmers are scared of the command line, 
and it is in the nature of things that there are more mediocre 
programmers than not, if you have a generous definition of 
programmer.  And then because there are more of them and we live 
in a democratic age that also shapes the culture to a certain 
extent.

* I appreciate that for large projects it may become close to 
necessary for refactorings etc (not that the command line 
couldn't do it, but perhaps the tools aren't there yet because 
the IDEs get the money).

See see here for a scientific broad study of the distribution of 
ability across many professions:
https://www.evernote.com/shard/s37/sh/12b86414-ed93-472d-9a6f-db223087d869/62f13d679581134ef1d368d5b57cd2b7



 Yesterday someone said too me "You must know D inside out by 
 now!" I replied "I know it well enough to know that I don't 
 know it well enough." There's no end to D in terms of 
 knowledge, in terms of learning about programming, and this 
 scares people away.


Do you think it's true that there is no end to D, as far as the 
language itself goes?  I mean there is no end to C in terms of 
learning about programming, but that's a different point.  I 
never even really wrote object-oriented code before a couple of 
years back, let alone doing metaprogramming (unless you count 
Forth).  I've still got much to learn, but I don't feel held back 
by the vast scope of the language or anything.  Mostly if I pick 
up someone else's source I can figure out what it's doing (some 
of the template stuff goes slowly).  That's after two years of 
learning D, and after a long long break from programming.  I'm 
also 42, which means it starts to become slower to learn then 30 
years ago.

Something that accelerated the curve for me, and I know has for 
others is having top people who are very generous in sharing 
their knowledge and code to learn from.  That makes a tremendous 
difference because you get stuck along the way, and if you stay 
stuck then that journey is over.  For example, Andy Smith had a 
strange linker error, and Adam Ruppe helped him out, and actually 
even rewrote his own code for him.  Without that, probably he 
wouldn't have used D at work (for one of the largest asset 
management institutions of its sort).

Where I think we don't do such a good job is curating such 
knowledge and presenting it in a form that's easy to digest for 
newcomers.  That's also a function of the kinds of people that 
are here, because creative people don't like doing boring things 
like write documentation.  (And they have other higher-valued 
demands on their time).  I don't know what the answer is, but we 
will have to find one over time.


 D openly shows what's going on under the hood, not just a nice 
 facade. But nobody really wants to see that. The frequent 
 demands for an IDE are a symptom of this.


Nobody = only a minority numerically, but perhaps the best 
minority.  You have to decide who you are and then who it is you 
are naturally going to appeal to.  If you have something of 
intrinsic excellence (albeit imperfectly realised, as is always 
the case), you'll do much better appealing to those who can see 
through the building works to what you have, than trying, not to 
put lipstick on a pig, but putting hair extensions, fake tan, 
silicone lips, and enhancement in the female thoracic region on a 
natural beauty.

The world isn't an egalitarian place.  The people that matter, 
both in making decisions about what to use, and in influencing 
others are a tiny set.  Vilfredo Pareto spoke about this, and so 
did the Marxists in their vanguard political strategy.  Modern 
empirical work on power distributions finds the same.  So you 
have to make it easy for them to see the benefit - some of them 
are technical people, but they aren't all such.


 They prefer a set menu, they want rules and strict guidelines. 
 They want to feel comfortable and secure in what they're doing. 

 has no traction


I'm a student of social trends and it's one of the ways I make 
money.  There's a mismatch between the speed at which things 
intrinsically unfold, and our desire to see things happen 
quickly.  The credit crisis happened so slowly - it was obvious 
what was going to happen, and what the policy response would be 
back in 2004, but it was torture waiting for the world to catch 
up.  And this happens again and again, and not just in financial 
markets and economics.

Similarly if you look at the development of a nation, there are 
long periods where nothing much seems to be happening, but then 
you hit various thresholds and things go wild.  But this wasn't a 
case of overnight success, but came out of the natural 
consequences of compounding growth meeting non-linear dynamics.  
(For example, until you have decent roads your internal 
development will be held back.  But you can't afford decent roads 
until you have enough income to pay for the roads and for the 
vehicles with fuel to go on them).

D isn't failing to gain traction.  The broadly rising downloads, 
rising media interest, and so on, are objective confirmation of 
what I perceive.  It's just not in a visibly explosive stage of 
growth and people would like it to be because in 2015 we are all 
impatient.  No 1,000 years to build a cathedral for moderns.  But 
you  can't get to that saliently explosive stage of growth 
without the slow build before, which involves still more work 
without so much gratification.  That's the same with any project 
- you have to pour in love for a long time, but it doesn't love 
you back, and people around you ask what you are doing because 
all they can see is appearances.  Then when you succeed they 
marvel at the overnight success, without realizing how far the 
roots of this go back.

So if one wants D to succeed, the best way will be patiently 
working on things in front of one that may help a little.  
Self-criticism is a great thing (and intelligent people with high 
standards are prone to complain when they can't see a better 
alternative) provided it's also combined with a constructive 
spirit.  Little, kaizen, changes are great.  They fit with the 
resources we have for now, but also out of those small seeds much 
bigger things can come.
Sep 25 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 16:15:45 UTC, Laeeth Isharc wrote:

 On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:


 Having followed this forum for 2 or 3 years now, I doubt 
 whether an IDE would attract people at this stage. If we had a 
 full-fledged IDE, there would be other concerns (or excuses). 
 D scares people away. It's too raw, too bare bones, everything 
 is still moving like hot lava, and maybe people are 
 intimidated by it, because they feel they might be considered 
 bad programmers, if they don't know the ins and outs of it.


 This is very insightful, and I think goes to the heart of 
 things.
  (Based on what I have observed, and my experience with working 
 with someone who had exactly this feeling).


I think there's a good bit of fear involved. I've seen this kind 
of behavior with other things, not just D. Nothing ever suits 
people, nothing will do. It's an excuse based on latent fear.


 I don't think it's true these days that programmers who depend 
 on an IDE and on a visual debugger are mediocre programmers[*], 
 but definitely mediocre programmers are scared of the command 
 line, and it is in the nature of things that there are more 
 mediocre programmers than not, if you have a generous 
 definition of programmer.  And then because there are more of 
 them and we live in a democratic age that also shapes the 
 culture to a certain extent.


Never would I call someone a mediocre programmer _because_ s/he 
uses an IDE. Neither do I think that I'm the cream of the crop, 
because I use D. But an IDE is not everything, actually it's the 
last bit you build, once the language is working. But these days 
it's the other way around, people think IDE means that a given 
language is good. It's just easier to use.



 Do you think it's true that there is no end to D, as far as the 
 language itself goes?  I mean there is no end to C in terms of 
 learning about programming, but that's a different point.  I 
 never even really wrote object-oriented code before a couple of 
 years back, let alone doing metaprogramming (unless you count 
 Forth).  I've still got much to learn, but I don't feel held 
 back by the vast scope of the language or anything.  Mostly if 
 I pick up someone else's source I can figure out what it's 
 doing (some of the template stuff goes slowly).  That's after 
 two years of learning D, and after a long long break from 
 programming.  I'm also 42, which means it starts to become 
 slower to learn then 30 years ago.


D keeps challenging you. That's the point. Java gives you an 
ideology, tells you it's good, it's the best and you follow it. 
They tell you "we guys know, we've tried things, and this is the 
best". No questions asked. In D people got together and said 
"wait a minute ..." It challenges beliefs and ideologies, and 
everyone can contribute and make suggestions. For me it changed 
my whole way of thinking. OOP no longer exists for me. D is 
iconoclastic, and this p*sses people off. You have to rethink all 
the time. Not many people want to do that.

[snip]

Impatience is maybe the D community's biggest drawback.
Sep 25 2015
parent reply Ola Fosheim Grostad <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 25 September 2015 at 19:07:08 UTC, Chris wrote:

 I think there's a good bit of fear involved. I've seen this 
 kind of behavior with other things, not just D. Nothing ever 
 suits people, nothing will do. It's an excuse based on latent 
 fear.


Risk aversion is just good project management though. Fringe 
tools are delegated to smaller tasks, and that just makes a lot 
of sense if you are looking at the failure potential for a long 
term development plan. Java, Go and C++ makes more sense as far 
as mitigating risk goes than Rust, Nim and D.


 the last bit you build, once the language is working. But these 
 days it's the other way around, people think IDE means that a 
 given language is good. It's just easier to use.


A good IDE is essential when working with large application 
libraries/frameworks etc. For more limited system programming a 
good editor works well enough.

But there appears to be several stand alone visual debugger front 
ends based on gdb/lldb, so reducing the scope to having a D 
friendly visual debuggers ought to be good enough.


 changed my whole way of thinking. OOP no longer exists for me. 
 D is iconoclastic, and this p*sses people off. You have to 
 rethink all the time. Not many people want to do that.


I don't understand what would make D iconclastic? The feature set 
is quite ordinary c++ish, but there are some areas that show that 
features have been added without enough work being put into them 
before they were implemented. But OO is primarily about 
modelling, it wasn't meant to be a low level programming 
paradigm. Classes etc is just language features to support the 
high level model and evolving it over time. Ths is where C++ went 
wrong IMO.
Sep 25 2015
next sibling parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Friday, 25 September 2015 at 20:05:08 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 25 September 2015 at 19:07:08 UTC, Chris wrote:

 I think there's a good bit of fear involved. I've seen this 
 kind of behavior with other things, not just D. Nothing ever 
 suits people, nothing will do. It's an excuse based on latent 
 fear.


 Risk aversion is just good project management though.


As is more then occasionally the case, Ola, you use language 
cleverly to say something that may be literally acceptable but in 
order to evoke a meaning that is debatable.

It certainly isn't the case that the possible risk of using a 
less widely used framework is the kind of risk to which one 
should in all contexts at all times have a high degree of 
aversion towards.  It really depends what you are trying to do, 
and what your other options are.

Because life is risk, and using something else instead of D also 
has not just risks but costs, too.  And against the cost and risk 
of using D are certain benefits.

So, no, one can't say that in a blanket way risk aversion is good 
project management if what you care about is enterprise value 
rather than what people think of you.

And sensible mercantile consideration of what might go wrong and 
what you are going to do if that happens - that's a very 
different thing from what Chris was speaking about.  Because in 
enterprises it's often the case that social and group emotional 
factors are more influential day to day than rational 
calculation.  (There is an extensive literature on this).  Of 
course, everyone gives reasons for things - it's just that if you 
observe closely those aren't the real reasons (and the people 
themselves may be unaware of this).


 Fringe tools are delegated to smaller tasks, and that just 
 makes a lot of sense if you are looking at the failure 
 potential for a long term development plan. Java, Go and C++ 
 makes more sense as far as mitigating risk goes than Rust, Nim 
 and D.


They have different natures and solve different problems.  It's 
easy to speak about things in blanket terms, but it doesn't 
contribute towards clarity about in which circumstances a 
particular language is the right tool for the job.


Laeeth.
Sep 25 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 25 September 2015 at 21:03:12 UTC, Laeeth Isharc wrote:

 So, no, one can't say that in a blanket way risk aversion is 
 good project management if what you care about is enterprise 
 value rather than what people think of you.


Risk aversion is good software project management. Period.

It is very common for software projects to not meet their target 
and fail to adapt to changes in the environment, so the first 
thing you should do is mitigate risk for failure and risks that 
you may not be able to move/change in the future.

You have to measure up the potential gains against potential 
risks. If the gains is 30% increased productivity and 30% higher 
risk for failure... then you give up the increased productivity 
and argue in favour of increased budgets.

Most current imperative languages are more or less of the same 
nature. They have different short-comings, but for 
non-system-programming you can basically do the same project in 

language. Production involves more than the language. C++, Java 

alternatives.

That Nim and D are more fun is not really a project management 
factor that should have a high priority.
Sep 26 2015
parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Saturday, 26 September 2015 at 11:00:39 UTC, Ola Fosheim 
Grøstad wrote:

 On Friday, 25 September 2015 at 21:03:12 UTC, Laeeth Isharc 
 wrote:

 So, no, one can't say that in a blanket way risk aversion is 
 good project management if what you care about is enterprise 
 value rather than what people think of you.


 Risk aversion is good software project management. Period.


What was it you were called by one compiler writer here ?  The 
king of shifting goal posts.

You don't argue in a straightforward manner, Ola.  Your words 
have a superficial logic to them, but not always much coherence 
or common sense,


 It is very common for software projects to not meet their 
 target and fail to adapt to changes in the environment,


Yes.  One reason for failure to adapt is lack of plasticity and 
ability to iterate rapidly.  But there are many factors and you 
can't reasonably portray it in the highly simplistic manner that 
in my opinion you do.

so the

 first thing you should do is mitigate risk for failure and 
 risks that you may not be able to move/change in the future.


No.  The first thing you should do is think about what you want 
to achieve and how you are going to get there.  Then you can 
think about what might go wrong, and what you will do if that 
happens, and what sensible optionality and insurance you can buy 
upfront.



 You have to measure up the potential gains against potential 
 risks.


Now you are repeating my words to me with different emphasis 
without acknowledging.  If it's a question of balance and 
tradeoffs then it's no longer purely about blanket risk aversion,


 If the gains is 30% increased productivity and 30% higher risk 
 for failure... then you give up the increased productivity and 
 argue in favour of increased budgets.


If.  And it's context dependent.  But you're making assumptions 
that may be true for you, and might be true for some others, but 
won't be true for another group.



 Most current imperative languages are more or less of the same 
 nature. They have different short-comings, but for 
 non-system-programming you can basically do the same project in 



Yeah yeah all Turing complete.  But languages have many relevant 
attributes beyond those, as Knuth pointed out in the speech I 
posted an extract from here a while ago.  The experience of 
writing different kind of projects in those languages is not the 
same, and in some cases that matters, sometimes a lot.  
Programmers are human beings, and the work on ergonomics and 
office design shows that even apparently trivial things can make 
a great deal of difference to human productivity.  And the 
difference between writing in those languages is far from 
trivial.  The fact that you can do it doesn't mean the language 
choice itself (setting aside tooling and libraries) is irrelevant 
commercially, as you must surely at some level realize.  The 
right decision depends on the project and the context, and human 
and organisational factors must be a good part of that.


 BUT that is only the language. Production involves more than 

 than the other alternatives.


True, but whether this matters much depends on what you are 
trying to do, particularly since with some effort you can talk to 

building things in terms of micro services and the interface 
doesn't need to be incredibly fast, then it doesn't need to be 
native (and maybe sometimes shouldn't).
Sep 26 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 26 September 2015 at 12:48:49 UTC, Laeeth Isharc 
wrote:

 What was it you were called by one compiler writer here ?  The 
 king of shifting goal posts.


Which is a completely unreasonable claim. Argue your point and 
don't go ad hominem.  Referencing Deadalnix's rhetorics when he 
is on the loosing end of a debate does not help your argument, on 
the contrary.


 You don't argue in a straightforward manner, Ola.  Your words 
 have a superficial logic to them, but not always much coherence 
 or common sense,


Where did I loose you? What exactly is it that you do not 
understand?

Stick to a clean line of argument, please.

You choose your tools before you start development. Therefore you 
mitigate risk. You favour known tools with known deficiencies 
over unknown tools with unknown deficiencies. It is that simple. 
Whenever you do something new the risk goes up by a high factor.
Sep 26 2015
parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Saturday, 26 September 2015 at 19:28:55 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 26 September 2015 at 12:48:49 UTC, Laeeth Isharc 
 wrote:

 What was it you were called by one compiler writer here ?  The 
 king of shifting goal posts.


 Which is a completely unreasonable claim. Argue your point and 
 don't go ad hominem.  Referencing Deadalnix's rhetorics when he 
 is on the loosing end of a debate does not help your argument, 
 on the contrary.


An ad hominem argument is used to attack the prestige of an 
intellectual adversary in debate when his prestige has no 
relevance as to whether his argument is correct.

This was not an ad hominem, but an observation about the way that 
you argue that makes it often ungenerative.  It's very much to 
the point.


 You don't argue in a straightforward manner, Ola.  Your words 
 have a superficial logic to them, but not always much 
 coherence or common sense,


 Where did I loose you? What exactly is it that you do not 
 understand?


I understand exactly what you are doing, and it's a pity because 
I think you are a smart guy that could contribute much if you 
decided to adopt a more constructive spirit.  I've learnt from 
your posts on some more theoretical topics, and I enjoyed reading 
them.

The proximate thing you did that I objected to was insisting that 
risk aversion "is good software management period".  Whilst going 
on to say that "you have to measure up potential gains against 
potential risks", which was exactly my point, with your emphasis 
reversing it but not acknowledging that you were echoing my 
words.  So then that makes you seem like the voice of reason, but 
you did that by responding very selectively to what I wrote.

In practice, life is risk, and sometimes you have to take 
calculated risks to advance - this is true whether or not we 
acknowledge it to ourselves.  Some people shouldn't even think 
about using D at work, but that tradeoff depends on their 
particular situation, what they want to achieve, and what their 
alternatives are.  You speak in a blanket way, as if you're in a 
position to know what's right for others.

But it's not your strange view of things that I object to, but 
that you don't argue in a straightforward way, and others have 
made the same observation.  It's not an ad hominem to call this 
out, because it relates to the way that you argue, and isn't an 
attempt to use irrelevant factors to undermine your prestige.



 Stick to a clean line of argument, please.


I observe this solemnly, and make no further comment!


 You choose your tools before you start development. Therefore 
 you mitigate risk. You favour known tools with known 
 deficiencies over unknown tools with unknown deficiencies. It 
 is that simple. Whenever you do something new the risk goes up 
 by a high factor.


As you wish, Ola.
Sep 26 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 26 September 2015 at 22:19:41 UTC, Laeeth Isharc 
wrote:

 In practice, life is risk, and sometimes you have to take 
 calculated risks to advance - this is true whether or not we 
 acknowledge it to ourselves.  Some people shouldn't even think 
 about using D at work, but that tradeoff depends on their 
 particular situation, what they want to achieve, and what their 
 alternatives are.  You speak in a blanket way, as if you're in 
 a position to know what's right for others.


I am not doing consulting on a forum, I am arguing against the 
viewpoint that the lack of adoption of fringe tools is a result 
of unjustified fear. I wouldn't make any blanket statement for a 
business in any shape or form without talking with them to 
understand their situation. I don't know why you think I am doing 
consulting here.

But risk management is at the core of software engineering. That 
is because there are many unknown factors during development, but 
you have to set the trajectory at an early stage, which includes 
picking the development environment. Software process/methods 
maturity is often quantified in "repeat success". That is, not 
that you have one success, but keep repeating the success over 
many projects.


 attempt to use irrelevant factors to undermine your prestige.


There is no prestige involved. But you seem to assume that 
whatever holds for your field translates well to other fields. 
That is most likely not true. If I started arguing about hedge 
fund managment like you do about programming and engineering you 
would most likely find it tiresome.

I've majored in human factors/software engineering, taught it to 
students and been with a research group where many focused on 
using Latour's actor network theory for understanding 
organizations and systems development processes. Software 
engineering is not a fun or easy topic to teach and also not 
suitable for forum debates unless people have the same background.

This is my key point: People are not avoiding fringe tools 
because they are afraid of progress. Geeks are quite happy to use 
fringe tools in their spare time or for smaller parts of bigger 
projects.

Managers should avoid using unsupported fringe tools for larger 
long running projects, for many reasons. The big players have 
many more options, it means you are more likely able to move and 
make changes later on in the project. Like adopting new platforms 
such as ARM, asm.js etc. With a tool like D you have to be 
prepared to take custody of the compiler/runtime to get the same 
flexibility.

You pick a solution for a project, not a language.
Sep 27 2015
next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 26 September 2015 at 22:19:41 UTC, Laeeth Isharc 
 wrote:

 [...]


 I am not doing consulting on a forum, I am arguing against the 
 viewpoint that the lack of adoption of fringe tools is a result 
 of unjustified fear. I wouldn't make any blanket statement for 
 a business in any shape or form without talking with them to 
 understand their situation. I don't know why you think I am 
 doing consulting here.

 But risk management is at the core of software engineering. 
 That is because there are many unknown factors during 
 development, but you have to set the trajectory at an early 
 stage, which includes picking the development environment. 
 Software process/methods maturity is often quantified in 
 "repeat success". That is, not that you have one success, but 
 keep repeating the success over many projects.


 [...]


 There is no prestige involved. But you seem to assume that 
 whatever holds for your field translates well to other fields. 
 That is most likely not true. If I started arguing about hedge 
 fund managment like you do about programming and engineering 
 you would most likely find it tiresome.

 I've majored in human factors/software engineering, taught it 
 to students and been with a research group where many focused 
 on using Latour's actor network theory for understanding 
 organizations and systems development processes. Software 
 engineering is not a fun or easy topic to teach and also not 
 suitable for forum debates unless people have the same 
 background.

 This is my key point: People are not avoiding fringe tools 
 because they are afraid of progress. Geeks are quite happy to 
 use fringe tools in their spare time or for smaller parts of 
 bigger projects.

 Managers should avoid using unsupported fringe tools for larger 
 long running projects, for many reasons. The big players have 
 many more options, it means you are more likely able to move 
 and make changes later on in the project. Like adopting new 
 platforms such as ARM, asm.js etc. With a tool like D you have 
 to be prepared to take custody of the compiler/runtime to get 
 the same flexibility.

 You pick a solution for a project, not a language.


You might like to read http://www.paulgraham.com/avg.html if 
that's not already done. Of course risk must be reduced to a sane 
minimum, but a project without any kind of risk is often a 
project without value, sometimes taking a calculated risk to gain 
a competitive advantage proves useful.

I see it a bit like software security (more my field): of course 
security risk must be kept low, but not at the expense of the 
ability for the company to produce its product. After all what 
you're protecting is the ability for the company to make money.
Sep 27 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 27 September 2015 at 10:38:39 UTC, cym13 wrote:

 You might like to read http://www.paulgraham.com/avg.html if 
 that's not already done.


Startups have a different logic to them, they might try to 
attract developers to build a small tight team, for less pay, by 
providing a more exciting cutting edge environment or might just 
aim to produce a proof of concept within their means/know-how 
with the goal of attracting investors... so whatever works for 
them.

But going with Lisp today in web development seems to represent a 
fairly high level of lockin. I wouldn't do it.


 Of course risk must be reduced to a sane minimum, but a project 
 without any kind of risk is often a project without value, 
 sometimes taking a calculated risk to gain a competitive 
 advantage proves useful.


Calculated risk is one thing, unnecessary risk something else. If 
you are doing projects for external customers you really don't 
want to end up in a situation where they say "we want to port to 
platform X, we know that can be done in C++/Java" and then have 
to admit that you cannot do that with whatever non-standard 
language you pushed for.  Another issue is that you don't want to 
develop on 10 different platforms, so sticking with a good 
allrounder language platform is not a bad strategy for many 
development teams.


 I see it a bit like software security (more my field): of 
 course security risk must be kept low, but not at the expense 
 of the ability for the company to produce its product. After 
 all what you're protecting is the ability for the company to 
 make money.


I don't really think choosing one of the more common modern 
algol-like languages over the less common ones affects your 
ability to produce the product. The software development process 
itself is more likely to play a significant role.

For software that is made for supporting organizations as much as 
80% of the total development costs might come after deployment. 
There are usually too many unknown factors in long term software 
development at the early project stages, so you cannot reduce the 
risks to the level you would like. What you can be pretty sure of 
is that requirements will change and that you need flexibility 
and the ability to evolve in new directions.

The department I was with, belonged to the scandinavian school 
within systems development which is largely looking at 
user-centered development where you involve/focus on real end 
users throughout the process. That is one way to reduce risk and 
increase acceptance among end users.
Sep 27 2015
prev sibling parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim Grøstad 
wrote:
On Monday, 28 September 2015 at 09:35:53 UTC, Chris wrote:
In response to Ola:
On Monday, 28 September 2015 at 09:35:53 UTC, Chris wrote:

 Yep. What I was talking about was not the fear of a commercial 
 failure because of having picked the wrong tool (management). I
 was talking about my impression that D might intimidate
 programmers /coders.






 This logic is very difficult to follow.


Difficult to follow for you, because your mind doesn't work that 
way.  But, as Knuth pointed out, there are many different kinds 
of minds in the world, and one will have an easier time of it if 
one accepts this.

Chris was speaking about human factors, and these are important, 
because programming is still for now a human activity.  It's 
rather well-established that people are funny creatures and are 
influenced by factors that are irrational, or transcend logic, 
depending on your perspective.  Chris's observation is based on 
an empirical view of how the world works; logic doesn't have much 
to do with the observation (although his subsequent conclusion is 
based on impeccable reasoning)



 From a project health point of view D2 suffers from the same
 issues as C++


That's your assessment, and you are certainly entitled to it.  
Whether it is persuasive to others is an open question, because 
those that have spent time writing significant projects in D tend 
to arrive at different conclusions.  There have been people who 
give up in frustration - this will always happen with something 
new, and may reflect a lack of maturity, or that D wasn't the 
right tool for the job, at least for this person in this 
environment, at this time, and from what I have seen this seems 
to be perhaps less commmon over time as the ecosystem matures.  
We don't give people 'exit interviews' here, but to the extent 
one can tell, the reasons given are rarely that D is too much 
like C++.

As John Colvin points out, someone who hasn't written quite a lot 
of code in D over time (because as you rightly observe, the 
ultimate consequences of choices aren't really observed till the 
code base develops and grows), simply isn't in a position to make 
a judgement about whether this is true.

You come across as someone very able (and I have worked with some 
very bright people over the years, so I don't say this lightly), 
but quite academically minded and theoretical, and I don't know 
how many lines of D you have written.  (Significant lines of D, 
if you prefer).  That matters, because the difference between 
theory and practice is bigger in practice than in theory.


 But even after years of polish Go is still perceived as risky:


Of course it's risky.  Yet why do people who are sensible 
commercial people who aren't in the business of gambling use it?  
Because it's a very good tool for certain kinds of job, and the 
benefits outweight the costs, risks being one of those costs.



 risk management is at the core of software engineering.


No it's not, any more than it's helpful to say that risk 
management is at the core of investment management.  It's one 
important thing, and if you don't do this reasonably well, life 
will crush you.  But engineering is about using tools to solve 
problems, and you need to consider benefits and opportunity costs 
in aggregate.  Also in terms of optionality, since a small bet 
today may open up future possibilities.


 Software process/methods maturity is often quantified in "repeat
 success". That is, not that you have one success, but keep
 repeating the success over many projects.


Indeed, and rapid iteration is an important part of reducing risk 
and aligning development with the needs of the business.  No 
doubt in some areas there isn't an alternative to waterfall, but 
I have seen this fail in many more cases than succeed in the 
areas I know well - banking and hedge funds.


 I've majored in human factors/software engineering, taught it to
 students and been with a research group where many focused on
 using Latour's actor network theory for understanding
 organizations and systems development processes.


It's not a surprise that this approach to understand 
organizations should appeal to you.  That's not the kind of human 
factors I mean, by the way.  Academic approaches can sometimes be 
useful in practice, and sometimes very useful, but when an 
academically-informed perspective clashes with practical 
experience and common sense, one must at least ask why.  My 
impression is that in the domain of software engineering 
practices, it hasn't been the academics that have driven insight 
about what works.



 But you seem to assume that  whatever holds for your field
 translates well to other fields.


No, because I read widely and talk to people.  And some things 
are clearly universal, whilst others are not.  And I haven't ever 
suggested "every enterprise should use D", but merely said that 
it really depends on the situation - what you are trying to 
achieve, what your alternatives are, and what the human and 
organisational factors.  And that an aversion to risk is just one 
factor that can't be said to apply in the kind of blanket way you 
suggest it does.

"If I started arguing about hedge fund managment like you do 
about programming and engineering you would most likely find it 
tiresome".

To make the analogy relevant to this case: if you had been 
managing money for a decade longer than you had been programming, 
had worked as a money manager, had always done some money 
management alongside your programming, had hired and managed 
money managers, and money management was a core and strategic 
part of your business at a time when money management was 
transforming programming.  Yes, I would want to hear what you had 
to say about money management.

But I haven't ventured many opinions here about computer science 
as it's not a field I formally studied, and what I know isn't 
current in every area.  I do have the right to have some 
tentative views about certain aspects of software development 
processes, because I have to have an opinion to be able to act in 
the world.  And on the commercial side, I have every right.

Let's for one moment suppose that finance and startups are 
strange areas where the usual lessons don't apply.  The 
exceptions that _preuve_ the rule.  What does one certain company 
that hasn't been a startup for a while now but has one of the 
largest codebases in the world, and is generally recognized to 
have some of the best people say about software development?

"Move slowly because you don't want to take the risk of breaking 
things?"

I don't think that's Facebook's motto, even if they have matured 
a bit in its application since the early days.  So your claim 
about risk aversion simply needs to be put into proper commercial 
context.  Not taking risks is also risky.  You just need to do 
what you can to understand them, and make sensible merchant-like 
decisions.  Sometimes that even means betting a large pecuniary 
amount on something uncertain, because that might be better than 
the alternatives.  It really all depends.




 Geeks have no trouble picking up new languages


A geek is someone who is intrinsically interested in technology 
and whose choice of activities reflect this.  Many such people 
don't have "no trouble" picking up a new language, since it's a 
lot of work to do so and not everyone who is technical has that 
specific ability or the time required.  One shouldn't 
underestimate the cost of learning something new, and that's one 
reason Manu is essentially right about getting rid of unnecessary 
frictions over time.


 C++ programmers most certainly will have no trouble picking up 
 D.


Thank you for the colour - helpful to hear, and it fits with what 
Sociomantic say.


 The semantics are too close, but D2 does not solve C++'s issues,
 and brings another set of issues that C++ does not have.


That's not what many people with at least equivalent compsci 
chops and much more practical experience of D seem to find.  
Reasonable people may differ on this, and actually the answer to 
the above will depend on the commercial situation as much as on 
language design questions and ecosystem.



 Projecting "fear" onto professional decision making is just a 
 way
 to make excuses for D's shortcomings.


That's not a charitable reading of what Chris said, because it 
isn't what he was doing or could be understood to mean.

I worked for a little while with someone recently - not the right 
guy for me, but the things he pointed out were exactly the 
obstacles with this guy.  And as it happens it might have made a 
big difference in adoption in financial sector had he not been 
put off by fear (I can't say more here), and so it's a 
significantly meaningful data point in itself.



 Sun was a big player in IBM's core market and the Java design 
 was
 very orthodox. Risk is certainly the single most important 
 factor > for avoiding change.


In my experience, risk is the excuse, and habit and human dislike 
of change is a much more powerful reason.


 If you change your core toolset you also will have to change the
 process and infrastructure.


Alas, alack, these things don't stay the same for very long these 
days.  I don't think you need to make massive changes as a result 
of using D if you don't want to, but you probably will.  Being 
able to write code quickly that works can certainly be a radical 
influence on organisational practices, processes and culture.  I 
certainly agree with that.



 has to do it. If we all had the same timid attitude towards
 adopting new technologies, D would no longer exist, nor would a
 whole bunch of other technologies.



 You are assuming that technologists have timid attitudes towards
 playing with new technologies.


Come on, Ola!  You don't like it when people talk of goalpost 
shifting, but you keep repeating the behaviour that led to this 
observation.  He wrote _adopting_ and rather than actually 
address what he said, you strawmanned it and said _playing with_. 
  I hardly need to point out the difference.


 I am not doing consulting on a forum, I am arguing against the
 viewpoint that the lack of adoption of fringe tools is a result 
 of
 unjustified fear. I wouldn't make any blanket statement for a
 business in any shape or form without talking with them to
 understand their situation. I don't know why you think I am 
 doing > consulting here.


You keep doing this strawman thing - you defend yourself against 
an imaginary accusation that is a caricature of what was actually 
said (not even a cariacature).  Nobody suggested you were doing 
consulting, so why do you respond to this imaginary suggestion, 
and with such vigour?

But you certainly have made many blanket statements about how 
others behave and should behave and it's my belief that you don't 
have a proper basis for doing so.


 Managers should avoid using unsupported fringe tools for larger
 long running projects, for many reasons. The big players have 
 many
 more options, it means you are more likely able to move and make
 changes later on in the project. Like adopting new platforms 
 such
 as ARM, asm.js etc. With a tool like D you have to be prepared 
 to
 take custody of the compiler/runtime to get the same 
 flexibility.


Nobody is suggesting you are doing consulting, but you certainly 
don't hesitate to make ex cathedra pronouncements on what people 
should and shouldn't do when you don't know their situation or 
what problems they face!

We know that you think D is a toy language, although you also say 
that you aren't calling it a toy language.  Whatever.  Factually 
speaking, an unsupported tool is one where if something doesn't 
work you are on your own.  D isn't unsupported, since there is a 
forum, a bug tracker, and if you're a significant user you can 
try to email Walter and persuade him to help you, as some 
commercial users of D have done in the past.  Practically 
speaking, access to people is very helpful (not just to Walter 
and Andrei but other compiler and library developers).  I know 
that if I had a problem I could get it fixed at a reasonable 
price.  (I don't mean writing a new GC since that doesn't matter 
to me much, but if I wanted to have one, even that wouldn't cost 
a fortune relative to what's at stake in my business).

Empirically speaking, some very smart people have built their 
business around D.  And not only that, but their numbers show 
that the cost advantage isn't theoretical.  When you tell people 
like that that in effect they are idiots, you ought to have some 
basis if you wish to be taken seriously.

Nobody is suggesting that 'unjustified fear' is the reason why D 
is not currently as widely adopted as C++.  (It's not right to 
say that what's striking is it's lack of adoption, since you 
start where you start, but the rate of growth is what matters and 
that, with all the ebb and flow of a natural phenomenon, keeps 
going).

People are suggesting that perceptions are important, and that 
it's little things that create a bit of pain in the beginning 
that deter some people.  That's often based on their practical 
experience, not some academic study - what one makes of this will 
depend on one's view of life, I suppose.


 adopting it for deployment is a completely different issue


Then you cover yourself, but then by doing so you essentially 
confirm his point.




 What tools can D successfully replace? Give a focused answer to
 that and you can improve on D to a level where it becomes
 attractive.


Most of us aren't interested, or can't afford to be for now, in 
answering such blanket questions.  It's anyway much more 
generative to ask oneself what's the best way to solve the 
business problem before me.  Hmm, maybe D could help - let's find 
out.

And for the language foundation people, they'll do best by 
listening to those who do use D successfully to solve their own 
problems, and there are plenty of those, and most of these have 
better things to do than post on the forum.  How often do you see 
emsi, sociomantic, weka, or the other well-known D users post 
here about this kind of question?  The forum is a tiny subset of 
the D userbase, and the numbers show that.







You imply that this is a pattern, when I am not aware of such, 
and indeed, as Walter pointed out, a significant shift a few 
years back was from people saying "I'm a Java guy at work, but I 
use D for side projects" to "Here is how I use D at work".  That 
wouldn't be the case (and it is), if Java programmers were 
systematically disgruntled.  Similarly you wouldn't have a 

were the case.


 is not a failure of the language, that is a failure of
 communicating that D is a system level programming language. It 
 is
 not a fear issue, they just ended up in the wrong neighbourhood.


Interesting idea.  Do you have anything to justify this view?  
Evidence or empirical observations.

I don't think it's right to characterize D as a systems language 
BTW - it can be if you want it to be, but the connnotations of a 
systems language are one that isn't suited for rapid and safe 
development, and you won't be understood if you use that term.  
Which, I suppose, is why it isn't mentioned any more on the front 
page, last I checked.


  When people who are looking for a system level programming
 language get disgruntled then you need to pay attention.


I agree with this.  I thought it was a pity people weren't 
immediately able to help the chap who was using D for embedded 
systems at work, but resources are limited and these things take 
time, and progress has been made since then.


 D2 is pretty much C++ with a Boehm collector attached to it.


That's one view.  Don't you find it a puzzle then that anyone 
should use D when they don't wish to use the GC or wish to write 
their own?  It's an anomaly for your theory really, and I think 
you might do well to pay attention to anomalies.



 There is nothing theoretical about this, I am only concerned 
 about
 the language, not the standard library. The same with C++.


Might be true for you, but the topic wasn't "how should Ola think 
about D", but the "adoption of D in the developer community", and 
when we speak about language adoption we cannot avoid speaking 
about the ecosystem.  If Go didn't have nice networking 
libraries, its adoption would have been rather different.  These 
things are a package deal.

If you want to speak about your particular domain then you should 
make clear what it is specifically, what the important things 
are.  And not create the impression - which you do, deliberately 
or inadvertently - that your comments applying to your personal 
use case and experience somehow have universal relevance.

It's a big world, and even Andrei and Walter should not pretend 
that they understand all the possible ways in which people might 
use D and what might be important to them.  (And they don't).


 But keep it real.


Ola, that's one area where we can certainly agree!


Laeeth.
Sep 29 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc 
wrote:

 On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim 
 Grøstad wrote:

 But even after years of polish Go is still perceived as risky:


 Of course it's risky.  Yet why do people who are sensible 
 commercial people who aren't in the business of gambling use 
 it?  Because it's a very good tool for certain kinds of job, 
 and the benefits outweight the costs, risks being one of those 
 costs.


Yet people are looking at creating a derivative language of Go 
for operating system development:

https://groups.google.com/d/topic/golang-nuts/6dI4vIxRgn8/discussion

Why did they not go with D?


 observation.  He wrote _adopting_ and rather than actually 
 address what he said, you strawmanned it and said _playing 
 with_.
  I hardly need to point out the difference.


Playing with is the starting point for adoption. That is how 
programming languages gain traction. You start playing with it, 
then make some small things with it, if it does not disappoint it 
moves up the chain. C++ didn't start out big, neither did Python 
or most other languages. This is also how tools are adopted in 
larger projects. You make small projects (or pilots) first. But 
if you want to use tools in big projects you actually require 
external support for it from multiple parties to avoid lock-in 
and many other factors.


 But you certainly have made many blanket statements about how 
 others behave and should behave and it's my belief that you 
 don't have a proper basis for doing so.


I am describing how best practices affects decision making 
priorities. This is not "prescriptive", it is "descriptive". It 
does not relate to any particular party, but I certainly defend 
the viewpoint that long running projects in general better off 
picking a base that is supported and where the solutions to 
problems are known in advance.


 We know that you think D is a toy language, although you also 
 say that you aren't calling it a toy language.


That's a rather manipulative assertion.


 Empirically speaking, some very smart people have built their 
 business around D.


And so they have around Visual Basic, Php, Javascript and just 
about any language imaginable.


 When you tell people like that that in effect they are idiots, 
 you ought to have some basis if you wish to be taken seriously.


Another manipulative assertion. I've never said anything about 
people who adopt D. They have their reasons, and their strategy. 
I have no interest in forming an opinion about what they do.

What I have said is that if you adopt D for a large project you 
have to be prepare to take custody of the compiler and runtime. 
You need several employees that are capable of that or an actual 
support contract with a solid organization.

The ecosystem around the D compilers is very vulnerable.


 And for the language foundation people, they'll do best by 
 listening to those who do use D successfully to solve their own 
 problems, and there are plenty of those, and most of these have 
 better things to do than post on the forum.


I have no opinions on a future D foundation.

Bute generally, pure development organizations are more likely to 
provide support for open source projects than non-development 
organizations.


 How often do you see emsi, sociomantic, weka, or the other 
 well-known D users post here about this kind of question?


I have no opionions on those organizations. But if they are the 
ones that actually drive the development of D then maybe it would 
be possible to formulate a strategic target for D that can give 
the project more direction.


 You imply that this is a pattern, when I am not aware of such, 
 and indeed, as Walter pointed out, a significant shift a few 
 years back was from people saying "I'm a Java guy at work, but 
 I use D for side projects" to "Here is how I use D at work".


Walter has in the past been excruciatingly clear on D being a 

other similar application level languages would be futile and not 
within the goals for him.

If that has changed, I'd like to see him spell it out.

I hope not. D has some potential as a system level language, much 
less potential as an application level language.


 avoid speaking about the ecosystem.  If Go didn't have nice 
 networking libraries, its adoption would have been rather 
 different.  These things are a package deal.


Go is not a system level language as per today.


 It's a big world, and even Andrei and Walter should not pretend 
 that they understand all the possible ways in which people 
 might use D and what might be important to them.  (And they 
 don't).


Actually, they should try to understand this for a defined target 
group. If not they will not be able to build a solid language 
that is competitive.
Sep 29 2015
parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 29 September 2015 at 16:19:19 UTC, Ola Fosheim 
Grøstad wrote:

 On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc 
 wrote:

 On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim 
 Grøstad wrote:

 But even after years of polish Go is still perceived as risky:


 Of course it's risky.  Yet why do people who are sensible 
 commercial people who aren't in the business of gambling use 
 it?  Because it's a very good tool for certain kinds of job, 
 and the benefits outweight the costs, risks being one of those 
 costs.


 Yet people are looking at creating a derivative language of Go 
 for operating system development:

 https://groups.google.com/d/topic/golang-nuts/6dI4vIxRgn8/discussion

 Why did they not go with D?


I have no idea - perhaps you should ask them.  I don't see how 
the 'yet' follows, but on the other hand it is not entirely 
unexpected that it doesn't.  People are right to perceive Go as 
risky - anything new is - but that doesn't mean that it's not a 
sound commercial decision to use it.  To this point, you don't 
seem to be inclined to respond.


 observation.  He wrote _adopting_ and rather than actually 
 address what he said, you strawmanned it and said _playing 
 with_.
  I hardly need to point out the difference.


 Playing with is the starting point for adoption. That is how 
 programming languages gain traction. You start playing with it, 
 then make some small things with it, if it does not disappoint 
 it moves up the chain. C++ didn't start out big, neither did 
 Python or most other languages. This is also how tools are 
 adopted in larger projects. You make small projects (or pilots) 
 first. But if you want to use tools in big projects you 
 actually require external support for it from multiple parties 
 to avoid lock-in and many other factors.


Gates made an interesting point a decade or more back about 
people impatiently overestimating what can be achieved in a 
couple of years and underestimating what can be achieved in a 
decade.  Humans have a bad intuition about the effects of 
compounded growth.  D seems to be growing quite quickly, but some 
people expect things to fall into a rigid stencil for what they 
think should happen when these things don't work like that - life 
unfolds at its own pace.

I hardly think lock-in is a relevant consideration for the 
present context.  I don't know what the threshold for big is 
these days either.



 But you certainly have made many blanket statements about how 
 others behave and should behave and it's my belief that you 
 don't have a proper basis for doing so.


 I am describing how best practices affects decision making 
 priorities. This is not "prescriptive", it is "descriptive".


Hume's distinction between is and ought is often misapplied.  But 
one can't get to ought from is, and what you call descriptive may 
reflect a slightly unusual perception of the world and certainly 
some value-judgements.  Nothing wrong with that, so long as one 
recognizes that.


 It does not relate to any particular party, but I certainly 
 defend the viewpoint that long running projects in general 
 better off picking a base that is supported and where the 
 solutions to problems are known in advance.


One can speak in generalities, but perhaps it rather depends on 
what you are trying to accomplish.


 We know that you think D is a toy language, although you also 
 say that you aren't calling it a toy language.


 That's a rather manipulative assertion.


That's a statement about intent that is based on a poor reading.  
And my statement - whatever you may perceive its intent to be - 
is based purely on what you have said (both that D is a toy 
language - in your view this being an entirely factual assertion 
- and that you are not calling D a toy language).

http://forum.dlang.org/search?q=ola+toy&scope=forum



 Empirically speaking, some very smart people have built their 
 business around D.


 And so they have around Visual Basic, Php, Javascript and just 
 about any language imaginable.


Indeed, and each of these languages do have their merits, whether 
or not they are your or my cup of tea.  But the particular use 
cases are intriguing since they don't entirely fit with your 
narrative.


 When you tell people like that that in effect they are idiots, 
 you ought to have some basis if you wish to be taken seriously.


 Another manipulative assertion. I've never said anything about 
 people who adopt D. They have their reasons, and their 
 strategy. I have no interest in forming an opinion about what 
 they do.


It's a constellation of points that doesn't fit with your theory. 
  When I see those, I wonder what I am missing.



 You imply that this is a pattern, when I am not aware of such, 
 and indeed, as Walter pointed out, a significant shift a few 
 years back was from people saying "I'm a Java guy at work, but 
 I use D for side projects" to "Here is how I use D at work".


 Walter has in the past been excruciatingly clear on D being a 

 and other similar application level languages would be futile 
 and not within the goals for him.

 If that has changed, I'd like to see him spell it out.


Interesting, but doesn't so much relate to your implication that 

response.  Languages have a life of their own, and intent changes 
as conditions change.  Pinning a label of applications language, 
scripting language, systems language etc seems to be much less 
useful in our age than previously.



 avoid speaking about the ecosystem.  If Go didn't have nice 
 networking libraries, its adoption would have been rather 
 different.  These things are a package deal.


 Go is not a system level language as per today.


Indeed not, but we were talking about something different up to 
this point.  (You had said you didn't care about libraries, when 
that clearly makes a difference to the adoption of a language, 
understood as an ecosystem not a spec, and that was the topic at 
hand).



 It's a big world, and even Andrei and Walter should not 
 pretend that they understand all the possible ways in which 
 people might use D and what might be important to them.  (And 
 they don't).


 Actually, they should try to understand this for a defined 
 target group. If not they will not be able to build a solid 
 language that is competitive.


Thank you for your view.


Laeeth.
Sep 30 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 30 September 2015 at 07:44:09 UTC, Laeeth Isharc 
wrote:

 On Tuesday, 29 September 2015 at 16:19:19 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc 
 wrote:

 We know that you think D is a toy language, although you also 
 say that you aren't calling it a toy language.


 That's a rather manipulative assertion.


 That's a statement about intent that is based on a poor 
 reading.  And my statement - whatever you may perceive its 
 intent to be - is based purely on what you have said (both that 
 D is a toy language - in your view this being an entirely 
 factual assertion - and that you are not calling D a toy 
 language).

 http://forum.dlang.org/search?q=ola+toy&scope=forum


I am tired of your manipulative mind games.

 From 
http://forum.dlang.org/post/amosmrxatnkntpgsjpqz forum.dlang.org :

«I said "if D is a toy language". That is not calling it 
anything. But it is, like Rust, a toy language by academic use of 
the phrase which is not a pejorative term, but an affectionate 
term in my book. The pejorative term is to call a language a 
"hack". C++ is a hack. String mixins is a hack. Etc.»
Sep 30 2015
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc 
wrote:

 In my experience, risk is the excuse, and habit and human 
 dislike of change is a much more powerful reason.


I love this line.
Sep 29 2015
parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 29 September 2015 at 17:22:30 UTC, jmh530 wrote:

 On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc 
 wrote:

 In my experience, risk is the excuse, and habit and human 
 dislike of change is a much more powerful reason.


 I love this line.


Thank you.  The sentiment I am sure came from someone else, but 
this has become etched in my consciousness through painful 
experience.
Sep 30 2015
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 21:03:12 UTC, Laeeth Isharc wrote:


 And sensible mercantile consideration of what might go wrong 
 and what you are going to do if that happens - that's a very 
 different thing from what Chris was speaking about.  Because in 
 enterprises it's often the case that social and group emotional 
 factors are more influential day to day than rational 
 calculation.  (There is an extensive literature on this).  Of 
 course, everyone gives reasons for things - it's just that if 
 you observe closely those aren't the real reasons (and the 
 people themselves may be unaware of this).


Yep. What I was talking about was not the fear of a commercial 
failure because of having picked the wrong tool (management). I 
was talking about my impression that D might intimidate 
programmers/coders. One has to dedicate time to new (or at least 
different) concepts like ranges and templates, old "comfortable" 
concepts are questioned or no longer as relevant as people 
thought they were (e.g. OOP). On top of this, everything is still 
moving. And as if this wasn't enough to scare the sh*t out of 
people (tongue in cheek), the tools are so "basic" that your 

world has to enter the dark realms of command line tools forged 
by Sauron.

Commercial risk is not that big a factor (Java was adopted by IBM 
very early), and there's always the option to interface to C, 
should D lack anything.

The only thing we can do is keep on keeping on (as Laeeth pointed 
out) and produce more and more quality stuff. Somebody has to do 
it. If we all had the same timid attitude towards adopting new 
technologies, D would no longer exist, nor would a whole bunch of 
other technologies.
Sep 28 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 28 September 2015 at 09:35:53 UTC, Chris wrote:

 Yep. What I was talking about was not the fear of a commercial 
 failure because of having picked the wrong tool (management). I 
 was talking about my impression that D might intimidate 
 programmers/coders.


This logic is very difficult to follow. Software project 
management is often done by people who are programmers. From a 
project health point of view D2 suffers from the same issues as 
C++, the language feature set makes it easy to create a mess, and 
therefore the demands of investments in the development process 
gets higher. This aspect is one significant reason for why 
languages like Go and Java are getting traction.

But even after years of polish Go is still perceived as risky:

http://www.techworld.com/apps/why-googles-go-programming-language-could-rival-java-in-enterprise-3626140/

Geeks have no trouble picking up new languages, C++ programmers 
most certainly will have no trouble picking up D. The semantics 
are too close, but D2 does not solve C++'s issues, and brings 
another set of issues that C++ does not have. This is not a fear 
issue. It relates directly to qualitative issues.

Projecting "fear" onto professional decision making is just a way 
to make excuses for D's shortcomings.


 Commercial risk is not that big a factor (Java was adopted by 
 IBM very early), and there's always the option to interface to 
 C, should D lack anything.


Sun was a big player in IBM's core market and the Java design was 
very orthodox. Risk is certainly the single most important factor 
for avoiding change. If you change your core toolset you also 
will have to change the process and infrastructure.


 has to do it. If we all had the same timid attitude towards 
 adopting new technologies, D would no longer exist, nor would a 
 whole bunch of other technologies.


You are assuming that technologists have timid attitudes towards 
playing with new technologies. That is not true. Most 
technologists I know of find that fun. Adopting tech for your 
personal use or for small tools is one thing, adopting it for 
deployment is a completely different issue.

What tools can D successfully replace? Give a focused answer to 
that and you can improve on D to a level where it becomes 
attractive.

But keep it real. Fear among programmers is not D's main issue. 
That's just an excuse.
Sep 28 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
Grøstad wrote:

 What tools can D successfully replace? Give a focused answer to 
 that and you can improve on D to a level where it becomes 
 attractive.

 But keep it real. Fear among programmers is not D's main issue. 
 That's just an excuse.


And just to avoid a misundertanding here:


failure of the language, that is a failure of communicating that 
D is a system level programming language. It is not a fear issue, 
they just ended up in the wrong neighbourhood.

2. When people who are looking for a system level programming 
language get disgruntled then you need to pay attention. It is 
still not a fear issue, there are so few system level languages 
to pick from that people looking for alternatives cannot afford 
to be "picky".

D2 is pretty much C++ with a Boehm collector attached to it. So 
to get traction D has to improve on that model significantly OR 
change direction completely.
Sep 28 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim 
Grøstad wrote:

 D2 is pretty much C++ with a Boehm collector attached to it. So 
 to get traction D has to improve on that model significantly OR 
 change direction completely.


You speak like someone who's read the spec, but doesn't actually 
use the product. If you can put your theoretical mind on hold for 
a few days and actually immerse yourself in the language and its 
idioms for practical use*, you'd see that D has a large 
feature-overlap with to up-to-date C++, but often feels very 
different in practice. Maybe take some of the time you spend 
writing theoretically motivated forum posts and turn it in to 
some practical experience?

P.S. forgive me if I'm wrong and you have done a bunch of serious 
coding in D, it just seemed unlikely seeing as you never seem to 
make specific practical complaints with example code, it's always 
an overarching principle or grand direction problem.
Sep 29 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:

 On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim 
 Grøstad wrote:

 D2 is pretty much C++ with a Boehm collector attached to it. 
 So to get traction D has to improve on that model 
 significantly OR change direction completely.


 You speak like someone who's read the spec, but doesn't 
 actually use the product. If you can put your theoretical mind 
 on hold for a few days and actually immerse yourself in the 
 language and its idioms for practical use*, you'd see that D 
 has a large feature-overlap with to up-to-date C++, but often 
 feels very different in practice. Maybe take some of the time 
 you spend writing theoretically motivated forum posts and turn 
 it in to some practical experience?

 P.S. forgive me if I'm wrong and you have done a bunch of 
 serious coding in D, it just seemed unlikely seeing as you 
 never seem to make specific practical complaints with example 
 code, it's always an overarching principle or grand direction 
 problem.


I have no idea what experience with D Ola really has, but I 
wouldn't have expected anyone to say that D2 is C++ with a 
garbage collector. The GC is a such a small part of D, and there 
are so many features that it has that either C++ doesn't or that 
it's improved considerably that it really doesn't make sense to 
try and claim that C++ and D are that similar. C++11 and 14 have 
closed the gap, but the two are still quite distinct. That 
doesn't necessarily mean that D is better in all cases, but D is 
definitely not just C++ with a GC.

- Jonathan M Davis
Sep 29 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 09:12:11 UTC, Jonathan M Davis 
wrote:

 C++11 and 14 have closed the gap, but the two are still quite 
 distinct. That doesn't necessarily mean that D is better in all 
 cases, but D is definitely not just C++ with a GC.


It isn't "just C++", but D as a language is close enough to be 
considered a close relative. So if you are used to implementing 
libraries in C++, the jump to D is not a big jump.

Where D1 was  a move towards creating a more constrained 
environment by adding builtin language features (a design ideal 
that is closer to where Go is, compared to C++), D2 has been and 
IMO still is moving towards features being done in libraries much 
like C++.

There are differences across the board, but they are minor, not 
major differences. Lambdas are done slightly different, 
templating is slightly different, traits are done somewhat 
different, object init is slightly different, exceptions are 
slightly different, operators are done slightly different, but 
you can roughly express the same things in roughly the same way 
with some exceptions.
Sep 29 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 29 September 2015 at 11:53:45 UTC, Ola Fosheim 
Grøstad wrote:

 It isn't "just C++", but D as a language is close enough to be 
 considered a close relative. So if you are used to implementing 
 libraries in C++, the jump to D is not a big jump.


That's as true as saying that D is similar enough to Java that it
wouldn't be a big jump. You'd end up with code that looks like 
C++ or
Java that no seasoned D developer would write.

The difference is actually quite big. If it weren't, why would
any of us bother?

Atila
Sep 29 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 14:24:45 UTC, Atila Neves wrote:

 wouldn't be a big jump. You'd end up with code that looks like 
 C++ or Java that no seasoned D developer would write.


I don't really see your point. "idiomatic" is a cultural regime, 
not a language and not necessarily an improvement over 
alternative coding styles. System level code isn't "idiomatic", 
you write code the way that makes sense for what you try to 
achieve and set guidelines suitable for your project.

If I want a systems development language and don't like C++ for 
various reasons (syntax bloat, no module system and tedious 
traits) then using D is one of very few potential options. 
Currently some things are better in D, some things are better in 
C++. The primary difference is that D can much more easily change 
for the better overall.

C++ is locked to backwards compatibility in a rather unhealthy 
way, which is why they now try to "change practice" by using 
guidelines. D can avoid all that.
Sep 29 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2015 7:24 AM, Atila Neves wrote:

 That's as true as saying that D is similar enough to Java that it
 wouldn't be a big jump. You'd end up with code that looks like C++ or
 Java that no seasoned D developer would write.

 The difference is actually quite big. If it weren't, why would
 any of us bother?


It's interesting looking at the ddmd source code. It's translated from C++, and 
it shows. It doesn't look much like D code.
Sep 29 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Sep 29, 2015 at 09:54:34PM -0700, Walter Bright via Digitalmars-d wrote:

 On 9/29/2015 7:24 AM, Atila Neves wrote:

That's as true as saying that D is similar enough to Java that it
wouldn't be a big jump. You'd end up with code that looks like C++ or
Java that no seasoned D developer would write.

The difference is actually quite big. If it weren't, why would any of
us bother?


 
 It's interesting looking at the ddmd source code. It's translated from
 C++, and it shows. It doesn't look much like D code.


Are we accepting PRs to convert ddmd to be more D-like?


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Sep 29 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 30 September 2015 at 05:00:11 UTC, H. S. Teoh wrote:

 On Tue, Sep 29, 2015 at 09:54:34PM -0700, Walter Bright via 
 Digitalmars-d wrote:

 On 9/29/2015 7:24 AM, Atila Neves wrote:

That's as true as saying that D is similar enough to Java 
that it wouldn't be a big jump. You'd end up with code that 
looks like C++ or Java that no seasoned D developer would 
write.

The difference is actually quite big. If it weren't, why 
would any of us bother?


 
 It's interesting looking at the ddmd source code. It's 
 translated from C++, and it shows. It doesn't look much like D 
 code.


 Are we accepting PRs to convert ddmd to be more D-like?


 T


Sure, you can submit PR here : 
https://github.com/SDC-Developers/SDC

;)
Sep 29 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 30 September 2015 at 05:17:59 UTC, deadalnix wrote:

 On Wednesday, 30 September 2015 at 05:00:11 UTC, H. S. Teoh 
 wrote:

 Are we accepting PRs to convert ddmd to be more D-like?


 T


 Sure, you can submit PR here : 
 https://github.com/SDC-Developers/SDC

 ;)


LOL.

- Jonathan M Davis
Sep 30 2015
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:

 actually use the product. If you can put your theoretical mind 
 on hold for a few days and actually immerse yourself in the 
 language and its idioms for practical use*, you'd see that D 
 has a large feature-overlap with to up-to-date C++, but often 
 feels very different in practice.


There is nothing theoretical about this, I am only concerned 
about the language, not the standard library. The same with C++.

One usually don't judge a system level language based on its 
libraries. System level usage of the same system level language 
can be very different because people use different core 
libraries. So there is essentially no reason to complain about 
D's libraries.

If you look for system level programming you also essentially 
agree to writing the libraries you need or create bindings to 
whatever system you intend to build for.  I am not interested in 
Phobos, I am not fond of it and I don't focus on it since I don't 
have to use it. I am interested in the language/runtime, not 
libraries which I understand that I have to do on my own.
Sep 29 2015
next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 29 September 2015 at 11:40:20 UTC, Ola Fosheim 
Grøstad wrote:

 On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin 
 wrote:

 actually use the product. If you can put your theoretical mind 
 on hold for a few days and actually immerse yourself in the 
 language and its idioms for practical use*, you'd see that D 
 has a large feature-overlap with to up-to-date C++, but often 
 feels very different in practice.


 There is nothing theoretical about this, I am only concerned 
 about the language, not the standard library. The same with C++.

 One usually don't judge a system level language based on its 
 libraries. System level usage of the same system level language 
 can be very different because people use different core 
 libraries. So there is essentially no reason to complain about 
 D's libraries.

 If you look for system level programming you also essentially 
 agree to writing the libraries you need or create bindings to 
 whatever system you intend to build for.  I am not interested 
 in Phobos, I am not fond of it and I don't focus on it since I 
 don't have to use it. I am interested in the language/runtime, 
 not libraries which I understand that I have to do on my own.


Ok, that's fine, but your comments don't generally come with a 
"this observation is limited to very bare-bones code, beyond 
which I am not interested to think about" caveat, the stuff your 
saying is often very wide-ranging. Also, even for the low-level 
work that you specialise in, practice can lead to insights.
Sep 29 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 29 September 2015 at 11:40:20 UTC, Ola Fosheim 
Grøstad wrote:


 There is nothing theoretical about this, I am only concerned 
 about the language, not the standard library. The same with C++.

 One usually don't judge a system level language based on its 
 libraries. System level usage of the same system level language 
 can be very different because people use different core 
 libraries. So there is essentially no reason to complain about 
 D's libraries.

 If you look for system level programming you also essentially 
 agree to writing the libraries you need or create bindings to 
 whatever system you intend to build for.  I am not interested 
 in Phobos, I am not fond of it and I don't focus on it since I 
 don't have to use it. I am interested in the language/runtime, 
 not libraries which I understand that I have to do on my own.


Ah, then a lot of your attitudes start making sense. But then you 
shouldn't comment on D's usability in the real world.
Sep 29 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim 
Grøstad wrote:

 On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
 Grøstad wrote:


 a failure of the language, that is a failure of communicating 
 that D is a system level programming language. It is not a fear 
 issue, they just ended up in the wrong neighbourhood.



and I'm not disgruntled. I doubt that D is just "a system level 
programming language", this definition is not even on the landing 
page. On the contrary, the landing page talks about efficiency, 
control, modelling power, safety and productivity. The original 
OP complained about compiler error messages and the lack of a 
true IDE, these are not "qualities" of a system level programming 
language, I see them as basic failures.

My main complaints are also the compiler error messages ("Out of 
memory" is the most annoying one) and the Linux-centric approach 
of the development, but I'm far from being disgruntled.
Sep 29 2015
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:

 My main complaints are also the compiler error messages ("Out 
 of memory" is the most annoying one) and the Linux-centric 
 approach of the development, but I'm far from being disgruntled.


I've never understood the "Linux-centric" complaint. I've been 
using D on Windows for 11 years with no problems. Hell, in the 
early days, Linux was the red-headed stepchild. DMD may not be 
deeply integrated into the MS ecosystem of dev tools (which could 
certainly be an issue for a Windows-only dev shop that uses 
Visual Studio and peripherals for everything), but that hardly 
makes it Linux-centric.
Sep 29 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 30, 2015 at 04:32:52AM +0000, Mike Parker via Digitalmars-d wrote:

 On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:

My main complaints are also the compiler error messages ("Out of
memory" is the most annoying one) and the Linux-centric approach of
the development, but I'm far from being disgruntled.


 
 I've never understood the "Linux-centric" complaint. I've been using D
 on Windows for 11 years with no problems. Hell, in the early days,
 Linux was the red-headed stepchild. DMD may not be deeply integrated
 into the MS ecosystem of dev tools (which could certainly be an issue
 for a Windows-only dev shop that uses Visual Studio and peripherals
 for everything), but that hardly makes it Linux-centric.


I find these kinds of comments rather humorous, actually. Every once in
a while, somebody would barge into the forum and decry the current state
of things, bemoaning that D is too Linux-centric and that Windows gets
no love.

Then some time later, somebody else barges in, complaining about why he
failed to install D on his Linux box and that the D developers must
therefore be Windows people and D needs more Linux love.

I've seen both types of complaints. So which is it? Is D Windows-centric
or Linux-centric? Maybe the answer is neither, it's the PBCAK problem.
;-)


T

-- 
"I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf,
Iraqi Minister of Information
Sep 29 2015
next sibling parent ponce <contact gam3sfrommars.fr> writes:
On Wednesday, 30 September 2015 at 04:59:22 UTC, H. S. Teoh wrote:

 I find these kinds of comments rather humorous, actually. Every 
 once in a while, somebody would barge into the forum and decry 
 the current state of things, bemoaning that D is too 
 Linux-centric and that Windows gets no love.

 Then some time later, somebody else barges in, complaining 
 about why he failed to install D on his Linux box and that the 
 D developers must therefore be Windows people and D needs more 
 Linux love.

 I've seen both types of complaints. So which is it? Is D 
 Windows-centric or Linux-centric? Maybe the answer is neither, 
 it's the PBCAK problem. ;-)


D is complaints-centric :)
Sep 30 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Wednesday, 30 September 2015 at 04:59:22 UTC, H. S. Teoh wrote:

 On Wed, Sep 30, 2015 at 04:32:52AM +0000, Mike Parker via 
 Digitalmars-d wrote:

 On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:

My main complaints are also the compiler error messages ("Out 
of memory" is the most annoying one) and the Linux-centric 
approach of the development, but I'm far from being 
disgruntled.


 
 I've never understood the "Linux-centric" complaint. I've been 
 using D on Windows for 11 years with no problems. Hell, in the 
 early days, Linux was the red-headed stepchild. DMD may not be 
 deeply integrated into the MS ecosystem of dev tools (which 
 could certainly be an issue for a Windows-only dev shop that 
 uses Visual Studio and peripherals for everything), but that 
 hardly makes it Linux-centric.


 I find these kinds of comments rather humorous, actually. Every 
 once in a while, somebody would barge into the forum and decry 
 the current state of things, bemoaning that D is too 
 Linux-centric and that Windows gets no love.

 Then some time later, somebody else barges in, complaining 
 about why he failed to install D on his Linux box and that the 
 D developers must therefore be Windows people and D needs more 
 Linux love.

 I've seen both types of complaints. So which is it? Is D 
 Windows-centric or Linux-centric? Maybe the answer is neither, 
 it's the PBCAK problem. ;-)


 T


I would believe that when core.sys.windows will have the same 
amount of code like core.sys.posix after the default 
installation. Or when the number of "This function is Windows 
only" remarks from phobos docs will surpass the number of "This 
function is posix only" remarks. Or when mscoff32 libs will be 
included in setup. Or when the libs from windows\lib will not 
have a content from 15 years ago.
Sep 30 2015
next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:

 Or when mscoff32 libs will be included in setup.


Said to be in 2.068.1: 
https://issues.dlang.org/show_bug.cgi?id=13889
Sep 30 2015
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:

 I would believe that when core.sys.windows will have the same 
 amount of code like core.sys.posix after the default 
 installation.


I'm unbelievably close to that now, I just have a million other 
things to do (...including adding Linux headers that are missing 
from druntime too. it is less Linux- or Windows- centric and more 
"the smallest amount of work the core devs can possibly do that 
is useful"- centric)


 Or when mscoff32 libs will be included in setup.


dmd -m32mscoff generates those files and links with the Microsoft 
linker. It just works when I try it on my computer (which already 
has VS installed btw).


 Or when the libs from windows\lib will not have a content from 
 15 years ago.


I might change that too though I'm not in as much of a rush since 
the 32mscoff and 64 don't use them anyway; they use the 
up-to-date MS sdks.
Sep 30 2015
parent rumbu <rumbu rumbu.ro> writes:
On Wednesday, 30 September 2015 at 16:52:21 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:

 I would believe that when core.sys.windows will have the same 
 amount of code like core.sys.posix after the default 
 installation.


 I'm unbelievably close to that now, I just have a million other 
 things to do (...including adding Linux headers that are 
 missing from druntime too. it is less Linux- or Windows- 
 centric and more "the smallest amount of work the core devs can 
 possibly do that is useful"- centric)


 Or when mscoff32 libs will be included in setup.


 dmd -m32mscoff generates those files and links with the 
 Microsoft linker. It just works when I try it on my computer 
 (which already has VS installed btw).


 Or when the libs from windows\lib will not have a content from 
 15 years ago.


 I might change that too though I'm not in as much of a rush 
 since the 32mscoff and 64 don't use them anyway; they use the 
 up-to-date MS sdks.


I want to personally thank you Adam for your efforts. My 
complaint was not about availability (updated WinAPI headers are 
around since D1 era), but about the fact that these headers were 
never a "first class" citizen of the dmd setup like the posix 
ones. Another problem was that even the headers were available, 
the corresponding libs were not updated, and each time I must run 
coffimplib to update them.

Like you said, using mscoff32 format will make them useless 
anyway.

Again, thank you for keeping them up to date and including them 
in the default setup, if possible.

When I say mscoff32 libs, I'm especially thinking about phobos, 
but this seems solved partially (curl32mscoff.lib is missing) in 
the last version.
Sep 30 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:

 The original OP complained about compiler error messages and 
 the lack of a true IDE, these are not "qualities" of a system 
 level programming language, I see them as basic failures.


Yes, sure, but people looking for a system level language don't 
have much to choose from so IDE is not a big issue.



the D project should be up front about that.


 My main complaints are also the compiler error messages ("Out 
 of memory" is the most annoying one) and the Linux-centric 
 approach of the development, but I'm far from being disgruntled.


Ok. I didn't mean to address you specifically. Sorry if you read 
it that way.

Certainly the complaints coming from D end users is rooted in 
realties coming from the D project itself. Whether it is quality 
problems or communication problems, one just cannot blame the end 
users that express the issues they experience like several people 
in the D community does. That kind of denial is toxic.

I don't think a full IDE experience is essential, but a 
comparable debugging experience probably is.
Sep 30 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
Grøstad wrote:


 This logic is very difficult to follow. Software project 
 management is often done by people who are programmers. From a 
 project health point of view D2 suffers from the same issues as 
 C++, the language feature set makes it easy to create a mess, 
 and therefore the demands of investments in the development 
 process gets higher.


You can create a mess in any language. Having written significant 
amounts of D code, I can tell you that D is very good at avoiding 
a mess.


 This aspect is one significant reason for why languages like Go 
 and Java are getting traction.


Which confirms what I've observed. People prefer set menus, rules 
and strict guidelines - and D seems not to appeal to them due to 
the lack of an ideology.


 Geeks have no trouble picking up new languages, C++ programmers 
 most certainly will have no trouble picking up D. The semantics 
 are too close, but D2 does not solve C++'s issues, and brings 
 another set of issues that C++ does not have. This is not a 
 fear issue. It relates directly to qualitative issues.


This is not my impression. Even "geeks" don't touch D (I know 
this from personal experience), even when there's no risk 
involved, e.g. when writing a small internal tool. As soon as 
they hear they have to learn about ranges and map!(a => 
to!string(a)) and the like, they lose interest. Fear or plain 
laziness ("couldn't be ar*sed"), one of the two. "I certainly 
won't learn D" is a comment I've heard myself.


 Projecting "fear" onto professional decision making is just a 
 way to make excuses for D's shortcomings.


The shortcomings D has wouldn't even interest the majority of 
those who reject D. They wouldn't get deep enough in their daily 
tasks to find out.


 Sun was a big player in IBM's core market and the Java design 
 was very orthodox. Risk is certainly the single most important 
 factor for avoiding change. If you change your core toolset you 
 also will have to change the process and infrastructure.


You've said it again. Java's design is orthodox, so IBM embraced 
it. Again, people prefer simple set menus, rules and strict 
guidelines. It's more of a psychological thing than objective 
risk aversion.



 You are assuming that technologists have timid attitudes 
 towards playing with new technologies. That is not true. Most 
 technologists I know of find that fun. Adopting tech for your 
 personal use or for small tools is one thing, adopting it for 
 deployment is a completely different issue.


See my answer above about "geeks".


 What tools can D successfully replace? Give a focused answer to 
 that and you can improve on D to a level where it becomes 
 attractive.


One example that come immediately to mind is data processing in 
Python. A lot of it is parsing and counting which is much faster 
and often easier to do in D/Phobos.


 But keep it real. Fear among programmers is not D's main issue.


I think it is. It took me a while to realize this. Why is there 
this passionate hostility towards D? I don't go to a Go or Rust 
forum to tell them that I don't like this or that feature and 
that it's all crap. I've decided they're not the right tools for 
what I need and that's it.

 That's just an excuse.
Sep 29 2015
next sibling parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 29 September 2015 at 17:33:04 UTC, Chris wrote:

 On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
 Grøstad wrote:


 This logic is very difficult to follow. Software project 
 management is often done by people who are programmers. From a 
 project health point of view D2 suffers from the same issues 
 as C++, the language feature set makes it easy to create a 
 mess, and therefore the demands of investments in the 
 development process gets higher.


 You can create a mess in any language. Having written 
 significant amounts of D code, I can tell you that D is very 
 good at avoiding a mess.


I found this too, but would you care to elaborate on why 
specifically you think this is?  (I think it's perhaps not one 
big thing, but lots of little things.  One thinks almost of Isiah 
Berlin's Fox vs the Hedgehog - grand conceptual narratives vs 
vast knowing many little related things).  Small frictions have 
big consequences in the world we inhabit, and perhaps for that 
reason it's easy to underestimate the benefits of things that 
superficially seem to be nothing new.


 This aspect is one significant reason for why languages like 
 Go and Java are getting traction.


 Which confirms what I've observed. People prefer set menus, 
 rules and strict guidelines - and D seems not to appeal to them 
 due to the lack of an ideology.


That's also just a matter of time because there isn't much 
written on blogs etc.  (Not necessarily an ideology, I hope, but 
perhaps a culture of how to do things that is easier to perceive 
from the outside).  I think in a strange way the 2008 crisis was 
the beginning of the end for ideology - people are waking up and 
you can see it beginning to unleash this very creative new era.


 This is not my impression. Even "geeks" don't touch D (I know 
 this from personal experience), even when there's no risk 
 involved, e.g. when writing a small internal tool. As soon as 
 they hear they have to learn about ranges and map!(a => 
 to!string(a)) and the like, they lose interest. Fear or plain 
 laziness ("couldn't be ar*sed"), one of the two. "I certainly 
 won't learn D" is a comment I've heard myself.


Probably right today.  As a student of social trends though, it's 
funny how things shift though in ways that are utterly surprising 
and yet far from unpredictable if you are looking clearly and 
closely.


 What tools can D successfully replace? Give a focused answer 
 to that and you can improve on D to a level where it becomes 
 attractive.


 One example that come immediately to mind is data processing in 
 Python. A lot of it is parsing and counting which is much 
 faster and often easier to do in D/Phobos.


Yes - see Andy Smith.  That's partly my own use too.  It's so 
much more pleasant to know that straight not particularly clever 
code I write will be reasonably efficient, and isn't hard to make 
efficient with a bit of effort from someone else.  Plus no 
dealing with runtime dependencies.  (If you think the D 
experience on Windows is subpar, try installing some python 
libraries - it doesn't always 'just work' in my experience, and 
the ready-made distros are great till you run into a snag).

I'm amazed not to see more discussion of the implications for 
relative trends in storage, network bandwidth, data generation vs 
memory bandwidth (and to an extent memory speed and CPU power).

I was searching for something the other day and came across some 
unix forum posts from 2006.  Apparently, a 1Tb SSD then cost more 
than a million bucks (maybe 1.5).  Looks like I can get one for 
not much more than 500 bucks today from Amazon.  The world hasn't 
yet adjusted to a 2,000 fold reduction in price.  If one 
struggles with python today with ordinary sized data sets, I 
wonder how things look in a decade?  (Which is why I asked if 
Facebook is an edge case or Gibson's unevenly distributed future).



 But keep it real. Fear among programmers is not D's main issue.


 I think it is. It took me a while to realize this. Why is there 
 this passionate hostility towards D? I don't go to a Go or Rust 
 forum to tell them that I don't like this or that feature and 
 that it's all crap. I've decided they're not the right tools 
 for what I need and that's it.


That is certainly a puzzling feature of the world, one for which 
I don't have any answer.  I have noticed that people trying to 
achieve something difficult must often endure relentless 
criticism.  (Pick your favourite reform-minded political leader 
of the past viewed favourably today and go back and read the 
press of that time).
Sep 30 2015
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 29 September 2015 at 17:33:04 UTC, Chris wrote:

 This is not my impression. Even "geeks" don't touch D (I know 
 this from personal experience), even when there's no risk 
 involved, e.g. when writing a small internal tool. As soon as 
 they hear they have to learn about ranges and map!(a => 
 to!string(a)) and the like, they lose interest. Fear or plain 
 laziness ("couldn't be ar*sed"), one of the two. "I certainly 
 won't learn D" is a comment I've heard myself.


But that does what is happening here, when people who have 
invested time in D complain. Also generators, iterators and 
functional style programming (D ranges) is something many 
languages provide one way or the other. In my experience that is 
of limited use and more often than not explicit loops are more 
transparent and maintainable. Although if a language offers 
comprehensions I use those.

And yes, I know what Phobos offers and how people who publish 
Phobos-centric code write their D code. There is nothing 
particularly surprising about Phobos.


 Projecting "fear" onto professional decision making is just a 
 way to make excuses for D's shortcomings.


 The shortcomings D has wouldn't even interest the majority of 
 those who reject D. They wouldn't get deep enough in their 
 daily tasks to find out.


Then we perceive reality quite differently. What I see is that 
people do try D, like qualities like syntactical familiarity and 
flexibility and then get disappointed. So basically people play 
with D, realize it is not where they expect it to be at, leave, 
then some time later they download D again, same shortcomings, 
leave... etc. Then at some point they share their frustration.


 You've said it again. Java's design is orthodox, so IBM 
 embraced it. Again, people prefer simple set menus, rules and 
 strict guidelines. It's more of a psychological thing than 
 objective risk aversion.


D isn't particularly novel either, lots of Simula67/C++ 
influence, so I don't really see how this works. IBM did it for 
competitive reasons.


 One example that come immediately to mind is data processing in 
 Python. A lot of it is parsing and counting which is much 
 faster and often easier to do in D/Phobos.


D can work as a replacement solution for parts of Python's 
domain. IMO Python "replaced/complemented" 
sed/awk/perl/bash/php/etc, so that would be a rather small 
portion of Python usage. And that is the primary reason for 
Python's adoption, I think, it replaced not a single tool, but 
people got to use one tool instead of multiple tools.


 I think it is. It took me a while to realize this. Why is there 
 this passionate hostility towards D? I don't go to a Go or Rust 
 forum to tell them that I don't like this or that feature and 
 that it's all crap. I've decided they're not the right tools 
 for what I need and that's it.


Ok, but this is actual D users complaining, not Go and Rust users.

The reason is much more likely that the expectations are set at a 
level where D does not deliver. If you want a production 
environment to be judged favourably it is a good idea to set the 
expectations one notch below what you deliver. There is a bit too 
much hubris in how D is portrayed and therefore you get a 
backlash, from actual D users.

People also complain in Go fora, and certainly in C++ fora (lots 
of sulking over accumulated syntax bloat), but with Go they know 
that the language is set in stone because the language designers 
are very clear in their communication. So the complaints is more 
along the lines of "Go is kinda boring, but I can use it for XYZ, 
then use other languages for W".

In Rust the moderation is quite harsh and the language is also 
too new for users to "give up" on it.
Sep 30 2015
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 30 September 2015 at 12:21:10 UTC, Ola Fosheim 
Grøstad wrote:

 The reason is much more likely that the expectations are set at 
 a level where D does not deliver. If you want a production 
 environment to be judged favourably it is a good idea to set 
 the expectations one notch below what you deliver. There is a 
 bit too much hubris in how D is portrayed and therefore you get 
 a backlash, from actual D users.


I agree that the D community raises the bar quite high for itself 
and other people might get the impression that everything is 
perfect, while it isn't. However, a lot of complaints are about 
IDEs, one click installers (i.e. the tools) and not about how D 
handles floating point numbers.

Could you line out how you would like a language to be so it 
doesn't bore you stiff?
Oct 01 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 1 October 2015 at 16:00:29 UTC, Chris wrote:

 I agree that the D community raises the bar quite high for 
 itself and other people might get the impression that 
 everything is perfect, while it isn't. However, a lot of 
 complaints are about IDEs, one click installers (i.e. the 
 tools) and not about how D handles floating point numbers.


Well, I am less concerned about those that stumble on the 
doorstep. If that is enough to not carry on then they are most 
likely not motivated and can probably get their needs covered 
elsewhere. I am more concerned about those that use D for what it 
is particularly well suited for (systems and OS-level 
programming) and give up after writing some tools with it.


 Could you line out how you would like a language to be so it 
 doesn't bore you stiff?


Consistency in philosophy is important. If D is a compile time 
oriented library authors language (and I think it is) then that 
needs to come to the forefront so that library authors easily can 
write beautiful code and easily integrate D code with other 
environments. The runtime dependencies must be kept low and the 
focus on powerful and easy to use compile time resolution and 
static analysis has to be strengthened.

There is a lot of competition in this domain right now with 
C++17, Rust and some 3rd party things going on in the Go sphere 
on one side and Pony, Nim, Loci, Crystal and quite a few others 
upcoming projects. In addition a plethora of scientific languages 
and toolkits are appearing on the horizon thanks to commoditised 
JIT/backends. Even Haskell seems to be gaining a little bit of 
ground, doesn't Facebook use Haskell for spam detection or 
something?

With so many emerging languages it is important to stay true to 
ones strengths and not overfocus on application domains that most 
likely will be taken over by domain oriented high level 
programming languages in a ten year time frame.
Oct 05 2015
next sibling parent reply Jeremy <jeremy quiescent.us> writes:
On Monday, 5 October 2015 at 15:01:14 UTC, Ola Fosheim Grøstad 
wrote:

 Well, I am less concerned about those that stumble on the 
 doorstep.




 If that is enough to not carry on then they are most likely not 
 motivated and can probably get their needs covered elsewhere.


Respectfully, I think helping new users get a jump start on their 
application produces an initial jolt of productivity which in 
turn helps keep someone motivated.


 I am more concerned about those that use D for what it is 
 particularly well suited for (systems and OS-level programming) 
 and give up after writing some tools with it.


I prefer Andrei's mantra of "...being good at everything C and 
C++ are good at, and also by being good at many tasks that C and 
C++ are not good at..."

https://yow.eventer.com/yow-2014-1222/cool-things-about-d-why-and-how-we-use-it-at-facebook-by-andrei-alexandrescu-1741
Oct 05 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 5 October 2015 at 15:46:35 UTC, Jeremy wrote:

 Respectfully, I think helping new users get a jump start on 
 their application produces an initial jolt of productivity 
 which in turn helps keep someone motivated.


Jump-starting does not keep them motivated. It makes them invest 
initially, but at this point retention of a specific type of 
developers (compiler/runtime capable developers) is more 
important than recruitment of all kinds of developers.

Rust is taking a lot of that market. Understanding why and doing 
something about it, is important.


 I prefer Andrei's mantra of "...being good at everything C and 
 C++ are good at, and also by being good at many tasks that C 
 and C++ are not good at..."


That's just a mantra, C++ and D are pretty close as far as 
library authoring goes, but currently D represents lock-in 
compared to C/C++, provides much fewer options than C++14 
compilers/extensions/tooling, also semantically. That is unlikely 
to change without a focused direction that also takes C++17/20 
and Rust into account.

D isn't competing with C++14 / Rust 1.0, it is competing with 
C++17/20 and Rust 1.X, due to the time it takes to polish. But it 
is impossible to do anything focused without defining what the 
target is. And that lack of a focused strategy that is currently 
a main issue with D's future, because the rest of the programming 
world _is_ moving.

Here's an entertaining video about the actor model, that 
represent one established programming model that C++ is not so 
good at currently (but may become better at):

https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask
Oct 05 2015
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 5 October 2015 at 15:01:14 UTC, Ola Fosheim Grøstad 
wrote:


 Could you line out how you would like a language to be so it 
 doesn't bore you stiff?


 Consistency in philosophy is important. If D is a compile time 
 oriented library authors language (and I think it is) then that 
 needs to come to the forefront so that library authors easily 
 can write beautiful code and easily integrate D code with other 
 environments. The runtime dependencies must be kept low and the 
 focus on powerful and easy to use compile time resolution and 
 static analysis has to be strengthened.


Ok, and do you have a plan or a concrete wish list that you could 
hand over to the core developers? What features would be 
indispensable or are of utmost importance, in your opinion? Do 
you have prototypes or made pull requests?
Oct 06 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:

 Ok, and do you have a plan or a concrete wish list that you 
 could hand over to the core developers? What features would be 
 indispensable or are of utmost importance, in your opinion?


1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.
6. Extend support to critical platforms like WebAssembly/asm.js


 Do you have prototypes or made pull requests?


I have some prototypes for my own use, but not sure what 
relevance that has? Pull requests would require decision making 
and policy changes, and be utterly pointless without it. 
Design/policy changes will have to start with the project 
leaders, that's the only way. End-users do not directly affect 
language features.
Oct 06 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:

 Ok, and do you have a plan or a concrete wish list that you 
 could hand over to the core developers? What features would be 
 indispensable or are of utmost importance, in your opinion?


 1. Define the target, then you can figure out the features.


The target is a pragmatic compiled language. Static analysis is a 
focus and believed to be done with relatively simple and clean 
language rules that ensure correct results.


 2. Solid non-gc memory management and ownership.


Current direction seems to be explicit 
structs+destructors+allocators.
Oct 07 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 7 October 2015 at 08:17:32 UTC, Kagamin wrote:

 The target is a pragmatic compiled language.


That's wonderfully undefined. A pragmatic compiled language can 
be anything from ATS to compiled Python.


 Static analysis is a focus and believed to be done with 
 relatively simple and clean language rules that ensure correct 
 results.


Which D is not.


 Current direction seems to be explicit 
 structs+destructors+allocators.


I don't see this. Allocators is purely a library feature and is 
not designed to be explicit either.

Buf if that is right then:

- Get rid of the dichotomy between classes and structs, having 
syntactically different pointers for classes without any semantic 
significance is rather annoying.

- Get rid of all gc-dependent language features.

- Add language features that enables proper custom pointers.

etc
Oct 07 2015
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 7 October 2015 at 09:25:10 UTC, Ola Fosheim Grøstad 
wrote:

 That's wonderfully undefined. A pragmatic compiled language can 
 be anything from ATS to compiled Python.


If you want to know what D is in details, see dlang.org for 
language spec.


 Static analysis is a focus and believed to be done with 
 relatively simple and clean language rules that ensure correct 
 results.


 Which D is not.


If one could design a language with just four words, it would be 
lisp :)


 Current direction seems to be explicit 
 structs+destructors+allocators.


 I don't see this. Allocators is purely a library feature and is 
 not designed to be explicit either.

 Buf if that is right then:

 - Get rid of the dichotomy between classes and structs, having 
 syntactically different pointers for classes without any 
 semantic significance is rather annoying.


Semantic significance is that classes are polymorphic and hence 
reference types, structs are value types.


 - Get rid of all gc-dependent language features.


 nogc


 - Add language features that enables proper custom pointers.


Phobos implements custom pointers.
Oct 07 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 7 October 2015 at 10:18:16 UTC, Kagamin wrote:

 If you want to know what D is in details, see dlang.org for 
 language spec.


No, that is backwards. :-) The language spec is the product. What 
is needed is a definition of what the problem area is (e.g. use 
cases).

problem area -> design -> language spec


 If one could design a language with just four words, it would 
 be lisp :)


That is actually pretty close. The more powerful semantic 
analysis engines are based on horn clauses.

(you translate the imperative constructs into horn clauses, then 
do analysis)


 Semantic significance is that classes are polymorphic and hence 
 reference types, structs are value types.


Not real difference regarding pointers.


 - Get rid of all gc-dependent language features.


  nogc


No, remove them from the language and replace them with library 
friendly constructs.


 - Add language features that enables proper custom pointers.


 Phobos implements custom pointers.


They are not sound, and that is a language issue, not a library 
issue.
Oct 07 2015
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 7 October 2015 at 13:15:38 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 7 October 2015 at 10:18:16 UTC, Kagamin wrote:

 If you want to know what D is in details, see dlang.org for 
 language spec.


 No, that is backwards. :-) The language spec is the product. 
 What is needed is a definition of what the problem area is 
 (e.g. use cases).

 problem area -> design -> language spec


Where do you think is a limit to applicability of a 
turing-complete language?


 Semantic significance is that classes are polymorphic and 
 hence reference types, structs are value types.


 Not real difference regarding pointers.


Pointers are of little use for a type that is always reference 
type.


 - Get rid of all gc-dependent language features.


  nogc


 No, remove them from the language and replace them with library 
 friendly constructs.


Make them not compile?  nogc does exactly that.
Reducing GC usage and emscripten backend are actionable if you 
want to work on them.
Oct 08 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 16:25:09 UTC, Kagamin wrote:

 Where do you think is a limit to applicability of a 
 turing-complete language?


?


 Pointers are of little use for a type that is always reference 
 type.


You can have many different types of references.


 Make them not compile?  nogc does exactly that.


No, make the features work well without GC or change them.


 Reducing GC usage and emscripten backend are actionable if you 
 want to work on them.


Changing the language is not "actionable" without creating a fork.

Regarding Emscripten, I don't see much value in spending so much 
work on getting something that isn't good enough to work. A 
higher level approach is needed for compact code gen. Possibly 
also language adjustments.
Oct 08 2015
parent Kagamin <spam here.lot> writes:
On Thursday, 8 October 2015 at 16:43:12 UTC, Ola Fosheim Grøstad 
wrote:

 Pointers are of little use for a type that is always reference 
 type.


 You can have many different types of references.


You can have class references in D.


 Make them not compile?  nogc does exactly that.


 No, make the features work well without GC or change them.


What  nogc features don't work without GC?


 Reducing GC usage and emscripten backend are actionable if you 
 want to work on them.


 Changing the language is not "actionable" without creating a 
 fork.


Reduction of GC usage is a work on phobos to make its algorithms 
usable without GC. But you can think of phobos as an extension to 
the language, there's a word that libraries are DSLs extending 
the core language, to improve range implementation in phobos you 
don't need to create a fork.


 Regarding Emscripten, I don't see much value in spending so 
 much work on getting something that isn't good enough to work. 
 A higher level approach is needed for compact code gen. 
 Possibly also language adjustments.


If emscripten backend is not good enough for you, how it is 
related to D?
Oct 09 2015
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad 
wrote:



 1. Define the target, then you can figure out the features.
 2. Solid non-gc memory management and ownership.
 3. Clean up the type system.
 4. Complete the language spec.
 5. Clean up the syntax.


That's very vague. Unless you have concrete cases along with 
possible solutions, nobody can follow your "plan".


 6. Extend support to critical platforms like WebAssembly/asm.js


I agree. Nim are doing a good job at that as far as I know.


 I have some prototypes for my own use, but not sure what 
 relevance that has? Pull requests would require decision making 
 and policy changes, and be utterly pointless without it. 
 Design/policy changes will have to start with the project 
 leaders, that's the only way. End-users do not directly affect 
 language features.


In D you can make a contribution as a user, but it has to be 
concrete and backed up by valid arguments. General statements and 
common places won't change anything.

Unlike Go and Rust, D has grown out of experience with 
programming in general, it's based on what worked in other 
languages and what didn't. Go and Rust address certain narrowly 
defined areas (Go more so than Rust I think). Given D's history 
there is, of course, some waste lying around (as is in any 
software after ~10 years) that has to be cleaned up and I would 
welcome any concrete, practical input from your side. Start with 
simple things first. Any hands-on help is welcome.
Oct 08 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:

 On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim 
 Grøstad wrote:



 1. Define the target, then you can figure out the features.
 2. Solid non-gc memory management and ownership.
 3. Clean up the type system.
 4. Complete the language spec.
 5. Clean up the syntax.


 That's very vague. Unless you have concrete cases along with 
 possible solutions, nobody can follow your "plan".


That's not vague at all.
Oct 08 2015
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:

 On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim 
 Grøstad wrote:





 That's not vague at all.



 1. Define the target, then you can figure out the features.


Then define the target. Make some suggestions.


 2. Solid non-gc memory management and ownership.


Any specific implementation in mind?


 3. Clean up the type system.


Examples + solutions?


 4. Complete the language spec.


I thought that was the last thing we should do.


 5. Clean up the syntax.


Examples + solutions?

You can put your proposals on Wiki.
Oct 08 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:

 On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim 
 Grøstad wrote:

 That's not vague at all.



 1. Define the target, then you can figure out the features.


 Then define the target. Make some suggestions.


I've already raised this topic in a thread where I asked where D 
sits in the web space. And I did that because it has been said 
that vibe.d defines a key application area. However, that is a 
very hard market to capture which many expressed in that thread.

I think D could do well if it focused on engine-level system 
programming and made sure it was absolutely top notch for that 
purpose. (Game engines, search engines, ray tracing engines, in 
memory database engines, business logic engines, etc).

The current focus goes the other way. The current assumption is 
that engines are written in C/C++ and they are used to complete 
applications in D. That would make D an application level 
language, which makes success _very_difficult. As time progresses 
I believe it makes less and less sense to do a full application 
in languages like C/C++/Rust/D...

But if you create an "engine language" then you also need to be 
very good at exporting APIs. Like having compact and readable API 
definitions in D that lends itself to auto-generating interfaces 
for other languages (Python, Ruby, Go, Javascript etc).


 2. Solid non-gc memory management and ownership.


 Any specific implementation in mind?


Change the language enough so that you can do full pointer 
analysis and compete with Rust/C++.

Limit GC to actors.  Use move semantics between actors.

Point 3 and out really depends on what you do with point 1 and 2.

The key point here is that the project leadership needs to start 
with defining enough constraints to do rational focused and 
strategic decision making.

Then make a high level plan that takes you from where you are to 
a finished project, then you refine the plan (and evolve it).

Piling up proposals and endless non-breaking evolution isn't 
effective.
Oct 08 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:

 On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim 
 Grøstad wrote:

 That's not vague at all.



 1. Define the target, then you can figure out the features.


 Then define the target. Make some suggestions.


 I've already raised this topic in a thread where I asked where 
 D sits in the web space. And I did that because it has been 
 said that vibe.d defines a key application area. However, that 
 is a very hard market to capture which many expressed in that 
 thread.

 I think D could do well if it focused on engine-level system 
 programming and made sure it was absolutely top notch for that 
 purpose. (Game engines, search engines, ray tracing engines, in 
 memory database engines, business logic engines, etc).

 The current focus goes the other way. The current assumption is 
 that engines are written in C/C++ and they are used to complete 
 applications in D. That would make D an application level 
 language, which makes success _very_difficult. As time 
 progresses I believe it makes less and less sense to do a full 
 application in languages like C/C++/Rust/D...


I agree that D should be strong in this area (engine level). On 
top of that you can stack powerful libs like Phobos. I use D as 
an engine in some projects and I'm thinking of using it for this 
purpose in other projects further down the road, for example 
using D as an engine for simpler, high-level languages like 
linguistic analysis tools where rules are defined by 
non-programmers at a higher level.

But by no means is it necessary that D be confined to this 
particular use case. An "engine language" can be extended with 
libs. However, you have to draw a clear line between the standard 
library and the language. This border is a bit blurred in D. Then 
again, I don't know how Go and Rust will fare in a couple of 
years' time. The lines seem to blur over time, because any 
language is pretty useless without at least one powerful library 
to its name.


 But if you create an "engine language" then you also need to be 
 very good at exporting APIs. Like having compact and readable 
 API definitions in D that lends itself to auto-generating 
 interfaces for other languages (Python, Ruby, Go, Javascript 
 etc).
Oct 08 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:

 in D. Then again, I don't know how Go and Rust will fare in a 
 couple of years' time.


I think the C++ people are desperately trying to recapture the 
application market with some of the things that they propose for 
C++17/20. I think that market is dying fast for C++. I don't know 
about Rust, they seem to aim for high level programming. I think 
both C++ and Rust have too many syntax issues to be convenient 
for high level applications.

Go I think will do ok for focused web services with not too 
complicated logic. I don't think they will replace Java. I think 
Go will take the market where people have been using Java, but 
not really needed the feature set.


 The lines seem to blur over time, because any language is 
 pretty useless without at least one powerful library to its 
 name.


Applications benefit from frameworks, and then the desired 
frameworks dictate the language you use. So growth is difficult 
in that domain.

But you can implement you application model in an "engine 
language" and use a javascript framework for the UI with a 
browser engine in-between then the "engine language" can focus on 
efficient marshalling between that browser engine and the runtime.

So basically, break up the eco system so that you aren't locked 
into a small language (like D or Rust).
Oct 08 2015
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 8 October 2015 at 11:56:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:

 in D. Then again, I don't know how Go and Rust will fare in a 
 couple of years' time.


 I think the C++ people are desperately trying to recapture the 
 application market with some of the things that they propose 
 for C++17/20. I think that market is dying fast for C++. I 
 don't know about Rust, they seem to aim for high level 
 programming. I think both C++ and Rust have too many syntax 
 issues to be convenient for high level applications.

 Go I think will do ok for focused web services with not too 
 complicated logic. I don't think they will replace Java. I 
 think Go will take the market where people have been using 
 Java, but not really needed the feature set.


But a language like D that is already very feature rich cannot be 
dragged down to the level of Go anymore. D combines Go and Java, 
although in an incomplete way (as of now).


 The lines seem to blur over time, because any language is 
 pretty useless without at least one powerful library to its 
 name.


 Applications benefit from frameworks, and then the desired 
 frameworks dictate the language you use. So growth is difficult 
 in that domain.

 But you can implement you application model in an "engine 
 language" and use a javascript framework for the UI with a 
 browser engine in-between then the "engine language" can focus 
 on efficient marshalling between that browser engine and the 
 runtime.

 So basically, break up the eco system so that you aren't locked 
 into a small language (like D or Rust).


That's what I've been doing for 2-3 years now thanks to D. I use 
D as the core and everything else is glued onto the D core. D is 
actually pretty good at this. Since it's cross-platform, I can 
use the same code base everywhere. I don't need to worry about 
UIs or the like. On Windows, for example, I can compile the code 
into a dll and expose the functions that are needed. The UI can 
be in Python, Lua or whatever. I'm kinda using D as "C with 
high-level features". This is exactly what brought me to D, not 
having to worry about platforms anymore. Write once, connect to 
anything.
Oct 08 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:

 That's what I've been doing for 2-3 years now thanks to D. I 
 use D as the core and everything else is glued onto the D core. 
 D is actually pretty good at this. Since it's cross-platform, I 
 can use the same code base everywhere. I don't need to worry 
 about UIs or the like.


Yes, I think this is the more scalable approach for both D, C++ 
and Rust.

For my use case (virtual world simulation) I'll probably end up 
using the first production level language that can provide tight 
asm.js codege, IEEE754-2008 support and guarantee reproducible 
results between client and server. But maybe I'll end up having 
to using a JIT on the server... I don't think there are any 
obvious alternatives at the moment. Maybe Rust will get there 
first.
Oct 08 2015
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 8 October 2015 at 13:45:43 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:

 That's what I've been doing for 2-3 years now thanks to D. I 
 use D as the core and everything else is glued onto the D 
 core. D is actually pretty good at this. Since it's 
 cross-platform, I can use the same code base everywhere. I 
 don't need to worry about UIs or the like.


 Yes, I think this is the more scalable approach for both D, C++ 
 and Rust.

 For my use case (virtual world simulation) I'll probably end up 
 using the first production level language that can provide 
 tight asm.js codege, IEEE754-2008 support and guarantee 
 reproducible results between client and server. But maybe I'll 
 end up having to using a JIT on the server... I don't think 
 there are any obvious alternatives at the moment. Maybe Rust 
 will get there first.


It'd be nice to have asm.js or even JS.
Oct 08 2015
next sibling parent reply Freddy <Hexagonalstar64 gmail.com> writes:
On Thursday, 8 October 2015 at 14:02:58 UTC, Chris wrote:

 It'd be nice to have asm.js or even JS.


The major ploblem I see right now with targeting asm.js is 
garbage collection. This can be worked around (I think) by having 
all pointers be fat pointers (size_t* stack_ref_count,T* data) 
and by having write barriers (that check for null for 
stack_ref_count) when coping pointers.
Oct 08 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 17:56:57 UTC, Freddy wrote:

 On Thursday, 8 October 2015 at 14:02:58 UTC, Chris wrote:

 It'd be nice to have asm.js or even JS.


 The major ploblem I see right now with targeting asm.js is 
 garbage collection. This can be worked around (I think) by 
 having all pointers be fat pointers (size_t* stack_ref_count,T* 
 data) and by having write barriers (that check for null for 
 stack_ref_count) when coping pointers.


Currently effective garbage collection is not possible since you 
cannot scan the stack. I think GC features are planned for some 
future version of WebAssembly.

However, you can generate asm.js like Javascript for gc code.

Or just require nogc.

asm.js also don't have exceptions and goto, neither does it have 
umul, udiv or 64 bit integers.

Non of those are show stoppers, but efficient code gen requires 
using what asm.js does well...
Oct 08 2015
prev sibling parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Thursday, 8 October 2015 at 14:02:58 UTC, Chris wrote:

 On Thursday, 8 October 2015 at 13:45:43 UTC, Ola Fosheim 
 Grøstad wrote:

 On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:

 That's what I've been doing for 2-3 years now thanks to D. I 
 use D as the core and everything else is glued onto the D 
 core. D is actually pretty good at this. Since it's 
 cross-platform, I can use the same code base everywhere. I 
 don't need to worry about UIs or the like.


 Yes, I think this is the more scalable approach for both D, 
 C++ and Rust.

 For my use case (virtual world simulation) I'll probably end 
 up using the first production level language that can provide 
 tight asm.js codege, IEEE754-2008 support and guarantee 
 reproducible results between client and server. But maybe I'll 
 end up having to using a JIT on the server... I don't think 
 there are any obvious alternatives at the moment. Maybe Rust 
 will get there first.


 It'd be nice to have asm.js or even JS.


Look at Adam Ruppe's D to JavaScript compiler.  It hasn't been 
maintained, but it was a very interesting experiment.

I wish there were more interest in having LDC generate JS via 
LLVM a la emscripten.  Some serious people think it's not that 
difficult.
Oct 08 2015
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 8 October 2015 at 18:29:00 UTC, Laeeth Isharc wrote:


 It'd be nice to have asm.js or even JS.


 Look at Adam Ruppe's D to JavaScript compiler.  It hasn't been 
 maintained, but it was a very interesting experiment.

 I wish there were more interest in having LDC generate JS via 
 LLVM a la emscripten.  Some serious people think it's not that 
 difficult.


To be honest, rather than having IDEs and all the bells and 
whistles (which started this thread), I'd prefer D to cater for 
things like asm.js and ARM processors. Nim got it right in the 
sense that it allows developers to write code and ship it to web 
browsers and everything else that understands JS. Writing JS is a 
pain in the "sit upon", being able to write code in a decent 
language and have it output as JS is great. There's no way around 
the web, i.e. JS.

 Ola

That said one has to be careful when looking at other languages 
such as Go and Rust. I remember the VM fashion a couple of years 

native code kept coming up and now everyone goes native, 
including the VM supporters. Why? Cos it didn't work and 
everybody working with Java realized that, it's too fookin slow. 
How can we tell that Go is the way to go (pardon the pun)? Maybe 
in a few years' time the thing to do will be library based memory 
management. One of D's strengths is to be impervious to fashion 
and to try to do what's right and what works. Ironically enough, 
C++ is playing catch up with D. D might not get the credit that's 
due, but D proves that certain concepts work better than others. 
But who ever gives credit to the lab rats? :-)
Oct 09 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 9 October 2015 at 10:13:07 UTC, Chris wrote:

 such as Go and Rust. I remember the VM fashion a couple of 

 compile to native code kept coming up and now everyone goes 
 native, including the VM supporters. Why? Cos it didn't work 
 and everybody working with Java realized that, it's too fookin 
 slow.


VMs and JIT compilation works well for things that aren't engine 
level, like most of the application level code. I think sluggish 
performance for has more to do with static typing and memory 
layout than codegen (sans SIMD).

So maybe just compiling to JIT friendly Javascript with typed 
arrays is good enough. The problem is that you need to know all 
the JITs and runtimes in order to figure out what kind of 
Javascript constructs you need to use. Basically figuring out 
what "templates" the JITs translate into efficient machine code.


 How can we tell that Go is the way to go (pardon the pun)?


Go is not the way to go in general, but it is currently the best 
option for ahead of time compiled web services that are I/O 
bound. But for me it is _primarily_ an infrastructure issue. 
Infrastructure issues makes it difficult to compete with 
languages like Go, Java and Python for web servers.


 Maybe in a few years' time the thing to do will be library 
 based memory management.


I think that is unlikely given all the research on pointer 
analysis etc.


 One of D's strengths is to be impervious to fashion and to try 
 to do what's right and what works. Ironically enough, C++ is 
 playing catch up with D.


C++ is under pressure from Rust, Go and perhaps also D. Mostly 
because it takes years (or decades) to get new features into C++, 
so they have to start working on new features early. I am not 
even sure we would have seen the C++ guidelines/GSL initiative 
without Rust. They basically bypassed the standard process in 
order to "add features" faster by pushing it at CppCon...
Oct 09 2015
parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 9 October 2015 at 12:05:13 UTC, Ola Fosheim Grøstad 
wrote:

 C++ is under pressure from Rust, Go and perhaps also D. Mostly 
 because it takes years (or decades) to get new features into 
 C++, so they have to start working on new features early. I am 
 not even sure we would have seen the C++ guidelines/GSL 
 initiative without Rust. They basically bypassed the standard 
 process in order to "add features" faster by pushing it at 
 CppCon...


and in typical C++ fashion, it's going to just be a gigantic ugly 
hack
Oct 09 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 9 October 2015 at 12:06:40 UTC, rsw0x wrote:

 On Friday, 9 October 2015 at 12:05:13 UTC, Ola Fosheim Grøstad 
 wrote:

 C++ is under pressure from Rust, Go and perhaps also D. Mostly 
 because it takes years (or decades) to get new features into 
 C++, so they have to start working on new features early. I am 
 not even sure we would have seen the C++ guidelines/GSL 
 initiative without Rust. They basically bypassed the standard 
 process in order to "add features" faster by pushing it at 
 CppCon...


 and in typical C++ fashion, it's going to just be a gigantic 
 ugly hack


But never mind, it's gonna be _the_ innovation and C++ people 
will say "Why use D, we have it in C++! D is outdated! C++ is 
modern!" There gonna be books like "Modern programming in C++" 
for $68+. It's so boring, so predictable.
Oct 09 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad 
wrote:

 I think D could do well if it focused on engine-level system 
 programming and made sure it was absolutely top notch for that 
 purpose. (Game engines, search engines, ray tracing engines, in 
 memory database engines, business logic engines, etc).

 The current focus goes the other way. The current assumption is 
 that engines are written in C/C++ and they are used to complete 
 applications in D.


What D lacks in comparison to C w.r.t. to writing an engine?
Oct 08 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 8 October 2015 at 16:28:45 UTC, Kagamin wrote:

 What D lacks in comparison to C w.r.t. to writing an engine?


C is not really a comparable option language wise, C has not 
changed a lot since the 70s. But if you started to make a list of 
what the C eco system offers then you get a rather long list 
ranging from platform support to tooling and language extensions.
Oct 08 2015
parent Kagamin <spam here.lot> writes:
On Thursday, 8 October 2015 at 16:47:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 8 October 2015 at 16:28:45 UTC, Kagamin wrote:

 What D lacks in comparison to C w.r.t. to writing an engine?


 C is not really a comparable option language wise, C has not 
 changed a lot since the 70s. But if you started to make a list 
 of what the C eco system offers then you get a rather long list 
 ranging from platform support to tooling and language 
 extensions.


So D as a language is better than C for engine development, it's 
just tools and libraries, that get the boring work done, are not 
written in it yet?
Oct 09 2015
prev sibling parent Freddy <Hexagonalstar64 gmail.com> writes:
On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:

 2. Solid non-gc memory management and ownership.


 Any specific implementation in mind?


Well the first step to that should be implement a way to make 
sure pointers don't escape their scope.
Oct 08 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
Grøstad wrote:

And don't forget a*se covering, risk aversion is often not much 
more than that. It's one of the most common things in 
organizations. If things go wrong, at least you stuck to the 
protocol, the the well-established, widely used language. So they 
can't get you there. If not they fry you, even if the failure is 
due to other things.
Sep 29 2015
parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 29 September 2015 at 17:52:54 UTC, Chris wrote:

 And don't forget a*se covering, risk aversion is often not much 
 more than that. It's one of the most common things in 
 organizations. If things go wrong, at least you stuck to the 
 protocol, the the well-established, widely used language. So 
 they can't get you there. If not they fry you, even if the 
 failure is due to other things.


Yes - that is most of it.  The way that changes is some people 
are less driven by social factors, whether because of who they 
are or the situation they are in.  Some of these succeed, slowly 
perceptions change, and after a while it's the best thing since 
sliced bread.  But these things take time, and it's senseless to 
think one can know the moment of inflection points based on 
logical reasoning (since the timing depends on many other factors 
out of the scope of things one is familiar with - these factors 
are easier to spot with hindsight than in real time).
Sep 30 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
Grøstad wrote:

 D2 does not solve C++'s issues


Heartbleed?
Sep 30 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 30 September 2015 at 09:16:44 UTC, Kagamin wrote:

 On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
 Grøstad wrote:

 D2 does not solve C++'s issues


 Heartbleed?


C++ offers optional bounds checks + static analysis tools.
Sep 30 2015
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 30 September 2015 at 12:43:10 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 September 2015 at 09:16:44 UTC, Kagamin wrote:

 On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim 
 Grøstad wrote:

 D2 does not solve C++'s issues


 Heartbleed?


 C++ offers optional bounds checks + static analysis tools.


C++ offers hidden features, D solves the issue :)
Sep 30 2015
parent reply learn <learn learn.com> writes:
  working as advertised




libucrtd.lib is still sought and not found after another new 
release.
you guys should get your shit together, otherwise more people 
that try D will "Moving back to .NET" and not tell you about it.

well i guess i leave now too, since i don't have the time and 
patience to wait any longer for the compiler to work.

sincerely yours
Sep 30 2015
parent reply Mengu <mengukagan gmail.com> writes:
On Wednesday, 30 September 2015 at 15:45:02 UTC, learn wrote:

  working as advertised




 libucrtd.lib is still sought and not found after another new 
 release.
 you guys should get your shit together, otherwise more people 
 that try D will "Moving back to .NET" and not tell you about it.

 well i guess i leave now too, since i don't have the time and 
 patience to wait any longer for the compiler to work.

 sincerely yours


what is libucrtd.lib? what kind of application/library were you 
trying to build?

i just wanted to see if i can use dmd without any problems with 
windows 10. downloaded it, installed it and everything just 
worked fine.
Sep 30 2015
next sibling parent learn <learn learn.com> writes:
On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:

 On Wednesday, 30 September 2015 at 15:45:02 UTC, learn wrote:

  working as advertised




 libucrtd.lib is still sought and not found after another new 
 release.
 you guys should get your shit together, otherwise more people 
 that try D will "Moving back to .NET" and not tell you about 
 it.

 well i guess i leave now too, since i don't have the time and 
 patience to wait any longer for the compiler to work.

 sincerely yours


 what is libucrtd.lib? what kind of application/library were you 
 trying to build?

 i just wanted to see if i can use dmd without any problems with 
 windows 10. downloaded it, installed it and everything just 
 worked fine.


please see "new release doesn't work as advertised" of august 13, 
2015.

(x64)
Building Debug\ConsoleApp1.exe...
LINK : fatal error LNK1104: cannot open file 'libucrtd.lib'
Building Debug\ConsoleApp1.exe failed!

win10 - vs2015
Sep 30 2015
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:

 what is libucrtd.lib


http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

"The Universal CRT is a Windows operating system component. It is 
a part of Windows 10. For Windows versions prior to Windows 10, 
the Universal CRT is distributed via Windows Update."
Sep 30 2015
parent Kagamin <spam here.lot> writes:
On Wednesday, 30 September 2015 at 17:32:27 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:

 what is libucrtd.lib


 http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

 "The Universal CRT is a Windows operating system component. It 
 is a part of Windows 10. For Windows versions prior to Windows 
 10, the Universal CRT is distributed via Windows Update."


That doesn't apply to link stage. And libucrtd.lib is a (not 
recommended) static universal crt.
Oct 01 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 25 September 2015 at 20:05:08 UTC, Ola Fosheim Grostad 
wrote:


 I don't understand what would make D iconclastic? The feature 
 set is quite ordinary c++ish, but there are some areas that 
 show that features have been added without enough work being 
 put into them before they were implemented. But OO is primarily 
 about modelling, it wasn't meant to be a low level programming 
 paradigm. Classes etc is just language features to support the 
 high level model and evolving it over time. Ths is where C++ 
 went wrong IMO.


"Iconoclastic" is a bit exaggerated, I know. But D makes people 
think, not just accept things, which is subversive. I've noticed 
that people prefer to accept things as is, which makes life 

reason why people who use these languages are offended and get 
angry, when you point out flaws to them (as Jonathan said). It's 
like any belief system.

We are not talking about D as a language/tool here, we are 
talking about psychological factors. Go and Java got it right 
from a psychological point of view. They cater for people's need 
for guidance by not giving them options. But I don't think this 
is what D is all about. And that's why it is hard for people to 
grasp.

Btw, risk is not that big a factor anymore. D is mature enough. 
When IBM embraced Java, it was a huge boost for Java, but Java 
was still quite young and immature. If IBM embraced D, it would 
soon see IDEs and libraries, everything. But nobody embraces D.
Sep 25 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 16:15:45 UTC, Laeeth Isharc wrote:

 Where I think we don't do such a good job is curating such 
 knowledge and presenting it in a form that's easy to digest for 
 newcomers.  That's also a function of the kinds of people that 
 are here, because creative people don't like doing boring 
 things like write documentation.  (And they have other 
 higher-valued demands on their time).  I don't know what the 
 answer is, but we will have to find one over time.


BTW I don't get the documentation problem. I often catch myself 
admiring my code, yeah I do a good job writing it, and by writing 
docs I give it credit for its beauty, I brag about great job I 
did. Like... "look there was this problem and I solved it in the 
most elegant way possible, see how:... and it does this and that 
because it's the best thing to do here, and it doesn't do that 
because it's not good to do it here, and it has this little 
feature that makes it better than without it and is really 
helpful". So it feels like people don't want to write docs 
because they think they wrote a crappy code and hence can't give 
it credit, they are ashamed to speak about it.
Sep 25 2015
next sibling parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Friday, 25 September 2015 at 20:01:18 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 16:15:45 UTC, Laeeth Isharc 
 wrote:

 Where I think we don't do such a good job is curating such 
 knowledge and presenting it in a form that's easy to digest 
 for newcomers.  That's also a function of the kinds of people 
 that are here, because creative people don't like doing boring 
 things like write documentation.  (And they have other 
 higher-valued demands on their time).  I don't know what the 
 answer is, but we will have to find one over time.


 BTW I don't get the documentation problem. I often catch myself 
 admiring my code, yeah I do a good job writing it, and by 
 writing docs I give it credit for its beauty, I brag about 
 great job I did. Like... "look there was this problem and I 
 solved it in the most elegant way possible, see how:... and it 
 does this and that because it's the best thing to do here, and 
 it doesn't do that because it's not good to do it here, and it 
 has this little feature that makes it better than without it 
 and is really helpful"



 So it feels like people don't want to write docs because they 
 think they wrote a crappy code and hence can't give it credit, 
 they are ashamed to speak about it.


I don't think that's it.  A certain part of the population is 
endogenously motivated.  Your emotions are organised towards the 
problem domain - the thing in itself - rather than social 
factors.  So when you have done what you wanted to the standard 
you want, you have your fix and getting others to notice may not 
be in itself gratifying.  This is a minority makeup, but an 
important one for various reasons.
Sep 25 2015
parent reply Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 20:52:32 UTC, Laeeth Isharc wrote:

 A certain part of the population is endogenously motivated.


What can be more endogenous than self-gratification? Or an 
incentive to write good code?


 Your emotions are organised towards the problem domain - the 
 thing in itself - rather than social factors.  So when you have 
 done what you wanted to the standard you want, you have your fix


Sounds as if you have no interest in what you do. You get it done 
and forget about it as a nightmare, you don't like what you wrote.
Sep 25 2015
parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Friday, 25 September 2015 at 21:18:08 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 20:52:32 UTC, Laeeth Isharc 
 wrote:

 A certain part of the population is endogenously motivated.


 What can be more endogenous than self-gratification? Or an 
 incentive to write good code?


"
BTW I don't get the documentation problem. I often catch myself 
admiring my code, yeah I do a good job writing it, and by writing 
docs I give it credit for its beauty, I brag about great job I 
did. Like... "look there was this problem and I solved it in the 
most elegant way possible, see how:... and it does this and that 
because it's the best thing to do here, and it doesn't do that 
because it's not good to do it here, and it has this little 
feature that makes it better than without it and is really 
helpful"
"

Because for some people, writing it is enough, and now onto the 
next challenge.  One has to accept that it's a big world with 
room for many different kinds of people.


 Your emotions are organised towards the problem domain - the 
 thing in itself - rather than social factors.  So when you 
 have done what you wanted to the standard you want, you have 
 your fix


 Sounds as if you have no interest in what you do. You get it 
 done and forget about it as a nightmare, you don't like what 
 you wrote.


;) !

Not everyone would agree with that one... as I do little else.

I was speaking about the general case, but since you made it a 
personal reference - if I spent time to step back and admire my 
handiwork, I wouldn't at this point have time to finish the 
broader project as its at the limit of what's possible.
Sep 25 2015
parent Kagamin <spam here.lot> writes:
On Friday, 25 September 2015 at 21:46:35 UTC, Laeeth Isharc wrote:

 I was speaking about the general case, but since you made it a 
 personal reference - if I spent time to step back and admire my 
 handiwork, I wouldn't at this point have time to finish the 
 broader project as its at the limit of what's possible.


Priorities are understandable, but I meant the boredom argument, 
which I usually hear:

 creative people don't like doing boring things like write 
 documentation


On Saturday, 26 September 2015 at 00:28:19 UTC, Jonathan M Davis 
wrote:

 A lot of folks write code because they want to get something 
 done and simply because they like coding. Most programmers 
 consider documentation to be a chore, even when they're really 
 excited about what they did. In general, I wouldn't expect 
 someone to even open source something if the problem was that 
 they were ashamed about how they did it.


If the objective is to get thing done, then even if code is 
horrible, it's worth to share, because it gets thing done. This 
is also the reason for commercial open source: they free each 
other from the nightmare of software development by sharing the 
source. It's understandable why one doesn't want to see this 
nightmare second time.
Sep 29 2015
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 25 September 2015 at 20:01:18 UTC, Kagamin wrote:

 On Friday, 25 September 2015 at 16:15:45 UTC, Laeeth Isharc 
 wrote:

 Where I think we don't do such a good job is curating such 
 knowledge and presenting it in a form that's easy to digest 
 for newcomers.  That's also a function of the kinds of people 
 that are here, because creative people don't like doing boring 
 things like write documentation.  (And they have other 
 higher-valued demands on their time).  I don't know what the 
 answer is, but we will have to find one over time.


 BTW I don't get the documentation problem. I often catch myself 
 admiring my code, yeah I do a good job writing it, and by 
 writing docs I give it credit for its beauty, I brag about 
 great job I did. Like... "look there was this problem and I 
 solved it in the most elegant way possible, see how:... and it 
 does this and that because it's the best thing to do here, and 
 it doesn't do that because it's not good to do it here, and it 
 has this little feature that makes it better than without it 
 and is really helpful". So it feels like people don't want to 
 write docs because they think they wrote a crappy code and 
 hence can't give it credit, they are ashamed to speak about it.


A lot of folks write code because they want to get something done 
and simply because they like coding. Publicizing it isn't 
necessarily particularly important to them. They may want to make 
it open source so that others can use it if they're so inclined, 
but that's frequently not the goal. And even when they _do_ want 
to make a big deal out of something, coding is a lot more 
interesting than writing documentation, and there's always more 
code to write, so it can be pretty easy to leave documentation by 
the wayside. Most programmers consider documentation to be a 
chore, even when they're really excited about what they did. In 
general, I wouldn't expect someone to even open source something 
if the problem was that they were ashamed about how they did it. 
I fully expect that in the vast majority of cases when code is 
available but not well documented, it's because the programmer 
didn't have the time to do it or didn't want to spend the time 
doing it. This is the first time that I've ever heard anyone 
suggest that it was due to shame about the code.

- Jonathan M Davis
Sep 25 2015
parent Chris <wendlec tcd.ie> writes:
On Saturday, 26 September 2015 at 00:28:19 UTC, Jonathan M Davis 
wrote:


 A lot of folks write code because they want to get something 
 done and simply because they like coding. Publicizing it isn't 
 necessarily particularly important to them. They may want to 
 make it open source so that others can use it if they're so 
 inclined, but that's frequently not the goal. And even when 
 they _do_ want to make a big deal out of something, coding is a 
 lot more interesting than writing documentation, and there's 
 always more code to write, so it can be pretty easy to leave 
 documentation by the wayside. Most programmers consider 
 documentation to be a chore, even when they're really excited 
 about what they did. In general, I wouldn't expect someone to 
 even open source something if the problem was that they were 
 ashamed about how they did it. I fully expect that in the vast 
 majority of cases when code is available but not well 
 documented, it's because the programmer didn't have the time to 
 do it or didn't want to spend the time doing it. This is the 
 first time that I've ever heard anyone suggest that it was due 
 to shame about the code.

 - Jonathan M Davis


And don't forget that there are also the unit tests. Once they 
are written they are documentation + example in one. I often find 
myself looking at the unit tests in Phobos to see how things 
work, when in doubt.
Sep 28 2015
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2015 14:54, Chris wrote:

 On Friday, 25 September 2015 at 13:13:29 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros wrote:

 Dunno if "expect" is the right word, but a language team that puts
 IDE support as part of its development effort, will have a big
 competitive advantage.


 Indeed, when you are production ready having a top notch IDE becomes a
 big competitive advantage! I don't know if an IDE attracts people who
 work on compilers/debuggers though...


 and basic tools). For example, they contracted an external developer
 to help them with debugger issues


 Sure, excellent debugging support (lldb/gdb) is important.


 Having followed this forum for 2 or 3 years now, I doubt whether an IDE
 would attract people at this stage. If we had a full-fledged IDE, there
 would be other concerns (or excuses). D scares people away. It's too
 raw, too bare bones, everything is still moving like hot lava, and maybe
 people are intimidated by it, because they feel they might be considered
 bad programmers, if they don't know the ins and outs of it.


I agree with the first sentence: "Having followed this forum for 2 or 3 
years now, I doubt whether an IDE would attract people at this stage."

Current D IDE's are far from the level of Eclipse CDT or VisualStudio, 
but they're not too bad either, they're pretty decent. This wasn't the 
case, say 5 years ago. If was to code in D 5 years ago, the issue that 
would be most troublesome would be IDE quality. Not so much nowadays. D 
IDEs have advanced enough that deficiencies in other tools become more 
important instead (this is very subjective of course, and depends also 
on one's work environment and area of development.)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
prev sibling parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros 
wrote:

 On 23/09/2015 22:02, Ola Fosheim Grøstad wrote:

 IDE is not just a nice interface to write code. It's a way to 
 organize
 files, AST based file browsing, github integration, and - the 
 most
 important aspect for me - is the *integrated debugging 
 support*. I'll
 never use dmd from command line and the lack of IDE support 
 would be
 definitely a stopper for me.


 While it is easy to agree with you, I don't think a lack of 
 IDE or even
 libraries is something one should expect to be addressed by 
 the language
 developer. Those are issues one can find solutions to if D is 
 suitable
 and different people have different taste. Go and Rust have 
 been in the
 same boat. This is not a show stopper...


 Dunno if "expect" is the right word, but a language team that 
 puts IDE support as part of its development effort, will have a 
 big competitive advantage.

 D is not on the same boat as Rust here. The Rust team is 
 investing much more in toolchain support (beyond the compiler 
 and basic tools). For example, they contracted an external 
 developer to help them with debugger issues 
 (https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html). And
more than that, they are also now effecting plans to improve their tools (or
create new ones) to support IDE functionality (
https://github.com/nrc/rfcs/blob/2410d2ce1682813ea79debbf13a99868e6a6b
8a/text/0000-ide.md )


Out of curiosity, how much money  would be needed to do something 
similar for D ?  Not that I can help for now, but it's good to 
understand the magnitude of things.
Sep 25 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/09/2015 14:43, Laeeth Isharc wrote:

 On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros wrote:

 On 23/09/2015 22:02, Ola Fosheim Grøstad wrote:

 IDE is not just a nice interface to write code. It's a way to organize
 files, AST based file browsing, github integration, and - the most
 important aspect for me - is the *integrated debugging support*. I'll
 never use dmd from command line and the lack of IDE support would be
 definitely a stopper for me.


 While it is easy to agree with you, I don't think a lack of IDE or even
 libraries is something one should expect to be addressed by the language
 developer. Those are issues one can find solutions to if D is suitable
 and different people have different taste. Go and Rust have been in the
 same boat. This is not a show stopper...


 Dunno if "expect" is the right word, but a language team that puts IDE
 support as part of its development effort, will have a big competitive
 advantage.

 D is not on the same boat as Rust here. The Rust team is investing
 much more in toolchain support (beyond the compiler and basic tools).
 For example, they contracted an external developer to help them with
 debugger issues
 (https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html).
 And more than that, they are also now effecting plans to improve their
 tools (or create new ones) to support IDE functionality (
 https://github.com/nrc/rfcs/blob/2410d2ce1682813ea79debbf13a99868e6a6bd8a/text/0000-ide.md
 )


 Out of curiosity, how much money  would be needed to do something
 similar for D ?  Not that I can help for now, but it's good to
 understand the magnitude of things.


Dunno. A developer's salary would have to be paid, and since it's a 
remote job, could vary a lot depending on the location where the 
developer is based.

Also, a developer who is already involved in the community, and has 
interested in working in such area, could be willing to work for a 
fraction of his normal salary. (I would, for example)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 28 2015
prev sibling next sibling parent reply alienhunter3 <alienhunter3 gmail.com> writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:


 IDE is not just a nice interface to write code. It's a way to 
 organize files, AST based file browsing, github integration, 
 and - the most important aspect for me - is the *integrated 
 debugging support*. I'll never use dmd from command line and 
 the lack of IDE support would be definitely a stopper for me.

 The same people not minding the lack of IDE support are usually 
 the Linux guys. Personally, I don't know any Windows developer 
 masochistic enough to use the command line when an IDE is 
 available for the task described above.


The weird thing to me about this is that I am a Linux guy, and 
the stuff that I do in D with Linux is done with 
MonoDevelop(Xamarin) and Mono-D.  I create solutions/projects 
just like I do for .NET stuff in Windows.  Granted, you have to 
follow instructions to set up the compiler, so it is slightly 
harder than .NET where you don't really have to set anything up.

Still, Mono-D in Windows and Linux has met all of my IDE needs.  
Are there some common IDE features that Mono-D/Xamarin don't have 
that are deal-breakers for the .NET folks?
Sep 23 2015
parent reply rumbu <rumbu rumbu.ro> writes:
On Wednesday, 23 September 2015 at 21:29:02 UTC, alienhunter3 
wrote:

 Still, Mono-D in Windows and Linux has met all of my IDE needs.
  Are there some common IDE features that Mono-D/Xamarin don't 
 have that are deal-breakers for the .NET folks?


Despite the fact that Mono-D is better than VisualD at syntax 
highlighting and code completion, it is very slow for large files 
and it crashes very often on Windows (this is not Mono-D fault, 
but Xamarins's). The main deal-breaker-feature missing in Mono-D 
is the debugging support, that's why I stick to VisualD. As the 
OP said, the error messages (especially when you are using plenty 
of templated code) are a PIA, regardless the IDE used. Debugging 
also is a PIA for templated or conditional code. Try to debug a 
bunch of unittest asserts - you'll never hit the correct line in 
code. Usually I break the unittests in one-liners just to see 
exactly where the problem is.
Sep 23 2015
next sibling parent reply ZombineDev <valid_email he.re> writes:
On Thursday, 24 September 2015 at 05:04:46 UTC, rumbu wrote:

 On Wednesday, 23 September 2015 at 21:29:02 UTC, alienhunter3 
 wrote:

 [...]


 Despite the fact that Mono-D is better than VisualD at syntax 
 highlighting and code completion, it is very slow for large 
 files and it crashes very often on Windows (this is not Mono-D 
 fault, but Xamarins's). The main deal-breaker-feature missing 
 in Mono-D is the debugging support, that's why I stick to 
 VisualD. As the OP said, the error messages (especially when 
 you are using plenty of templated code) are a PIA, regardless 
 the IDE used. Debugging also is a PIA for templated or 
 conditional code. Try to debug a bunch of unittest asserts - 
 you'll never hit the correct line in code. Usually I break the 
 unittests in one-liners just to see exactly where the problem 
 is.


Actually Mono-D has better debugging experience than VisualD, but 
ironically it works only on Linux :D
I don't know why you are having troubles with unittests because 
when a UT fails, the error message includes the line number, so 
you can put a breakpoint there.
Sep 23 2015
parent rumbu <rumbu rumbu.ro> writes:
On Thursday, 24 September 2015 at 06:22:06 UTC, ZombineDev wrote:


 Actually Mono-D has better debugging experience than VisualD, 
 but ironically it works only on Linux :D
 I don't know why you are having troubles with unittests because 
 when a UT fails, the error message includes the line number, so 
 you can put a breakpoint there.


Debugging asserts:

http://imgur.com/LEiGN61

Debugging templated code:

http://imgur.com/NJcdeH8

Mago & Visual Studio debugger, both failed.
Sep 24 2015
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 24/09/2015 06:04, rumbu wrote:

 Despite the fact that Mono-D is better than VisualD at syntax
 highlighting and code completion, it is very slow for large files and it
 crashes very often on Windows (this is not Mono-D fault, but Xamarins's).


I wonder if this is related to the GDB release one has in Windows? DDT 
has a similar problem in that some GDB releases work better than others 
(for example the Cygwin GDB doesn't work properly).

Ideally a bad GDB release / version should never crash or freeze the IDE 
itself - but otherwise, it definitely can still affect the debugging 
experience.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 25 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:
  stopper for me.

 The same people not minding the lack of IDE support are usually 
 the Linux guys. Personally, I don't know any Windows developer 
 masochistic enough to use the command line when an IDE is 
 available for the task described above.


I guess I'm a masochist! Seriously, though, most of the time I 
use Sublime Text and a command prompt where I execute DUB. 
Painless.
Sep 23 2015
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 24 September 2015 at 06:05:05 UTC, Mike Parker wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:
  stopper for me.

 The same people not minding the lack of IDE support are 
 usually the Linux guys. Personally, I don't know any Windows 
 developer masochistic enough to use the command line when an 
 IDE is available for the task described above.


 I guess I'm a masochist! Seriously, though, most of the time I 
 use Sublime Text and a command prompt where I execute DUB. 
 Painless.


Oh, and git through MSYS2.
Sep 23 2015
prev sibling next sibling parent reply wobbles <grogan.colin gmail.com> writes:
On Thursday, 24 September 2015 at 06:05:05 UTC, Mike Parker wrote:

 On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:
  stopper for me.

 The same people not minding the lack of IDE support are 
 usually the Linux guys. Personally, I don't know any Windows 
 developer masochistic enough to use the command line when an 
 IDE is available for the task described above.


 I guess I'm a masochist! Seriously, though, most of the time I 
 use Sublime Text and a command prompt where I execute DUB. 
 Painless.


Yep. Exactly this.

DKit is in good nick I think - and sublime makes it so very easy 
to add extra command that if there is anything missing it's an 
easy DIY job.

I've only had to add 1 though, "dub build --build=release".

I might put it in a pull request soon enough. Is there any other 
pain points for D on Sublime/DKit do you think?
Sep 23 2015
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 24 September 2015 at 06:56:16 UTC, wobbles wrote:

 I might put it in a pull request soon enough. Is there any 
 other pain points for D on Sublime/DKit do you think?


I don't actually use DKit, so I can't say anything about it. 
alt-tab, followed by down arrow-enter, is so reflexive for me now 
that I'm sure something like DKit would disrupt my flow and take 
a long time to get used to. Whenever I load up a C or C++ project 
in Visual Studio, I constantly alt-tab instead of ctrl-b (and 
that's on top of the D-isms that enter the code out of habit).
Sep 24 2015
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 24 September 2015 at 06:05:05 UTC, Mike Parker wrote:

 I guess I'm a masochist! Seriously, though, most of the time I 
 use Sublime Text and a command prompt where I execute DUB. 
 Painless.


Same here, though I had tried Coedit and found it pleasant (but 
not perfect).
Sep 24 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 23 September 2015 at 18:36:01 UTC, rumbu wrote:

 On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:

 On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:


 It's almost exclusively due to the error messages and IDE. I 
 know many here will write off such complaints, So be it.


 The thing is that a lot of people who use D don't mind the 
 lack of IDE support.


 IDE is not just a nice interface to write code. It's a way to 
 organize files, AST based file browsing, github integration, 
 and - the most important aspect for me - is the *integrated 
 debugging support*. I'll never use dmd from command line and 
 the lack of IDE support would be definitely a stopper for me.

 The same people not minding the lack of IDE support are usually 
 the Linux guys. Personally, I don't know any Windows developer 
 masochistic enough to use the command line when an IDE is 
 available for the task described above.


Whenever I (have to) work on a Windows machine, I use command 
line + text editor (Textadept). I've written a batch file that I 
call to compile the code, because there were problems due to dub 
not being able to create a dll. If I don't create a dll, I use 
dub. No problem. Why go through all the pain of setting up Visual 
whatever, if you can sort it out easily yourself?
Sep 24 2015
prev sibling next sibling parent Jan Johansson <jan.johansson.mr gmail.com> writes:
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

 My experiences with D recently have not been fun.

 The language itself has a top notch feature rich set. The 
 implementation, excluding bugs, feels a bit boxy and old 
 school. .NET has a unified approach and everything seems to fit 
 together nicely and feels consistent. The abomination of dmd, 
 though, is it's error messages. Most of them are meaningless 
 and you have to dive down 2 or 3 levels of assumptions to 
 figure out what they mean. It's not too bad but because of the 
 poor tool set it makes it difficult to debug apps.

 [...]



quite nice language. I like the Interface construct (and many 
more things). I tried mono, and find it a very interesting 
project, but it also has lots of stuff unimplemented and some of 
the stuff can't be done (Windows specific), since Xamarian 
targets multiple platforms with their .NET version.

But go ahead! :-)
Sep 30 2015
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Who cares? - Good luck in the .NET world.
Oct 07 2015