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.
