October 07, 2021
On Wed, Oct 06, 2021 at 11:26:14PM +0000, Tejas via Digitalmars-d wrote: [...]
> Why do you continue to walk the path less travelled when others enjoy the advantages of mainstream languages like better tooling and greater stability, ie, fewer/no breaking changes with each release(and disadvantages like various janky workarounds for backwards compatibility, deigns/ideological constraints, etc)?

Speaking for myself only here:

(1) I have very little concern about walking less travelled paths; IME popularity does not correlate with quality. Javascript is one of the most popular languages out there, but from a design perspective it's trash. No real OO, you fake it with prototypes (or whatever it is they call 'em), fragile error handling, tons of WATs (== vs ===, weird implicit conversions between strings, integers, floats, etc.), debugging is a royal pain.[*]  The only reason JS is still afloat is because its disproportionate popularity draws in enough manpower to barrel through problems.  On the contrary, better-designed languages tend to be the less popular ones.

(2) I have all the tooling I need for efficient work with D (vim +
compiler + Unix shell == yeahhh).  Though I understand I'm in the far
minority on this point. :-D

(3) Breaking changes with each release happens not just with D. I have some very old C++ projects dating from the 90's, and I can tell you that trying to get them to compile with a modern compiler is an exercise in pain.  The only reason people don't complain about this very much is because D releases much more frequently than C++.  Janky workarounds for C++ code are pretty much so widely-accepted that you don't even think twice, you just insert const casts everywhere, insert compiler switches to suppress errors/warnings, use macro hacks to patch over stuff just for Mt Cesuaga (Making That Compile Error Shut Up And Go Away), etc.. By comparison, D workarounds are a walk in the park.

(4) Ideological constraints: I find D the most liberating in this respect, actually. Javascript forces you to fake things like OO with its weird backwards prototype-based ideology, Java constrains you to shoehorn the most unlikely things into OO-sanctioned constructs, and both Java and C# force you to endure a watered-down generics system because full-on template-style generics are considered "too dangerous" for the unwashed masses to consume (don't even get me start on Go, which doesn't even have generics), leading to boilerplate galore; functional languages force you to rephrase the simplest of imperative constructs in a functional guise, etc..  With D, I can choose the best paradigm for the problem at hand without needing to pay lip service to some ideological ideal that doesn't actually map well to the problem domain. OO when I need OO, functional when I need functional, bare pointers and asm for when I need to go under the hood to solder wires together, so to speak.

Of course, that's not to say D doesn't have its own set of problems. But in comparison with the other languages I've experienced so far, D has the least of the problems in exchange for the most of the benefits.


//

([*] Once, I had the misfortune of having a complex, ill-maintained JS project dumped on my lap at work. Most bugs in that code manifested themselves in a blank page with no other traces of the problem.  The browser's debug console was useless because somebody "helpfully" installed an exception catcher that deliberately swallows errors. Worse yet, one of our support targets at the time was IE6, which did NOT have a debug console at all. It was a lot of "fun" debugging problems specific to IE.  JS is indeed the epitome of a popular language with better tooling and greater stability.</sarcasm>)


T

-- 
Любишь кататься - люби и саночки возить.
October 07, 2021

On Thursday, 7 October 2021 at 20:12:49 UTC, Dukc wrote:

>

Wow, are modern C++ compilers crashy when compared to D? I definitely agree that D compilers nowadays are more than stable enough for production, but do they really rival the most common C++ ones?

LDC rivals clang of course. On what metric do you think it wouldn't?
And if you have used C++ professionally, yes you stumble upon compiler bugs. I certainly have. And in that case there is often no nice bugtracker to file that bug.

D having one front-end means that in practice you have less unknowns.

>

More news for me, if you really mean that. C++ does add features fast for such an old language. But changing faster than D, considering they tend to keep the old features around where we deprecate them? Really?

Yes really, it is very difficult to keep up with the C++ changes even if you were a full-time C++ programmer. And you need to since people start to use the new stuff when available. It is very likely that when the next standard comes out, you would have barely assimilated the one from 10 years ago. C++ needs a cast of "explainers" like Scott Meyers.

October 07, 2021

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

Yes really, it is very difficult to keep up with the C++ changes even if you were a full-time C++ programmer. And you need to since people start to use the new stuff when available. It is very likely that when the next standard comes out, you would have barely assimilated the one from 10 years ago. C++ needs a cast of "explainers" like Scott Meyers.

I've given up on C++ unless it is embedded programming. C++ is still ok for embedded but since you don't use much from the standard library, it looks more like C++11 or before that, not much change with another words.

I expect to use less C++ for embedded as time goes by as well.

Many of the changes in "modern C++" are made for application programming and library improvements. The problem is that today if you are going to do application programming there are a myriad of better alternatives, D is one of them.

The last application programming projects I worked on professionally with C++ have just been a pain. It was so obvious that despite all the "modern improvements", C++ cannot compete anymore. Also since there are dozens of ways to do the same thing in C++, the code becomes very inconsistent.

The question is, should you invest a lot of time learning C++? Both yes and no. C++ and C is still lowest common denominator when it comes to APIs and FFIs. Learn C++ so that you understand moderate amount. Learning C++ to become a meta programming wizard would be a waste of time, for me at least. That would be huge investment of time that I don't think is worth it. Better alternatives exists.

October 08, 2021
On Tuesday, 5 October 2021 at 17:53:46 UTC, H. S. Teoh wrote:

> So naturally, in C you'd rather avoid such refactorings, preferring instead to keep the existing design so as to avoid breaking things unintentionally or spending too much time refactoring stuff that already works.  In D, you're freed from a lot of such concerns, so are more likely to perform deep refactorings that change the original design in more drastic ways.
>
>
> T

Yeah, D is better than C in that respect.
October 08, 2021

On Monday, 4 October 2021 at 13:23:40 UTC, Paul Backus wrote:

>

In ["Rust and Other Interesting Things"][1], Bryan Cantrill talks about the importance of a programming language's values.

...

>
Approachability   Integrity        Robustness
Availability      Maintainability  Safety
Compatibility     Measurability    Security
Composability     Operability      Simplicity
Debuggability     Performance      Stability
Expressiveness    Portability      Thoroughness
Extensibility     Resiliency       Transparency
Interoperability  Rigor            Velocity

I thought it might be fun to ask the D community: which of the above values do you think are the most important to D? Choose no more than 5, and reply with your answer!

From my experience:

Use case: replacing 2 executables with one written in D in a system consisting of multiple executables all written in C++ using various libraries and a proprietary bus system originally designed and build in 2004.

Approachability + Expressiveness: almost without any friction to get started in D coming from more than 20 years primarily C++ and also C C# python javascript. The language feels familiar and the code written seems to be better at expressing intend than any of the other languages I've used. More succinct code, less comments needed for 'explaining'.

Composability + Interoperability: The language and its facilities made it very easy to plug and plump together the solution based on various D C++ and C components. Exchanging one implementation with another approach went very smooth in the D based code.

Stability + Safety: Unit test in D are godsend, it saved me from various logic errors/misses in edge cases. The compiler (language) saved me several times by erroring out helping and telling me what is unsafe.

In general my experience is once a D compiler produces a binary, it almost never crashes due to stupid mistakes which happens in C++ quite often like out of bound access, not proper initialized objects null pointer derefs etc.
Also I had the impression the functional completeness was much quicker reached, because there was almost no time needed and so no distraction from actual problem solving to get the darn thing to run.

Another observation I made is: the final solution barely uses classes. D module system as unit of encapsulation seems perfectly fit for purpose.

October 08, 2021

On Thursday, 7 October 2021 at 21:59:26 UTC, H. S. Teoh wrote:

>

Speaking for myself only here:

(1) I have very little concern about walking less travelled paths; IME popularity does not correlate with quality. Javascript is one of the most popular languages out there, but from a design perspective it's trash. No real OO, you fake it with prototypes (or whatever it is they call 'em), fragile error handling, tons of WATs (== vs ===, weird implicit conversions between strings, integers, floats, etc.), debugging is a royal pain.[*] The only reason JS is still afloat is because its disproportionate popularity draws in enough manpower to barrel through problems. On the contrary, better-designed languages tend to be the less popular ones.

Yeah JS is a royal pain, but now TS has become a true alternative. The shops that are stuck with JS for some reason are stuck with it; but I think we should now compare with TS if we will ever talk about web stuff, since practically all new projects start with TS now.

>

(2) I have all the tooling I need for efficient work with D (vim +
compiler + Unix shell == yeahhh). Though I understand I'm in the far
minority on this point. :-D

Same here :D

>

(3) Breaking changes with each release happens not just with D. I have some very old C++ projects dating from the 90's, and I can tell you that trying to get them to compile with a modern compiler is an exercise in pain. The only reason people don't complain about this very much is because D releases much more frequently than C++. Janky workarounds for C++ code are pretty much so widely-accepted that you don't even think twice, you just insert const casts everywhere, insert compiler switches to suppress errors/warnings, use macro hacks to patch over stuff just for Mt Cesuaga (Making That Compile Error Shut Up And Go Away), etc.. By comparison, D workarounds are a walk in the park.

I think C++ has more robust backwards compatibility. The latest (mainstream) C++ compiler(s) can easily compile code written in 2010. But I doubt the latest D compilers can do so.

Sure, it might get painful if we go 20 years behind, but C++ is still better in that department, in D you can't even imagine having that degree of support(yet, hopefully).

>

(4) Ideological constraints: I find D the most liberating in this respect, actually. Javascript forces you to fake things like OO with its weird backwards prototype-based ideology, Java constrains you to shoehorn the most unlikely things into OO-sanctioned constructs, and both Java and C# force you to endure a watered-down generics system because full-on template-style generics are considered "too dangerous" for the unwashed masses to consume (don't even get me start on Go, which doesn't even have generics), leading to boilerplate galore; functional languages force you to rephrase the simplest of imperative constructs in a functional guise, etc.. With D, I can choose the best paradigm for the problem at hand without needing to pay lip service to some ideological ideal that doesn't actually map well to the problem domain. OO when I need OO, functional when I need functional, bare pointers and asm for when I need to go under the hood to solder wires together, so to speak.

Yeah, but you don't think that could lead to inconsistencies? Like the other languages are subscribed to a specific paradigm so certain constructs might appear unnatural, but atleast they might be consistently unnatural? I hope our flexibility doesn't result in perl style only-I-can-read-my-code, but actually goes closer to python's there-should-be-only-one-way-to-do-it.

>

Of course, that's not to say D doesn't have its own set of problems. But in comparison with the other languages I've experienced so far, D has the least of the problems in exchange for the most of the benefits.

//

([*] Once, I had the misfortune of having a complex, ill-maintained JS project dumped on my lap at work. Most bugs in that code manifested themselves in a blank page with no other traces of the problem. The browser's debug console was useless because somebody "helpfully" installed an exception catcher that deliberately swallows errors. Worse yet, one of our support targets at the time was IE6, which did NOT have a debug console at all. It was a lot of "fun" debugging problems specific to IE. JS is indeed the epitome of a popular language with better tooling and greater stability.</sarcasm>)

Eeeek D:

October 08, 2021

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

D having one front-end means that in practice you have less unknowns.

I think that could well be one of our strongest advantages against C++, since UB stuff can also have a reference point for implementation, meaning vendors don't have to guess something when implementing a corner case.

>

Yes really, it is very difficult to keep up with the C++ changes even if you were a full-time C++ programmer. And you need to since people start to use the new stuff when available. It is very likely that when the next standard comes out, you would have barely assimilated the one from 10 years ago. C++ needs a cast of "explainers" like Scott Meyers.

The last 10 years have really been a roller-coaster for C++ practitioners, but I think it's necessary for the language to evolve at that breakneck pace to at-least be relevant.

Imagine if Rust and D and Nim and whatever fail to replace C++? If the C++ recommended in use is still the same as C++03? That would've been a nightmare.

C++20 and its successors won't be very good languages in their own right, but for the jobs that they're expected to perform(be 100% compatible with existing code), they'll be perfect, unfortunately.

October 08, 2021

On Thursday, 7 October 2021 at 22:21:21 UTC, IGotD- wrote:

>

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

[...]

I've given up on C++ unless it is embedded programming. C++ is still ok for embedded but since you don't use much from the standard library, it looks more like C++11 or before that, not much change with another words.

[...]

Chances of Rust taking over that segment?

Also C++ is still used (and must be used??) for applications like photo and video editing s/w.

Will Adobe be better off using C# or swift or whatever instead pf C++?

October 08, 2021

On Friday, 8 October 2021 at 10:58:00 UTC, Tejas wrote:

>

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

[...]

I think that could well be one of our strongest advantages against C++, since UB stuff can also have a reference point for implementation, meaning vendors don't have to guess something when implementing a corner case.

[...]

This is why I'm still so ambivalent on what I should do with C++ 😭

October 08, 2021

On Friday, 8 October 2021 at 11:00:59 UTC, Tejas wrote:

>

Chances of Rust taking over that segment?

Also C++ is still used (and must be used??) for applications like photo and video editing s/w.

Will Adobe be better off using C# or swift or whatever instead pf C++?

Rust is already partially eating up the marketshare of C/C++. There is a big drive to enable Rust for Linux drivers for example. For low level programming, I find Rust annoying but some people might endure it.

When it comes to applications, it is a mystery to me that C++ still is so popular. Probably mostly because there is an existing code base that companies don't want to rewrite. This is a great opportunity for D as the FFI is one of the best out there which enables a gradual migration.

C# is great for applications, for Windows. For other platforms I'm not sure what the status is and if you get the same performance. For cross platform GUI application, there isn't an obvious choice. C++ with Qt is still a strong contender but it is becoming proprietary. Let's not forget web applications, when performance is not required web applications do a good enough job at the same time becoming totally platform independent.

Paint.net is written in C# and you don't really notice it as it runs just as well as any C++ program.