• Mensikov (47/47) Jul 20 I have an idea. Due to the abundance of D capabilities, I propose
• harakim (15/17) Jul 20 I like the idea of targeting specific audiences and having the
• monkyyy (3/4) Jul 20 Im pretty sure betterc doesnt exist as a well designed subset,
• Denis Feklushkin (7/11) Jul 20 Not agreed
• Guillaume Piolat (4/6) Jul 21 The restricted D subsets aren't fun. Adam and Hipreme (and
• aberba (8/27) Jul 21 You're better off looking at D as a complete language and use it

Mensikov <mensikovk817 gmail.com> writes:

I have an idea. Due to the abundance of D capabilities, I propose 
to introduce the concept of D profiles to the community. In D, 
you can write firmware for a microcontroller, an OS, a web 
server, scripts, a vst plugin, and a compiler. All these niches 
have different requirements from the programming language. We 
already have a betterC mode, but what if we introduce a more 
understandable gradation? Well-defined subsets, let's say. We 
call these subsets profiles. With these profiles you can better 
search for the required packages in dub. Let's say I have a 
system profile, and it will be possible to filter all packages by 
this request. A system profile may have requirements not only for 
the absence of GC, but also for the API in general, for example, 
to be closer to a low level. Or I have a script profile, I can 
use both system and script profiles. This will also allow 
language developers to see the weaknesses of specific profiles 
and introduce features for them. You can build std like a 
pyramid, with a system profile at the bottom, and a managment 
profile based on it, for example.


Here is the list of profiles I suggest:

CompileTime profile. This profile is the most universal, since it 
does not affect runtime in any way.

System profile. This profile uses a DOD (data oriented design) 
approach. Minimum classes, delegates. Error handling via values. 
Data is not live, scope(exit) instead of destructors. Using 
std.sumtype. If it is a library, full dip1000 support. If it is a 
library, std.experimental.allocators are fully supported. Can 
call gc code at higher levels, so the nogc attribute is not 
required. The code will have a lot of boilerplate around memory 
management and error handling, just like in C or Zig.

Application profile. Classes and interfaces are already available 
in this profile. Structures have raii. Garbage collector is fully 
accessible. Processing through exceptions is possible. Support 
for OOP and FP paradigms. There may be some kind of runtime 
reflection. Totally  safe.

Script profile. It mainly differs in its API in the libraries. It 
should be simple and flexible. This can be used as 50 line 
scripts for image processing, parsing, data analysis, conversion. 
Maybe it’s a library that parses a binary file based on UDA (like 
imhex patterns). This could be a library for prototyping 
something. Data visualization, plotting, etc. That is, what 
Python is used for. Perhaps the compiler will need support for 
parsing a module simply as a main function. Perhaps a selective 
level of optimization is needed (O2 dependencies, O0 script). You 
need a fast linker, or the ability of a compiler to link the code 
in jit and execute it right here.

What do you think? Should we split D into 3 languages ​​with a 
common ffi?

harakim <harakim gmail.com> writes:

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:
 What do you think? Should we split D into 3 languages ​​with a 
 common ffi?

I like the idea of targeting specific audiences and having the 
language just work for them. I think right now the biggest 
potential draw to D is from C developers migrating because people 
all of the sudden decided C was not safe. I think we can just 
target those groups specifically. I would imagine it is mostly 
hardware interfacing.

The other group we have are companies that sponsor D who write 
applications.

Another group would be people making games.

Lastly, you have new people.

I think if it becomes more popular with the first three groups, 
the last group would come on their own. I think having a profile 
set up that will support whatever the government is requiring 
from languages and easy porting from C would be smart.

monkyyy <crazymonkyyy gmail.com> writes:

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:
 We already have a betterC mode

Im pretty sure betterc doesnt exist as a well designed subset, 
its a collection of hacks

Denis Feklushkin <feklushkin.denis gmail.com> writes:

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:
 In D, you can write firmware for a microcontroller, an OS, a 
 web server, scripts, a vst plugin, and a compiler. All these 
 niches have different requirements from the programming 
 language.

Not agreed

And I am absolutely convinced of opposite: there is no difference 
between developing for a desktop, mobile, MCU or some sort of 
"supercomputer"

Therefore, it makes sense to strive for universality and commonty 
of code

Guillaume Piolat <first.name gmail.com> writes:

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:
 What do you think? Should we split D into 3 languages ​​with a 
 common ffi?

The restricted D subsets aren't fun. Adam and Hipreme (and 
Spasm?) have shown how you can be better off with a custom D 
runtime instead.

aberba <karabutaworld gmail.com> writes:

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:
 I have an idea. Due to the abundance of D capabilities, I 
 propose to introduce the concept of D profiles to the 
 community. In D, you can write firmware for a microcontroller, 
 an OS, a web server, scripts, a vst plugin, and a compiler. All 
 these niches have different requirements from the programming 
 language. We already have a betterC mode, but what if we 
 introduce a more understandable gradation? Well-defined 
 subsets, let's say. We call these subsets profiles. With these 
 profiles you can better search for the required packages in 
 dub. Let's say I have a system profile, and it will be possible 
 to filter all packages by this request. A system profile may 
 have requirements not only for the absence of GC, but also for 
 the API in general, for example, to be closer to a low level. 
 Or I have a script profile, I can use both system and script 
 profiles. This will also allow language developers to see the 
 weaknesses of specific profiles and introduce features for 
 them. You can build std like a pyramid, with a system profile 
 at the bottom, and a managment profile based on it, for example.

 [...]

You're better off looking at D as a complete language and use it 
as is rather than a language that'll suddenly switch to some cool 
model. Versions of D isn't going to be significantly different. 
It just doesn't make sense. I don't see why current D can't do 
any of the above.

You can write every type of code in current D or use a custom 
runtime as mentioned above.