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.

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.

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.

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.

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.

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

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

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

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

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.