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.

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.

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

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.

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

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

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).

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.

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.

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.