digitalmars.D - DIP66 has been approved contingent to a few amendments as noted
- Andrei Alexandrescu (1/1) Dec 23 2014 Congratulations, Igor! -- Andrei
- ketmar via Digitalmars-d (6/7) Dec 23 2014 On Tue, 23 Dec 2014 07:49:47 -0800
- Vic (4/5) Dec 23 2014 http://wiki.dlang.org/DIP66
- H. S. Teoh via Digitalmars-d (7/11) Dec 23 2014 [...]
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/16) Dec 23 2014 Is TDPL the language spec? As I've pointed out before "multiple
- Dicebot (5/23) Dec 24 2014 Pretty much yes. It is a bit obsolete here and there but it does
- Nick Treleaven (4/6) Dec 27 2014 FWIW Apple's recent Swift has @autoclosure, which is the same as lazy.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/14) Dec 27 2014 Yes...
- Jacob Carlborg (4/6) Dec 27 2014 Doesn't Scala have something similar.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/8) Dec 27 2014 Yes, both Simula and Scala provide call-by-name.
- Dicebot (6/7) Dec 24 2014 Good to see that.
- eles (12/15) Dec 24 2014 I feel like dropping D1 was not such a good move. Especially if
- Dicebot (18/33) Dec 24 2014 In my opinion whole D1 vs D2 dichotomy could have been avoided if
- eles (10/17) Dec 24 2014 I do not contest that. But will be a less-deceiving entry-point
- Dicebot (6/17) Dec 27 2014 It sounds like you have overly positive memories of D1. Working
- bearophile (5/8) Dec 27 2014 I used to find a new D1 compiler bug about every 20 lines of my
- newbe (6/26) Dec 27 2014 does that mean, that sociomantics is writing crappy, fault prone
- Dicebot (9/14) Dec 27 2014 That means that they have huge working code base that can be just
- eles (28/40) Dec 27 2014 Ypu are comparing the D2 toolchain from today with the D1
- newbe (7/48) Dec 27 2014 +1
- Dicebot (4/4) Dec 27 2014 You can't speak about resurrecting language without considering
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (2/6) Dec 27 2014 Shh... It is possible to strip down D2.
- newbe (3/7) Dec 27 2014 troll? it doesn't fit your opinion?
- ketmar via Digitalmars-d (3/6) Dec 27 2014 bingo!
- eles (11/15) Dec 27 2014 That's true, because the gap in developping the toolchain
- Joseph Rushton Wakeling via Digitalmars-d (25/27) Dec 28 2014 Honestly, developing in D1, I personally feel that this is not so much a...
- eles (70/94) Dec 28 2014 Yes, because D1 is just that. It was already a D2 in the making
- Joseph Rushton Wakeling via Digitalmars-d (20/37) Dec 28 2014 With some exceptions (e.g. embedded programming), the assumption of a GC...
- eles (32/48) Dec 29 2014 Yes. And games. And realtime systems (yes, usually embedded). And
- eles (5/11) Dec 29 2014 And to this either in a stable build that will be maintained in
- eles (2/6) Dec 29 2014 And you do that in the language's standard library... Nice basis.
- eles (9/18) Dec 29 2014 It was simply ironic. If D1 was a subset of D2, the porting would
- Andrei Alexandrescu (2/5) Dec 24 2014 ETA? -- Andrei
- Dicebot (7/14) Dec 24 2014 With current progress I'd estimate second half of 2015 (closer to
- newbe (3/18) Dec 27 2014 yes - please resurrect D1!!!!!!!!!!!
- ketmar via Digitalmars-d (3/6) Dec 27 2014 do you *really* need it? then DO IT.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/9) Dec 27 2014 Are you willing to help out, ketmar?
- ketmar via Digitalmars-d (4/16) Dec 27 2014 i don't need D1, and i'm not interested in D1. so sure, i can help if
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (6/8) Dec 27 2014 Then your comment makes no sense. If people want trim down and
- ketmar via Digitalmars-d (8/16) Dec 27 2014 that's very easy: "hey, guys, i created a site dedicated to D1
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (5/6) Dec 27 2014 No, there are way to many projects in the D community that goes
- ketmar via Digitalmars-d (6/13) Dec 27 2014 start a site. call for arms. close a site if there will be not enough
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (13/19) Dec 27 2014 Step 1: figure out what people are unhappy about with D2
- ketmar via Digitalmars-d (6/20) Dec 27 2014 i bet that topic with the name "DIP66 has been approved contingent to a
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (9/15) Dec 27 2014 That's a different topic. The tail of this thread has been a
- ketmar via Digitalmars-d (10/20) Dec 27 2014 some people reading this in their e-mail clients, and see no "tails",
- Jacob Carlborg (9/10) Dec 28 2014 If you're interested in D1 you might want to have a look at Amber [1].
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/10) Dec 28 2014 Yes, except Amber appears to be less mature than D2 according to
- Andrei Alexandrescu (5/11) Dec 24 2014 An emerging pattern (which Walter will effect for dip69) is to initially...
- Dicebot (6/9) Dec 24 2014 Great!
- Martin Nowak (2/9) Dec 25 2014 +1
- Tobias Pankrath (7/23) Dec 28 2014 Where breaking changes are self-contained in a separate
- eles (3/12) Dec 29 2014 Much better.
- Martin Nowak (3/4) Dec 25 2014 Good news, congratulations Igor.
Congratulations, Igor! -- Andrei
Dec 23 2014
On Tue, 23 Dec 2014 07:49:47 -0800 Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com> wrote:Congratulations, Igor! -- Andreii can't believe my eyes! congrats, and thanks to all people who was working on it, either by contributing code or by contributing time to discuss and settle the things!
Dec 23 2014
http://wiki.dlang.org/DIP66 One more feature. On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:Congratulations, Igor! -- Andrei
Dec 23 2014
On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via Digitalmars-d wrote:http://wiki.dlang.org/DIP66 One more feature.[...] Which has been promised by TDPL years ago and only now become fully implemented. T -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot
Dec 23 2014
On Wednesday, 24 December 2014 at 06:13:43 UTC, H. S. Teoh via Digitalmars-d wrote:On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via Digitalmars-d wrote:Is TDPL the language spec? As I've pointed out before "multiple alias this" was implemented in Self, then removed because it was considered confusing and not useful. "lazy" was implemented in Algol and then shunned in just about all languages that followed. Time for D to learn from history...http://wiki.dlang.org/DIP66 One more feature.[...] Which has been promised by TDPL years ago and only now become fully implemented.
Dec 23 2014
On Wednesday, 24 December 2014 at 06:18:56 UTC, Ola Fosheim Grøstad wrote:On Wednesday, 24 December 2014 at 06:13:43 UTC, H. S. Teoh via Digitalmars-d wrote:Pretty much yes. It is a bit obsolete here and there but it does not have any speculation, only actual design intentions.On Tue, Dec 23, 2014 at 11:05:05PM +0000, Vic via Digitalmars-d wrote:Is TDPL the language spec?http://wiki.dlang.org/DIP66 One more feature.[...] Which has been promised by TDPL years ago and only now become fully implemented.As I've pointed out before "multiple alias this" was implemented in Self, then removed because it was considered confusing and not useful. "lazy" was implemented in Algol and then shunned in just about all languages that followed. Time for D to learn from history...Whatever.
Dec 24 2014
On 24/12/2014 06:18, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:"lazy" was implemented in Algol and then shunned in just about all languages that followed.FWIW Apple's recent Swift has autoclosure, which is the same as lazy. It's needed to implement assert in Swift.
Dec 27 2014
On Saturday, 27 December 2014 at 12:32:32 UTC, Nick Treleaven wrote:On 24/12/2014 06:18, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:Yes... «As with macros in C, auto-closures are a very powerful feature that must be used carefully because there is no indication on the caller side that argument evaluation is affected.» https://developer.apple.com/swift/blog/?id=4"lazy" was implemented in Algol and then shunned in just about all languages that followed.FWIW Apple's recent Swift has autoclosure, which is the same as lazy. It's needed to implement assert in Swift.
Dec 27 2014
On 2014-12-27 13:32, Nick Treleaven wrote:FWIW Apple's recent Swift has autoclosure, which is the same as lazy. It's needed to implement assert in Swift.Doesn't Scala have something similar. -- /Jacob Carlborg
Dec 27 2014
On Saturday, 27 December 2014 at 15:13:07 UTC, Jacob Carlborg wrote:On 2014-12-27 13:32, Nick Treleaven wrote:Yes, both Simula and Scala provide call-by-name.FWIW Apple's recent Swift has autoclosure, which is the same as lazy. It's needed to implement assert in Swift.Doesn't Scala have something similar.
Dec 27 2014
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:Congratulations, Igor! -- AndreiGood 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?
Dec 24 2014
On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:resolution. How about providing it as a separate compiler buildI feel like dropping D1 was not such a good move. Especially if full ABI compatibility with D2, people could have chose to write some of the less critical modules of their software in D2 (along with the enthusiasm of discovery), while still having a stable&non-experimental compiler for the really critical things. Then, D1 would have become D1.5 by integrating the D2 time-proven features etc., just as D2 could become D2.5. Is too late (or undesired) to resurrect D1 in maintenance mode? It is a bit strange that one of the most successful stories of D (Sociomantic) uses D1, still the compiler is ignored and everybody seems pretending that is a D (D2) success story.
Dec 24 2014
On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:In my opinion whole D1 vs D2 dichotomy could have been avoided if not design decisions for very few language parts that cause 90% of trouble - this comes from currently porting Sociomantic projects to D2. I am going to write some blog posts about it pretty soon. ABI compatibility is hard though, it does not currently exist even between different D2 releases.On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:resolution. How about providing it as a separate compiler buildI feel like dropping D1 was not such a good move. Especially if full ABI compatibility with D2, people could have chose to write some of the less critical modules of their software in D2 (along with the enthusiasm of discovery), while still having a stable&non-experimental compiler for the really critical things.Then, D1 would have become D1.5 by integrating the D2 time-proven features etc., just as D2 could become D2.5This pretty much means using proper semantic versioning as inherent part of development / release process - something I'd like to see a lot but impossible until it is acknowledged by those who actually work on compiler.Is too late (or undesired) to resurrect D1 in maintenance mode? It is a bit strange that one of the most successful stories of D (Sociomantic) uses D1, still the compiler is ignored and everybody seems pretending that is a D (D2) success story.What would be the point of it? D1 is almost absolutely inferior to D2 (both compiler and language) and lacks any better tools recently created by the community. Only reason why D1 is still used here is huge effort investment to actually port that much code without ever delaying normal deployment schedule - and I am working on this to change :)
Dec 24 2014
On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:What would be the point of it? D1 is almost absolutely inferior to D2 (both compiler and language) and lacks any better tools recently created by the community.I do not contest that. But will be a less-deceiving entry-point for those that are new to the language, they will bite and would wish to see more... And it would relieve time pressure on the current D2 development, that thrives to be both innovative and production-ready at the same time. D2 is still looking for the best design. D1 has one, is not as good, but is a safer default. Anyway, I do not push for it.
Dec 24 2014
On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:It sounds like you have overly positive memories of D1. Working with it daily and especially dealing with all the compiler bugs we had back then (and still have with dmd1) - it is hardly an experience I'd want newcomer to have. Lacking quality of the toolchain kills any benefit from the language simplicity.On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:What would be the point of it? D1 is almost absolutely inferior to D2 (both compiler and language) and lacks any better tools recently created by the community.I do not contest that. But will be a less-deceiving entry-point for those that are new to the language, they will bite and would wish to see more...
Dec 27 2014
Dicebot:It sounds like you have overly positive memories of D1. Working with it daily and especially dealing with all the compiler bugs we had back thenI used to find a new D1 compiler bug about every 20 lines of my code. This isn't nice. Bye, bearophile
Dec 27 2014
does that mean, that sociomantics is writing crappy, fault prone and unusable software? they are the praised light on D's sky when evangelizing D, even if everybody thinks they are using D2. are they dumb or just uneducated? On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:It sounds like you have overly positive memories of D1. Working with it daily and especially dealing with all the compiler bugs we had back then (and still have with dmd1) - it is hardly an experience I'd want newcomer to have. Lacking quality of the toolchain kills any benefit from the language simplicity.On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:What would be the point of it? D1 is almost absolutely inferior to D2 (both compiler and language) and lacks any better tools recently created by the community.I do not contest that. But will be a less-deceiving entry-point for those that are new to the language, they will bite and would wish to see more...
Dec 27 2014
On Saturday, 27 December 2014 at 14:59:58 UTC, newbe wrote:does that mean, that sociomantics is writing crappy, fault prone and unusable software? they are the praised light on D's sky when evangelizing D, even if everybody thinks they are using D2. are they dumb or just uneducated?That means that they have huge working code base that can be just simply switched to different language version. If using inferior toolchain didn't result in productivity losses no one would bother upgrading even now. There is certain sympathy towards D1 as a _language_ but compiler quality as well as toolchain infrastructure is simply non-existent. I dream of being able to use DScanner, mono-d, dfix, ldc/gdc and similar cool things at work.
Dec 27 2014
On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:It sounds like you have overly positive memories of D1. Working with it daily and especially dealing with all the compiler bugs we had back then (and still have with dmd1) - it is hardly an experience I'd want newcomer to have. Lacking quality of the toolchain kills any benefit from the language simplicity.Ypu are comparing the D2 toolchain from today with the D1 toolchain from back then (as the work on the latter stalled when the language was retired, and the bulk of the work on D2 toolchain - and language - was done in the last 1.5-2 years). Back then I doubt that D2 toolchain was in better shape than D1. Yes, the latter was doomed by the Phobos vs Tango issue, but that wasn't the fault of the language. But I do not discuss about toolchains, but about the language versions (D1 and D2) themselves. Please, for the remaininig of the discussion, let's not mix the language and the toolchain. Point is, after so many years, D in its current incarnation (D2) is in the same recurring stage (and I speak about the language): on one hand, need to tie up some knots and ensure consistency and stability of the language. On the other hands, the need to modify the curren design and implement nicer features. I feel that the two conflict too much already. OTOH, D2's design is far from reaching the ideal, and many ideas needs pushing the frontier even further. The approach that I had in mind was to let D1 there for peple who need to compile code and let D2 also there for people who need to innovate their code. Then, once a feature is tested and re-tested and the design of it is concidered to be optimal, it is migrated from D2 to D1. It doesn't need to be immediately, but over a span that could e even 6 months. People will have time to adapt their skills and their code to integrate (or take advantage) of the new feature. Then, the new frontlines would become D1.1 and D2.1.
Dec 27 2014
+1 You are stating the situation absolutely correct! Exactly the same is happening now what happened with the decision to get a release version D1 and start with D2. it has been an experiment ever since with D2 and I quit the rat race - keeping up with bad docs, features I don't need etc.. On Saturday, 27 December 2014 at 16:10:57 UTC, eles wrote:On Saturday, 27 December 2014 at 14:27:09 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:It sounds like you have overly positive memories of D1. Working with it daily and especially dealing with all the compiler bugs we had back then (and still have with dmd1) - it is hardly an experience I'd want newcomer to have. Lacking quality of the toolchain kills any benefit from the language simplicity.Ypu are comparing the D2 toolchain from today with the D1 toolchain from back then (as the work on the latter stalled when the language was retired, and the bulk of the work on D2 toolchain - and language - was done in the last 1.5-2 years). Back then I doubt that D2 toolchain was in better shape than D1. Yes, the latter was doomed by the Phobos vs Tango issue, but that wasn't the fault of the language. But I do not discuss about toolchains, but about the language versions (D1 and D2) themselves. Please, for the remaininig of the discussion, let's not mix the language and the toolchain. Point is, after so many years, D in its current incarnation (D2) is in the same recurring stage (and I speak about the language): on one hand, need to tie up some knots and ensure consistency and stability of the language. On the other hands, the need to modify the curren design and implement nicer features. I feel that the two conflict too much already. OTOH, D2's design is far from reaching the ideal, and many ideas needs pushing the frontier even further. The approach that I had in mind was to let D1 there for peple who need to compile code and let D2 also there for people who need to innovate their code. Then, once a feature is tested and re-tested and the design of it is concidered to be optimal, it is migrated from D2 to D1. It doesn't need to be immediately, but over a span that could e even 6 months. People will have time to adapt their skills and their code to integrate (or take advantage) of the new feature. Then, the new frontlines would become D1.1 and D2.1.
Dec 27 2014
You can't speak about resurrecting language without considering costs of resurrecting the toolchain - unless one wants to write programs exclusively with pen and paper of course. But I do recognize the troll pattern now, thanks.
Dec 27 2014
On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:You can't speak about resurrecting language without considering costs of resurrecting the toolchain - unless one wants to write programs exclusively with pen and paper of course. But I do recognize the troll pattern now, thanks.Shh... It is possible to strip down D2.
Dec 27 2014
troll? it doesn't fit your opinion? well I won't write anymore - therefore you win. On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:You can't speak about resurrecting language without considering costs of resurrecting the toolchain - unless one wants to write programs exclusively with pen and paper of course. But I do recognize the troll pattern now, thanks.
Dec 27 2014
On Sat, 27 Dec 2014 16:50:34 +0000 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:troll? it doesn't fit your opinion? =20 well I won't write anymore - therefore you win.bingo!
Dec 27 2014
On Saturday, 27 December 2014 at 16:44:35 UTC, Dicebot wrote:You can't speak about resurrecting language without considering costs of resurrecting the toolchain - unless one wants to write programs exclusively with pen and paper of course.That's true, because the gap in developping the toolchain accumulated. The alternative would be to stall D2 at the current language state and start D3 with the main target being the memory management pardigm. I kinda doubt that RC and other management techniques will integrate smoothly into D2. And is not the breakages that I worry about, it is that the language could become a behemoth with many legs and no head. That is, will loose streamilness.But I do recognize the troll pattern now, thanks.With all respect, but you are looking into a mirror while taking it for a window.
Dec 27 2014
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.
Dec 28 2014
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: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!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.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).
Dec 28 2014
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.
Dec 28 2014
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: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.Thing is, by now, most of D2 code that is written is GC-centric.With some exceptions (e.g. embedded programming), theassumption 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'tYes, 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.Well. This is why English has two meanings of "you". To make it clear.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.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.
Dec 29 2014
On Monday, 29 December 2014 at 22:49:00 UTC, eles wrote: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.idea: clean up the language of deprecated features. TheyAnd to this either in a stable build that will be maintained in parallel with the crazy (but *the right*) new memory management, either do it *before*. Otherwise will get even more loose.
Dec 29 2014
On Monday, 29 December 2014 at 22:49:00 UTC, eles wrote: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:then you fight the compiler and the language to bend it all theAnd you do that in the language's standard library... Nice basis.
Dec 29 2014
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:It was simply ironic. If D1 was a subset of D2, the porting would have been immediate: install a D2 compiler and that's all. There is no such subset. It looks like one, that's another matter.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 taketime. It would be much more straightforward to port a codebase through a sequence of individual, well-defined breaking changes.And? Isn't that exactly what I was saying? With so much featuritis, porting is such a mess that one might better attempt a complete rewrite. Why all deprecated and unfinished features if they are not even good at porting legacy code?
Dec 29 2014
On 12/24/14 5:54 AM, Dicebot wrote:Only reason why D1 is still used here is huge effort investment to actually port that much code without ever delaying normal deployment schedule - and I am working on this to change :)ETA? -- Andrei
Dec 24 2014
On Wednesday, 24 December 2014 at 22:13:26 UTC, Andrei Alexandrescu wrote:On 12/24/14 5:54 AM, Dicebot wrote:With current progress I'd estimate second half of 2015 (closer to the end) to get first proof of concept service ported to D2. Getting completely rid of D1 and specifically ensuring smooth transition of services with real-time requirements will take much longer, probably several more years.Only reason why D1 is still used here is huge effort investment to actually port that much code without ever delaying normal deployment schedule - and I am working on this to change :)ETA? -- Andrei
Dec 24 2014
yes - please resurrect D1!!!!!!!!!!! +100 On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:resolution. How about providing it as a separate compiler buildI feel like dropping D1 was not such a good move. Especially if full ABI compatibility with D2, people could have chose to write some of the less critical modules of their software in D2 (along with the enthusiasm of discovery), while still having a stable&non-experimental compiler for the really critical things. Then, D1 would have become D1.5 by integrating the D2 time-proven features etc., just as D2 could become D2.5. Is too late (or undesired) to resurrect D1 in maintenance mode? It is a bit strange that one of the most successful stories of D (Sociomantic) uses D1, still the compiler is ignored and everybody seems pretending that is a D (D2) success story.
Dec 27 2014
On Sat, 27 Dec 2014 14:01:50 +0000 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:yes - please resurrect D1!!!!!!!!!!! =20 +100do you *really* need it? then DO IT.
Dec 27 2014
On Saturday, 27 December 2014 at 19:18:04 UTC, ketmar via Digitalmars-d wrote:On Sat, 27 Dec 2014 14:01:50 +0000 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:Are you willing to help out, ketmar?yes - please resurrect D1!!!!!!!!!!! +100do you *really* need it? then DO IT.
Dec 27 2014
On Sun, 28 Dec 2014 04:53:51 +0000 via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Saturday, 27 December 2014 at 19:18:04 UTC, ketmar via=20 Digitalmars-d wrote:i don't need D1, and i'm not interested in D1. so sure, i can help if the payment will be big enough.On Sat, 27 Dec 2014 14:01:50 +0000 newbe via Digitalmars-d <digitalmars-d puremagic.com> wrote:=20 Are you willing to help out, ketmar?yes - please resurrect D1!!!!!!!!!!! =20 +100do you *really* need it? then DO IT.
Dec 27 2014
On Sunday, 28 December 2014 at 05:06:42 UTC, ketmar via Digitalmars-d wrote:i don't need D1, and i'm not interested in D1. so sure, i can help if the payment will be big enough.Then your comment makes no sense. If people want trim down and refactor D2 then they need to communicate in order to figure out if there is common ground. That is, if one wants to break this cycle of conglomerate solo-projects.
Dec 27 2014
On Sun, 28 Dec 2014 05:11:35 +0000 via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Sunday, 28 December 2014 at 05:06:42 UTC, ketmar via=20 Digitalmars-d wrote:that's very easy: "hey, guys, i created a site dedicated to D1 resurrection! we have a forum and a wiki, right now we are in the planning stage. join us and help if you're interested!" it's easy enough, isn't it? i bet that such message will see a warm responses. but "yes - please resurrect D1!!!!!!!!!!! +100" is complete BS. to make something happen just START DOING IT.i don't need D1, and i'm not interested in D1. so sure, i can=20 help if the payment will be big enough.=20 Then your comment makes no sense. If people want trim down and=20 refactor D2 then they need to communicate in order to figure out=20 if there is common ground.
Dec 27 2014
On Sunday, 28 December 2014 at 05:42:07 UTC, ketmar via Digitalmars-d wrote:BS. to make something happen just START DOING IT.No, there are way to many projects in the D community that goes like that. You need to find common ground, if only 1-2 people want it then you cannot sustain it.
Dec 27 2014
On Sun, 28 Dec 2014 05:48:45 +0000 via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Sunday, 28 December 2014 at 05:42:07 UTC, ketmar via=20 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. but i see that the idea is already deadborn.BS. to make something happen just START DOING IT.=20 No, there are way to many projects in the D community that goes=20 like that. You need to find common ground, if only 1-2 people=20 want it then you cannot sustain it.
Dec 27 2014
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... Wasting time on solo projects that die is not very efficient. Spending time on figuring things out is potentially rewarding even if one decides to move in a different direction.but i see that the idea is already deadborn.First you need to assess the current state of the D2 compiler to see if it is worth the trouble.
Dec 27 2014
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=20 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! besides, there is alot of interest in D1 on D2 NGs!start a site. call for arms. close a site if there will be not=20 enough tension. writing "yes, resurrect D1!" here will do nothing for=20 the project: people just have no place to go if they are interested.=20 Step 1: figure out what people are unhappy about with D2 Step 2: figure out if there is a reduced feature set that people=20 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...
Dec 27 2014
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.
Dec 27 2014
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=20 sensible concern about featuritis, and eles expressed a solution=20 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=20 separate thread, but telling people to create a separate website=20 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.D1 is dead. dead as a doornail. i don't think that there are alot of necromancers here. ;-)besides, there is alot of interest in D1 on D2 NGs!=20 There are no D1/D2 NGs, only D NG. People are not saying they=20 want D1 specifically, they are saying they want a stable D.
Dec 27 2014
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
Dec 28 2014
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:Yes, except Amber appears to be less mature than D2 according to the Amber repository. https://bitbucket.org/larsivi/amber/wiki/ProgressReportAre 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].
Dec 28 2014
On 12/24/14 4:59 AM, Dicebot wrote:On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:An emerging pattern (which Walter will effect for dip69) is to initially make it opt-in as a flag: dip -dip69 test.d AndreiCongratulations, Igor! -- AndreiGood 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?
Dec 24 2014
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei Alexandrescu wrote:An emerging pattern (which Walter will effect for dip69) is to initially make it opt-in as a flag: dip -dip69 test.dGreat! Though I would suggest -dip=69 as a small tweak for a bit more robust CLI (leaves possibility for both -dip=-69 and -dip=+69 in future)
Dec 24 2014
On Wednesday, 24 December 2014 at 22:52:12 UTC, Dicebot wrote:On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei Alexandrescu wrote:+1An emerging pattern (which Walter will effect for dip69) is to initially make it opt-in as a flag: dip -dip69 test.dGreat!
Dec 25 2014
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei Alexandrescu wrote:On 12/24/14 4:59 AM, Dicebot wrote: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 Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:An emerging pattern (which Walter will effect for dip69) is to initially make it opt-in as a flag: dip -dip69 test.d AndreiCongratulations, Igor! -- AndreiGood 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?
Dec 28 2014
On Sunday, 28 December 2014 at 23:05:28 UTC, Tobias Pankrath wrote: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:Where breaking changes are self-contained in a separate compilation sense, I'd rather have a pragma that effects the hole module.Much better.
Dec 29 2014
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote:Congratulations, Igor! -- AndreiGood news, congratulations Igor.
Dec 25 2014