Re: vibe.d compatible with d3 or pixieJS
On 1/28/18 11:45 AM, Mark wrote: Hello! As the title suggests, I'm looking for the answer to this question. I've searched / asked it on the vibe forums, but nobody has answered. vibe.d is a server, and it serves javascript just fine. I've experimented with vibe, and I would like to build a data visualization website using one of the two (preferably pixieJS). Either is fine AFAIK, javascript is browser-side, so the server just has to dish out the files for the browser to run them. -Steve
vibe.d compatible with d3 or pixieJS
Hello! As the title suggests, I'm looking for the answer to this question. I've searched / asked it on the vibe forums, but nobody has answered. I'm not familiar enough with JS frameworks / vibe to really know how this would (not) work together. I've experimented with vibe, and I would like to build a data visualization website using one of the two (preferably pixieJS). If they are not, can anyone point to where I should start to make a custom web kit out of the stuff found on dub? Thanks!
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: * Drop the GC or at a minimum make it opt-in. Add a borrow checker, automatic reference counting, or some other GC alternative that doesn't require a separate thread. AIUI D's GC doesn't use a separate thread: https://dlang.org/spec/garbage.html#how_gc_works "1. Stopping all other threads than the thread currently trying to allocate GC memory. 2. ‘Hijacking’ the current thread for GC work." An earlier bullet point is confusing: "Normally, all threads other than the collector thread must be halted while the collection is in progress." Probably 'other than the collector thread' should be removed - 'collector thread' implies asynchronous collections.
Re: Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On Thursday, 15 June 2017 at 18:26:57 UTC, Jesse Phillips wrote: In essence he is saying we should have immutable code releases. For example he would say that we should add a new namespace and not get rid of the original (std2.io, std2.xml, std2.json) now you can get your improvements out and not break anyone's code, for example he would say old modules would be deprecated but never removed. Not much different from moving old code to Undead, requires very little work. On a plus side you have to decide whether to upgrade your code or stick with the existing modules.
Re: Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On Wednesday, 14 June 2017 at 19:12:36 UTC, Jacob Carlborg wrote: You only need one, AST macros ;) Not going to happen anytime soon, as we do not have much interest in DSL abuse.
Re: Isn't it about time for D3?
Here are some ways that D3 can be an improvement of D2: -Final by default -A standard library that is effective with or without garbage collection 100% OK about the optional garbage collector, but I have to totally disagree with you on the "final by default" approach. The current design keeps the code open to extension, in a perfectly complementary way to UFCS. They are both incredibly useful, and are part of what makes D2 perfectly work as a strongly-typed JavaScript-like scripting language. (I just had another proof of that this morning, see my recent post.) And dropping C++ compatibility is a complete non-sense IMHO. If you want more people using D, its interoperability with C and C++ should instead be improved, so that D applications can quickly and easily use any C/C++ 3D/2D/VR/audio multimedia libraries for instance...
Re: Isn't it about time for D3?
On Sunday, 18 June 2017 at 12:05:37 UTC, Suliman wrote: And not every people need to interfacing with C/C++. For me it's more important to have static-typing and compilable alternative to Python. And a lot of people whom I know want same. I see this a lot, but then you have to ask yourself how many languages are trying to enter the same domain (faster Python). In the end a language has to be the best for some particular domain to gain traction.
Re: Isn't it about time for D3?
But C++ will still be big in 10 years. Ok, let's assume it will be poplar in 10 years. But it's very short time. D exists almost 17 years. And not every people need to interfacing with C/C++. For me it's more important to have static-typing and compilable alternative to Python. And a lot of people whom I know want same.
Re: Isn't it about time for D3?
On Sunday, 18 June 2017 at 07:14:24 UTC, Suliman wrote: Why for example not Rust (i am not its fan). I do not see any real perspective in C++. What to do in next 5 years if C++ will start loosing it's popularity? Implement D4? Plus any backwards compatibility make implementation new ideas in language very hard. Both C/C++ are loosing popularity relatively speaking, but this is not because of the languages themselves. It is because more and more applications can be written either fully or in part in higher level languages. So C++ is taking over parts of the former C domain, and other high level languages are taking over some parts of the C++ application development domain. But C++ will still be big in 10 years.
Re: Isn't it about time for D3?
Why for example not Rust (i am not its fan). I do not see any real perspective in C++. What to do in next 5 years if C++ will start loosing it's popularity? Implement D4? Plus any backwards compatibility make implementation new ideas in language very hard.
Re: Isn't it about time for D3?
Removing all C++ compatibility is a death sentence for D. This may not be apparent to some people that already program in D, but it is downright critical to potential D users. Zero C++ compatibility means that D can no longer interface with C++ libraries such as Qt, putting a severe limitation on it's uses. At the very least, dropping C++ compatibility is not for D3. If ever, it should happen when D is already as popular as C++. I brought up this whole D3 idea because I feel like D just needs one more wave of breaking changes to the language and library to be brought to perfection. There are many C++ programmers out there who looked into/tried D and felt like it was almost good enough. I think it will just take one major breaking version to make them jump, but not if it's totally incompatible with C++. D3 should make the changes that can be agreed between proud D users and C++ users who have hopes for D. On Saturday, 17 June 2017 at 06:23:08 UTC, Suliman wrote: On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote: On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: > THINGS TO DROP -- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years. Totally agree! C++ now in 90% of cases is legacy projects. At current time is more important to out of the box interoperability with Rust or Julia. Time show that C++ do not want to migrate to D. Only few people come from C++ world, because all of them waiting of new C++ standard c++x2035 (or whatever) Please don't quote me just to say "Totally agree!" to someone that I quoted and disagree with. A prediction that C++ is going to be dead in 10 years is not good enough. C++ is very active, not just legacy like you say. As I said, D should not drop compatibility until it's ALREADY clear that it's getting surpassed by D. I support interoperability with Rust if it's doable. I barely know about Julia. Like I said, there are actually many C++ programmers out there who feel like D2 has promise, but not quite there. THIS is why I brought up this D3 idea. I really do think that D3 could bring quite some excitement to the programming community if it's coming along well. After a few of the more open-minded C++ programmers adopt D, it will trickle up to more and more.
Re: Isn't it about time for D3?
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote: On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: > THINGS TO DROP -- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years. Thank you for making a list to give people an idea of what D3 could be, but I definitely don't support less interoperability with C++. I want D3 to have a better argument to transition from C++ than D2 has. With all the C++ API's out there, making D incompatible would be a ginormous deal-breaker for a ridiculous number of projects. D3 should seek to be worth the transition from C++. Seems like there is a split right down the middle. The problem is of course that going down the middle is neither satisfactory nor innovative. I agree with you, but I think the C++ compatibility is a lost game and increasingly so without aligning the core semantics. C++ is changing too...
Re: Isn't it about time for D3?
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote: I hope that Walter and Andrei give a proper response to this thread. I wonder why they haven't. They rarely give definitive answers... except after the fact, once it is already in master.
Re: Isn't it about time for D3?
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote: On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: > THINGS TO DROP -- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years. Totally agree! C++ now in 90% of cases is legacy projects. At current time is more important to out of the box interoperability with Rust or Julia. Time show that C++ do not want to migrate to D. Only few people come from C++ world, because all of them waiting of new C++ standard c++x2035 (or whatever)
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: > THINGS TO DROP -- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years. Thank you for making a list to give people an idea of what D3 could be, but I definitely don't support less interoperability with C++. I want D3 to have a better argument to transition from C++ than D2 has. With all the C++ API's out there, making D incompatible would be a ginormous deal-breaker for a ridiculous number of projects. D3 should seek to be worth the transition from C++. For those who say that this idea can't go anywhere without an idea of what changes it would make, I'll relink to the page I already posted. There are many proposals that were rejected due to "breaking changes" that should be relooked for D3. https://wiki.dlang.org/Language_design_discussions People who say they like D2 for "stability" don't need to worry. What would be a threat to stability is breaking changes in D2. But that was never allowed, so you must not worry. If D3 was released, you may still use D2 just as you would have otherwise. For the people who talk about D3 being an alternative to, rather than a replacement for D2: I think that D3 should seek to be a better option than D2 for virtually every new project. If done right, it will barely split the community; I'm hoping for D3 to expand the popularity of D to overshadow what D2 ever was. Improving some things in D would make it an easier sell to C++ programmers, even in converting existing projects. What I think should be one of, if not the #1, main goal of D3 is to significantly shrink the number of scenario's in which C++ is more viable than D (to less than one third. Not "more viable" in the opinions of the D fanatics here, but to everyone who properly considers D vs C++. I feel like D only needs one more major (breaking) revision to do this, and it would be a less dramatic change than D1-D2. For those who are saying that everything is right with D2, I want to point out that there is a bias to the people in this forum. It is that people posting here tend to be "insiders", who don't mind/see the problems that discourage others from using D. There are surely many "outsiders" out there (not reading this) who have considered D in the past, but chose C++ instead for valid reasons. I recommend searching the internet for others opinions on D. You may find disadvantages of D apparent to other programmers that you never thought of. Have you ever talked to a C++ programmer about what they think of D, and why they don't use it? Also, I must say that although D is often discussed as a "systems programming language", I also have high hopes for it as an application programming language. Once it's more widely supported, it can significantly lower the barrier-of-entry for programming. People naturally gifted at programming probably don't realize how ridiculously high the barrier of entry is for most people, even those who are interested. I hope that Walter and Andrei give a proper response to this thread. I wonder why they haven't.
Re: Isn't it about time for D3?
On Thursday, 15 June 2017 at 18:02:54 UTC, Moritz Maxeiner wrote: We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII). Not sure what exactly you are expecting, tbh. I'm not advocating for a language change here. As I said, we already have some deterministic destruction (the rest being the GC). Why are you even talking about the GC when your problem seems to require deterministic lifetime management. That's not what a GC does, and thus it's the wrong tool for the job. I don't have a programming problem ; I'm fine with unique and scoped! I just wanted to make a point about how even GC-languages still benefit from some extra automatic and deterministic means of resource management.
Re: Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along. Of course discussing which modules should be obsoleted is a tricky question. I just got done with watching this great presentation by Rich Hickey[1]. It's about change, how semantic versioning is broken, and why packages are wrong when it comes to dependencies. In essence he is saying we should have immutable code releases. For example he would say that we should add a new namespace and not get rid of the original (std2.io, std2.xml, std2.json) now you can get your improvements out and not break anyone's code, for example he would say old modules would be deprecated but never removed. I don't agree 100% with him but he does make good points. Really what I'm hearing out of it is that these semantic versioned packages should all be accessible from your code, when you upgrade the package you don't automatically start calling the new version of the functions but instead get access to those functions along with all the previous releases. But that is a lot of extra information to add to every function call: @Package(arg, 1.4.2) foo(string i, int s) ... 1. https://www.youtube.com/watch?v=oyLBGkS5ICk=youtu.be
Re: Isn't it about time for D3?
On Thursday, 15 June 2017 at 17:06:31 UTC, Sebastien Alaiwan
wrote:
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
Should D really move to GC-free? I think there is already
enough GC-free language on the market. D even now is very
complected language, and adding ways to manually managing
memory will make it's more complicated.
We need automatic deterministic destruction (and we partially
have it, using scope(exit) and structs RAII).
Not sure what exactly you are expecting, tbh. If you expect
classes to be changed to behave like structs with regards to
finalization: That can't happen, because they are reference
types, not value types:
The lifetime of value type objects is statically known to end at
their enclosing scope (unless they are moved), in contrast to
reference types.
Memory management is only the tip of the iceberg of resource
management ;it's the easy problem, where an automated process
can to tell which resources aren't needed any more.
However, an instance of a class can hold a lot more than flat
memory blocks: threads, file handles, on-disk files,
system-wide events, sockets, mutexes, etc.
All of which you can easily take care of in the class' destructor
and then .destroy such objects when needed.
Freeing the memory of my "TcpServer" instance is mostly useless
if I can't reinstanciate a new one because the TCP port is kept
open by the freed instance (whose destructor won't be run by
the GC).
*might not be run by the GC when you want it to.
Why are you even talking about the GC when your problem seems to
require deterministic lifetime management. That's not what a GC
does, and thus it's the wrong tool for the job.
The right tool here would be one of
- std.experimental.allocator.{make,dispose} (statically known
lifetime)
- {std.typecons / automem}.RefCounted (dynamic lifetime)
Re: Isn't it about time for D3?
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote: Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated. We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII). Memory management is only the tip of the iceberg of resource management ; it's the easy problem, where an automated process can to tell which resources aren't needed any more. However, an instance of a class can hold a lot more than flat memory blocks: threads, file handles, on-disk files, system-wide events, sockets, mutexes, etc. Freeing the memory of my "TcpServer" instance is mostly useless if I can't reinstanciate a new one because the TCP port is kept open by the freed instance (whose destructor won't be run by the GC).
Re: Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote: I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along. Of course discussing which modules should be obsoleted is a tricky question. std.signals std.xml std.outbuffer std.socket std.json // maybe ;) I do not at all agree that a big language change is needed. We just changed the lookup rules with http://dlang.org/changelog/2.071.0.html and managed to make this a transition instead of a break. Also without a proposed feature list this discussion is somewhat lame. Let's do this! https://github.com/dlang/phobos/pull/5488
Re: Isn't it about time for D3?
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote: Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated. A lot of people need more powerful static-typing alternative to Python/C# for common tasks that allow to build stand-alone executable files. I think it's bad idea to mix to paradigms. People who do not need GC at all already use Rust. Actually, D already supports GC-Free / manual memory management. https://dlang.org/phobos/std_experimental_allocator.html + @nogc = manual memory management The issue is that the std library is still full of GC parts and so is third party software. But you can simply turn functions and classes that do not use the library / 3th party software into pure nogc parts. Think of it more as a hybridize system. I think there is somebody here who was writing a non-gc library for D.
Re: Isn't it about time for D3?
Should D really move to GC-free? I think there is already enough GC-free language on the market. D even now is very complected language, and adding ways to manually managing memory will make it's more complicated. A lot of people need more powerful static-typing alternative to Python/C# for common tasks that allow to build stand-alone executable files. I think it's bad idea to mix to paradigms. People who do not need GC at all already use Rust.
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 22:01:38 UTC, bachmeier wrote: It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers, like Python, can be less conservative about breaking changes and not have it disrupt the ecosystem. Yes, on the other hand, if you reach a stable version and stop adding features then you can focus on and reach maturity... Then leave the new features to the unstable version. If you keep adding features to a stable branch then maturity is perpetually out of reach. I think Go gained a lot of ground from focusing on maturity over features.
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote: * immutable by default I have to admit I always get confused why people get so invested in this. It seems like you would have to completely redesign everything related to std.range/std.algorithm.
Re: Isn't it about time for D3?
Moritz Maxeiner wrote: Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes. exactly my feelings! ;-)
Re: Isn't it about time for D3?
On Thursday, 15 June 2017 at 07:32:42 UTC, Russel Winder wrote: The GC is the single major factor for D in a world of C++17, Rust, and Go: An opinion. Mine is this: The two major factors for D are (and have been for as long as I've been using it): 1. Productivity (i.e. focusing on writing actual problem solving code, not on dealing with language deficiencies) 2. Maintainability (i.e. still have that productive code look reasonable easy to understand a year from now without having to look up language deficiencies to understand why something *has* to look exactly the way it does, or introduce bugs) The GC is nice in that it contributes to both of these points (and I have no desire to see it removed), but even without it there is no other native language (that I've tried as of yet) that comes even remotely close. without the GC there is little point in using D since C++, Rust, and Go have much more resources for development of tools as much as of the language – cf. CLion, Gogland, IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs. Still an opinion, so here is mine again (based merely on personal experience): Despite all those resources, someone having invested about the same amount of time in mastering C++(17), Rust, Go, and D will still end up being more productive in D, simply because, out of all of these languages, you have to fight D to do what you want the least. Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes.
Re: Isn't it about time for D3?
Wulfklaue wrote: On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote: yeah. D should silently miscompile old code too: it seems that this is exactly what people want! Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this. we were talking about broken C code. that was a joke about what C commitee did with it's "UB" defintion, and allowing compilers to act as if code never ever can have "UB" in it.
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote: yeah. D should silently miscompile old code too: it seems that this is exactly what people want! Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this. There is a difference between changes that: - Fix bugs - Fix security issues And changes like - Rewritten Library functions where those function calls end up working differently - Removal of the Garbage collector ( and introducing ownership / lifetime and other rules ) - Changes that make tools not work anymore - ... It is this second part people worry about. If i need to fix code issues 5 years from now because the compiler got smarter, so be it. This will happen anyway with each progressive bugfix / recompile. But there is a difference if massive rewrites are done on the language or libraries for that benefit only a few specific people there own usage. So please keep this topic on track and not pull any straw man argumentation's. Its the internet and i know that some people like to win arguments with any means necessary but keep facts alive thank you very much. I see nothing new being added to this topic anymore beyond more and more ridiculous claims.
Re: Isn't it about time for D3?
On Wed, 2017-06-14 at 21:55 +, bachmeier via Digitalmars-d wrote: > […] > > I'm not saying all old code should compile without changes, just > that it should compile with only minor changes. I know that in > some cases new releases of DMD have stopped compiling pieces of > my code that shouldn't have compiled in the first place, and > that's a good thing. On the other hand, dropping the GC would be > a dramatic change that would require a complete rewrite. > Libraries have to work with future versions of the compiler, > especially if others are using them and can't make changes > themselves. If D dropped the GC, then there wouldn't be a problem because there wouldn't be any users. The GC is the single major factor for D in a world of C++17, Rust, and Go: without the GC there is little point in using D since C++, Rust, and Go have much more resources for development of tools as much as of the language – cf. CLion, Gogland, IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 20:35:15 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable... So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7... It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers, like Python, can be less conservative about breaking changes and not have it disrupt the ecosystem.
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: On Wed, 2017-06-14 at 11:57 +, bachmeier via Digitalmars-d wrote: […] I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now. I suggest this is the wrong view of backward compatibility. If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong. If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I'm not saying all old code should compile without changes, just that it should compile with only minor changes. I know that in some cases new releases of DMD have stopped compiling pieces of my code that shouldn't have compiled in the first place, and that's a good thing. On the other hand, dropping the GC would be a dramatic change that would require a complete rewrite. Libraries have to work with future versions of the compiler, especially if others are using them and can't make changes themselves.
Re: Isn't it about time for D3?
H. S. Teoh wrote: On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote: Ola Fosheim Grøstad wrote: On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" at least C doesn't: almost all old-enough code is broken by various "UB". The difference is that unlike D deprecations, the C code will still compile and appear to work (for the most part, anyway), thus giving people the illusion that their old code is still "OK". When actually, the compiler may have done something unexpected with the UBs and thus inadvertently introduced security holes. Of course, none of this matters, since when was the last time bad C code has caused security problems? :-P yeah. D should silently miscompile old code too: it seems that this is exactly what people want!
Re: Isn't it about time for D3?
On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote: > Ola Fosheim Grøstad wrote: > > > On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: > > > If a code is to be left untouched but the compiler not archived > > > then the code must be recompiled and amended as needed with each > > > new compiler that is accepted in the workflow. > > > > I don't disagree with the general sentiment than one have to evolve > > the codebase along with the tooling, but if C, C++, Python and > > JavaScript didn't provide backwards compatibility in their > > maintained "production lines" > > at least C doesn't: almost all old-enough code is broken by various > "UB". The difference is that unlike D deprecations, the C code will still compile and appear to work (for the most part, anyway), thus giving people the illusion that their old code is still "OK". When actually, the compiler may have done something unexpected with the UBs and thus inadvertently introduced security holes. Of course, none of this matters, since when was the last time bad C code has caused security problems? :-P T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: Isn't it about time for D3?
Ola Fosheim Grøstad wrote: On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" at least C doesn't: almost all old-enough code is broken by various "UB".
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable... So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7...
Re: Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On 2017-06-14 11:38, Martin Nowak wrote: Also without a proposed feature list this discussion is somewhat lame. You only need one, AST macros ;) -- /Jacob Carlborg
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
* Rust is probably the best, but it doesn't have the modeling
power of D and C++.
A lot of the points you mention, i also agree with but
implementing that list is akin to writing a new language. You do
not trow out the baby with the bathwater ;)
From what i am reading, you want D to be Rust. Personally, Rust
make me want to tear out my eyes the moment you start with
lifetimes, unwrapping and ownership all combined , its becomes
almost unreadable.
fn the_longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() > s2.len() { s1 } else { s2 }
}
Rust really skips on the syntactic sugar *lol*.
If people want a low level language for microprocessors/plc, well
they already got C++14/17 and Rust. D can carve its own market
segment no? Why complicate D for one specific market segment?
There are defiantly nice point that you mention but dropping
C/C++ support is like a dead sentence. D does not have the
manpower and libraries that people may need.
Re: Isn't it about time for D3?
On Wed, 2017-06-14 at 11:57 +, bachmeier via Digitalmars-d wrote: > […] > I've been using D for four years. I can still compile code that > compiled with DMD at that time, with only a few minor > modifications. I expect to be able to do the same four years from > now. I suggest this is the wrong view of backward compatibility. If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong. If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I think it's about time for D3 to start developing.
I would love to see a fork of D2 that attempts to address some
obstacles I encountered when I was using D. However, it is quite
apparent that there is little to no interest in such a venture
from those in the D community with the talent to actually do it.
And I have to admit there is still room for innovation in D2, and
that seems to be where most want to allocate their limited
resources.
For D3 to happen, it will likely require talent outside D's core
team.
I do a lot of programming in different domains, and it seems I
have to use a different language for each one in order to be
productive. I would like to find a single language that I can use
to program just about any domain, but still be able to enjoy
modern features for safety, convenience, zero-cost abstractions,
and modeling power. I'm not aware of any language that fits that
description, but the languages I've found to be somewhat close
are C++11~17 and Rust. They're the only ones that appear to be
scalable down to domains such as resource constrained
microcontrollers.
* Using D for resource constrained systems requires too many
compromises and silly runtime hackery.
* C++11~17 is quite good but it is not at all convenient, and
safety is just too easy to get wrong.
* Rust is probably the best, but it doesn't have the modeling
power of D and C++.
It'd be more constructive to begin collecting information from
the community about what changes they'd like to see in D3.
Here's a start from things just off the top of my head and in no
particular order.
THINGS TO CHANGE OR ADD
---
* Final-by-default
* immutable by default
* @safe by default
* Fix attribute inconsistency and revisit if D is using the
appropriate defaults
* Pay as you go druntime.
The compiler is too coupled to druntime and expects things to be
there even though they're not required. This would also make D a
better language for replacing much of the exising infrastructure
code out there that is currently written in C because it wouldn't
require the D runtime dependency and all the overhead that goes
with it. Rust has done well in this regard.
* Minimal druntime
The language should be easy to port to other platforms. Keep
druntime small and to a few fundamental primitives to whatever
extent that is possible. Rust has also done well in this regard.
* Compiler resolves druntime symbols at compile time.
This is important for porting D to other platforms that may not
have the resources or hardware to support certain features of the
language. The compiler would emit a compile-time error if usage
of such a feature was attempted, but not supported by the
runtime. Proposed here [1].
* Some way to mark memory at compile-time with certain attributes
(e.g. See [2]) to inform the compiler of proper code generation
(e.g. volatile semantics). This would probably only be useful
for bare-metal programming, but I encounter this all the time and
its getting worse with each new MCU generation.
* Remove the "module must be a file" arbitrary limitation
I ran into this when I was trying to model hundreds of
memory-mapped IO registers. I wanted to use a module for each
register, but each module would only have a small amount of code,
and I would have ended up with hundreds of little files. It
would have been better if I could group all "register" modules
for a given peripheral under one "peripheral.d" package file.
Something like `package UART { module SR {} module DR{} }` would
have been nice. I ultimately ended up with `final abstract class
{}` instead, which is stupid.
* get rid of the "_t" suffix added to types from C.
Come up with a better, more consistent naming convention for
these types that doesn't carry baggage from other languages.
* Drop the GC or at a minimum make it opt-in. Add a borrow
checker, automatic reference counting, or some other GC
alternative that doesn't require a separate thread.
DIP1000 is interesting and may enable some new interesting
patterns and idioms. Might be able to take some inspiration from
it. I wonder if DIP1000 would have been more elegant if D didn't
have to worry about breaking code.
* The C standard library bindings and C++ standard library
bindings should be in Deimos not in the druntime.
I already tried to promote this, but only encountered obstruction.
* Cure the TypeInfo infection [3]
TypeInfo has been over(ab)used in the runtime implementation.
This is probably due to historical baggage, but also a lack of
discipline.
THINGS TO KEEP
--
* CTFE
* Templates and static-if (static-if is some powerful stuff!)
* Mixins (or some other way to do convenient composition)
I get that one should favor composition over inheritance, but
most object oriented languages offer prec
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 11:34:09 UTC, Wulfklaue wrote: Just changing the library to D3 and not the base D name will result in people finding old code, not getting it to work, getting frustrated and simply ignoring the language. Hey, despite loving the syntax, did the exact same thing with Swift. With D i can find 3 or 4 year old code and get it running something without a single issue. Or a quick fix. Just saying, its not just about the language and library features. it also about what is round the language. The examples and code out there, the packages, the editors and other support. D3 isn't going to happen. I ignored this thread as a result. I only read the most recent posts because I wanted to see why it hadn't died. I doubt that Phobos 2 will happen either. All comments I've read from Walter and Andrei indicate that there are no plans for either. I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now.
Re: Isn't it about time for D3?
On Wednesday, 14 June 2017 at 09:18:58 UTC, Jonathan M Davis wrote: If you're maintaining your code and making the occasional, required adjustments when the language or library changes something that requires adjustments, then you should be just fine without having to do massive code rewrites or anything like that (and at this point, breaking changes normally involve a deprecation process so that they don't just force you to immediately change your code). That is my point exactly. I have nothing against evolving a language slowly over time to include more features. A few things get obsolete, ... no big issue. New options are added. Again. No big issue. But the moment a language opens up for developers their "wishlist", it seems everybody wants "their" changes added to the language. And this then turn into a language that is constantly changing. That is consider more the worst case scenario. Frankly, if things are handled in a evolutionary way, then i do not have a issue with it. As long as thing do not turn out into: "well, x percentage of your code just become useless". ;) The main issue is library vs existing code. There is a lot of code out there that is now abandoned but still (mostly) works. The moment the evolution gets too far, your starting to get more and more code out there that simple does not work. In my personal opinion, if you want to pull something like that, then make a totally complete clean break. Change the language name ... And yes it sounds radical and silly but if there is one frustrating point that people have new to a language, is legacy non-functional code. I can right now look up Swift examples and get over 50% that simply do not work because the language evolved so fast and everybody used the name "Swift", not "Swift 1.0", "Swift 2.0"... Its frankly a mess. And while i personally love some of the features that Swift has, its a mess for anything outside of the pure Apple development. Just putting the cards on the table but frankly D is a generic name ( Mars was not much better ). When Googling for D code, the results are hit or miss. When Googling for Dlang, it tries to search on GoLang. Marketing is hard when your product is so generic named ( double pun is intended ) :) Just changing the library to D3 and not the base D name will result in people finding old code, not getting it to work, getting frustrated and simply ignoring the language. Hey, despite loving the syntax, did the exact same thing with Swift. With D i can find 3 or 4 year old code and get it running something without a single issue. Or a quick fix. Just saying, its not just about the language and library features. it also about what is round the language. The examples and code out there, the packages, the editors and other support.
Deprecating phobos modules [was: Re: Isn't it about time for D3?]
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along. Of course discussing which modules should be obsoleted is a tricky question. std.signals std.xml std.outbuffer std.socket std.json // maybe ;) I do not at all agree that a big language change is needed. We just changed the lookup rules with http://dlang.org/changelog/2.071.0.html and managed to make this a transition instead of a break. Also without a proposed feature list this discussion is somewhat lame.
Re: Isn't it about time for D3?
On Wednesday, June 14, 2017 07:28:34 Wulfklaue via Digitalmars-d wrote: > Unless i am wrong there seem to be only one or two people > actually pushing this D3 idea... It comes up periodically, because there's some change that someone wants that will never make it into D2. Historically, it's the response to most anyone being told that what they want won't make it into D2, and actually, it used to come up quite a bit, but it rarely comes up now. Sure, there are some changes that we'd probably make to the language if we were doing things from scratch or willing to just break every existing D program, but I think that you'd have a hard time getting folks to agree on a list of what would be changed under those circumstances, and for the most part, I think that folks will agree that it's not worth it at this point - certainly, I think that you're going to have a hard time finding any core contributors who think that starting D3 would be a good idea at this point. And I'd be shocked if anyone managed to convince Walter or Andrei that it was a good idea. Now, there are changes in Phobos which a number of us would like to see that you'll see a much greater consensus on, some of which aren't likely to be possible without breaking a lot of code (most notably, the fact that strings auto-decode to ranges of dchar), which is part of why there was a recent discussion on creating a new version of Phobos that would eventually replace the one that we have now ( http://forum.dlang.org/post/volmdaxjihbkpbtpl...@forum.dlang.org ), but even that discussion didn't exactly gain much traction, and changes that require massive breakage in Phobos are unlikely to happen, even if we'd very much like those changes, precisely because they'd cause massive breakage. It's still possible to make changes in the language and standard library without breaking everyone's code, and there's still plenty of room to make some changes which are breaking changes if they bring enough value, but there's a much greater focus on stability and avoiding code breakage than there used to be, and having the massive breakage of redoing the standard library or moving on to a new version of the language really doesn't fit in with that. And we can do quite a lot in place without such massive breakage. However, some folks are always looking for massive changes in the search of making the language perfect. So, there will likely always be occasional talk of moving on to D3, even if it is unlikely to be on the table any time soon, if ever. That being said, if you're expecting to be able to write D code and then have it compile 10 years from now with whatever the current compiler is at that time, you're likely to be disappointed. We're targetting stability, and we're better at managing change than we once were, but there are still occasional changes to the language, and even if the standard library is not undergoing massive churn, it does change somewhat over time. If you're maintaining your code and making the occasional, required adjustments when the language or library changes something that requires adjustments, then you should be just fine without having to do massive code rewrites or anything like that (and at this point, breaking changes normally involve a deprecation process so that they don't just force you to immediately change your code). But if you write your code now and try and compile it in a few years without maintaining it in the interim, then you're likely to have at least some code which won't compile anymore. - Jonathan M Davis
Re: Isn't it about time for D3?
Wulfklaue wrote: On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote: Patrick Schluter wrote: the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it). Can you actually show us examples of what you think needs to break? it would be a very long post. ;-) i scratched it a little above, though. my private dmd fork has 100+ patches only to dmd itself, for example, and some are disruptive enough that alot of my code is marked with `module a is aliced;`. Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read. and one of mine reasons was "yay, it is relatively new, unencumbered with alot of legacy, and *evolving*!" none of it (our reasoning) is better over another. ;-) D its flaws are the Phobos documentation layout one of the things i absolutely don't care about, for example. ;-) besides, dpldocs rox. So call me confused as to what is missing and needs such radical changes? evolving. something very opposite to "stability", as expected by some enterprise users. remember, not all D users are enterprise users. ;-) some of us (me!) came here 'cause D is fun, not 'cause D is "stable", and we may value stability much less than other kinds of users. Unless i am wrong there seem to be only one or two people actually pushing this D3 idea... as for me, i'm not "pushing" it, i am merely "supporting" it. just to make sure that other optinions besides "no, we don't need D3" are not seeing as non-existant only due to their bearers being silent. ;-)
Re: Isn't it about time for D3?
On 14/06/2017 8:28 AM, Wulfklaue wrote: On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote: Patrick Schluter wrote: the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it). Can you actually show us examples of what you think needs to break? Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong. Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ). Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read. D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers. So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language. Unless i am wrong there seem to be only one or two people actually pushing this D3 idea... Don't worry too much about "D3". While I also want a "D3" it won't be a big technical change, much more likely a philosophical change than anything else. In other words, except for the odd change like final by default for classes(eww), there isn't anything that needs to change for D2. Only smaller improvements which are well worth breaking current semantics.
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote: Patrick Schluter wrote: the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it). Can you actually show us examples of what you think needs to break? Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong. Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ). Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read. D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers. So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language. Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote: Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution? I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment. D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach. +1 Does anyone currently maintain somewhere such a list of not-gonna-be-fixed-in-D2 defects? This might provide more solid grounds to this discussion.
Re: Isn't it about time for D3?
crimaniak wrote:
If it depended on me, I would declare an embargo on language changes
that's why we (me, and others like me ;-) need D3. i don't need "better
phobos", for example ('cause i'm trying to aboid using phobos anyway), but
i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be
usable for any method/free function, not only for lambdas. i want $-expands
in mixin strings. warnings on unary minus on byte/short types (do you know
that D doesn't do int promition in this case, and C does? it bites me
several times!). i want `foreach_reverse` to be replaced with `foreach
(auto a; b; reverse)` (and *require* type, modifier or `auto` there). i
want optional `ref` and `out` marks for function *calls*. i want... i want
alot of things, i'm not even started yet. especially not started to talk
about breaking changes. i cannot do that now (i have my private fork of
dmd), 'cause i need to keep compatibility with vanilla, and i have zero
hopes to see it all introduced in D2 (language stability, etc.). with D2,
i'll have a chance to bring 'em on a table.
Re: Isn't it about time for D3?
Patrick Schluter wrote: Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution? I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment. D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach. the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).
Re: Isn't it about time for D3?
jmh530 wrote: Nevertheless, C++ is still a constantly evolving language. one of the key features of evolution is removing old and rudimentary things. without this, it is not evolution, it is mutilation...
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote: I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment. I have the same opinion. Raw libraries, poor documentation and infrastructure are much more problematic. If it depended on me, I would declare an embargo on language changes and throw all the forces to eliminate the problems of infrastructure and libraries.
Re: Isn't it about time for D3?
Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution? I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment. D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach.
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 13:29:45 UTC, jmh530 wrote: Companies clearly value C++'s backwards compatibility. However, if there's one lesson from the D1/D2 or the Python 2/Python 3 split, it's that it's hugely disruptive (so much so that I find The D1/D2 split was actually a unifier. It was the Phobos/Tango divide that was the problem. D2 healed that rift, brought us a single runtime that both libraries could share, improved Phobos, and was relatively easy for most projects to transition to (Sociomantic's experience was not common), and D1 was eventually retired. We're all better off for it. A vastly different situation than what happened with Python, where you find 2.x releases continuing on and some projects requiring one or the other. That said, at this stage, I can't imagine a D2/D3 transition being anything other than negatively disruptive.
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 12:23:19 UTC, ketmar wrote: Sebastien Alaiwan wrote: My point precisely was that "not splitting D1/D2" might correspond to "doing things right". "not splitting" here means "we're stuck with D1". deprecation cycle of several years (not counting the time required to actually *start* the process) means "no evolution". i must make myself clear here, i guess: i value "good language" way more than "stable language". i absolutely don't mind fixing my code if it makes it better/more clear/etc. while it's hard to sell "constantly evolving" language to Big Enterprise Wheels, not making breaking changes means cloning worst C++ feature. ;-) Companies clearly value C++'s backwards compatibility. However, if there's one lesson from the D1/D2 or the Python 2/Python 3 split, it's that it's hugely disruptive (so much so that I find the idea of D3, at the moment, to be such an obviously terrible idea that I really wanted to avoid commenting on this thread). Nevertheless, C++ is still a constantly evolving language. C++14 looks a lot different from C++98. Maintaining backwards compatibility, however, has significantly increased the complexity. Thus, I think there's a trade-off. Breaking changes that improve the language may be good in certain circumstances, but Walter/Andrei should try to get the buy-in from big D users beforehand (even with a depreciation cycle). Requiring some kind of broad support from big D users would mean that breaking changes only happen if the the costs of breaking changes are smaller than the improvement to the language.
Re: Isn't it about time for D3?
Sebastien Alaiwan wrote: My point precisely was that "not splitting D1/D2" might correspond to "doing things right". "not splitting" here means "we're stuck with D1". deprecation cycle of several years (not counting the time required to actually *start* the process) means "no evolution". i must make myself clear here, i guess: i value "good language" way more than "stable language". i absolutely don't mind fixing my code if it makes it better/more clear/etc. while it's hard to sell "constantly evolving" language to Big Enterprise Wheels, not making breaking changes means cloning worst C++ feature. ;-)
Re: Isn't it about time for D3?
On Tuesday, 13 June 2017 at 06:56:14 UTC, ketmar wrote: Sebastien Alaiwan wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens. Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split? this question has no answer. can we do better if we will do everything right on the first try? of course! My point precisely was that "not splitting D1/D2" might correspond to "doing things right".
Re: Isn't it about time for D3?
Sebastien Alaiwan wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens. Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split? this question has no answer. can we do better if we will do everything right on the first try? of course!
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens. Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split?
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. [...] I anyone seeing the "i think" "I think"...statements? It's not something "you know". He doesn't mention "his" problem with GC. I would like to know
Re: Isn't it about time for D3?
solidstate1991 wrote: E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). and there were several "D"s too. ;-) There were already a few changes in the language (use of static imports instead of directly accessing functions/libraries, etc), just as we're adding to the language, we can remove rarely used functions by first making them deprecated, then removing them altogether as time passes on. sometimes it is hard or even impossible to change something and keep old feature still working. it also require considerably more efforts to support old and new feature set simultaneously. while D2 can continue evolving (and it surely will!), having D3, where keeping old code working is not a concern, can be useful. nobody says that we should abandon D2 tomorrow and switch everything to D3. it's more about exploring new ways without constant pressure of "don't break the code" mantra. don't get me wrong, tho: "don't break the code" is good. but it limits possible ways D can evolve (or greatly slows it all down). D3 can be "experimental research project", where some of the dreams can come true. it may won't even reach the state where it will replace D2, instead D2 may adopt some D3 features, and D3 will be scrapped (or restarted). there is nothing wrong with it. also, i don't expect D3 to be developed in "full speed" too.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 22:53:44 UTC, ketmar wrote: so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, nothing fatal happens. backing fear of changes with "last time it almost destroyed us" won't do any good in the long term: it will ultimately end with having no changes at all, D will stagnate and die. changing is a natural thing for evolution, even breaking change. evaluating was what done wrong/inoptimal, and improving on that it the thing that will keep D not only alive, but will make it better and better. otherwise, accumulated legacy will inevitably turn D into another C++, and somebody will create E (or something ;-). why don't create E outselves, and call it D3 instead? E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). There were already a few changes in the language (use of static imports instead of directly accessing functions/libraries, etc), just as we're adding to the language, we can remove rarely used functions by first making them deprecated, then removing them altogether as time passes on.
Re: Isn't it about time for D3?
Guillaume Piolat wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens. https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright=Search so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, nothing fatal happens. backing fear of changes with "last time it almost destroyed us" won't do any good in the long term: it will ultimately end with having no changes at all, D will stagnate and die. changing is a natural thing for evolution, even breaking change. evaluating was what done wrong/inoptimal, and improving on that it the thing that will keep D not only alive, but will make it better and better. otherwise, accumulated legacy will inevitably turn D into another C++, and somebody will create E (or something ;-). why don't create E outselves, and call it D3 instead?
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens. https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright=Search
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes. I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to. But they must happen once in a while for things to advance. I think it's about time for D3 to start developing. So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes. It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization. https://wiki.dlang.org/Language_design_discussions I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it. In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions. While I do think that's excessively frequent, there are still users of Lua 5.1. Making D3 doesn't mean that D2 has to die. I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. Here are some ways that D3 can be an improvement of D2: -Final by default -A standard library that is effective with or without garbage collection Even Andrei has admitted some issues with D when answering this Quora question: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later. D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before. I think we just should do those little fixes on D2 (eg. fixing the standard library, DIP45), instead of yet again reinventing the wheel. We have limited resources, I think first and foremost we should port the backend from C to D to further improve our productivity on the main compiler, then bugfixes and implementing non-x86 targets will be much easier.
Re: Isn't it about time for D3?
Mike B Johnson wrote: On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote: Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle. Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time). yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-) It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be. yeah. i don't have enough energy to keep a *real* fight going, but i at least poping up with my "experimental forum" idea from time to time. i'm in no hurry, and i'm sure that slow, but constant efforts will won the battle. 10 years, 100 years, 1000 years... as i said, i'm in no hurry at all. ;-)
Re: Isn't it about time for D3?
Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
Re: Isn't it about time for D3?
Ola Fosheim Grøstad wrote: On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote: and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we D--? Out of curiosity; wouldn't it be better to start with one of the alternative compilers that are being worked on (SDC or others), or are they no longer active? to remove features, it is nice to *have* those features first. and there are no other feature-complete frontends besides dmdfe.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote: and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we D--? Out of curiosity; wouldn't it be better to start with one of the alternative compilers that are being worked on (SDC or others), or are they no longer active?
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu wrote: On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei Found it: the paper I linked focuses more on webkit, the case of firefox is detailed in a previous paper [1]. They did choose to focus on core developers defining them as having proposed 100+ patches. This point of the methodology is explained in more details in section IV of the paper. [1]: https://plg.uwaterloo.ca/~migod/papers/2012/wcre12-olgaAlexReid.pdf
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu wrote: On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei I'm not certain either. For Webkit they took all patches without discriminating by origin so I think they did the same for Firefox. The development plateform is public so it would be more work to filter commits, therefore I don't think they did.
Re: Isn't it about time for D3?
On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it. sorry, i was overreading those lines of yours
Re: Isn't it about time for D3?
in my opinion starting with D3 is too early, because D-people dont even seem to know how exactly to implement new exciting features like "reference counting" (and how will "reference counting" work together with the new "scope"-feature?). So, if a D3 gets developed _now_, i guess the compiler developers will create syntax issues again for those features and then we need a D4. Instead it might be better to collect more experience before thinking about D3
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote: Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle. Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time). yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-) It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:22:50 UTC, Adam D. Ruppe wrote: On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote: Dev resources are stretched thin as it is, I doubt the core team would go for it. I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage. Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Analysis of the reviews shows that the developper himself often comes back to his patch to correct it before resubmitting it. Such corrections often are due to style because style isn't generally blocking. That said, having worked on Firefox's codebase a fair amount of time I must say that they have one of the cleanest C++ codebase I've ever seen. The whitepaper is here [1], named "The influence of non-technical factors on code review". I strongly recommend reading it, especially for you Walter and Andrei as I think you might like some of its insights. There again we are not Mozilla, Phobos is a standard library, a compiler doesn't release every 3 months. But one thing is sure, if Firefox can accept 82% of patches at first sight, if 60% of all patches end up being integrated without resubmission, then the projet size isn't an issue. And before such evidence I am definitely not convinced that it should be hard to introduce a change. What should be hard is introducing a bad one. (Then again I'm all talk and not wanting to take care of the matter myself so I'm not expecting anything to change just from this post.) [1]: https://cs.uwaterloo.ca/~rtholmes/papers/wcre_2013_baysal.pdf
Re: Isn't it about time for D3?
Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle. Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time). yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)
Re: Isn't it about time for D3?
Seb wrote: On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote: Adam D. Ruppe wrote: I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage. +1 actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented. That's called a feature-branch ;-) not everybody in the world is github-centric.
Re: Isn't it about time for D3?
Liam McGillivray wrote: On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote: ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language). D1.5? What? This has nothing to do with D1. and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we have D1, then D2, and the newest version is D1.5. people will blog/tweet this, for sure. free PR!
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 05:03:10 UTC, Suliman wrote: There is already something like D3 exists. https://github.com/VoltLang https://github.com/VoltLang/Watt/blob/97507a202250af96560317f84c29cb2248ae588b/src/watt/algorithm.volt#L37-L91 I don't think so.
Re: Isn't it about time for D3?
There is already something like D3 exists. https://github.com/VoltLang
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I realize that there are people who want to continue using D as
it is, but those people may continue to use D2. Putting the
breaking changes in a separate branch ensures that DM won't
lose current clients as they can just continue using D2 as they
are. Even after D3 is stabilized, D2 could have continued
support until nobody wants it.
Here is my suggestion for how to migrate into D3 well, if it were
to be done:
First define a "Small D2". The goal of this language is to not
really be that much smaller(it could still leave in most of the
language, in fact), but to sweep up all the changes breaking with
D2 into a form that's clearly less flexible while still being
palatable for the majority of modules. It's allowed to be
intentionally clumsy and regressive in some ways so that it can
be forward-looking later, but not so much so that people don't
want to write in it.
Small D2 is given the freedom to do things like regress standard
library functions back into hardcoded compiler behaviors, to be
more restrictive, to allow less ambiguity, and to generally
follow with existing idioms but break the things that needed
breaking and leave out the parts that didn't work. The new stuff
of Small D2 would be "one-trick-pony" features that bottleneck
what can be expressed into a "library" that is actually a
compiler hack, or "new syntax" that is actually fake and only
allows arbitrary expressions that are already possible in other
ways.
Most importantly, Small D2 retains compatibility with regular
("big") D2 modules, so codebases can be migrated into Small D2
piecemeal, while leaving a small remainder to be migrated in a
larger way when D3 rolls out. In essence, Small D2 allows the
underlying formulation of D to be challenged, but it actually
relies on regular D2 constructs internally, so iteration on
design can go faster than if we "did it for real". And because
Small D2 gives people a taste of new stuff, it will have some
instant appeal: People should want to write new code in it, even
knowing that it's a hack and less powerful.
Small D2 would be the debate platform for what the "core" of D
is. Then, D3 is Small D2 with everything "done for real" this
time. Small D2 code migrates forward seamlessly and can continue
operating as if nothing happened. The rest of it is considered
breaking.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote: ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language). D1.5? What? This has nothing to do with D1. D3 would be forked from D2. The reason that it would be considered a major version is because it introduces breaking changes. As far as I know, D2 hasn't been allowed breaking changes since stabilization June 2010.
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote: Adam D. Ruppe wrote: I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage. +1 actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented. That's called a feature-branch ;-) The nightlies and CI scripts fully support feature branches since a couple of months (i.e. the same branch is checked out on all dmd, druntime and phobos). Currently it's only used for `scope` and `newCTFE`: http://nightlies.dlang.org Currently not much is happening on these feature branches and thus Martin is running the builds on demand by hand. However, from a technical point of view, it would be rather easy to use this for more feature branches ;-)
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
Adam D. Ruppe wrote:
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
Dev resources are stretched thin as it is, I doubt the core
team would go for it.
I think dev resources are thin because of mismanagement by the
core team failing to attract and retain contributors. Part of
this mismanagement is a really discouraging attitude toward
positive yet breaking change; I propose that mere willingness
to shake up the status quo would help to solve the resource
shortage.
actually, some time ago i proposed to create "experimental and
breaking language changes" subforum, where people can go with
their wild ideas, and other people can post patches/builds with
those (or other) ideas imlemented/half-implemented.
this way we can gather some feedback from someone who is really
using new feature, and have a better vision if it worth further
time investments or not. 'cause having a live compiler with new
feature to play with is not the same as simply dicussing the
possible feature in NG. i maintain my private fork of
dmd/druntime/phobos, and this is the way i evaluate features:
just add what i can, and then see if i'll start using it in my
code. if not, the feature is cutted, otherwise it is retained.
and ah, building dmd from sources is not something many people
want/can to do. sure, downloading binaries from random people
over the net is not the safest thing to do, but if there will
be patch+binary combos, it may work.
i.e. i see that "experimental" subforum as a place for ideas
*and* implementations. and implementors can provide built
binaries for people to play, or other people can build binaries
('cause if you built it for yourself, why don't share it with
others?).
i know that this forum is actually a newsgroup, and it can't
host files. but i believe that this problem can be solved --
either by using some simple js-free (for download; yeah, there
are such things! ;-) service to host binaries, or by some other
means.
Yeah, sounds good, because to make progress, progress has to be
made. Most people are very shortsighted and live in a fear based
mentality. Mention any type of change and they nearly shit
themselves and never actually think about the consequence of
those changes. They just assume it means change and it's
something they can't handle.
Having an "experimental" D allows those crazy and potentially
"mind altering" advancements to be worked on, advanced, and
polished. It takes time for ideas to grow(because, ultimately, it
involves learning and learning takes time).
So, the good experimental changes will eventually be adopted.
Without such a mechanism, they can't EVER be. The problem is that
only the core people of D actually get to decide what is good and
they tend to push through changes that haven't been well
tested(regardless of what they think, D is a prime example by all
the miscalculations as is C).
Most people fear growth because growth requires change and change
ventures in to the unknown... The unknown is where all the good
shit lies and the breakthrough is when someone brings the unknown
in to the known.
Re: Isn't it about time for D3?
Adam D. Ruppe wrote:
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
Dev resources are stretched thin as it is, I doubt the core team would
go for it.
I think dev resources are thin because of mismanagement by the core team
failing to attract and retain contributors. Part of this mismanagement is
a really discouraging attitude toward positive yet breaking change; I
propose that mere willingness to shake up the status quo would help to
solve the resource shortage.
actually, some time ago i proposed to create "experimental and breaking
language changes" subforum, where people can go with their wild ideas, and
other people can post patches/builds with those (or other) ideas
imlemented/half-implemented.
this way we can gather some feedback from someone who is really using new
feature, and have a better vision if it worth further time investments or
not. 'cause having a live compiler with new feature to play with is not the
same as simply dicussing the possible feature in NG. i maintain my private
fork of dmd/druntime/phobos, and this is the way i evaluate features: just
add what i can, and then see if i'll start using it in my code. if not, the
feature is cutted, otherwise it is retained.
and ah, building dmd from sources is not something many people want/can to
do. sure, downloading binaries from random people over the net is not the
safest thing to do, but if there will be patch+binary combos, it may work.
i.e. i see that "experimental" subforum as a place for ideas *and*
implementations. and implementors can provide built binaries for people to
play, or other people can build binaries ('cause if you built it for
yourself, why don't share it with others?).
i know that this forum is actually a newsgroup, and it can't host files.
but i believe that this problem can be solved -- either by using some
simple js-free (for download; yeah, there are such things! ;-) service to
host binaries, or by some other means.
Re: Isn't it about time for D3?
Liam McGillivray wrote: I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language).
Re: Isn't it about time for D3?
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote: Dev resources are stretched thin as it is, I doubt the core team would go for it. I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes. I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to. But they must happen once in a while for things to advance. I think it's about time for D3 to start developing. So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes. It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization. https://wiki.dlang.org/Language_design_discussions I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it. In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions. While I do think that's excessively frequent, there are still users of Lua 5.1. Making D3 doesn't mean that D2 has to die. I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. Here are some ways that D3 can be an improvement of D2: -Final by default -A standard library that is effective with or without garbage collection Even Andrei has admitted some issues with D when answering this Quora question: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later. D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before. Dev resources are stretched thin as it is, I doubt the core team would go for it. For example, the vast majority of the work on the main compiler frontend in the last year was done by one person, 3-5 if you're being generous: https://github.com/dlang/dmd/graphs/contributors?from=2016-05-01=2017-06-10=c I think we need to build that team up before we consider branching again. While it has now been longer since the D2 branch than from the beginning to D2, I get the impression the core team is nowhere near finished with D2, to the point where they want to branch again. While I personally think a D3 branch now would make sense on the technical merits, I doubt we're at an organizational state where we can afford it, ie not enough manpower.
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I'd be fascinated by a revised D like language, say D3 or whatever. Here are some ways that D3 can be an improvement of D2: -Final by default Wow, after all that, this is it? I think final by default would be an improvement, and I wish it had gone through, but it's not a big enough deal to make a new language. -A standard library that is effective with or without garbage collection That's being worked on with D right now, isn't it? If you're not going to be very bold, what's the point of a D3? Let's really change stuff! Structs, enums, and pattern matching, like Rust and ML Type follows name like Ada, Scala, Rust, ... Macros like Nim Parallel features from Chapel I think it's a huge uphill battle for a new language these days, and that there's more to be gained from fixing the current D and others, but I encourage you to design the next D.
Re: Isn't it about time for D3?
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. [...] FYI: There also has been a recent debate about developing a new version of Phobos (http://forum.dlang.org/post/volmdaxjihbkpbtpl...@forum.dlang.org) to be able to get rid of auto-decoding, make everything work nicely with @nogc and allocators, fix design issues with ranges, cleanup messy packages (e.g. std.traits), etc. I think everyone on the forums here agrees about the problems, it's just not clear what the best course of action is as breaking changes are costly. Remember that there are still companies using D1 or Python 2 out there. OTOH many people representing companies have already vouched here that they would love to see the annoyances fixed and something these issues are even blockers for their official D use at work ...
Isn't it about time for D3?
D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes. I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to. But they must happen once in a while for things to advance. I think it's about time for D3 to start developing. So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes. It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization. https://wiki.dlang.org/Language_design_discussions I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it. In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions. While I do think that's excessively frequent, there are still users of Lua 5.1. Making D3 doesn't mean that D2 has to die. I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. Here are some ways that D3 can be an improvement of D2: -Final by default -A standard library that is effective with or without garbage collection Even Andrei has admitted some issues with D when answering this Quora question: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later. D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before.
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) How about D+ (v1 v2 etc) ? Only one plus, so D++ can be reserved for the next major version :)
Re: D3
I suggest to call it The D.
Re: D3
On Fri, 2014-12-12 at 07:40 +, thedeemon via Digitalmars-d wrote: On Tuesday, 9 December 2014 at 08:15:02 UTC, Puming wrote: For Chinese it would be 帝 which pronounces the same as 'D' and means Emperor. In Thai language ดี pronounces dee and means good. That just has to get into the official documentation! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: D3
On Tuesday, 9 December 2014 at 08:15:02 UTC, Puming wrote: For Chinese it would be 帝 which pronounces the same as 'D' and means Emperor. In Thai language ดี pronounces dee and means good.
Re: D3
On Wednesday, 10 December 2014 at 00:58:59 UTC, Chris Williams wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Powers of two are magic. Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up in the version numbering race and call the next one D11. Followed, naturally, by D100. ;) -Wyatt
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) That's DDD or D³, not D v3.
Re: D3
On Wednesday, 10 December 2014 at 13:55:22 UTC, Wyatt wrote: Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up in the version numbering race and call the next one D11. Followed, naturally, by D100. ;) Som alternatives: - Unary notation: D1, D11, D111, D… - Roman: DI, DII, DIII, DIV, DV, DVI, DVII… D=500, so DI would start off at version 501… Just like Levi's…
Re: D3
On Wed, Dec 10, 2014 at 03:35:36PM +, via Digitalmars-d wrote: On Wednesday, 10 December 2014 at 13:55:22 UTC, Wyatt wrote: Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up in the version numbering race and call the next one D11. Followed, naturally, by D100. ;) Som alternatives: - Unary notation: D1, D11, D111, D… - Roman: DI, DII, DIII, DIV, DV, DVI, DVII… D=500, so DI would start off at version 501… Just like Levi's… I find the obsession with small integers (aka version numbers) rather petty. We should start with some random number, like 49183029, and every subsequent release increment it by a random positive increment, TCP sequence number style. So the next version could be 50372948, then the following 59384729, then 73940121, etc.. Or perhaps the initial version should be Graham's number, and every following version is obtained by calling the Ackermann function on the previous version number. :-P That'll beat all competitors, for sure. T -- Doubt is a self-fulfilling prophecy.
