Moving back to .NET

[Laeeth Isharc via Digitalmars-d]

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.