> lack of LLM training data doesn't help either.

That shouldn't stop any self-respecting programmer.

I work with D and LLMs do very well with it. I don't know if it could be better but it does D well enough. The problem is only working on a complex system that cannot all be held in context at once.

My experience is that all LLMs that I have tested so far did a very good job producing D code.

I actually think that the average D code produced has been superior to the code produced for the C++ problems I tested. This may be an outlier (the problems are quite different), but the quality issues I saw on the C++ side came partially from the ease in which the language enables incompatible use of different features to achieve similar goals (e.g. smart_ptr s new/delete).

I don't know D so I'm probably missing some basic syntax. If pointers cannot be copied how do you have multiple objects referencing the same shared object?

Is there any experience on how this works in practice?

This is a somewhat simplistic view of ownership and borrowing for modern programming languages.

Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names.

An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers.

This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)

I work at a D company. We tend to use OOP only for state owners with strict dependencies, so it's rare to even get cycles. It is extremely useful for modeling application state. However, all the domain data is described by immutable values and objects are accessed via parameters as much as fields.

When commandline apps were everywhere, people dreamed of graphical interfaces. Burdened by having to also do jobs that it was bad at, the commandline got a bad reputation. It took the dominance of the desktop for commandline apps to find their niche.

In a similar way, OOP is cursed by its popularity. It has to become part of a mixed diet so that people can put it where it has advantages, and it does have advantages.

On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing.

In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.

It worked alright for Rust, and yes Rust does support OOP, there are many meanings to what is OOP from CS point of view.

I have ported Ray Tracing in One Weekend into Rust, while keeping the same OOP design from the tutorial, and affine types were not an impediment to interfaces, polymorphism and dynamic dispatch.

>one of the biggest flaws of OOP is that if x.foo() calls x.bar() in the middle, x.bar() can clobber a lot of local state, and result in code that's very difficult to reason about

That's more a problem of having mutable references, you'd have the same problem in a procedural language.

It was competing with C and Java when it came out. People who like C will not use a language with garbage collection, even one that allows you to not use it. Against Java, it was a losing battle due to Java being backed by a giant (Sun , then Oracle) and basically taking the world by storm. Then there were also license problems in early versions of D, and two incompatible and competing standard libraries dividing the community. By the time all these problems were fixed, like a decade ago, it was already too late to make a comeback. Today D is a nice language with 3 different compilers with different strengths, one very fast, one produces faster results, and one also does that by works in the GCC ecosystem. That’s something few languages have. D even has a betterC mode now which makes it very good as a C replacement, with speed and size equivalent or better than a C equivalent binary… and D has the arguably best meta programming capabilities of any language that is not a Lisp, including Zig. But no one seems to care anymore as all the hotness is now with Rust and Zig in the systems languages space.

Interestingly, today someone can be one of the lucky to learn about the lucky 10000:

https://xkcd.com/1053/

meta

All seriousness, do you honestly think this site has 10,000 new users a day? How many people do you think are on here that aren't very well informed? Honestly, I'm just wondering?

Also, do you know it only gets to front page if the hardcore that go to new upvote it? How many hardcore people don't know what D is?

Let's be serious, most people are regulars and this has been on the front page multiple times like constantly. And it was upvoted 4 times on new to get to the front page rapidly. It's not something new that we're all "Oh that's cool".

We also know there are tons of sock accounts.

And no half of the posts on front page can't be put in that since they aren't constantly reposted like this.

So, while there are a few people who will have learnt about this for the first time. Most of you know what it is and somehow feel like this is your chance to go look I'm smarter than Iain. And I think you've failed again.

That's not how I remember it. Excitement for python strongly predated ML and data science. I remember python being the cool new language in 1997 when I was still in high school. Python 2.4 was already out, and O'Reilly had put several books kn the topic already it. Python was known as this almost pseudo code like language thst used indentation for blocking. MIT was considering switching to it for its introductory classes. It was definitely already hyped back then -- which led to U Toronto picking it for its first ML projects that eventually everyone adopted when deep learning got started.

Python crossed the chasm in the early 2000s with scripting, web applications, and teaching. Yes, it's riding an ML rocket, but it didn't become popular because it was used for ML, it was chosen for ML because it was popular.

Python was common place long before ML. Ever since 1991, it would jump in popularity every now and then, collect enough mindshare, then dives again once people find better tools for the job. It long took the place of perl as the quick "linux script that's too complex for bash" especially when python2 was shipping with almost all distros.

For example, python got a similar boost in popularity in the late 2000s and early 2010s when almost every startup was either ruby on rails or django. Then again in the mid 2010s when "data science" got popular with pandas. Then again in the end of 2010s with ML. Then again in the 2020s with LLMs. Every time people eventually drop it for something else. It's arguably in a much better place with types, asyncio, and much better ecosystem in general these days than it was back then. As someone who worked on developer tools and devops for most of the time, I always dread dealing with python developers though tbh.

Oh? How about Raymond's "Why python?" article that basically described the language as the best thing since sliced bread? Published in 2000, and my first contact with python.