On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:

> If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this?

https://forum.dlang.org/post/ioiglnwckjsdrukpxbvn@forum.dlang.org

I've been updating some pre-C++11 code to C++14 and above.

It's actually been pretty trivial, because gcc has nice warnings that tell me exactly which file and line I need to fix, and I can turn them on one by one and clean up all warnings in the code base and on to the next.

If you look at my delta's 99% of them are deletions rather than modifications, and quite a few of them could have been automated (if it wasn't for the horrible complexity of the preprocessor).

I have also been shifting a bunch of ruby 1.8.6 era code to 2.3 and beyond, a lot of the fixes I could let rubocop autofix for me, review for peace of mind sake, run unit tests, done. Yes autofix. Sounds very scary...but it has been amazingly rock solid so far.

Language development needs to leave behind the notion that it's an API fixed for all eternity.

Rather the assumption must be, a language processor eats source, it can (re)write source as well.

To evolve, a language processor must learn to evolve the code base it supports.

On Thursday, 23 August 2018 at 09:16:23 UTC, Mihails wrote:
> Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D.
>
> What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return.

Just as power is not something to be grasped or abolished, leadership is not something you can consider as an attribute or property of the D endeavour or its community. You criticise the leadership as if them being leaders is part of the problem, leaving no event or cause to credit for why their stewardship is bad! You think -dip1000 is disadvisable? What grounds are those on? How does that tie into the leadership at hand here? When I ask about leadership I ask not about leaders, but rather the actions leaders take, since those count for everything in evaluating their skill.

On Thursday, 23 August 2018 at 14:29:23 UTC, bachmeier wrote:
> Weka is an awesome project, but I don't know that most people considering D should use your experience as the basis of their decision. At least in my areas, I expect considerable growth in the usage of D over the next 10 years. Maybe it won't see much traction as a C++ replacement for large projects like Weka.

It’s as much to consider as any other project, in that you shouldn’t base your opinions or decisions on it alone. There are other aspects of this I will comment on later.

On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh wrote:
> What I did mean by that is that the enthusiasm from D has *greatly* diminished. Many (but not all) developer will definitely not choose D for our next project, should the choice be ours to make.
>
> Like I said in my original post, it is not even in consensus whether picking D to begin with had been a mistake. Some think it was, some think, even in hind sight and after being more or less disillusioned, that it was still better than picking another language. As such, it is not even universally true that engineers at Weka regret going with D.

Perhaps your team’s mistake is deciding from their enthusiasm instead of a solid analysis of what the language will demand from your team. It is no secret that D is not as ready for production as C++, so why did they not evaluate the shortcomings of the ecosystem beforehand? Was the honest consensus that D would carry your project as well as Go, Rust, or C++? A cursory examination shows the former two languages have a corporate backbone absent from D, and C++ is self-explanatory with ISO and OS code.

On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh wrote:
> To summarize: Weka isn't ditching D, and people aren't even particularly angry about it. It has problems, and we've learned to live with them, and that's that. The general consensus, however, is that these problems will not be resolved (we used to file bugs in Bugzilla. We stopped doing that because we saw nothing happens with them), and as far as the future of the language goes, that's bad news.
>
> Shachar

Imagine you are on a state-of-the-art boat in the bronze age that needs many many people to move it by oar. You aren’t the crew of the ship, but you have cargo that needs pulled for trade. This boat is short-staffed, and by freemen to boot, and your merchantry has insisted on going with this boat over the bigger boats, because maybe they use slave drivers, or they’re really old and the sea won’t take them well, or whathaveyou. Can you, in reasonable conscience, expect this noble new boat to carry your load the same as older, rustier, or more backwards ships? It may be able to, but at a greatly reduced speed, or split into multiple trips or some other serious concession. But you are a merchant, you roll the nickels in the mediterranean and if you really wanted to you could push to hire more oarmen and have it both ways. In a way, this is the decision your team needed to make with a language like this, and it puzzles me why you haven’t mentioned a discussion of this sort yet. And it is even more bemusing that, somehow, you find the people running the boat to be at fault for not meeting your expectations. Were you hoping to find the holy grail aboard this ship?

On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
>> On 23/08/18 17:01, Steven Schveighoffer wrote:
>> My main job is to develop for Weka, not develop D itself.
>
> Weka, at some point, made the strategic decision to use a non mainstream language
>
> I dont think Weka, have a choice, they have to invest in the development of D itself

Arguably, this should have been an expectation from the start. I have not spent a lot of time here, yet I am plenty prepared to fork over a lot of my own resources to make things happen in D for my company because of what I’ve seen of the ecosystem so far. I don’t know of Weka’s leadership at all, but since I lead my company I can say that it will almost certainly transition from my time as a developer into my money as I make more things and make more money. It’s no small favour to ask, but it’s the only realistic expectation to have besides the current state of affairs that result when you do nothing or sit idly hoping for things to come to you. They say Rome was not built in a day, but what they don’t tell you is Rome was not built from anything less than a global fortune either. It’s paramount to really know what you’re up to task for.

On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
> I'm reminded of a friend of mine, who kept hoping to win the lottery despite never buying a ticket. His reasoning was that the chances of winning are not much changed by buying a ticket.
>
> Shachar

Is using D tantamount to a lottery for you? What did you expect in your original enthusiasm if not this?

On Thursday, 23 August 2018 at 18:27:27 UTC, Abdulhaq wrote:
> On Thursday, 23 August 2018 at 09:51:43 UTC, rikki cattermole wrote:
>>> Good luck getting W&A to agree to it, especially when there is yet another "critical D opportunity" on the table ;)
>>
>> No. They have power for as long as we the community say that they do.
>> We are at the point where they need a check and balance to keep everybody going smoothly. And I do hope that they listen to us before somebody decides its forkin' time.
>
> No fork of D can be successful, it won't have the manpower, skills or willpower to draw on. Even with W and A it's already short.
>
> 'Threatening' W and A with a fork is an empty threat that just p***es them off. Bad move on your part.

The solution is obviously not hard power, then. Ever wonder why the US has unquestioned global military dominance? It’s all in soft power. Most of the military isn’t tasked with punching down everyone on earth, but rather protecting all of the trade routes on the planet with the concessions countries give in exchange for that. You have a much better time doing what you want if you convince people to go along with you instead of forcing them into your will, and it’s true at every scale from global geopolitics to programming language communities. Funding the D foundation with solid, clear expectations is an easy example of this, but there are lots of ways to go about it that makes everyone happy.

On Thursday, 23 August 2018 at 23:06:03 UTC, Everlast wrote:
> I agree with this. I no longer program in D, except for minor things, because of this type of approach. D, as a language, is the best. D as an actual practical tool is a deadly pit of snakes... anyone of which can bite you, and that won't stop the others. Of course, in the pit is where all the gold is at...

So then, you need a snake charmer to distract them all as you run the gold. See below for a more concise explanation of this.

On Thursday, 23 August 2018 at 23:06:03 UTC, Everlast wrote:
> My feeling is D is and will stay stagnate for the majority of the world. It doesn't seem to have enough momentum to break out and the "leaders" don't seem to know much about actually leading... programming? Yes, but leading? No, not really...(obviously they know something but I'm talking about what is required... a bill gate like character, say, not that we want another one of those!)

It’s interesting you mention Bill Gates! Like Steve Jobs, one thing he was notoriously brilliant for doing was in leadership. In the joint interview they did together (I believe it was some time in 2007), both of them mentioned how critical it was that they had so many people around them to make their companies happen, and how lucky they were for it. They kept it simple, but luck doesn’t earn you workmates - leadership does. It’s one of the most thankless jobs around and there are more people than many programmers can imagine who grossly overestimate their aptitude at it.

On Thursday, 23 August 2018 at 23:06:03 UTC, Everlast wrote:
> Since time is money, you know these types of issues will stop businesses from adopting D. The typical answer from the D community is "Implement it in a library!" or "It has bindings!" as if these are the solutions someone trying to get shit done wants to hear. Usually the libraries are defunct in some way(bit rot, version issues, shitty design, some deal breaker(e.g., uses gc), shitty documentation, etc).

The default modus operandum for businesses is total indifference. If they shy away from D for these issues it is almost always because they didn’t care much at all in the first place and were likely eyeing it to see what it even is because they haven’t heard of it before. “Time is money” is not wrong but there’s a much less confusing way to put it: priorities. They usually don’t care, and in that case, what did you expect them to do? I’d see them taking a vacation to Greenland before they adopt D in that case.

On Friday, 24 August 2018 at 21:53:18 UTC, H. S. Teoh wrote:
> I think it's clear by now that most of D's woes are not really technical in nature, but managerial.  I'm not sure how to improve this situation, since I'm no manager type either.  It's a known problem among techies that we tend to see all problems as technical in nature, or solvable via technical solutions, when in reality what's actually needed is someone with real management skills.  Hammer and nail, and all that, y'know.
>
> Unfortunately, we techies also tend to resist non-technical "interference", especially from non-techies (like manager types). I used to have that attitude too (and probably still do to some extent), and only with age did I begin realizing this about myself.  It's not an easy problem to fix in practice, especially in a place like here, where we're driven primarily by the technical aspects of D, and for the most part outside of any financial or other motivations that might have served to moderate things a little.

Yes, yes. As I said before, management is very valuable and the time is nigh for more of it because it is apparent D has plenty of technical rigour in its alumni. The most critical thing in management is that it needs to be from people who are technically rigourous, because an incompetent manager is, in D’s case at least, worse for everyone than a competent non-manager. It’s basically a matter of the folks who already kick ass + take names stepping up to bat together as a team, bringing more cohesion into things. This is anything but easy, but if accomplished it would make D shine a lot for enterprise onlookers, particularly the kinds of wealthy interests that do very much care about things even when it doesn’t really make them money (think Gabe Newell with his insistence on opening PC gaming up for linux).

On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:
> I definitely think a stable version with backfixes ported would be great if feasible.

Agreed as well. once I have the ability I will see to this myself with LDC if it hasn’t happened already.

On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:
> I wonder if we are approaching the point where enterprise crowd-funding of missing features or capabilities in the ecosystem could make sense.  If you look at how Liran managed to find David Nadlinger to help him, it could just be in part a matter of lacking social organisation preventing the market addressing unfulfilled mutual coincidences of wants.  Lots of capable people would like to work full time programming in D.  Enough firms would like some improvements made.  If takes work to organise these things.  If I were a student I might be trying to see if there was an opportunity there.

We’re well into the timeframe where it makes sense, imo. the problem is actually getting that to happen, which the community does not have many cards to play to influence the outcome of, many of which can easily backfire anyways. the best strategy is to maintain cohesion and mend divides, avoiding sentiments that sow them in the first place. I’m sure pretty much no one here sees anything less than great potential if not an outright great language in front of us here, so it’s in everyone’s interest to keep one’s head straight and grounded in reality on things. there’s plenty of concrete problems to solve as it is ;)

-----

all things considered here, I see a lot of valid concerns from several angles here. the company aspect of the discussion seems misguided as to why expectations weren’t met, and as far as D itself is concerned stronger + smarter leadership is in the biggest demand from what I see.

another thing I want to mention about corporate involvement and sponsorship dynamics: as a company your involvement is totally elastic. Really you can dictate and harmoniously fulfill any level of involvement you desire, and the only question is if your negotiation skills are decent enough and whether your expectations from others are grounded in reality. You can fund the foundation, pay developers of your choosing who are already vets in the ecosystem, hire your own IOI-style squadron of FOSS mercenaries, or get down-and-dirty and literally do it yourself. they don’t call head honchos ‘executives’ for nothing! ;)

On Monday, 27 August 2018 at 04:00:18 UTC, John Carter wrote:

> Rather the assumption must be, a language processor eats source, it can (re)write source as well.

And before any one mentions halting problems and the impossibility of a compiler understanding whether a refactoring is behaviour altering.....

My empirical experience with this is, most recent advances in language design have been around making it harder to make stupid mistakes.

And whenever I have found a chunk of pre-existing code that required substantial modification to update it to the new language paradigm... it was because it was buggy already, and attempting to express the current behaviour in latest preferred idiomatic way made that obvious.

ie. It was hard to move that code to latest preferred idiom because it require a bug fix AND a syntactic tweak.

ie. That code was working "by accident" or not at all.

The older I get the less sympathy and mercy I have for code that works "by accident" and the more I encourage language designers to evolve our tools faster to give us more safety from our own inexhaustible supply of stupidity.

On 8/26/2018 5:40 PM, Manu wrote:
> By contrast, another colleague tried writing a small game in his own
> time. His feedback was that it felt 'fine', but he didn't encounter
> anything that made it "simpler than C++", and claimed readability
> improvements were tenuous.
> He wouldn't show us his code. I'm sure he wrote basically what he
> would have written in C++, and that's not how to get advantages out of
> D... but his experience is still relevant. It demonstrates that C++
> programmers won't be convinced without clear demonstration of superior
> expressive opportunity.

Actually, I understand that one. If you look at my conversions of C++ code to D, like this one:

https://github.com/dlang/dmd/commit/8322559195c28835d61c99877ea7c344cb0e1c91#diff-1be391ebabb9f6e11079e1ea4ef1158b

The code looks the same, and in fact, is about 98% the same.

I first learned programming in BASIC. Outgrew it, and switched to Fortran. Amusingly, my early Fortran code looked just like BASIC. My early C code looked like Fortran. My early C++ code looked like C.

The productivity gains of D won't happen until one stops writing C++ code in it, and stops thinking in C++ terms. In fact, one gets irked because one is deep in the rut of how C++ does things, and it's annoying when one is forced to do things a different way in D. Like, why can't I have member function pointers, or friend declarations?

Going the other way, though, is even worse - what do you mean, I have to write forward declarations? Why can't I pass a string literal to a template? No user defined attributes? Why doesn't CTFE work? Who can actually get work done in this language?

Thanks for the list! This is good stuff.

On 8/26/2018 6:11 PM, Manu wrote:
> I'm sure I recall experimental patches where those operators were
> available to try out... was I dreaming? :/

Andrei has worked on this for a long while, and finally came to the conclusion that ref counting won't work without copy constructors. Hence copy constructors are a priority.

On Sun, 26 Aug 2018 at 21:50, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 8/26/2018 5:40 PM, Manu wrote:
> > By contrast, another colleague tried writing a small game in his own
> > time. His feedback was that it felt 'fine', but he didn't encounter
> > anything that made it "simpler than C++", and claimed readability
> > improvements were tenuous.
> > He wouldn't show us his code. I'm sure he wrote basically what he
> > would have written in C++, and that's not how to get advantages out of
> > D... but his experience is still relevant. It demonstrates that C++
> > programmers won't be convinced without clear demonstration of superior
> > expressive opportunity.
>
> Actually, I understand that one. If you look at my conversions of C++ code to D, like this one:
>
> https://github.com/dlang/dmd/commit/8322559195c28835d61c99877ea7c344cb0e1c91#diff-1be391ebabb9f6e11079e1ea4ef1158b
>
> The code looks the same, and in fact, is about 98% the same.

This code appears to be a mechanical translation. That's not what
happened in this case; he wrote his game in D from scratch.
It was just that he arrived at mostly the same place. He was googling
for styling and sample material, but I suspect the problem was a lack
of topical material demonstrating how he might write his D code
differently.

It's also the case that the significant difference between C++ and D
(in my experience) mostly come down to: D has modules, tidier meta,
UDA's, slices, and ranges/UFCS. In trade, D struggles with const, and
ref is broken.
If your code doesn't manifest some gravity towards one of those
features, it will tend to be quite same-ey, and advantage may not be
particularly apparent.

In my current project, we stand to make substantial gains from D's
meta and UDA's in particular. I think UFCS could make a big play too.
Tidier lambda syntax will also be attractive, however controlling
closures with respect to @nogc appears to be a challenge which C++
doesn't suffer.
It's all contingent on fighting through outstanding C++ related
issues, and making the tooling as good as we can get it though.

On Sun, 26 Aug 2018 at 21:50, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Going the other way, though, is even worse - what do you mean, I have to write forward declarations? Why can't I pass a string literal to a template? No user defined attributes? Why doesn't CTFE work? Who can actually get work done in this language?

And yes... this.
This is the truth that has ruined my career.
There was a time when I used to be happy; ignorance is bliss ;)

That said, most of my problems I personally care about are purely
artificial. We could make ref work, we could make namespaces work, it
wouldn't hurt anybody. The power is yours, and yours alone. Everyone
else is behind it... you're the only gatekeeper ;)
const however... that's another kettle of fish, and I'm slowly
becoming sympathetic to the complaining that I've been watching here
for years, which I've somehow managed to resist being sucked into for
a very long time.

On Monday, 27 August 2018 at 01:10:17 UTC, Manu wrote:
> On Sun, 26 Aug 2018 at 18:08, Manu <turkeyman@gmail.com> wrote:
>> Actually, I'm really mostly interested in DX12 shader output right
>> now... I think there are tools that can convert LLVM to DX shaders? I
>> haven't looked into it yet, but it's on my backlog.
>> Next would be SPIRV for Vulkan.
>
> This looks promising: https://blogs.msdn.microsoft.com/directx/2017/01/23/new-directx-shader-compiler-based-on-clangllvm-now-available-as-open-source/

I would love to do it but that repo is _horribly_ organised and resembles nothing like a backend and appears to lack relevant LLVM IR tests. SPIRV for Vulkan would be doable if there is support from the Vulcan folks when the SPIRV backend is upstreamed to LLVM.

On 8/26/2018 6:25 PM, Neia Neutuladh wrote:
> Same here. I do make unicode errors more often than I'd care to admit (someString[$-1] being the most common; I need to write a lastChar helper function), but autodecoding means I can avoid that class of errors.

Autodecoding doesn't prevent you from incorrectly using indices like [$-1].