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

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

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.

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.

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.

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.

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.

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.

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.

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