I am starting a project to create a new language based on D.

The name I have chosen is Laser-D.
It is supposed to be Lesser D - rather than Better C. This follows from my post about better branding for Better-C.

The project will basically be about turning off certain features in D - the language will have better C option baked in. I do not intend to make any changes to D itself other than turning off features.

The main effort will be update documentation that accurately reflects what works in the language. So there will be a new language reference.

The project will be hosted at https://github.com/laser-d

I hope to start creating content soon.

Regards
Dibyendu

On 2020-11-12 16:08, Dibyendu Majumdar wrote:
> I am starting a project to create a new language based on D.
> 
> The name I have chosen is Laser-D.
> It is supposed to be Lesser D - rather than Better C. This follows from my post about better branding for Better-C.
> 
> The project will basically be about turning off certain features in D - the language will have better C option baked in. I do not intend to make any changes to D itself other than turning off features.
> 
> The main effort will be update documentation that accurately reflects what works in the language. So there will be a new language reference.
> 
> The project will be hosted at https://github.com/laser-d
> 
> I hope to start creating content soon.
> 
> Regards
> Dibyendu

I was thinking about something similar: Basic-D, a subset of D which would be a perfect starting language with appropriate docs and tutorials.

Maybe these type of subset languages could be integrated in the D frontpage.

On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote:

> Maybe these type of subset languages could be integrated in the D frontpage.

I hope not. That would create lots of problems:

- There are multiple versions of the language.
- What happens when a version dies? What do you tell the developers (perhaps even businesses) that relied on a version they downloaded from the official homepage that now have a dead version?
- What if a developer makes weird changes (like removing int, which would still be a subset) or goes Windows-only because of the burden maintaining for multiple OSes? Is that something that should be promoted on the official homepage?

These are just the problems that immediately come to mind. I'm sure there are others. Open source is wonderful because it lets things like this happen. That doesn't mean we want to promote them on dlang.org.

On Thursday, 12 November 2020 at 19:00:51 UTC, bachmeier wrote:
> On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote:
>
>> Maybe these type of subset languages could be integrated in the D frontpage.
>
> I hope not. That would create lots of problems:
>
> - There are multiple versions of the language.

That is already the case though. If you only use gdc or ldc, then you get access to features that wont compile with dmd.

On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote:

> I was thinking about something similar: Basic-D, a subset of D which would be a perfect starting language with appropriate docs and tutorials.
>
> Maybe these type of subset languages could be integrated in the D frontpage.

I think it is too early for that as my project is not yet started, and it may not have any traction. I believe that if I can create solid documentation then it might make a difference but we will see.

Fortunately or not - I have limited time - so I won't be making changes to D other than very simple patches to switch off some things. I simply cannot afford to spend time on maintaining a different code base. My main focus will be to create documentation.

I can probably do one thing - guarantee that the new language is a proper subset of D and that any code in laser-D is guaranteed to build with dmd, ldc, gdc.

On Friday, 13 November 2020 at 12:25:48 UTC, Dibyendu Majumdar wrote:
> Fortunately or not - I have limited time - so I won't be making changes to D other than very simple patches to switch off some things. I simply cannot afford to spend time on maintaining a different code base. My main focus will be to create documentation.
>
> I can probably do one thing - guarantee that the new language is a proper subset of D and that any code in laser-D is guaranteed to build with dmd, ldc, gdc.

It sounds like maybe your time would be better spent improving the official D documentation to say which features and libraries are compatible with betterC and which are not.

On Friday, 13 November 2020 at 13:41:50 UTC, Paul Backus wrote:
>
> It sounds like maybe your time would be better spent improving the official D documentation to say which features and libraries are compatible with betterC and which are not.

Not really. It is a waste of time trying to do that.

On Friday, 13 November 2020 at 15:22:03 UTC, Dibyendu Majumdar wrote:
> On Friday, 13 November 2020 at 13:41:50 UTC, Paul Backus wrote:
>>
>> It sounds like maybe your time would be better spent improving the official D documentation to say which features and libraries are compatible with betterC and which are not.
>
> Not really. It is a waste of time trying to do that.

Why is it a waste of time? If I understand your proposal correctly, you will be doing more or less the same work either way--that is, figuring out which features and libraries still work with certain language features disabled. The only difference is whether you write up your results in a separate document, or incorporate them into the official documentation.

On Friday, 13 November 2020 at 16:18:32 UTC, Paul Backus wrote:
>
> Why is it a waste of time? If I understand your proposal correctly, you will be doing more or less the same work either way--that is, figuring out which features and libraries still work with certain language features disabled. The only difference is whether you write up your results in a separate document, or incorporate them into the official documentation.

For several reasons.

My goal is to create good docs without being constrained by existing docs (I will of course reuse what I can).

I have little time so I need to make most efficient use of it - and not get bogged down by discussions, arguments, process.

I think it is almost certain that Laser-D docs will not fit into the D docs model. Because my goal is make Laser-D attractive, and that means stripping out anything that will not work in Laser-D.

On Thursday, 12 November 2020 at 15:08:55 UTC, Dibyendu Majumdar wrote:
> I am starting a project to create a new language based on D.
>
> The name I have chosen is Laser-D.
> It is supposed to be Lesser D - rather than Better C. This follows from my post about better branding for Better-C.
>
> The project will basically be about turning off certain features in D - the language will have better C option baked in. I do not intend to make any changes to D itself other than turning off features.
>
> The main effort will be update documentation that accurately reflects what works in the language. So there will be a new language reference.
>
> The project will be hosted at https://github.com/laser-d
>
> I hope to start creating content soon.
>
> Regards
> Dibyendu

Where are you going to use this subset? embedded systems? desktop? are you going to cut features only not change anything else?