On Sun, 28 Dec 2014 06:01:39 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Sunday, 28 December 2014 at 05:55:02 UTC, ketmar via Digitalmars-d wrote:
> > start a site. call for arms. close a site if there will be not
> > enough
> > tension. writing "yes, resurrect D1!" here will do nothing for
> > the
> > project: people just have no place to go if they are interested.
> 
> Step 1: figure out what people are unhappy about with D2
> Step 2: figure out if there is a reduced feature set that people
> will be happy with
> Step 3: figure out how much work it is to refactor D2
> Step 4: figure out how many will be interested in contributing
> etc...

i bet that topic with the name "DIP66 has been approved contingent to a few amendments as noted" is the best place for this. dedicated forum can't be better!

besides, there is alot of interest in D1 on D2 NGs!

On Sunday, 28 December 2014 at 06:10:39 UTC, ketmar via Digitalmars-d wrote:
> i bet that topic with the name "DIP66 has been approved contingent to a
> few amendments as noted" is the best place for this. dedicated forum
> can't be better!

That's a different topic. The tail of this thread has been a sensible concern about featuritis, and eles expressed a solution which someone agreed to. The next step might be to create a separate thread, but telling people to create a separate website is way out of line.

> besides, there is alot of interest in D1 on D2 NGs!

There are no D1/D2 NGs, only D NG. People are not saying they want D1 specifically, they are saying they want a stable D.

On Sun, 28 Dec 2014 06:40:08 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That's a different topic. The tail of this thread has been a sensible concern about featuritis, and eles expressed a solution which someone agreed to.
some people reading this in their e-mail clients, and see no "tails", but a tree. so you actually dropped out such people, as looking for something in the middle of the discussion tree is... not enjoyable.

> The next step might be to create a separate thread, but telling people to create a separate website is way out of line.
there is nothing hard in creating a simple website. i believe that one can still find a free hosting that either already has or allow to install some simple wiki and web-forum.

> > besides, there is alot of interest in D1 on D2 NGs!
> 
> There are no D1/D2 NGs, only D NG. People are not saying they want D1 specifically, they are saying they want a stable D.
D1 is dead. dead as a doornail. i don't think that there are alot of necromancers here. ;-)

On 2014-12-28 05:53, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> Are you willing to help out, ketmar?

If you're interested in D1 you might want to have a look at Amber [1]. It's a language based on D1 created by the guys that worked on Tango. Differences compared to D1 [2].

[1] https://bitbucket.org/larsivi/amber/wiki/Home
[2] https://bitbucket.org/larsivi/amber/wiki/Diff_D1

-- 
/Jacob Carlborg

On 24/12/14 15:27, eles via Digitalmars-d wrote:
> D2 is still looking for the best design. D1 has one, is not as good, but is a
> safer default.

Honestly, developing in D1, I personally feel that this is not so much a stable version as a frozen snapshot of a still-evolving language.  There are just too many idiosyncrasies and inconsistencies in its design (for example, the way in which dynamic/static/associative arrays behave).

Now, that said, in practice D1 does feel for the most part very much like a subset of D2 features; you could code a new project in D2, using the same design principles, and have pretty much identical results.  So it's entirely fair to see a D success story here.

With more historical resources, it might have been sane or possible to backport some of the relevant breaking changes -- that is, to have a D1.5 with the same reduced feature set but with the inconsistencies and bad design decisions ironed out -- but now that D2 has reached its current state, it doesn't seem worth it to me.  D2 may still be evolving, but it's stable _enough_, and with good change management (e.g. the -dip flag as discussed here) there's nothing on a _language_ basis that seems other than an improvement (Dicebot may have some counter-examples to hand, but off the top of my head, I can't think of any:-).

I suppose that we could, today, divide D2 into a guaranteed stable subset and a wider range of features whose final design is still up for discussion, but even that seems non-trivial: cf. the kerfuffle over whether class methods should be virtual or final by default.  (And no, please don't take this as a reason to re-open that discussion.)

The simple, straightforward fact is that it's hard to upgrade a large codebase with high performance requirements.  That's not a judgement on D2 as a production-ready language.

On Sunday, 28 December 2014 at 10:53:30 UTC, Jacob Carlborg wrote:
> On 2014-12-28 05:53, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
>> Are you willing to help out, ketmar?
>
> If you're interested in D1 you might want to have a look at Amber [1]. It's a language based on D1 created by the guys that worked on Tango. Differences compared to D1 [2].

Yes, except Amber appears to be less mature than D2 according to the Amber repository.

https://bitbucket.org/larsivi/amber/wiki/ProgressReport

On Sunday, 28 December 2014 at 12:10:15 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 24/12/14 15:27, eles via Digitalmars-d wrote:
>> D2 is still looking for the best design. D1 has one, is not as good, but is a
>> safer default.
>
> Honestly, developing in D1, I personally feel that this is not so much a stable version as a frozen snapshot of a still-evolving language.

Yes, because D1 is just that. It was already a D2 in the making at that time and D1 was stopped not because it has reached a significant milestone, but simply because Andrei bet everything on D2 and wanted all resources concentrated on it.

But D1 might be dead, the question of stability s experiment remains.

As Ola wisely observed, the debate is not about D1 per sé, but about the moving target that one chases when (trying to) use(ing) D.

Instead of D1 and D2, think D2 and D3 or, if you like, stableD and experimentD. Place the border between them wherever you want, but before changing the paradigm of memory management.

In the original comment to which I replied with the proposal of D1 back again, the trigger was "different build". Just re-read that post and replace D1 with "different (aka stable) build" and re-shape the ideas accordingly.

Why that? Well, as Walter stated several times, using a new memory management technique is not only about having a new compiler and memory management mechanism. It is also (and mainly) about *coding style*. When developing for a GC-based language, one makes some assumptions and writes some code accordingly. When developing for a RC-based language, one writes *different* code. And when writing for MM-based language, one structures and writes another kind of code.

Thing is, by now, most of D2 code that is written is GC-centric. Supporting that to at least the same level of performance, while making sure the impact of the new changes that should allow RC and MM techniques, along with the work on a precise/concurrent/performant GC, while letting room for the new memory paradigm to provide optimized code (and not asking changes in the coding style)... is too much.

Even much too much given the other untied knots that D has: from properties, multiple aliasing this, re-definition of "scope" and C++ compatibility. I am sure there are others too.

And you charge this already unstable state with a new mechanism of memory management that is yet to be designed, not to say about being written? Now oua re introducing -dip= flags, which could work as long as they are orthogonal with existing code but... for how long and how? Will every project come with a .ini file that will list the dips that are necessary for that project to work?

"This project is not written in D1, but in D2+dip63,+dip45+dip119v3,+dip23 and incompatible with dip22 and dip99. For best performance we recommend disabling dip67 and use the dmd source version 2a2b3c4ddf2a"?

What about tying up the current issues that keep running in circles, a lot of eternally to be deprecated features and so on? They will be let for 2025? Will drag properties issues and the others (*complex types, anyone*?) until then?

Don clearly stated in one of hist posts: "keeping deprecated features has a cost!". It works for one of the most successful stories in the D world. Guess its name? Sociomantic!

> Now, that said, in practice D1 does feel for the most part very much like a subset of D2 features; you could code a new project in D2, using the same design principles, and have pretty much identical results.  So it's entirely fair to see a D success story here.

Except that porting this subset to its own takes quite some time for Sociomantics...

> With more historical resources, it might have been sane or possible to backport some of the relevant breaking changes -- that is, to have a D1.5 with the same reduced feature set but with the inconsistencies and bad design decisions ironed out -- but now that D2 has reached its current state, it doesn't seem worth it to me.

I agree with that. But the point is, D2 has been also reached a state where is too much on its plate in terms of contradiction between "be-production-ready!" and "be-innovative!". Not even to say "clean up all the dark corners!".

Everybody keeps replying with "that was then and a decision was made back then!". I am saying "hey! this happens again!".

> I suppose that we could, today, divide D2 into a guaranteed stable subset and a wider range of features whose final design is still up for discussion, but even that seems non-trivial: cf. the kerfuffle over whether class methods should be virtual or final by default.  (And no, please don't take this as a reason to re-open that discussion.)

No, I do not start that discussion. Thing is, you cannot add zillions of flags that basically make you jumping from a language to another every time that you compile code. This way, what about adding some new flags like "-java", "-csharp" and "-c++1zwithconceptsliteandmodules"?

The only thing that those flags will have in common with D and with each other will be the fact that they are all braces-family languages. That, and nothing more than that. (yes, yes, it's an exaggeration).

On 28/12/14 21:08, eles via Digitalmars-d wrote:
> Thing is, by now, most of D2 code that is written is GC-centric.

With some exceptions (e.g. embedded programming), the assumption of a GC isn't so much a problem as the fact that too many parts of Phobos have been written in a way that doesn't allow you to avoid generating garbage (e.g. by passing in preallocated buffers or suchlike).

> And you charge this already unstable state with a new mechanism of memory
> management that is yet to be designed, not to say about being written?

I'm really not sure who this "you" is that you're talking about.

> "This project is not written in D1, but in D2+dip63,+dip45+dip119v3,+dip23 and
> incompatible with dip22 and dip99. For best performance we recommend disabling
> dip67 and use the dmd source version 2a2b3c4ddf2a"?

... will only happen if the project is slow about reviewing implemented DIPs. To my mind it would be a pretty bad show if any one -dip flag hung about for longer than a couple of compiler releases.

> Don clearly stated in one of hist posts: "keeping deprecated features has a
> cost!". It works for one of the most successful stories in the D world. Guess
> its name? Sociomantic!

I think you might want to do a bit more research into the context and concerns behind Don's remarks, before you cite Sociomantic as an argument for keeping deprecated features :-)

> Except that porting this subset to its own takes quite some time for
> Sociomantics...

Porting a large codebase, with high performance requirements, through a large number of breaking changes, many of which cause silent changes in program behaviour ... it's going to take time.  It would be much more straightforward to port a codebase through a sequence of individual, well-defined breaking changes.

> I agree with that. But the point is, D2 has been also reached a state where is
> too much on its plate in terms of contradiction between "be-production-ready!"
> and "be-innovative!". Not even to say "clean up all the dark corners!".

I don't think that well defined, well signposted breaking changes are an issue for production code (actually, they are quite welcome if they provide a meaningful improvement).  They're more an issue for unmaintained code.

> No, I do not start that discussion. Thing is, you cannot add zillions of flags
> that basically make you jumping from a language to another every time that you
> compile code.

I don't think I or anyone else was suggesting that.

On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei
Alexandrescu wrote:
> On 12/24/14 4:59 AM, Dicebot wrote:
>> On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:
>>> Congratulations, Igor! -- Andrei
>>
>> Good to see that.
>>
>> It is a big feature though with a notable impact on symbol resolution.
>> How about providing it as a separate compiler build for a release or two
>> before deploying as part of master?
>
> An emerging pattern (which Walter will effect for dip69) is to initially make it opt-in as a flag:
>
> dip -dip69 test.d
>
>
> Andrei

Where breaking changes are self-contained in a separate
compilation sense, I'd rather have a pragma that effects the hole
module.

Especially changes that prohibit currently allowed code could be
incorporated bit by bit.

On Sunday, 28 December 2014 at 22:37:48 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 28/12/14 21:08, eles via Digitalmars-d wrote:
>> Thing is, by now, most of D2 code that is written is GC-centric.
>
> With some exceptions (e.g. embedded programming), the

Yes. And games. And realtime systems (yes, usually embedded). And is not only about realtime, it is also about the memory at your disposal. But you know that already.

But me, for one, I don't see those as exceptions. That exception for you is my full time work. I see only this. "Some exceptions" are, for me: desktop applications, client and server applications, Web, GUIs etc. Minor stuff that I don't even understand why people even write. They are just some minor exception.

> assumption of a GC isn't so much a problem as the fact that too many parts of Phobos have been written in a way that doesn't

Yes, yes. As I was telling when rewording what Walter said, there is one code style when you write for a GC, and another one when you don't. And it support my assertion that most of the D2 code written by now is too GC-centric for that to change.

Walter was perfectly right in one of his post when he told: "GC must be part of language specifications, because otherwise libraries must be written without assuming that a GC is present." We're getting there with Phobos. But, I admit, he was visionary.

And I am really worried that throwing the new memory management mechanism into the game will not mess things. I thing the appropriate way would be "separate build" for that. Read D3.

> allow you to avoid generating garbage (e.g. by passing in preallocated buffers or suchlike).

That is, you design a language that puts the GC at its heart, then you fight the compiler and the language to bend it all the way to get over its implicit behavior. I really understand why people from the C++ world coming here hit the GC thing like a wall.

>> And you charge this already unstable state with a new mechanism of memory
>> management that is yet to be designed, not to say about being written?
>
> I'm really not sure who this "you" is that you're talking about.

Well. This is why English has two meanings of "you". To make it clear.

> I think you might want to do a bit more research into the context and concerns behind Don's remarks, before you cite Sociomantic as an argument for keeping deprecated features :-)

Actually, I was citing his opinion to support the contrary idea: clean up the language of deprecated features. They complicate the language without giving any help.