On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:
>> Ok, and do you have a plan or a concrete wish list that you could hand over to the core developers? What features would be indispensable or are of utmost importance, in your opinion?
>
> 1. Define the target, then you can figure out the features.

The target is a pragmatic compiled language. Static analysis is a focus and believed to be done with relatively simple and clean language rules that ensure correct results.

> 2. Solid non-gc memory management and ownership.

Current direction seems to be explicit structs+destructors+allocators.

Who cares? - Good luck in the .NET world.

On Wednesday, 7 October 2015 at 08:17:32 UTC, Kagamin wrote:
> The target is a pragmatic compiled language.

That's wonderfully undefined. A pragmatic compiled language can be anything from ATS to compiled Python.

> Static analysis is a focus and believed to be done with relatively simple and clean language rules that ensure correct results.

Which D is not.

> Current direction seems to be explicit structs+destructors+allocators.

I don't see this. Allocators is purely a library feature and is not designed to be explicit either.

Buf if that is right then:

- Get rid of the dichotomy between classes and structs, having syntactically different pointers for classes without any semantic significance is rather annoying.

- Get rid of all gc-dependent language features.

- Add language features that enables proper custom pointers.

etc

On Wednesday, 7 October 2015 at 09:25:10 UTC, Ola Fosheim Grøstad wrote:
> That's wonderfully undefined. A pragmatic compiled language can be anything from ATS to compiled Python.

If you want to know what D is in details, see dlang.org for language spec.

>> Static analysis is a focus and believed to be done with relatively simple and clean language rules that ensure correct results.
>
> Which D is not.

If one could design a language with just four words, it would be lisp :)

>> Current direction seems to be explicit structs+destructors+allocators.
>
> I don't see this. Allocators is purely a library feature and is not designed to be explicit either.
>
> Buf if that is right then:
>
> - Get rid of the dichotomy between classes and structs, having syntactically different pointers for classes without any semantic significance is rather annoying.

Semantic significance is that classes are polymorphic and hence reference types, structs are value types.

> - Get rid of all gc-dependent language features.

@nogc

> - Add language features that enables proper custom pointers.

Phobos implements custom pointers.

On Wednesday, 7 October 2015 at 10:18:16 UTC, Kagamin wrote:
> If you want to know what D is in details, see dlang.org for language spec.

No, that is backwards. :-) The language spec is the product. What is needed is a definition of what the problem area is (e.g. use cases).

problem area -> design -> language spec

> If one could design a language with just four words, it would be lisp :)

That is actually pretty close. The more powerful semantic analysis engines are based on horn clauses.

(you translate the imperative constructs into horn clauses, then do analysis)

> Semantic significance is that classes are polymorphic and hence reference types, structs are value types.

Not real difference regarding pointers.

>> - Get rid of all gc-dependent language features.
>
> @nogc

No, remove them from the language and replace them with library friendly constructs.

>> - Add language features that enables proper custom pointers.
>
> Phobos implements custom pointers.

They are not sound, and that is a language issue, not a library issue.

On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad wrote:


> 1. Define the target, then you can figure out the features.
> 2. Solid non-gc memory management and ownership.
> 3. Clean up the type system.
> 4. Complete the language spec.
> 5. Clean up the syntax.

That's very vague. Unless you have concrete cases along with possible solutions, nobody can follow your "plan".

> 6. Extend support to critical platforms like WebAssembly/asm.js

I agree. Nim are doing a good job at that as far as I know.

>
> I have some prototypes for my own use, but not sure what relevance that has? Pull requests would require decision making and policy changes, and be utterly pointless without it. Design/policy changes will have to start with the project leaders, that's the only way. End-users do not directly affect language features.

In D you can make a contribution as a user, but it has to be concrete and backed up by valid arguments. General statements and common places won't change anything.

Unlike Go and Rust, D has grown out of experience with programming in general, it's based on what worked in other languages and what didn't. Go and Rust address certain narrowly defined areas (Go more so than Rust I think). Given D's history there is, of course, some waste lying around (as is in any software after ~10 years) that has to be cleaned up and I would welcome any concrete, practical input from your side. Start with simple things first. Any hands-on help is welcome.

On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:
> On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad wrote:
>
>
>> 1. Define the target, then you can figure out the features.
>> 2. Solid non-gc memory management and ownership.
>> 3. Clean up the type system.
>> 4. Complete the language spec.
>> 5. Clean up the syntax.
>
> That's very vague. Unless you have concrete cases along with possible solutions, nobody can follow your "plan".

That's not vague at all.

On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:
>> On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad wrote:

> That's not vague at all.

> 1. Define the target, then you can figure out the features.

Then define the target. Make some suggestions.

> 2. Solid non-gc memory management and ownership.

Any specific implementation in mind?

> 3. Clean up the type system.

Examples + solutions?

> 4. Complete the language spec.

I thought that was the last thing we should do.

> 5. Clean up the syntax.

Examples + solutions?

You can put your proposals on Wiki.

On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
> On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim Grøstad wrote:
>> That's not vague at all.
>
>> 1. Define the target, then you can figure out the features.
>
> Then define the target. Make some suggestions.

I've already raised this topic in a thread where I asked where D sits in the web space. And I did that because it has been said that vibe.d defines a key application area. However, that is a very hard market to capture which many expressed in that thread.

I think D could do well if it focused on engine-level system programming and made sure it was absolutely top notch for that purpose. (Game engines, search engines, ray tracing engines, in memory database engines, business logic engines, etc).

The current focus goes the other way. The current assumption is that engines are written in C/C++ and they are used to complete applications in D. That would make D an application level language, which makes success _very_difficult. As time progresses I believe it makes less and less sense to do a full application in languages like C/C++/Rust/D...

But if you create an "engine language" then you also need to be very good at exporting APIs. Like having compact and readable API definitions in D that lends itself to auto-generating interfaces for other languages (Python, Ruby, Go, Javascript etc).

>> 2. Solid non-gc memory management and ownership.
>
> Any specific implementation in mind?

Change the language enough so that you can do full pointer analysis and compete with Rust/C++.

Limit GC to actors.  Use move semantics between actors.

Point 3 and out really depends on what you do with point 1 and 2.

The key point here is that the project leadership needs to start with defining enough constraints to do rational focused and strategic decision making.

Then make a high level plan that takes you from where you are to a finished project, then you refine the plan (and evolve it).

Piling up proposals and endless non-breaking evolution isn't effective.

On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
>> On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim Grøstad wrote:
>>> That's not vague at all.
>>
>>> 1. Define the target, then you can figure out the features.
>>
>> Then define the target. Make some suggestions.
>
> I've already raised this topic in a thread where I asked where D sits in the web space. And I did that because it has been said that vibe.d defines a key application area. However, that is a very hard market to capture which many expressed in that thread.
>
> I think D could do well if it focused on engine-level system programming and made sure it was absolutely top notch for that purpose. (Game engines, search engines, ray tracing engines, in memory database engines, business logic engines, etc).
>
> The current focus goes the other way. The current assumption is that engines are written in C/C++ and they are used to complete applications in D. That would make D an application level language, which makes success _very_difficult. As time progresses I believe it makes less and less sense to do a full application in languages like C/C++/Rust/D...

I agree that D should be strong in this area (engine level). On top of that you can stack powerful libs like Phobos. I use D as an engine in some projects and I'm thinking of using it for this purpose in other projects further down the road, for example using D as an engine for simpler, high-level languages like linguistic analysis tools where rules are defined by non-programmers at a higher level.

But by no means is it necessary that D be confined to this particular use case. An "engine language" can be extended with libs. However, you have to draw a clear line between the standard library and the language. This border is a bit blurred in D. Then again, I don't know how Go and Rust will fare in a couple of years' time. The lines seem to blur over time, because any language is pretty useless without at least one powerful library to its name.

> But if you create an "engine language" then you also need to be very good at exporting APIs. Like having compact and readable API definitions in D that lends itself to auto-generating interfaces for other languages (Python, Ruby, Go, Javascript etc).