On Wednesday, 3 November 2021 at 16:38:03 UTC, Ola Fosheim Grøstad wrote:

i am using c++ for almost 20 years and i am quite productive in it. given enough time i think one can be productive in any language. of course D would at least double that. this project (game) at first targetted both mobile and pc platforms. for this reason alone, i was stuck with c/c++. then i dropped mobile support. I don't know the state of tooling of D, but if it was seamless enough then D would be my first choice now. i don't like rust as much, rust code looks even uglier than c++ and its handling of generic-code/metaprogramming looks even worse. they should have started from D templates, not c++.

obvious choice for such a project is lisp, afaik no other language still has that speed/power when it comes to live coding. compared to C++ D has that too, answer is the same for both; tool and os support

On Tuesday, 2 November 2021 at 17:35:08 UTC, IGotD- wrote:

I was thinking about this post for a while. What about R, Perl, Ruby or PHP? I don't think even C++ had corporate backing out of the gate. Which company backed Scala? Sun?

It seems like Python is in good company and the corporate-backed languages are the outliers.

On Wednesday, 3 November 2021 at 17:12:28 UTC, kot wrote:

Yes, but some languages require you to do solid modelling before you start so they limit "evolutionary experiments". I find C++ to be such a language, in order to be productive you need a clear picture of what you want before you start. Lisp and Python and such languages allow you to grow a program "like a tree". I guess we could say they support metamorphosis (although dynamic typing can backfire).

The first time I saw a C program I thought it looked like incomprehensible shit compared to Turbo Pascal. :-) Then I learned it and went out of my way to write terse C code on an assignment in an algorithm class. I think the teacher got an headache when I wrote my solution on the blackboard (he allowed us to pick whatever language we wanted).

When I see a Rust program (like the Rust compiler) I get the same feeling, but I cannot be sure if it is me or Rust. Maybe both?

If it is a game, then I guess your choice is reasonable. C++ with gcc extensions is well tailored for games. Not having a SIMD type with traits is a weak spot in C++ though. I had to make my own library with SIMD traits to clean up my code, and figuring out how to do that was time-consuming… That is my main gripe with C++, you set out to clean up your code by designing a beautiful library and then implementing it turns into a chore because of some language weak spots. It is important for D to iron out weak spots, otherwise D is too much like C++ to stand out.

(I guess you can embed Scheme/Guile or some other scripting language if you want to experiment too.)

On Wednesday, 3 November 2021 at 17:47:45 UTC, Ola Fosheim Grøstad wrote:

after D every language looks ugly when it comes to generic programming.

years ago i suggested D should be distributed with an embeded C compiler. since it was already required to be binary compatible with C, this was the obvious next step which would also solve most tooling issues out of the box. from license issues to practicality there were many voices against it, some said it was a dumb.

what you are saying about c++ at first looks like the failure of the language. for the most part it is of course right. but i also think it is a compleiment to c/c++. at least with these languages you are not dealing with tooling issues, which to me is the most important. they save you from one hell, only to welcome you with another, yet they give you the tools (half-assed tools, tools nonetheless) to get something done.

On Wednesday, 3 November 2021 at 18:20:55 UTC, kot wrote:

Hah, I have suggested this too!! About seven (??) years ago. Did you use a different nickname back then? (Walter didn't like it, but he changed his mind now?)

Well, yes, although it shows that C/C++ was not designed with tooling in mind. But looking back those language has improved a lot. When I started with C, the Ansi-standard was so new that most codebases I retrieved by FTP didn't support it. So they were littered with #ifdefs and macros to support all the C-dialects (and Unices…). So there has been a steady stream of improvement, although C itself looks arcane now.

On Wednesday, 3 November 2021 at 18:49:46 UTC, Ola Fosheim Grøstad wrote:

looks like it was around 2011-2013, i have yet to find the post. yes i used a different name back then, haven't posted anything since.

On Wednesday, 3 November 2021 at 19:05:49 UTC, kot wrote:

It could have been around that time. I am not able to find my first post in the forums, maybe some of the early posts have been lost? Anyway, one other user agreed (:-D), but I cannot remember the nick…

On Wednesday, 3 November 2021 at 17:36:19 UTC, harakim wrote:

C++ had the corporate backing from AT&T, being part of UNIX, thus all major C compiler vendors either adopted CFront, or tried to create their own compiler, one of the first ones was created by Walter.

All UNIX workstations had C++ compiler alongside C, Apple moved from Object Pascal to C++, Windows and OS/2 used C for low level code alongside high level frameworks in C++ like OWL, VCL and MFC, Borland had a MS-DOS C++ framework that remains famous to this day (Turbo Vision), BeOS and Symbian were written in C++, on the last MS-DOS days Watcom C++ was the compiler to go for game development.

PHP had the corporate support from Zope and all ISP across the world.

Python had the initial backing from Zope, followed by all major corporations like Google and Dropbox that kept paying Guido's salary.

Ruby was mostly ignored until Ruby on Rails stormed the world.

On Wednesday, 3 November 2021 at 17:36:19 UTC, harakim wrote:

S was created at Bell Labs shortly after the creation of C. R is an open source implementation of S that became extremely popular for university teaching. Students in many fields, not just statistics, use it in multiple courses before graduation. And unlike other applications, someone analyzing data has a lot of freedom in choosing their language, so adoption didn't require convincing someone in a suit.

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

This is my first post here. I've been reading this for a long time out of general interest but since I never actually decided to try D, I though I could contribute my 2 cents to this topic.

In addition to all that has already been said, I think there are two fundamental issues. This first one is historic: for a long time, D was not open source, in an era where proprietary languages were long frowned upon. People expect a language and all its associated tools to be free, both as in speech and beer. D may not have been expensive and difficult to obtain like Ada was, but it was still probably a big detriment to its early adoption. By the time it was relicensed and truly open source compilers appeared, its launch window had closed and there were other languages around.

This brings me to the second point: perhaps D is simply based on the wrong idea. From my reading of the dlang forums it wants to be, if not all things to everyone, at least a general all-around language that can do more or less everything. The problem is that maybe this is not what the world wants. Most people are very happy to use different languages for different problems, and they will go for the one that is the best (for varying definitions of best) at something rather than one that is pretty good at lots of things. Today one can certainly do low level system programming in D, but Rust is a better systems language. One can develop microservices etc. in D, and it might be pretty good for that, but Go is better. D can even be used as a scripting language or one to drive high level logic, but Python is better for that.

To put it differently, the world doesn't seem to want another C++. Both Rust and Go came after D and enjoyed significant uptake in areas that overlap with D's. The key difference IMHO is that they both know not only what they need to provide to be good options for their selected application spaces, but also what they don't want to become and what is totally out of scope for them. I really believe that the latter part is as important, if not more, than the former, and if there is one feature that D is lacking to get more traction, it's probably this one: decide which rabbits it's not trying to chase.