Moving back to .NET

[Laeeth Isharc via Digitalmars-d]

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