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. Software project management is often done by people who are programmers. From a project health point of view D2 suffers from the same issues as C++, the language feature set makes it easy to create a mess, and therefore the demands of investments in the development process gets higher. This aspect is one significant reason for why languages like Go and Java are getting traction.

But even after years of polish Go is still perceived as risky:

http://www.techworld.com/apps/why-googles-go-programming-language-could-rival-java-in-enterprise-3626140/

Geeks have no trouble picking up new languages, C++ programmers most certainly will have no trouble picking up D. The semantics are too close, but D2 does not solve C++'s issues, and brings another set of issues that C++ does not have. This is not a fear issue. It relates directly to qualitative issues.

Projecting "fear" onto professional decision making is just a way to make excuses for D's shortcomings.

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

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. If you change your core toolset you also will have to change the process and infrastructure.

> 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. That is not true. Most technologists I know of find that fun. Adopting tech for your personal use or for small tools is one thing, adopting it for deployment is a completely different issue.

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.

But keep it real. Fear among programmers is not D's main issue. That's just an excuse.

On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim Grøstad wrote:
> 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.
>
> But keep it real. Fear among programmers is not D's main issue. That's just an excuse.

And just to avoid a misundertanding here:

1. That C# and Java programmers end up being disgruntled 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.

2. When people who are looking for a system level programming language get disgruntled then you need to pay attention. It is still not a fear issue, there are so few system level languages to pick from that people looking for alternatives cannot afford to be "picky".

D2 is pretty much C++ with a Boehm collector attached to it. So to get traction D has to improve on that model significantly OR change direction completely.

On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim Grøstad wrote:
> D2 is pretty much C++ with a Boehm collector attached to it. So to get traction D has to improve on that model significantly OR change direction completely.

You speak like someone who's read the spec, but doesn't actually use the product. If you can put your theoretical mind on hold for a few days and actually immerse yourself in the language and its idioms for practical use*, you'd see that D has a large feature-overlap with to up-to-date C++, but often feels very different in practice. Maybe take some of the time you spend writing theoretically motivated forum posts and turn it in to some practical experience?

P.S. forgive me if I'm wrong and you have done a bunch of serious coding in D, it just seemed unlikely seeing as you never seem to make specific practical complaints with example code, it's always an overarching principle or grand direction problem.

On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:
> On Tuesday, 29 September 2015 at 06:16:18 UTC, Ola Fosheim Grøstad wrote:
>> D2 is pretty much C++ with a Boehm collector attached to it. So to get traction D has to improve on that model significantly OR change direction completely.
>
> You speak like someone who's read the spec, but doesn't actually use the product. If you can put your theoretical mind on hold for a few days and actually immerse yourself in the language and its idioms for practical use*, you'd see that D has a large feature-overlap with to up-to-date C++, but often feels very different in practice. Maybe take some of the time you spend writing theoretically motivated forum posts and turn it in to some practical experience?
>
> P.S. forgive me if I'm wrong and you have done a bunch of serious coding in D, it just seemed unlikely seeing as you never seem to make specific practical complaints with example code, it's always an overarching principle or grand direction problem.

I have no idea what experience with D Ola really has, but I wouldn't have expected anyone to say that D2 is C++ with a garbage collector. The GC is a such a small part of D, and there are so many features that it has that either C++ doesn't or that it's improved considerably that it really doesn't make sense to try and claim that C++ and D are that similar. C++11 and 14 have closed the gap, but the two are still quite distinct. That doesn't necessarily mean that D is better in all cases, but D is definitely not just C++ with a GC.

- Jonathan M Davis

On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:
> actually use the product. If you can put your theoretical mind on hold for a few days and actually immerse yourself in the language and its idioms for practical use*, you'd see that D has a large feature-overlap with to up-to-date C++, but often feels very different in practice.

There is nothing theoretical about this, I am only concerned about the language, not the standard library. The same with C++.

One usually don't judge a system level language based on its libraries. System level usage of the same system level language can be very different because people use different core libraries. So there is essentially no reason to complain about D's libraries.

If you look for system level programming you also essentially agree to writing the libraries you need or create bindings to whatever system you intend to build for.  I am not interested in Phobos, I am not fond of it and I don't focus on it since I don't have to use it. I am interested in the language/runtime, not libraries which I understand that I have to do on my own.

On Tuesday, 29 September 2015 at 09:12:11 UTC, Jonathan M Davis wrote:
> C++11 and 14 have closed the gap, but the two are still quite distinct. That doesn't necessarily mean that D is better in all cases, but D is definitely not just C++ with a GC.

It isn't "just C++", but D as a language is close enough to be considered a close relative. So if you are used to implementing libraries in C++, the jump to D is not a big jump.

Where D1 was  a move towards creating a more constrained environment by adding builtin language features (a design ideal that is closer to where Go is, compared to C++), D2 has been and IMO still is moving towards features being done in libraries much like C++.

There are differences across the board, but they are minor, not major differences. Lambdas are done slightly different, templating is slightly different, traits are done somewhat different, object init is slightly different, exceptions are slightly different, operators are done slightly different, but you can roughly express the same things in roughly the same way with some exceptions.

On Tuesday, 29 September 2015 at 11:40:20 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 29 September 2015 at 09:02:13 UTC, John Colvin wrote:
>> actually use the product. If you can put your theoretical mind on hold for a few days and actually immerse yourself in the language and its idioms for practical use*, you'd see that D has a large feature-overlap with to up-to-date C++, but often feels very different in practice.
>
> There is nothing theoretical about this, I am only concerned about the language, not the standard library. The same with C++.
>
> One usually don't judge a system level language based on its libraries. System level usage of the same system level language can be very different because people use different core libraries. So there is essentially no reason to complain about D's libraries.
>
> If you look for system level programming you also essentially agree to writing the libraries you need or create bindings to whatever system you intend to build for.  I am not interested in Phobos, I am not fond of it and I don't focus on it since I don't have to use it. I am interested in the language/runtime, not libraries which I understand that I have to do on my own.

Ok, that's fine, but your comments don't generally come with a "this observation is limited to very bare-bones code, beyond which I am not interested to think about" caveat, the stuff your saying is often very wide-ranging. Also, even for the low-level work that you specialise in, practice can lead to insights.

On Tuesday, 29 September 2015 at 11:53:45 UTC, Ola Fosheim Grøstad wrote:
> It isn't "just C++", but D as a language is close enough to be considered a close relative. So if you are used to implementing libraries in C++, the jump to D is not a big jump.

That's as true as saying that D is similar enough to Java that it
wouldn't be a big jump. You'd end up with code that looks like C++ or
Java that no seasoned D developer would write.

The difference is actually quite big. If it weren't, why would
any of us bother?

Atila

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.

On Tuesday, 29 September 2015 at 14:24:45 UTC, Atila Neves wrote:
> wouldn't be a big jump. You'd end up with code that looks like C++ or Java that no seasoned D developer would write.

I don't really see your point. "idiomatic" is a cultural regime, not a language and not necessarily an improvement over alternative coding styles. System level code isn't "idiomatic", you write code the way that makes sense for what you try to achieve and set guidelines suitable for your project.

If I want a systems development language and don't like C++ for various reasons (syntax bloat, no module system and tedious traits) then using D is one of very few potential options. Currently some things are better in D, some things are better in C++. The primary difference is that D can much more easily change for the better overall.

C++ is locked to backwards compatibility in a rather unhealthy way, which is why they now try to "change practice" by using guidelines. D can avoid all that.