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 
a D compiler similar to what it has done with C#. No 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.
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 
 build a D compiler similar to what it has done with C#. No 
 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
 compiler similar to what it has done with C#. No 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.
+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 
 build a D compiler similar to what it has done with C#. No 
 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 learning curve for anyone with C/C++/C# background.
 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 IDE-languages like Java or C#, the frustration of not being able 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 when I was programming in C#, which means I had to write .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...
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 when I was programming in C#, which means I had to write .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? Even though it is C# like and supports .net libs.
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? Even though it is C# like and supports .net libs.
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. now c# will be compiled to machine code - people you lost.
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? Even though it is C# like and supports .net libs.
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. now c# will be compiled to machine code - people you lost.
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.
 now c# will be compiled to machine code - people you lost.
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 or C# where you have a set menu. D is the kitchen, if you want to 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.
 now c# will be compiled to machine code - people you lost.
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 C#, but for D the button is green - deal breaker. 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? Even though it is C# like and supports .net libs.
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? Even though it is C# like and supports .net libs.
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 Loading a complex C# solution (11 projects - ASP.NET web server, 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 guess, C# compiler exists as a command line tools and as a 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. Java, C# and Go cater for this. D doesn't, and that's why it has 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. 
 Java, C# and Go cater for this. D doesn't, and that's why it 
 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 Go, C, C++, D, Java, C#, Nim, Rust, Ada... BUT that is only the language. Production involves more than the language. C++, Java and C# has a much larger set of options than the other 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 
 Go, C, C++, D, Java, C#, Nim, Rust, Ada...
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 
 the language. C++, Java and C# has a much larger set of options 
 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 C++ natively and more effort Java and prob C#. And if you are 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.
 1. That C# and Java programmers end up being disgruntled
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 serious chap talking about how they transitioned from C# if this 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 system level programming language and that competing with C# 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. 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 system level programming language and that competing with C# 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 C# &c programmers are driven away to which what I wrote was a 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 average Java/C# programmer who is used to the comfortable IDE 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: 1. That C# and Java programmers end up being disgruntled 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. 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:

 1. That C# and Java programmers end up being disgruntled 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.
Yes, I'm mainly a C# programmer. There are 4 years since I'm here 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. Comparisons to C# comes up regularly. My point is more that there is no way D can compete with projects that are good fit for C#. A 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 back (mainly Java and C#), but still languages that 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. 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 
 years back (mainly Java and C#), but still languages that 
 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 easier. Hence the huge success of Java and C#. This is also the 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.

 [...]
I got many *many* years experience of .NET, and I find C# as a 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