November 01, 2022
On Wed, Nov 02, 2022 at 03:42:47AM +0000, UmmReally via Digitalmars-d wrote: [...]
> Well.. just as long that project doesn't involve providing 'an option' to the programmer, so the programmer can specify that a member of a class is private to that class.
> 
> Anything else... fine.. he'll consider it...but 'private to the class' .. never!

Of all the issues that one could bring up about the nuclear reactor design, the one that keeps coming up is the color of the bikeshed attached to the building.  Clearly, this must be one of the most critical aspects of nuclear reactor design, and the key question that will decide whether the funding will be approved. :-P


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
November 02, 2022
On Wednesday, 2 November 2022 at 03:42:47 UTC, UmmReally wrote:
> On Tuesday, 1 November 2022 at 00:16:32 UTC, Walter Bright wrote:
>> ..
>> ....
>> We've been known to incorporate projects people have done all on their own initiative. I've been known to ask the creators of such projects to donate them to D.
>>
>
> Well.. just as long that project doesn't involve providing 'an option' to the programmer, so the programmer can specify that a member of a class is private to that class.
>
> Anything else... fine.. he'll consider it...but 'private to the class' .. never!

Just have a module with the class in it and nothing more, brotown.
I'll bill you my consultation fees later.
November 02, 2022
On 02.11.22 00:30, Don Allen wrote:
> 
> In any case, I'm sorry you were offended, but it was not intentional.

No worries! No offense taken, was just a bit confusing.
November 02, 2022

On Tuesday, 1 November 2022 at 21:48:35 UTC, Bioinfornatics wrote:

>
  1. Promote some killer libraries (Gsoc is a good way to see those libraries as it is cuurently done). But they need to survive to this events, be maintained or added to the the std library.
    What is the state of d dataframe? Mir ? D ai ? D web framework back and front included through wasm ?

To me, the community have to create those libraries instead to complain in order to transform an application language to a system language.

My suspicion is that if we want inroads to scientific computing, D needs to create packages that provide seamless utility with current solutions. People are not going to learn D just to use yet another AI, dataframe, or linear algebra library or framework.

If an analyst is working in R or Python, you have to go to them, meaning that at first you speak their language. So a high quality alternative to a current tool that does something their's does not, perhaps it performs better or is easier to use and so forth with a backend in D.

In terms of getting "enthusiast" programmers to write D code, you'll need to persuade someone using Rcpp/cpp11 or even the new extendr (for Rust) that they are better off writing D code using something like embedr or whatever. This is where people will need to be persuaded why they should switch to D. Things like:

  1. Performance - super-important in scientific computing. Can D stand up to C++ in those terms? Easy and well documented access to popular HPC frameworks.
  2. Memory safety - if they already have Rust why should they use D? How memory safe is D?
  3. Ecosystem - what does D's language ecosystem have to offer? This one is not a deal breaker but is still very important.
  4. What's so special about D and why should they use it?

If this was 5-6 years ago, I'd have said that the barrier was much easier to penetrate, but now things have become much more competitive, and there are fewer low-hanging fruit. There are still opportunities out there but efforts need to be properly focused. I suspect it needs to be an ongoing affair rather than a summer project. It's not necessarily about expending a huge amount of resource, just finding the right focus to wedge the door open and then progressively capitalising.

November 02, 2022
On Wednesday, 2 November 2022 at 04:48:23 UTC, surlymoor wrote:
>
> Just have a module with the class in it and nothing more, brotown.
> I'll bill you my consultation fees later.

In my version of D (a fork based on someone elses work), I am not 'forced' to use that 'workaround'.

Even javascript has private to the class.

D is comlete joke! i.e. ..>  that you cannot even make a private member within a class (except through some stupid 'workaround').

So with that...back on to topic.. YES 'offical' D really IS that bad!

(but not my version of D ;-)

btw. This is not really a complaint ;-)

It's great that I can create my own fork based on someone else work (to do what I can do in anyother langauge, including javascript!).

November 02, 2022
On Wednesday, 2 November 2022 at 04:09:09 UTC, H. S. Teoh wrote:
> ...
>
> Of all the issues that one could bring up about the nuclear reactor design, the one that keeps coming up is the color of the bikeshed attached to the building.  Clearly, this must be one of the most critical aspects of nuclear reactor design, and the key question that will decide whether the funding will be approved. :-P
>
>
> T

Wanting to use a class to represent a concrete abstract type, which you can do in 'official D', is not bikesheding.

At best, in 'offical' D, you can 'simulate' using a class as an concrete abstract type, by putting that class in its own module.

C'mon. Let's be honest about this ;-)

The real 'bikesheding', is the pretending that this is ok.
November 02, 2022
On Wednesday, 2 November 2022 at 08:02:13 UTC, UmmReally wrote:
>....

argH! prehistoric forum software!

> Wanting to use a class to represent a concrete abstract type, which you can do in 'official D', is not bikesheding.

CORRECTION:
Wanting to use a class to represent a concrete abstract type, which you CANNOT do in 'official D', is not bikesheding.
November 02, 2022
On Tuesday, 1 November 2022 at 22:43:57 UTC, Timon Gehr wrote:
>
> Not everyone is in Walter's position. I really don't understand why you are singling me out here and being disrespectful towards me.

Heat in this forum generally comes from two kinds of people. The first kind are those that are direct in their opinions, but work with the language and direct their criticism at real pain points and suggest, often even contribute, workable improvements. Those people are not the problem and in my books you belong to that first category. Manu Evans is another classic example of that kind of person.

The another kind of people, that are the real problem, are those who have an air of negativity about D and the language foundation in general. They turn many threads into those battles where most of us feel the need to defend D against overt criticism. Often - not always, but often - they have no or next to no record of contributing. I can't pinpoint exactly what the problem in their behaviour is, but somehow they almost never manage to be constructive. I can only suspect they have some subconscious desire to prove others misguided and themselves above the mass, or something like that.


> I hope you understand that nowadays there are many people in jobs where open source contributions are a no go by default, _even_ in their spare time.

<political rant> Forbidding that should be declared illegal in every country. I can maybe understand if, say someone developing car radio software, would be forbidden from contributing to open-source radio software, but to software in general? That's ridiculous!
</political rant>


November 02, 2022

On Wednesday, 2 November 2022 at 03:10:47 UTC, cc wrote:

>

On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat wrote:

>

the better it is, the more any perceived flaw is painted as huge and "show-stopper".

This is a truth I have encountered numerous times in game design. The more rich and rewarding your feature set and environment are, the more it generates a sense of "well, if only it was BETTER, THEN it would be just what I wanted!" The more restricted something is, the more content one remains with what has been accomplished within the bounds of the design.

And to respond to the OP, D is definitely good enough that I don't want to switch to anything else for this purpose when I don't have to! And by good enough, I mean great. I definitely feel D is the "should have been, but wasn't" language that C# ended up becoming for claiming the gaming industry (or at least squeezing alongside C++, which will sadly never leave us). It's just a joy to program in, the metaprogramming capabilities are fantastic. I don't know how to really quantify whether D does them "better" than other languages, but it always feels cleaner to me. I am not a language design expert, I am just a humble tiller of the soil that is allotted to me. But IMO D lets you write things that end up looking beautiful. I put together a quick RPC module to call functions on client objects from their server representations in a multiplayer game engine. All parameters matched for implicit conversions, marshaled, bundled and prepared for network sending. Hard compiler errors on any mismatches. Any method I want replicable, All I need to do is just drop a UDA onto it. No complicated lookup tables or list of mangles or serialization definition documents. No need to add any code or create stubs anywhere else in the project. It all "just works". The entire RPC module? 194 lines of code. Brings a tear to my eye. The thought of building the equivalent in C# gives me a headache. C++? Migraine. And I do not care for Rust.

On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

>

in fact

d rox

This. Although I do agree that allocators should be tuned up and taken out of experimental. I would personally love to see alternative memory management strategies made to feel more "at home" as base language features, instead of tricks with structs and templates. Just my pipedream.

I'm in the same boat. I use C# daily at work, but want to use D instead. In the cases I actually did replace C# with D, I reduced the codebase by 20% without even trying. That's a huge win to me.

As everyone knows, the less code you must write, the fewer bugs you will have.

The expressiveness of D combined with its power is what does it for me. Being able to utilize CTFE and generate code at compile time is like magic sometimes. With D I never really feel that the language is what's holding me back, but rather my knowledge. I can't say the same thing about C#, even though I like the language.

The reason for making this thread was to get people the slow down and think about what it is they really want and need in a language. Because it is literally impossible for Zig (for example) to be better than D right now (sorry for picking on Zig, I could have chosen any other language). Impossible. Just take a look at some of the things I wrote in my initial post.

But still some people would choose it instead of D. I am 98.76% sure that's only because of hype/popularity than anything else. Which is really weird. Are we developers really not more sophisticated than that? We just chase the next shiny thing? Maybe, I honestly don't know. But I'm starting to think that might be it.

For example, if D in secret was rebranded to Olympus and given a new logo, maybe people would praise it as the best thing since sliced bread. "Have you heard of Olympus?" Omg it rocks!

But, D boulders.

November 02, 2022

On Wednesday, 2 November 2022 at 09:11:43 UTC, Imperatorn wrote:

>

On Wednesday, 2 November 2022 at 03:10:47 UTC, cc wrote:

>

[...]

I'm in the same boat. I use C# daily at work, but want to use D instead. In the cases I actually did replace C# with D, I reduced the codebase by 20% without even trying. That's a huge win to me.

[...]

Damn, I knew it already existed 😤

https://github.com/rottytooth/Olympus