August 07, 2019
On Tuesday, 6 August 2019 at 23:55:11 UTC, Walter Bright wrote:
> The imminent demise of D was confidently predicted 20 years ago, and every year since, yet it keeps growing and getting better. The imminent failure of Zortech C++ was also constantly predicted by pretty much everyone, meanwhile Zortech was pretty successful.

One of the popular hobbies of programmers is to predict the death of languages because there's another language they like better. C++ is dead. Java is dead. Clojure is dead. Scala is dead. C is dead. Perl is dead. Ruby is dead. R is dead. Python is dead. Or so I've been told.

As long as the D compiler continues to work, I'll be fine.
August 07, 2019
On Wednesday, 7 August 2019 at 00:36:19 UTC, Exil wrote:
> On Tuesday, 6 August 2019 at 23:55:11 UTC, Walter Bright wrote:
>
>> The imminent failure of Zortech C++ was also constantly predicted by pretty much everyone, meanwhile Zortech was pretty successful.
>
> They weren't wrong, Zortech C++ doesn't exist anymore. While C++ is still going strong.

Zortech was bought by Symantec and they rebranded the compiler to Symantec C++. It's now Digital Mars C++, still very much alive, and the backend was reused in DMD.
August 06, 2019
On 8/6/2019 7:23 PM, Mike Parker wrote:
> On Wednesday, 7 August 2019 at 00:36:19 UTC, Exil wrote:
>> On Tuesday, 6 August 2019 at 23:55:11 UTC, Walter Bright wrote:
>>
>>> The imminent failure of Zortech C++ was also constantly predicted by pretty much everyone, meanwhile Zortech was pretty successful.
>>
>> They weren't wrong, Zortech C++ doesn't exist anymore. While C++ is still going strong.
> 
> Zortech was bought by Symantec and they rebranded the compiler to Symantec C++. It's now Digital Mars C++, still very much alive, and the backend was reused in DMD.

Not only that, Zortech C++ is the reason C++ itself reached the tipping point and became mainstream.
August 07, 2019
On Tuesday, 6 August 2019 at 21:28:26 UTC, JN wrote:
> On Tuesday, 6 August 2019 at 14:25:05 UTC, Suliman wrote:
>> Personally I moved from D, to Dart because it's more look like D3. A lot of modern and useful futures.
>
> I love Dart. I think it's one of the cleanest languages around. I love the language and I love the tools surrounding it (IDE support is quite nice). Unfortunately, it lacks value types and it's not really usable outside of web/server context.

I use Dart daily (at work we're writing a Flutter app) and I hate every moment as every line reminds me that I could do much better with D. I would gladly give up all of it's tooling if Flutter was written in D.

Dart's tooling beats D's 10x, but D is at least 100x better language, IMO. Of course the language is not all, which why sadly I would need to stick to Dart for the time being.

On the plus side, Dart's language team seems to have more experience with formal specifications and I have confidence that NNBD will be a strong language addition.

On the minus side, Dart is very uninspiring and I have to constantly write tons of boilerplate. And use code generation as a separate build step. In isolation, it's type-system is well-designed, but compared to other languages like TypeScript it is seriously lacking in expressive power.

And of course, the runtime performance is shit (but that's not surprising).

In both D and Dart I miss TypeScript's more advanced features: https://www.typescriptlang.org/docs/handbook/advanced-types.html
August 07, 2019
On Wednesday, 7 August 2019 at 00:36:19 UTC, Exil wrote:
> It won't be imminent but it hasn't reached the point of self sufficiency. I don't see it reaching the same level of success as other younger languages, at it stands.

So I guess this point needs stating again.

Why did C# get picked up? Because Microsoft.

Why did Swift get picked up? Because Apple.

Why did Dart and Go get picked up? Because Google.

Why did Rust get picked up? Because Mozilla.

Why are people still making posts like this about D? Because languages thrive when there are large corporations in play, and no corporation has committed to D like those behemoths mentioned above.

Many of the problems I've highlighted in D/DMD lately will get solved naturally when human- and financial- resources are addressed. But you've got a chicken and egg situation there.
August 07, 2019
On Tuesday, 6 August 2019 at 11:59:04 UTC, Bert wrote:
> I'm about 10x as productive in other languages than D. It's not the language itself as it is everything around it. It's great for minor things like utilities or simple one offs but few in the right mind will use D for anything major(as a serious massive app targeted as the real public).

So this is a good point and a bad point rolled in to one.

Manu has mentioned VisualD, and his points are spot on. It's good, but I keep hitting rough edges. Associative arrays inside templated types don't display in the debugger for me, for example.

But being productive in other languages. Well.

This serious massive app targeted at the real public that I'm working on has the native component written in D. Server and client backends; and a runtime component that will be linked in to your program.

The only native UI framework that gives me the performance and quality I need is WPF.

Anyone that tries telling me that C# is a more protective language than in D only needs to take a look at my codebase to see just how much boilerplate my D code needs to generate for my C# code to be written as quickly as D code. Every time I try to use generics in C#, either the language or the .NET runtime quickly reminds me that generics were an afterthought and I often have to stop using generics and resort to writing D code that does the job the C# compiler should.

C# isn't at a point where I'd link it in to a major console game for runtime operations. return ref is good and all that, but there's still boxing and unboxing of even basic types that happens. Not to mention that to talk to any game codebase (outside of Unity games) requires marshalling and unmarshalling.

But on the other hand, I can load a PNG easily with C#. When I tried using libpng in D last year, the two (TWO) separate packages on dub didn't compile under the then-current DMD version. One of the packages was updated earlier this year, but it's too late, I'm using Adam Ruppe's PNG handler. That D has no quality control on what is a *CRITICAL* library these days is kinda insane.

So. My point - writing code in D is easy, and my project would not be where it is right now were it not for the deep introspection and metaprogramming techniques I'm using. Integrating D code in to the wider ecosystem, however, is where things get tricky.

Atila's point is spot on - it needs to be as simple as #include.
August 07, 2019
On Tuesday, 6 August 2019 at 21:31:21 UTC, Manu wrote:
> It's hard to say exactly where that balance is, but I'm fairly
> confident it exists, and as soon as the threshold is crossed, it will
> fork. We haven't forked because D is not currently as bad as you say.

There's still people that come in to IRC asking about Tango. That in itself is a problem.

I'm generally against forking, but I do think making D3 would be a rational option for two reasons:

1) const functions/methods by default
2) pure by default

Way too much code would need retrofitting in the 2.x specification to just enable those things overnight. And these two things are *VERY* important for the future.
August 07, 2019
On Wednesday, 7 August 2019 at 06:26:34 UTC, Walter Bright wrote:
> On 8/6/2019 7:23 PM, Mike Parker wrote:
>> On Wednesday, 7 August 2019 at 00:36:19 UTC, Exil wrote:
>>> On Tuesday, 6 August 2019 at 23:55:11 UTC, Walter Bright wrote:
>>>
>>>> The imminent failure of Zortech C++ was also constantly predicted by pretty much everyone, meanwhile Zortech was pretty successful.
>>>
>>> They weren't wrong, Zortech C++ doesn't exist anymore. While C++ is still going strong.
>> 
>> Zortech was bought by Symantec and they rebranded the compiler to Symantec C++. It's now Digital Mars C++, still very much alive, and the backend was reused in DMD.
>
> Not only that, Zortech C++ is the reason C++ itself reached the tipping point and became mainstream.

Sorry to say it like this, but Zortech wasn't relevant in Europe, if at all.

I got introduced to C++ via Turbo C++ 1.0 and it was all Borland, Microsoft and Metrowerks from there on.

For us early C++ adopters in the Iberian Penisula, Zortech was only seen on magazine ads.
August 07, 2019
On Wednesday, 7 August 2019 at 10:45:44 UTC, Ethan wrote:
> On Tuesday, 6 August 2019 at 11:59:04 UTC, Bert wrote:
>> I'm about 10x as productive in other languages than D. It's not the language itself as it is everything around it. It's great for minor things like utilities or simple one offs but few in the right mind will use D for anything major(as a serious massive app targeted as the real public).
>
> So this is a good point and a bad point rolled in to one.
>
> Manu has mentioned VisualD, and his points are spot on. It's good, but I keep hitting rough edges. Associative arrays inside templated types don't display in the debugger for me, for example.

I run in to all kinds of issues with Visual D constantly, it is not nearly as bad as it was but it has issues. It's one guy that has a life trying just to maintain it, at some point it too goes by the wayside.

> But being productive in other languages. Well.
>

Depends on what one defines as productive.

> This serious massive app targeted at the real public that I'm working on has the native component written in D. Server and client backends; and a runtime component that will be linked in to your program.

But you are one person who has decided to use D in that regard, and funny how you didn't strictly do it in D alone! That actually says a lot about D.

> The only native UI framework that gives me the performance and quality I need is WPF.

Oh, but wait, we have dlang-ui, nuclear-d, well, here:
https://wiki.dlang.org/GUI_Libraries

I just wonder what the glass ceiling is?

> Anyone that tries telling me that C# is a more protective language than in D only needs to take a look at my codebase to see just how much boilerplate my D code needs to generate for my C# code to be written as quickly as D code. Every time I try to use generics in C#, either the language or the .NET runtime quickly reminds me that generics were an afterthought and I often have to stop using generics and resort to writing D code that does the job the C# compiler should.

It depends on what you are doing. I was using C# before I moved to D precisely because of some of these limitations. It was the generics that was limiting(things have changed somewhat by now though)... I thought D's meta programming might handle it, and it D, and the meta programming is superior, but EVERYTHING(virtually) is a fail! I think the only other thing is compile times.  C#'s library design and functionality is superior, C#'s IDE is superior(because of the issues with VD), C#'s utilities are superior, C#'s community is superior, etc...

In fact, the reason why I had issues with C# was not just generics but performance for high widget count in wpf and the pain of it was giving me(I can't remember the details but it killed my app even using their recommendations).

> C# isn't at a point where I'd link it in to a major console game for runtime operations. return ref is good and all that, but there's still boxing and unboxing of even basic types that happens. Not to mention that to talk to any game codebase (outside of Unity games) requires marshalling and unmarshalling.

Yes, this is an issue with the managed code, but for many people not writing games it is not an issue and C# generally is quite amazing performant given what it does and some of the features it provides.

> But on the other hand, I can load a PNG easily with C#. When I tried using libpng in D last year, the two (TWO) separate packages on dub didn't compile under the then-current DMD version. One of the packages was updated earlier this year, but it's too late, I'm using Adam Ruppe's PNG handler. That D has no quality control on what is a *CRITICAL* library these days is kinda insane.

Yes, but this sort of thing in D is all over the place. Most libraries are defunct. Adams library is good because it works but I find it's structure quite annoying. It's a hodge podge of code and he tends to write in large files. I had to modify some of his simpledisplay to get some functionality I wanted for windows but maintaining it with any updates he pushes is a mess. I did it as a simple project but it worked well enough, but to go back and find all my changes to push to him or fork would be a pain and not worth it. What it means is that I have something that works for my purposes but because I don't want to put in the time to make it better I'm stuck.

What I'd expect from D is how C# works, a nice library that is written very cleanly, organized, great docs, etc... It's a pipe dream, I know... but imagine if D was C# in "every" regard except the language and was native!

That would be heaven to me. It would be a programming environment that I enjoy, that when I go to program code I feel good about it because I know I'm very productive and I'm not constantly running in to pot holes that distract me from my main goal. These things wear on a person after a while. Going down a long dirt road to a very nice mansion is great the first few times but after your suspension goes, and your car is full of dirt, it starts to be a problem.



> So. My point - writing code in D is easy, and my project would not be where it is right now were it not for the deep introspection and metaprogramming techniques I'm using. Integrating D code in to the wider ecosystem, however, is where things get tricky.

Writing code in D, for the most part is easy and great. Getting that code to work is not as easy, but integraing it in the ecosyste is the problem.. and that is why you are mixing it with wpf... and that should be a serious flag of "WHY!!!!!!!!!!!!" and the reason is simple, Walter doesn't give a shit about having proper gui, audio, video, or anything else. For him these things are not relevant so he will not push for them. He says "Someone wrote a library for that"... yeah, but that library doesn't work or is not maintained... or has depreciated features.

.NET is "complete" basically anything you want to do and you can do it, it has a few things that are not, it's almost entire performance related and meta programming related. If C# had D's performance and D's meta programing I would be using C#. You would be too... and that is a problem for D, not C#. [While I think wpf is quite bloated and such it still functions quite well after one learns the in's and outs. I don't like xaml programing but at the end of the day it does exactly what it says and there are no major problems and I can always go at it programatically, so I get to choose how much of one I want to go with. I like choices!]

I want D to catch up to what languages like C# does(even Haskell does certain things so much better that D could learn from) but my feeling is that the leadership is not interested in making D compete with these languages. They are happy where it's at. That is a problem for me because I'm not happy where it's at and it means another 5 years of the same thing, and then 10, and then 20. I want my programming life to get easier, not stay the same. I want to be able to enjoy programming while being productive. It's like having a Ferrari that is always breaking down... at some point it becomes an issue and the coolness factor fades and at some point you want to give it away too the next sucker.

D can be competitive with these other platforms, but I see no real interest in the community to make it so. It's more like it wants to care out it's own niche. I will continue to use D for odd ball stuff such as simple utilities that I write to increase my own productivity, and maybe a few simulations but I will not use it to write any more apps, it's just too much trouble.






August 07, 2019
On Wednesday, 7 August 2019 at 12:36:53 UTC, Bert wrote:
> Adams library is good because it works but I find it's structure quite annoying. It's a hodge podge of code and he tends to write in large files. I had to modify some of his simpledisplay to get some functionality I wanted for windows but maintaining it with any updates he pushes is a mess. I did it as a simple project but it worked well enough, but to go back and find all my changes to push to him or fork would be a pain and not worth it.

You don't really have to find the files yourself, if you send me a copy there's a good chance I can extract the diff for you.

Though it'll be even more of a hodge podge of code lol