Re: What are the worst parts of D?
On 2014-09-24 08:57, Walter Bright wrote: Heck, the dmd release package build scripts break every single release cycle. The it's obviously doing something wrong. -- /Jacob Carlborg
Re: What are the worst parts of D?
On Tue, Sep 23, 2014 at 10:37:59PM -0700, Walter Bright via Digitalmars-d wrote: On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote: Yeah, I wish that at least *some* attention would be paid to refining existing features so that problematic corner cases could be ironed out. It's kinda maddening to hear statements like that. Just in 2.066: 103 compiler regressions fixed 235 compiler bugs fixed 39 language enhancements 12 phobos regressions fixed 110 phobos bugs fixed 41 phobos enhancements 9 druntime regressions fixed 17 druntime bugs fixed 9 druntime enhancements https://dlang.org/changelog.html#list2066 Like identifier lookup rules for local imports. Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else? No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on. Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code. And what to do about dtors. And so many little niggling details that seem minor, but added together, can form a pretty big mountain of frustration sometimes. So help out! I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. The situation with Phobos has improved dramatically, thanks to a well-timed rant some months ago, which triggered a coordinated effort of aggressive merging, pinging, reviewing, etc. -- we've managed to cut the Phobos PR queue from around 90+ to around 29 as of last night (from 4+ pages on github to only barely 2 pages). For that, I applaud my fellow Phobos reviewers, and I hope the trend will continue until the Phobos PR queue is firmly back at 1 page (=25 open PRs). Unfortunately, the problem persists in druntime, dlang.org, and dmd. It feels like there's a forest fire raging and only a handful of firefighters, and now we want to add more fires (new development directions) without adding more people. What about reviewing and merging / rejecting the 100+ PRs in the dmd queue, most of which contain fixes and language improvements that people have been waiting for, for a long time, before we think about new directions? Some PRs appear to fix bugs opened *years* ago, and yet nothing is done about them. Some PRs are at an impasse due to decisions that need to be made, yet nobody is making said decisions or even discussing them, and the PRs just continue to rot there. There are already a *ton* of new features / fixes / language improvements that are waiting to be decided upon (and, given the size of the dmd PR queue, I submit this is no exaggeration), and yet we are indifferent and instead look away to new directions. Many of us are indeed ready to help, but it would *really* be nice if our help is received more readily, or, at the very least, *some* indication is shown that more effort will be put into reviewing said help before more energy is expended in new directions. The dramatic shortening of the Phobos PR queue over the last 2-3 months proves that this is not only possible, but also beneficial (more fixes are making it into Phobos than ever before) and improves morale (people are more likely to contribute if they don't have to wait 3 weeks before getting any feedback for their contribution) -- if we would only put our efforts into it. So here's to hoping that the other PR queues will shorten quickly in the near future. ;-) And mind you, the lengths of the PR queues are only the tip of the iceberg of stuff we ought to finish doing before embarking on the next new direction. There are a ton of old bugs that need attention, and a ton of language features that need improvement / refinement. We could at least pay those *some* heed even if we absolutely have to start something new right now at this moment. It would be a great tragedy if D goes down in history as the project that had so
Re: What are the worst parts of D?
On 9/24/2014 11:42 AM, Jacob Carlborg wrote: On 2014-09-24 08:57, Walter Bright wrote: Heck, the dmd release package build scripts break every single release cycle. The it's obviously doing something wrong. See my reply to Vladimir.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 08:53:51 UTC, user wrote: On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via Digitalmars-d wrote: On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d digitalmars-d@puremagic.com wrote: i couldn't agree more. i would like to add, that coming from D1's clean and nice syntax - D2 becomes a syntactic monster You are a bit right, it is about on the edge and dragging all those undecisions with it only makes things worse. People usually say that complexity is not that bad, because you only use what you know (but what about maintenance?). Still, people criticize C++ for being too complex. http://abstrusegoose.com/strips/ars_longa_vita_brevis.PNG 80 percents of C++ programmers know only 20% of the language. However, not *the same* 20% percents...
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote: On 9/24/2014 2:56 AM, Vladimir Panteleev wrote: On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright wrote: On 9/23/2014 11:24 PM, Jacob Carlborg wrote: On 24/09/14 06:31, Walter Bright wrote: But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program. The solution is to make it automatic. There's no such thing as automatic testing of someone's moving target large project with another moving compiler target. It doesn't exist because no one has created it yet :) I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Most (all?) of these issues are solved by using a modern build system. (No, make is not a modern build system.) Heck, the dmd release package build scripts break every single release cycle. Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable. Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.) That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle. T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Re: What are the worst parts of D?
On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. -- /Jacob Carlborg
Re: What are the worst parts of D?
On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote: On 9/24/2014 2:56 AM, Vladimir Panteleev wrote: On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright wrote: On 9/23/2014 11:24 PM, Jacob Carlborg wrote: On 24/09/14 06:31, Walter Bright wrote: But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program. The solution is to make it automatic. There's no such thing as automatic testing of someone's moving target large project with another moving compiler target. It doesn't exist because no one has created it yet :) I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Most (all?) of these issues are solved by using a modern build system. (No, make is not a modern build system.) Heck, the dmd release package build scripts break every single release cycle. Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable. Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.) That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle. We of course agree on all these good things but it's all vacuous unless somebody champions it. Andrei
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 12:30:23PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote: [...] Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.) That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle. We of course agree on all these good things but it's all vacuous unless somebody champions it. [...] Wasn't Nick Sabalausky working on an automated (or automatable) packaging script some time ago? Whatever happened with that? T -- Real programmers can write assembly code in any language. :-) -- Larry Wall
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg wrote: On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems. Unfortunately, build engineering is effectively a specialty of its own when you step outside the most trivial of systems. It's really no surprise how few people can get it right - most people can't even agree on what a build system is supposed to do...
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 18:46:29 UTC, H. S. Teoh via Digitalmars-d wrote: On Tue, Sep 23, 2014 at 10:37:59PM -0700, Walter Bright via Digitalmars-d wrote: On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote: Yeah, I wish that at least *some* attention would be paid to refining existing features so that problematic corner cases could be ironed out. It's kinda maddening to hear statements like that. Just in 2.066: 103 compiler regressions fixed 235 compiler bugs fixed 39 language enhancements 12 phobos regressions fixed 110 phobos bugs fixed 41 phobos enhancements 9 druntime regressions fixed 17 druntime bugs fixed 9 druntime enhancements https://dlang.org/changelog.html#list2066 Like identifier lookup rules for local imports. Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else? No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on. Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code. And what to do about dtors. And so many little niggling details that seem minor, but added together, can form a pretty big mountain of frustration sometimes. So help out! I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. The situation with Phobos has improved dramatically, thanks to a well-timed rant some months ago, which triggered a coordinated effort of aggressive merging, pinging, reviewing, etc. -- we've managed to cut the Phobos PR queue from around 90+ to around 29 as of last night (from 4+ pages on github to only barely 2 pages). For that, I applaud my fellow Phobos reviewers, and I hope the trend will continue until the Phobos PR queue is firmly back at 1 page (=25 open PRs). Unfortunately, the problem persists in druntime, dlang.org, and dmd. It feels like there's a forest fire raging and only a handful of firefighters, and now we want to add more fires (new development directions) without adding more people. What about reviewing and merging / rejecting the 100+ PRs in the dmd queue, most of which contain fixes and language improvements that people have been waiting for, for a long time, before we think about new directions? Some PRs appear to fix bugs opened *years* ago, and yet nothing is done about them. Some PRs are at an impasse due to decisions that need to be made, yet nobody is making said decisions or even discussing them, and the PRs just continue to rot there. There are already a *ton* of new features / fixes / language improvements that are waiting to be decided upon (and, given the size of the dmd PR queue, I submit this is no exaggeration), and yet we are indifferent and instead look away to new directions. Many of us are indeed ready to help, but it would *really* be nice if our help is received more readily, or, at the very least, *some* indication is shown that more effort will be put into reviewing said help before more energy is expended in new directions. The dramatic shortening of the Phobos PR queue over the last 2-3 months proves that this is not only possible, but also beneficial (more fixes are making it into Phobos than ever before) and improves morale (people are more likely to contribute if they don't have to wait 3 weeks before getting any feedback for their contribution) -- if we would only put our efforts into it. So here's to hoping that the other PR queues will shorten quickly in the near future. ;-) And mind you, the lengths of the PR queues are only the tip of the iceberg of stuff we ought to finish doing before embarking on the next new direction. There are a ton of old bugs that need attention, and a ton of language features that need improvement / refinement. We could at least pay those *some* heed even if we absolutely have to
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 07:36:05PM +, Cliff via Digitalmars-d wrote: On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg wrote: On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems. That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) Unfortunately, build engineering is effectively a specialty of its own when you step outside the most trivial of systems. It's really no surprise how few people can get it right - most people can't even agree on what a build system is supposed to do... It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T -- Political correctness: socially-sanctioned hypocrisy.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 20:12:40 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 07:36:05PM +, Cliff via Digitalmars-d wrote: On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg wrote: On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems. That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) Unfortunately, build engineering is effectively a specialty of its own when you step outside the most trivial of systems. It's really no surprise how few people can get it right - most people can't even agree on what a build system is supposed to do... It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T Yes, Google in fact implemented must of this for their internal build systems, I am led to believe. I have myself written such a system before. In fact, the first project I have been working on in D is exactly this, using OS call interception for validating/discovering dependencies, building execution graphs, etc. I haven't seen TUP before, thanks for pointing it out.
Re: What are the worst parts of D?
On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote: That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. [snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has won over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei
Re: What are the worst parts of D?
On Wed, 24 Sep 2014 13:16:23 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: This is starting to be a little offensive... sorry, i don't meant to. excuse me if i'm getting rude and iffensive. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 9/24/14, 2:14 PM, ketmar via Digitalmars-d wrote: On Wed, 24 Sep 2014 13:16:23 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: This is starting to be a little offensive... sorry, i don't meant to. excuse me if i'm getting rude and iffensive. Much appreciated. -- Andrei
Re: What are the worst parts of D?
On Wed, 24 Sep 2014 07:44:38 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: Your guidance of my career is uncalled for. excuse me, i'm not trying to tell you what to do. neither i was trying to say that you are forced to work on the features you don't want. same for Walter. it was a bad example and i missed the thing i wanted to highlight. This is Walter's and my vision. He is working on C++ interop, and I am working on C++ interop. To the extent possible we hope the larger community will share this vision and help us to implement it. from my side i'm trying to at least not hijacking technical threads (sorry if i sent some of my rants to some of them, it's by accident). this is the maximum of my possible help in this area. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Wed, 24 Sep 2014 13:10:46 -0700 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) +many. 'make' is a PITA even for small personal projects. i myself using heavily modified jam as build system. it's not shiny good too, but it is at least usable without much suffering and small enough to be managed by one man. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 24 September 2014 17:43, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote: 1. Constant rejection of improvements because OMG breaking change!. Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes. What change in particular? The instances this has been used as a defence are innumerable. Perhaps the one that's closest to me was that time when I spent months arguing final-by-default, won unanimous support of the community, you approved it, patch written, LGTM, merged, then Andrei appeared with When did this happen? I never would have agreed to this! Revert it immediately! (which apparently he has the authority to do, but that's a separate matter). He later said that if it were that way from the start, I agree it should have been that way. It was reverted because breaking change, despite that it was an established fact that with virtual-by-default, any effort to optimise a library is also a breaking change and a major version increment. Most D code is yet to be written. We reject a single breaking change now, and by doing so, commit to endless breaking changes in the future. Of course, there are many more. Things like C-style arrays should be removed, @property looks like it will never be finished/fixed. I expect changes to 'ref' will probably receive this same defence. I'm sure everybody here can add extensively to this list. Phobos is full of things that should be tidied up. 2. Tooling is still insufficient. I use Visual Studio, and while VisualD is good, it's not great. Like almost all tooling projects, there is only one contributor, and I think this trend presents huge friction to adoption. Tooling is always factored outside of the D community and their perceived realm of responsibility. I'd like to see tooling taken into the core community and issues/bugs treated just as seriously as issues in the compiler/language itself. 3. Debugging is barely ever considered important. I'd love to see a concerted focus on making the debug experience excellent. Iain had a go at GDB, I understand there is great improvement there. Sadly, we recently lost the developer of Mago (a Windows debugger). There's lots of work we could do here, and I think it's of gigantic impact. There are 23 issues tagged with 'symdeb': https://issues.dlang.org/buglist.cgi?keywords=symdeblist_id=109316resolution=--- If there are more untagged ones, please tag them. The fact there's only 23 doesn't really mean anything, they're all major usability problems. I feel like I'm back in the early 90's when trying to iterate on my D code. These issues have proven to be the most likely to send my professional friends/colleagues running upon initial contact with D. Here's some more: https://issues.dlang.org/show_bug.cgi?id=12899 https://issues.dlang.org/show_bug.cgi?id=13198 https://issues.dlang.org/show_bug.cgi?id=13213 https://issues.dlang.org/show_bug.cgi?id=13227 https://issues.dlang.org/show_bug.cgi?id=13243 https://issues.dlang.org/show_bug.cgi?id=11541 https://issues.dlang.org/show_bug.cgi?id=11549 https://issues.dlang.org/show_bug.cgi?id=11902 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12163 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12244 MASSIVE NUISANCE The last 3 make debugging of anything but the simplest D code practically impossible/pointless. Aside from that though, this somewhat leads back to my second point, which is that symdeb issues in the compiler aren't enough. It needs to be taken wholistically. Cooperation between the compiler and tooling devs need to be actively engaged to fix many of these issues. 4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years later, I still can't pass an rvalue-ref (been discussed endlessly), create a ref local, and the separation from the type system makes it a nightmare in generic code. This was a nuisance for me on day-1, and has been grinding me down endlessly for years. It has now far eclipsed my grudges with the GC/RC, or literally anything else about the language on account of frequency of occurrence; almost daily. I have to ask why all your code revolves about this one thing? I suspect it's because I rely on far more C++ interop than the average D user. I have half a decade of solid experience with D-C++ interop, perhaps more than
Re: What are the worst parts of D?
On Wed, 24 Sep 2014 14:56:10 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: Most D code is yet to be written. and it will be wrtitten in a language with heavy legacy. it's the same thing as with c++ interop: pleasing imaginary future users at the expense for current users. even small changes that either breaks something or even adds a more sane/more consistent way to do some small thing without breaking the old way have virtually no chances to get into mainline. see, for example, function attributes. neither patch that allows to use '@' in front of pure and nothrow nor patch that allows to omit @ for @safe, @trusted and so on was blessed. they were destroyed almost immediately: it's not hard to type that '@', there is nothing wrong in such inconsistent syntax, newcomers will be confused by having two syntaxes (as if they are not confused now, failing to understand why some of the attributes requires @, and some can't be used with @!). or 'const' function attribute, which, i believe, should be forbidden as prefix attribute. i.e. 'const A foo ()' should be compilation error. or having no way to cancel final: and static: (this annoys me virtually each time i'm writing some complex structs/classes). and so on. i'd say change this while we can! but no, imaginary future users will be dissatisfied. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 25 September 2014 00:56, Don via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 24 September 2014 at 07:43:49 UTC, Walter Bright wrote: On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote: 1. Constant rejection of improvements because OMG breaking change!. Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes. I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today. Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can. For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? As I said earlier in the year, one of the biggest ever breaking changes was the fix for array stomping, but it wasn't even recognized as a breaking change! Breaking changes happen all the time, and the ones that break noisily are really not a problem. Most D code is yet to be written. What change in particular? I've got a nasty feeling that you misread what he wrote. Every time we say, breaking changes are good, you seem to hear breaking changes are bad! The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia. We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes. Break our code TODAY. Most D code is yet to be written. Oh good, I'm glad you're reading! :) This was our unanimous feeling at Remedy too. I think all D users want to see the language become clean, tidy and uniform.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 20:12:40 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 07:36:05PM +, Cliff via Digitalmars-d wrote: On Wednesday, 24 September 2014 at 19:26:46 UTC, Jacob Carlborg wrote: On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. People do it very, very wrong all the time - that's the problem :) Build systems are felt by most developers to be a tax they have to pay to do what they want to do, which is write code and solve non-build-related problems. That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) Unfortunately, build engineering is effectively a specialty of its own when you step outside the most trivial of systems. It's really no surprise how few people can get it right - most people can't even agree on what a build system is supposed to do... It's that bad, huh? At its most fundamental level, a build system is really nothing but a dependency management system. You have a directed, acyclic graph of objects that are built from other objects, and a command which takes said other objects as input, and produces the target object(s) as output. The build system takes as input this dependency graph, and runs the associated commands in topological order to produce the product(s). A modern build system can parallelize independent steps automatically. None of this is specific to compiling programs, in fact, it works for any process that takes a set of inputs and incrementally derives intermediate products until the final set of products are produced. Although the input is the (entire) dependency graph, it's not desirable to specify this graph explicitly (it's far too big in non-trivial projects); so most build systems offer ways of automatically deducing dependencies. Usually this is done by scanning the inputs, and modern build systems would offer ways for the user to define new scanning methods for new input types. One particularly clever system, Tup (http://gittup.org/tup/), uses OS call proxying to discover the *exact* set of inputs and outputs for a given command, including hidden dependencies (like reading a compiler configuration file that may change compiler behaviour) that most people don't even know about. It's also not desirable to have to derive all products from its original inputs all the time; what hasn't changed shouldn't need to be re-processed (we want incremental builds). So modern build systems implement some way of detecting when a node in the dependency graph has changed, thereby requiring all derived products downstream to be rebuilt. The most unreliable method is to scan for file change timestamps (make). A reliable (but slow) method is to compare file hash checksums. Tup uses OS filesystem change notifications to detect changes, thereby cutting out the scanning overhead, which can be quite large in complex projects (but it may be unreliable if the monitoring daemon isn't running / after rebooting). These are all just icing on the cake; the fundamental core of a build system is basically dependency graph management. T Couldn't have said it better myself. Atila
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 21:53:34 UTC, ketmar via Digitalmars-d wrote: On Wed, 24 Sep 2014 14:56:10 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: almost immediately: it's not hard to type that '@', Actually, on the French keyboard, it is. The '\' too.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 21:12:15 UTC, Andrei Alexandrescu wrote: On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote: That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. [snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has won over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei It depends on who you ask, I guess. I don't know what the definition of has won here is. make is certainly widespread, but so is C, Java and Javascript and I don't have much respect for those. I wouldn't use make again unless external forces made me. For one, it's slower than some of the alternatives, which admittedly only matters for larger builds (i.e. somebody's personal project on Github isn't ever going to see the difference, but a company project will). I'm saying this because I'm actively working on changing my company's existing build systems and did a migration from autotools to CMake in the past. I also looked at what was available for C/C++ recently and concluded it was better to go with the devil I know, namely CMake. From what I know, premake is pretty good (but I haven't used it) and tup looks good for arbritary rules (and large projects), but the ease of using CMake (despite its ridiculously bad scripting language) beats it. For me anyway. BTW, I totally agree with 2) above. Build systems are sort of simple but not really and frequently (always?) balloon out of proportion. As alluded to above, I've been that czar. If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. Make? I'd be just as likely to pick ant. Which I wouldn't. Atila P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. P.S.S autotools is the worse GNU project I know of
Re: What are the worst parts of D?
H. S. Teoh via Digitalmars-d wrote in message news:mailman.1573.1411584389.5783.digitalmar...@puremagic.com... I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. This is a misleading description of the situation with dmd pull requests. There are lots of open pull requests, but the number has stayed fairly stable at ~100 for a long time. This means they are getting merged or closed at the same rate they are created. Some of them have certainly been forgotten by reviewers (sorry) but most of them need work, or implement controversial or questionable features. The situation is harder (IMO) than with phobos because changes usually touch multiple systems in the compiler, even if the diff only touches a single file. Things could always be better (can we clone Walter and Kenji yet?) but the thing holding back issue XYZ is almost always the people who care about XYZ haven't fixed it yet, and the people who are fixing things don't care about XYZ. This includes not only making patches, but convincing others it's something worth caring about. Everybody has a different set of priorities they want everybody else to share.
Re: What are the worst parts of D?
On Wed, 24 Sep 2014 21:59:08 + eles via Digitalmars-d digitalmars-d@puremagic.com wrote: almost immediately: it's not hard to type that '@', Actually, on the French keyboard, it is. The '\' too. and i'm for adding more @... sorry to all French people. ;-) signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Thu, Sep 25, 2014 at 08:20:32AM +1000, Daniel Murphy via Digitalmars-d wrote: H. S. Teoh via Digitalmars-d wrote in message news:mailman.1573.1411584389.5783.digitalmar...@puremagic.com... I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. This is a misleading description of the situation with dmd pull requests. There are lots of open pull requests, but the number has stayed fairly stable at ~100 for a long time. This means they are getting merged or closed at the same rate they are created. Some of them have certainly been forgotten by reviewers (sorry) but most of them need work, or implement controversial or questionable features. IMNSHO, any PR that haven't been touched in more than, say, 1-2 months, should just be outright closed. If/when the people involved have time to work on it again, it can be reopened. If a feature is questionable or controversial, shouldn't it be discussed on the forum and then a decision made? Ignoring controversial PRs isn't getting us anywhere. At the very least, if we can't decide, the PR should be closed (the submitter can just reopen it later once he manages to convince people that it's worthwhile -- that's what git branches are for). [...] Things could always be better (can we clone Walter and Kenji yet?) Yeah, if we could clone Kenji, it would speed things up dramatically. :-) but the thing holding back issue XYZ is almost always the people who care about XYZ haven't fixed it yet, and the people who are fixing things don't care about XYZ. This includes not only making patches, but convincing others it's something worth caring about. Everybody has a different set of priorities they want everybody else to share. I wish people would just make a decision about PRs, even if it's just to close it with sorry this is not worth the time, than to silently ignore it and hope it would somehow go away on its own. T -- Always remember that you are unique. Just like everybody else. -- despair.com
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 10:18:29PM +, Atila Neves via Digitalmars-d wrote: [...] If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. [...] P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. For this, I find that SCon's architecture of fully-customizable plugins may work best: ship the system with prebaked rules for common tasks like compiling C/C++/D/Java/etc programs, packaging into tarballs / zips, etc., and expose a consistent API for users to make their own rules where applicable. If the scripting language is D, that opens up a whole new realm of possibilities like using introspection to auto-derive build dependencies, which would be so cool it'd freeze the sun. Now throw in things like built-in parallelization ala SCons (I'm not sure if tup does that too, I suspect it does), 100%-reproducible builds, auto-packaging, etc., and we might have a contender for Andrei's winner build system. P.S.S autotools is the worse GNU project I know of +100! It's a system of hacks built upon patches to broken systems built upon other hacks, a veritable metropolis of cards that will entirely collapse at the slightest missing toothpick in your shell environment / directory structure / stray object files or makefiles leftover from previous builds, thanks to 'make'. It's pretty marvelous for what it does -- autoconfigure complex system-dependent parameters for every existing flavor of Unix that you've never heard of -- when it works, that is. When it doesn't, you're in for days -- no, weeks -- no, months, of hair-pulling frustration trying to figure out where in the metropolis of cards the missing toothpick went. The error messages help -- in the same way stray hair or disturbed sand helps in a crime investigation -- if you know how to interpret them. Which ordinary people don't. T -- Philosophy: how to make a career out of daydreaming.
Re: What are the worst parts of D?
H. S. Teoh via Digitalmars-d wrote in message news:mailman.1605.1411597973.5783.digitalmar...@puremagic.com... IMNSHO, any PR that haven't been touched in more than, say, 1-2 months, should just be outright closed. If/when the people involved have time to work on it again, it can be reopened. If a feature is questionable or controversial, shouldn't it be discussed on the forum and then a decision made? Ignoring controversial PRs isn't getting us anywhere. At the very least, if we can't decide, the PR should be closed (the submitter can just reopen it later once he manages to convince people that it's worthwhile -- that's what git branches are for). If they're abandoned. Closing pull requests because Walter hasn't made a decision yet would be a terrible policy. Many forum discussions produce only i want this responses and provide no useful review on the design or implementation. I wish people would just make a decision about PRs, even if it's just to close it with sorry this is not worth the time, than to silently ignore it and hope it would somehow go away on its own. I'd want that too, if those were the only two options.
Re: What are the worst parts of D?
On 9/24/14, 3:18 PM, Atila Neves wrote: On Wednesday, 24 September 2014 at 21:12:15 UTC, Andrei Alexandrescu wrote: On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote: That's unfortunate indeed. I wish I could inspire them as to how cool a properly-done build system can be. [snip] That's all nice. However: (1) the truth is there's no clear modern build tool that has won over make; oh there's plenty of them, but each has its own quirks that makes it tenuous to use; (2) any build system for a project of nontrivial size needs a person/team minding it - never saw such a thing as it's just all automated and it works; (3) especially if the build system is not that familiar, the role of the build czar is all the more important. So the reality is quite a bit more complicated than the shiny city on a hill you describe. Andrei It depends on who you ask, I guess. I don't know what the definition of has won here is. Simple: ask 10 random engineers we need a build system. There's no dominant answer. Well except maybe for make :o). Case in point: we have two at Facebook, both created in house. But even that's beside the point. The plea here implies D devs are enamored with make and won't change their ways. Not at all! If there were a better thing with a strong champion, yay to that. But we can't be volunteered to use the build system that somebody else likes. Andrei
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 10:18:29PM +, Atila Neves via Digitalmars-d wrote: [...] If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. [...] P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. For this, I find that SCon's architecture of fully-customizable plugins may work best: ship the system with prebaked rules for common tasks like compiling C/C++/D/Java/etc programs, packaging into tarballs / zips, etc., and expose a consistent API for users to make their own rules where applicable. If the scripting language is D, that opens up a whole new realm of possibilities like using introspection to auto-derive build dependencies, which would be so cool it'd freeze the sun. Now throw in things like built-in parallelization ala SCons (I'm not sure if tup does that too, I suspect it does), 100%-reproducible builds, auto-packaging, etc., and we might have a contender for Andrei's winner build system. P.S.S autotools is the worse GNU project I know of +100! It's a system of hacks built upon patches to broken systems built upon other hacks, a veritable metropolis of cards that will entirely collapse at the slightest missing toothpick in your shell environment / directory structure / stray object files or makefiles leftover from previous builds, thanks to 'make'. It's pretty marvelous for what it does -- autoconfigure complex system-dependent parameters for every existing flavor of Unix that you've never heard of -- when it works, that is. When it doesn't, you're in for days -- no, weeks -- no, months, of hair-pulling frustration trying to figure out where in the metropolis of cards the missing toothpick went. The error messages help -- in the same way stray hair or disturbed sand helps in a crime investigation -- if you know how to interpret them. Which ordinary people don't. T If you have a passion and interest in this space and would like to collaborate, I would be thrilled. We can also split this discussion off of this thread since it is not D specific.
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 11:02:51PM +, Cliff via Digitalmars-d wrote: On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 10:18:29PM +, Atila Neves via Digitalmars-d wrote: [...] If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. [...] P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. [...] If you have a passion and interest in this space and would like to collaborate, I would be thrilled. We can also split this discussion off of this thread since it is not D specific. I'm interested. What about Atila? T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: What are the worst parts of D?
On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote: I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using a properly-done build system with these amazing qualities? To quote: I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) So should we take it that actually that system does not exist but you want to create it? Andrei
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 19:38:44 UTC, H. S. Teoh via Digitalmars-d wrote: Wasn't Nick Sabalausky working on an automated (or automatable) packaging script some time ago? Whatever happened with that? I think that's the one that keeps breaking. https://github.com/D-Programming-Language/installer/tree/master/create_dmd_release
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 04:16:20PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote: I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. For example, SCons is notoriously bad at scalability: the need to scan huge directory structures of large projects when all you want is to rebuild a tiny subdirectory, is disappointing. This part should be replaced by Tup-style OS file change notifications. However, Tup requires arcane shell commands to get anything done -- that's good if you're a Bash guru, but most people are not. Well, what I see here is there's no really good build system there. So then how can we interpret your long plea for dropping make like a bad habit and using a properly-done build system with these amazing qualities? To quote: I wish I could inspire them as to how cool a properly-done build system can be. Automatic parallel building, for example. Fully-reproducible, incremental builds (never ever do `make clean` again). Automatic build + packaging in a single command. Incrementally *updating* packaging in a single command. Automatic dependency discovery. And lots more. A lot of this technology actually already exists. The problem is that still too many people think make whenever they hear build system. Make is but a poor, antiquated caricature of what modern build systems can do. Worse is that most people are resistant to replacing make because of inertia. (Not realizing that by not throwing out make, they're subjecting themselves to a lifetime of unending, unnecessary suffering.) So should we take it that actually that system does not exist but you want to create it? [...] You're misrepresenting my position. *In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Your argument reduces to declining to replace a decrepit car that breaks down every other day with a new one, just because the new car isn't a flawlessly perfect epitome of engineering yet and still needs a little maintenance every half a year. T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 11:02:51PM +, Cliff via Digitalmars-d wrote: On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 10:18:29PM +, Atila Neves via Digitalmars-d wrote: [...] If I were to write a build system today that had to spell out all of its commands, I'd go with tup or Ninja. That CMake has support for Ninja is the icing on the cake for me. I wrote a Ninja build system generator the other day, that thing is awesome. [...] P.S. I've thought of writing a build system in D, for which the configuration language would be D. I still might. Right now, dub is serving my needs. I've been thinking of that too! I have in mind a hybrid between tup and SCons, integrating the best ideas of both and discarding the bad parts. [...] If you have a passion and interest in this space and would like to collaborate, I would be thrilled. We can also split this discussion off of this thread since it is not D specific. I'm interested. What about Atila? T Yes, whoever has a passionate interest in this space and (of course) an interest in D. Probably the best thing to do is take this to another forum - I don't want to further pollute this thread. Please g-mail to: cliff s hudson. (I'm assuming you are a human and can figure out the appropriate dotted address from the preceding :) )
Re: What are the worst parts of D?
On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei
Re: What are the worst parts of D?
On 9/24/2014 7:56 AM, Don wrote: For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? They do generate a warning if compiled with -w. What change in particular? I've got a nasty feeling that you misread what he wrote. Every time we say, breaking changes are good, you seem to hear breaking changes are bad! It would be helpful having a list of what breaking changes you had in mind.
Re: What are the worst parts of D?
On 9/24/2014 2:44 PM, Manu via Digitalmars-d wrote: The fact there's only 23 doesn't really mean anything, they're all major usability problems. I feel like I'm back in the early 90's when trying to iterate on my D code. These issues have proven to be the most likely to send my professional friends/colleagues running upon initial contact with D. Here's some more: https://issues.dlang.org/show_bug.cgi?id=12899 https://issues.dlang.org/show_bug.cgi?id=13198 https://issues.dlang.org/show_bug.cgi?id=13213 https://issues.dlang.org/show_bug.cgi?id=13227 https://issues.dlang.org/show_bug.cgi?id=13243 https://issues.dlang.org/show_bug.cgi?id=11541 https://issues.dlang.org/show_bug.cgi?id=11549 https://issues.dlang.org/show_bug.cgi?id=11902 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12163 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12244 MASSIVE NUISANCE Thanks for tagging them. The last 3 make debugging of anything but the simplest D code practically impossible/pointless. Aside from that though, this somewhat leads back to my second point, which is that symdeb issues in the compiler aren't enough. It needs to be taken wholistically. Cooperation between the compiler and tooling devs need to be actively engaged to fix many of these issues. I'm sorry, but this is awfully vague and contains nothing actionable. I suspect it's because I rely on far more C++ interop than the average D user. I have half a decade of solid experience with D-C++ interop, perhaps more than anyone else here? It's not 'all my code', but a sufficient quantity that it pops up and bites me almost every day, particularly when I try and write any meta. I still don't understand what use case is it that pops up every day. What are you trying to do? Why doesn't auto ref work?
Re: What are the worst parts of D?
On 9/24/2014 12:26 PM, Jacob Carlborg wrote: On 2014-09-24 12:16, Walter Bright wrote: I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration. And on and on. Again, if changing the file contents breaks the build system you're doing it very, very wrong. What matters is if the autotester imports X's large project, then it must somehow import whatever X's build system is, for better or worse. And I guarantee it will break constantly. Analogously, you and I know how to write code correctly (as does everyone else). But I guarantee that you and I are mistaken about that, and we don't write perfect code, and it breaks. Just like the build systems.
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: What are the worst parts of D?
On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful. Andrei
Re: What are the worst parts of D?
On 9/24/2014 11:44 AM, H. S. Teoh via Digitalmars-d wrote: No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on. I don't know of any language that is fully ironed out. There's no such thing. I can give you a list of such things with C. Furthermore, if your car is missing wheels, spending all your time getting the paint job perfect isn't getting the car into usable condition. Corner cases are, by definition, in the corners, not the center of the road. Corner cases need to be addressed, but they are not in the way of getting s**t done, and getting s**t is the primary purpose of a programming language. I know I tend to focus on issues that block people from getting useful work done. Those aren't the corner cases. For example, the local import thing that suddenly became critical - it is not critical. (We still need to address it.) If it is causing you problems, you can: 1. not use local imports, put them in the global scope 2. stick with short local names - if a module is exporting a symbol named 'i', whoever wrote that module needs to receive a strongly worded letter (!). It's still good that the import issue is brought up, and we need to make it work better. But it is not critical, and does not prevent people from getting work done. The C++ interop, on the other hand, DOES block people from getting work done. Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code. A language that doesn't do much of anything is fairly easy to get right - and the very first thing users will do is propose extensions. May I say that awesome features are proposed here EVERY SINGLE DAY, they label the features as absolutely critical, usually by the people who argue the next day that D overreaches, or sometimes even in the same post. I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest. For some perspective, there are currently 98 open PRs for dmd, and more importantly, 3,925 closed ones. There are 39 resolved ones for every unresolved one. Furthermore, many of my own PRs have sat there for years. std.halffloat, anyone? I find it frustrating, too. We could at least pay those *some* heed We are not sitting around doing nothing.
Re: What are the worst parts of D?
On 25 September 2014 11:01, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/24/2014 2:44 PM, Manu via Digitalmars-d wrote: The fact there's only 23 doesn't really mean anything, they're all major usability problems. I feel like I'm back in the early 90's when trying to iterate on my D code. These issues have proven to be the most likely to send my professional friends/colleagues running upon initial contact with D. Here's some more: https://issues.dlang.org/show_bug.cgi?id=12899 https://issues.dlang.org/show_bug.cgi?id=13198 https://issues.dlang.org/show_bug.cgi?id=13213 https://issues.dlang.org/show_bug.cgi?id=13227 https://issues.dlang.org/show_bug.cgi?id=13243 https://issues.dlang.org/show_bug.cgi?id=11541 https://issues.dlang.org/show_bug.cgi?id=11549 https://issues.dlang.org/show_bug.cgi?id=11902 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12163 MASSIVE NUISANCE https://issues.dlang.org/show_bug.cgi?id=12244 MASSIVE NUISANCE Thanks for tagging them. The last 3 make debugging of anything but the simplest D code practically impossible/pointless. Aside from that though, this somewhat leads back to my second point, which is that symdeb issues in the compiler aren't enough. It needs to be taken wholistically. Cooperation between the compiler and tooling devs need to be actively engaged to fix many of these issues. I'm sorry, but this is awfully vague and contains nothing actionable. The action I'd love to see would be Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished ;) I recognise that is probably unrealistic, because it seems so few people even use symbolic debuggers at all, that we have very few people interested in working on it. I don't really have a practical solution, but the post topic is 'the worst parts of D', and for me, this definitely rates very high :) An excellent action would be to implement proper scoping in the debuginfo, that would fix cursor movement while stepping, differently scoped local's with the same names causing havoc. And also classes not working. Those are some big tickets from the language side responsible for the most trouble. I suspect it's because I rely on far more C++ interop than the average D user. I have half a decade of solid experience with D-C++ interop, perhaps more than anyone else here? It's not 'all my code', but a sufficient quantity that it pops up and bites me almost every day, particularly when I try and write any meta. I still don't understand what use case is it that pops up every day. What are you trying to do? Why doesn't auto ref work? auto ref makes a reference out of int and float. There are all manner of primitive types and very small structs that shouldn't be ref, and auto ref can't possibly know. auto ref has never to date produced the semantics that I have wanted. If ref is part of the type, it flows through templates neatly, it is also possible to use app-specific logic to decide if something should be ref or not, and then give that argument without static if and duplication of entire functions, or text mixin.
Re: What are the worst parts of D?
On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote: I'm sorry, but this is awfully vague and contains nothing actionable. The action I'd love to see would be Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished ;) I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them. Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-) I recognise that is probably unrealistic, because it seems so few people even use symbolic debuggers at all, that we have very few people interested in working on it. You kinda put your finger on what the real issue is. Note that I find gdb well nigh unusable even for C++ code, so to me an unusable debugger is pretty normal and I don't think much about it. :-) It doesn't impair my debugging sessions much. I've also found that the more high level abstractions are used, the less useful a symbolic debugger is. Symbolic debuggers are only good for pedestrian, low level code that ironically is also what other methods are very good at, too. I don't really have a practical solution, but the post topic is 'the worst parts of D', and for me, this definitely rates very high :) No prob. The initiating post was an invitation to a wine festival, and that's what we have :-) I still don't understand what use case is it that pops up every day. What are you trying to do? Why doesn't auto ref work? auto ref makes a reference out of int and float. There are all manner of primitive types and very small structs that shouldn't be ref, Why not? What does it harm? And with inlining, pointless refs should be optimized away. and auto ref can't possibly know. Can't know what? auto ref has never to date produced the semantics that I have wanted. Please be more specific about what and why. If ref is part of the type, it flows through templates neatly, it is also possible to use app-specific logic to decide if something should be ref or not, and then give that argument without static if and duplication of entire functions, or text mixin. It seems you are very focused on very low level details. Not knowing specifically what and why you're focused on ref/value, I suggest the possibility of taking a larger view, focus more on algorithms, and rely on the inliner more. Take a look at the asm code generated now and then and see if your worries are justified.
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful. [...] Clearly, the more automatic dependency management can be, the better. In an ideal world, one should be able to say, here is my source tree, and here's the file that contains main(), and the build tool should automatically figure out all the dependencies as well as how to compile the sources into the final executable. In pseudocode, all one needs to write should in theory be simply: Program(mySuperApp, src/main.d); and everything else will be automatically figured out. But of course, this is currently not yet fully practical. So some amount of manual dependency specification will be needed. But the idea is to keep those minimal. T -- This is a tpyo.
Re: What are the worst parts of D?
On 9/24/14, 9:15 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful. [...] Clearly, the more automatic dependency management can be, the better. In an ideal world, one should be able to say, here is my source tree, and here's the file that contains main(), and the build tool should automatically figure out all the dependencies as well as how to compile the sources into the final executable. In pseudocode, all one needs to write should in theory be simply: Program(mySuperApp, src/main.d); and everything else will be automatically figured out. But of course, this is currently not yet fully practical. So some amount of manual dependency specification will be needed. But the idea is to keep those minimal. Actually you can't do this for D properly without enlisting the help of the compiler. Scoped import is a very interesting conditional dependency (it is realized only if the template is instantiated). Also, lazy opening of imports is almost guaranteed to have a huge good impact on build times. Your reply confirms my worst fear: you're looking at yet another general build system, of which there are plenty of carcasses rotting in the drought are plenty left and right of highway 101. The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. Andrei
Re: What are the worst parts of D?
On 9/24/14, 9:15 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. Sounds like a fun project. In case you'll allow me an opinion: I think dependency management is important for D, but a build tool is highly liable to become a distraction. Other ways to improve dependency management are likely to be more impactful. [...] Clearly, the more automatic dependency management can be, the better. In an ideal world, one should be able to say, here is my source tree, and here's the file that contains main(), and the build tool should automatically figure out all the dependencies as well as how to compile the sources into the final executable. In pseudocode, all one needs to write should in theory be simply: Program(mySuperApp, src/main.d); and everything else will be automatically figured out. But of course, this is currently not yet fully practical. So some amount of manual dependency specification will be needed. But the idea is to keep those minimal. Actually you can't do this for D properly without enlisting the help of the compiler. Scoped import is a very interesting conditional dependency (it is realized only if the template is instantiated). Also, lazy opening of imports is almost guaranteed to have a huge good impact on build times. Your reply confirms my worst fear: you're looking at yet another general build system, of which there are plenty of carcasses rotting in the drought left and right of highway 101. The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. Andrei
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 08:55:23PM -0700, Walter Bright via Digitalmars-d wrote: On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote: I'm sorry, but this is awfully vague and contains nothing actionable. The action I'd love to see would be Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished ;) I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them. Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-) Yeah, this is characteristic of free software. If this were proprietary software like what I write at work, the PTBs would just set down items X, Y, Z as their mandate, and everyone would have to work on it, like it or not. With free software, however, if something isn't getting done, you just gotta get your hands dirty and do it yourself. Surprisingly, many times what comes out can be superior to the cruft churned out by enterprise programmers who were forced to write something they didn't really want to. [...] Note that I find gdb well nigh unusable even for C++ code, so to me an unusable debugger is pretty normal and I don't think much about it. :-) It doesn't impair my debugging sessions much. printf debugging FTW! :-P I've also found that the more high level abstractions are used, the less useful a symbolic debugger is. Symbolic debuggers are only good for pedestrian, low level code that ironically is also what other methods are very good at, too. [...] I don't agree with that. I think symbolic debuggers should be improved so that they *can* become useful with high level abstractions. For example, if debuggers could be made to understand templates and compile-time constants, they could become much more useful than they are today in debugging high-level code. For example, the idea of stepping through lines of code (i.e. individual statements) is a convenient simplification, but really, in modern programming languages there are multiple levels of semantics that could have a meaningful concept of stepping forward/backward. You could step through individual expressions or subexpressions, step over function calls whose return values are passed to an enclosing function call, or step through individual arithmetic operations in a subexpression. Each of these levels of stepping could be useful in certain contexts, depending on what kind of bug you're trying to track down. Sometimes having statements as the stepping unit is too coarse-grained for certain debugging operations. Sometimes they are too fine-grained for high levels of abstractions. Ideally, there should be a way for the debugger to dissect your code into its constituent parts, at various levels of expression, for example: statement: [main.d:123]auto x = f(x,y/2,z) + z*2; == variable allocation: [hoisted to beginning of function] == evaluate expression: f(x,y/2,z) + z*2 == evaluate expression: f(x,y/2,z) == evaluate expression: x == load x == evaluate expression: y/2 == load y: [already in register eax] == load 2: [part of operation: /] == arithmetic operation: / == evaluate expression: z == function call: f == evaluate expression: z*2 == load z: [already in register ebx] == load 2: [optimized away] == arithmetic operation: / [optimized to z1] == evaluate sum == expression result: [in register edx] == assign expression to x == store x The user can choose which level of detail to zoom into, and the debugger would allow stepping through each operation at the selected level of detail (provided it hasn't been optimized away -- if it did, ideally the debugger would tell you what the optimized equivalent is). T -- Public parking: euphemism for paid parking. -- Flora
Re: What are the worst parts of D?
On 9/24/2014 9:26 PM, Andrei Alexandrescu wrote: The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. There's far more to a build system than generating executables. And there's more to generating executables than D source files (there may be C files in there, and C++ files, YACC files, and random other files). Heck, dmd uses C code to generated more .c source files. I've seen more than one fabulous build system that couldn't cope with that. Make is the C++ of build systems. It may be ugly, but you can get it to work.
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 09:44:26PM -0700, Walter Bright via Digitalmars-d wrote: On 9/24/2014 9:26 PM, Andrei Alexandrescu wrote: The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. I didn't specify *how* the build system would implement automatic dependency now, did I? :-) Nowhere did I say that the build system will (re)invent its own way of deriving source file dependencies. FYI, Tup is able to tell exactly what file(s) are read by the compiler in compiling a particular program (or source file) automatically, thus its dependency graph is actually accurate, unlike some build systems that depend on source-level scanning, which would lead to the problems you describe with conditional local imports. There's far more to a build system than generating executables. And there's more to generating executables than D source files (there may be C files in there, and C++ files, YACC files, and random other files). Heck, dmd uses C code to generated more .c source files. I've seen more than one fabulous build system that couldn't cope with that. Which build system would that be? I'll be sure to avoid it. :-P I've written SCons scripts that correctly handles automated handling of auto-generated source files. For example, a lex/flex source file gets compiled to a .c source file which in turn compiles to the object file that then gets linked with the executable. Heck, I have a working SCons script that handles the generation of animations from individual image frames which are in turn generated by invocations of povray on scene files programmatically generated by a program that reads script input and polytope definitions in a DSL and computes each scene file. The image generation includes scripted trimming and transparency adjustments of each individual frame, specified *in the build spec* via imagemagick, and the entire process from end to end is fully automatically parallelized by SCons, which is able to correctly sequence each step in a website project that has numerous such generation tasks, interleaving multiple generation procedures as CPUs become free without any breakage in dependencies. This process even optionally includes a final deployment step which copies the generated files into a web directory, and it is able to detect steps for which the products haven't changed from the last run and elide redundant copying of the unchanged files to the web directory, thus preserving last-updated timestamps on the target files. So before you bash modern build systems in favor of make, do take some time to educate yourself about what they're actually capable of. :-) You'll be a lot more convincing then. Make is the C++ of build systems. It may be ugly, but you can get it to work. If you like building real airplanes out of Lego pieces, be my guest. Me, I prefer using more suitable tools. :-P T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: What are the worst parts of D?
Actually you can't do this for D properly without enlisting the help of the compiler. Scoped import is a very interesting conditional dependency (it is realized only if the template is instantiated). Also, lazy opening of imports is almost guaranteed to have a huge good impact on build times. Your reply confirms my worst fear: you're looking at yet another general build system, of which there are plenty of carcasses rotting in the drought left and right of highway 101. This is one of my biggest frustrations with existing build systems - which really are nothing more than glorified makes with some extra syntax and - for the really advanced ones - ways to help you correctly specify your makefiles by flagging errors or missing dependencies. The build system that will be successful for D will cooperate with the compiler, which will give it fine-grained dependency information. Haskell does the same with good results. Andrei The compiler has a ton of precise information useful for build tools, IDEs and other kinds of analysis tools (to this day, it still bugs the crap out of me that Visual Studio has effectively *two* compilers, one for intellisense and one for the command-line and they do not share the same build environment or share the work they do!) Build is more than just producing a binary - it incorporates validation through testing, packaging for distribution, deployment and even versioning. I'd like to unlock the data in our tools and find ways to leverage it to improve automation and the whole developer workflow. Those ideas and principles go beyond D and the compiler of course, but we do have a nice opportunity here because we can work closely with the compiler authors, rather than having to rely *entirely* on OS-level process introspection through e.g. detours (which is still valuable from a pure dependency discovery process of course.) If we came out of this project with tup-for-D I'd consider that an abject failure.
Re: What are the worst parts of D?
On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote: If you like building real airplanes out of Lego pieces, be my guest. Me, I prefer using more suitable tools. :-P I spend very little time fussing with make. Making it work better (even to 0 cost) will add pretty much nothing to my productivity.
Re: What are the worst parts of D?
On 9/24/14, 10:14 PM, Cliff wrote: This is one of my biggest frustrations with existing build systems - which really are nothing more than glorified makes with some extra syntax and - for the really advanced ones - ways to help you correctly specify your makefiles by flagging errors or missing dependencies. It's nice you two are enthusiastic about improving that space. Also, it's a good example of how open source development works. I can't tell you what to do, you guys get to work on whatever strikes your fancy. Have fun! -- Andrei
Re: What are the worst parts of D?
On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote: printf debugging FTW! :-P There's more than that, but yeah. Most of my types I'll write a pretty printer for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation. I don't agree with that. I think symbolic debuggers should be improved so that they *can* become useful with high level abstractions. For example, if debuggers could be made to understand templates and compile-time constants, they could become much more useful than they are today in debugging high-level code. The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code.
Re: What are the worst parts of D?
The lack of clear direction or communication thereof. A continual adding of new stuff to try and appease the theoretical masses who will certainly come flocking to D if implemented, and a lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more. And inconsistency in how things work in the language. Oh, and function attributes. I'm sure someone likes them, but I'm drowning in pure system const immutable @nogc @illegitemate @wtf hell.
Re: What are the worst parts of D?
On 9/23/14, 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. * C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. Andrei
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei Alexandrescu wrote: On 9/23/14, 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. * C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. Well yeah, but that's just the current clear direction. Who knows what it will be next week.
Re: What are the worst parts of D?
On 9/23/14, 9:06 AM, Sean Kelly wrote: On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei Alexandrescu wrote: On 9/23/14, 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. * C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. Well yeah, but that's just the current clear direction. Who knows what it will be next week. It's been this for a good while, and it will probably be until done. -- Andrei
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 16:19:31 UTC, Andrei Alexandrescu wrote: On 9/23/14, 9:06 AM, Sean Kelly wrote: On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei Alexandrescu wrote: On 9/23/14, 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. * C++ compatibility Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. Well yeah, but that's just the current clear direction. Who knows what it will be next week. It's been this for a good while, and it will probably be until done. -- Andrei Here at work I'm toying with C++ compatibility right now: If it's viable, I would like to use D instead of C++ for a cloud tool that must link with C++ computer vision libraries... Right now it sounds promising, so this feature could really be very interesting, not only to facilitate the integration with existing in-house codebase, but also for brand new projects. I'm starting to think that there will be a lot of buzz and fuss about D as soon as good bindings to popular C++ libs will appear in the wild... --- /Paolo
Re: What are the worst parts of D?
Andrei Alexandrescu: * C++ compatibility * Everything GC-related Probably a distant third is improving build tooling. But those two are more important that everything else by an order of magnitude. In parallel there are other things like ddmd, checked ints in core library, perhaps to finish shared libs, to test the patch from Kenji that fixes the module system, and more. Bye, bearophile
Re: What are the worst parts of D?
On 9/23/14, 9:40 AM, Paolo Invernizzi wrote: I'm starting to think that there will be a lot of buzz and fuss about D as soon as good bindings to popular C++ libs will appear in the wild... Yah, and core.stdcpp will be quite the surprise. -- Andrei
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 16:50:26 UTC, Andrei Alexandrescu wrote: On 9/23/14, 9:40 AM, Paolo Invernizzi wrote: I'm starting to think that there will be a lot of buzz and fuss about D as soon as good bindings to popular C++ libs will appear in the wild... Yah, and core.stdcpp will be quite the surprise. -- Andrei Really?? Wow. Awesome! Atila
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote: […] and a lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more. This. The hypocritical fear of making breaking changes (the fact that not all of them are bad has been brought up over and over again by some of the corporate users) is crippling us, making D a much more cluttered language than necessary. Seriously, once somebody comes up with an automatic fixup tool, there is hardly any generic argument left against language changes. Sure, there will always be some cases where manual intervention is still required, such as with string mixins. But unless we have lost hope that the D community is still to grow significantly, I don't see why the burden of proof should automatically lie on the side of those in favor of cleaning up cruft and semantical quirks. Most D code is still to be written. David
Re: What are the worst parts of D?
On Tue, 23 Sep 2014 14:29:05 + Sean Kelly via Digitalmars-d digitalmars-d@puremagic.com wrote: function attributes. I'm sure someone likes them, but I'm drowning in pure system const immutable @nogc @illegitemate @wtf hell. and 'const' is such overpowered that it's barely usable on methods and struct/class fields. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Tue, 23 Sep 2014 18:32:39 + David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: Seriously, once somebody comes up with an automatic fixup tool, i bet nobody will. for many various reasons. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 9/23/14, 11:32 AM, David Nadlinger wrote: On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote: […] and a lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more. This. The hypocritical fear of making breaking changes (the fact that not all of them are bad has been brought up over and over again by some of the corporate users) is crippling us, making D a much more cluttered language than necessary. Seriously, once somebody comes up with an automatic fixup tool, there is hardly any generic argument left against language changes. Sure, there will always be some cases where manual intervention is still required, such as with string mixins. But unless we have lost hope that the D community is still to grow significantly, I don't see why the burden of proof should automatically lie on the side of those in favor of cleaning up cruft and semantical quirks. Most D code is still to be written. Well put. Again, the two things we need to work on are C++ compatibility and the GC. -- Andrei
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote: Well put. Again, the two things we need to work on are C++ compatibility and the GC. -- Andrei Has much thought gone into how we'll address C++ const?
Re: What are the worst parts of D?
On 9/23/14, 12:01 PM, Sean Kelly wrote: On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote: Well put. Again, the two things we need to work on are C++ compatibility and the GC. -- Andrei Has much thought gone into how we'll address C++ const? Some. A lot more needs to. -- Andrei
Re: What are the worst parts of D?
On Tue, Sep 23, 2014 at 07:01:05PM +, Sean Kelly via Digitalmars-d wrote: On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote: Well put. Again, the two things we need to work on are C++ compatibility and the GC. -- Andrei Has much thought gone into how we'll address C++ const? Is that even addressable?? D const is fundamentally different from C++ const. Short of introducing logical const into D, I don't see how we could bridge the gap. T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Sep 23, 2014 at 07:01:05PM +, Sean Kelly via
Digitalmars-d wrote:
On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei
Alexandrescu wrote:
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei
Has much thought gone into how we'll address C++ const?
Is that even addressable?? D const is fundamentally different
from C++
const. Short of introducing logical const into D, I don't see
how we
could bridge the gap.
I haven't really thought about it, but something could probably
be made to work with type wrappers that do implicit casting plus
just pretending that const is the same like we do with our C
interfaces. I'm also wondering how we'd handle something like:
struct S { virtual int foo() {...} };
std::mapint,S m;
We'd have to make S a value type in D, so struct, but D struct
does't allow virtual functions. Maybe something weird with
in-place construction of classes? I suspect the more we look
into C++ compatibility the more problems we'll find, and actually
interfacing with most C++ code worth using will result in
terrifying D code. But I hope I'm wrong since C++ support is
apparently now where all of our effort is being devoted (mark me
down as being completely uninterested in this feature despite
using C/C++ at work).
Re: What are the worst parts of D?
On Tue, Sep 23, 2014 at 07:50:38PM +, Sean Kelly via Digitalmars-d wrote:
On Tuesday, 23 September 2014 at 19:10:07 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Tue, Sep 23, 2014 at 07:01:05PM +, Sean Kelly via Digitalmars-d
wrote:
[...]
Has much thought gone into how we'll address C++ const?
Is that even addressable?? D const is fundamentally different from
C++ const. Short of introducing logical const into D, I don't see how
we could bridge the gap.
I haven't really thought about it, but something could probably be
made to work with type wrappers that do implicit casting plus just
pretending that const is the same like we do with our C interfaces.
I'm also wondering how we'd handle something like:
struct S { virtual int foo() {...} };
std::mapint,S m;
We'd have to make S a value type in D, so struct, but D struct does't
allow virtual functions. Maybe something weird with in-place
construction of classes?
Or turn them into function pointers / member delegates? But that doesn't
work well with ABI compatibility.
I suspect the more we look into C++ compatibility the more problems
we'll find,
SFINAE is another dark corner of disaster waiting to happen, once we
decide to implement C++ template compatibility. As well as Koenig
lookup, which will become indispensible if D code is to actually use
non-trivial C++ libraries.
and actually interfacing with most C++ code worth using will result in
terrifying D code. But I hope I'm wrong since C++ support is
apparently now where all of our effort is being devoted (mark me down
as being completely uninterested in this feature despite using C/C++
at work).
Yeah, I can't say I'm exactly thrilled about being able to call C++ code
from D. I suppose it's a nice-to-have, but I'm not sure how well that's
gonna work in practice, given the fundamental differences between D and
C++.
But be that as it may, if we're serious about cross-linguistic ABI
compatibility, then we better start with a solid design of how exactly
said interfacing is going to happen in a way that fits in well with how
D works. Cowboying our way through piecemeal (i.e., ad hoc addition of
compatibilities like adding C++ class support, then C++ templates, then
SFINAE in extern(c++), then ...) isn't going to cut it. We might end up
reinventing C++, even more poorly than C++ already is.
T
--
Everybody talks about it, but nobody does anything about it! -- Mark Twain
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via Digitalmars-d wrote: SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries. We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back.
Re: What are the worst parts of D?
On 9/23/14, 4:25 PM, deadalnix wrote: On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via Digitalmars-d wrote: SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries. We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back. Yah, that's exactly it. Syntax and semantics stay D; the functions called may be C++. -- Andrei
Re: What are the worst parts of D?
On Tue, Sep 23, 2014 at 11:25:52PM +, deadalnix via Digitalmars-d wrote: On Tuesday, 23 September 2014 at 20:22:32 UTC, H. S. Teoh via Digitalmars-d wrote: SFINAE is another dark corner of disaster waiting to happen, once we decide to implement C++ template compatibility. As well as Koenig lookup, which will become indispensible if D code is to actually use non-trivial C++ libraries. We don't need these to be compatible with C++. We don't want to be able to cut/paste C++ into a . file and expect it to compile, but that you can map a reasonable amount of C++ constructs and expect them to interact with the C++ code and back. You *will* need SFINAE if you expect to interface C++ template libraries with D. Imagine that an existing codebase is using some C++ template library that depends on SFINAE. You'd like to start migrating to D, so you start writing new code in D. Eventually you need to make use of the C++ template library in order to interface with the C++ parts of the code, so you write a .di that declares template functions in an extern(c++) block. It works... some of the time. Other times you start getting weird errors or the wrong functions get called, because the C++ template library was written with SFINAE in mind, but D doesn't have that. So at the end of the day, it's a gigantic mess, and you go crawling back to C++. Unless, of course, we draw the line at templates and say that we won't support template compatibility with C++ (and I'd fully support that decision!). But that means we throw all C++ template libraries out the window, and any C++ codebase that makes heavy use of a template library will have to be rewritten from scratch in D. As for Koenig lookup, you might run into problems if you declare C++ wrappers for D functions in the C++ part of the codebase, and suddenly the wrong D functions are getting called due to Koenig lookup in C++ which wasn't considered when the D part of the code was written. T -- Без труда не выловишь и рыбку из пруда.
Re: What are the worst parts of D?
On 9/23/14, 5:06 PM, H. S. Teoh via Digitalmars-d wrote: You *will* need SFINAE if you expect to interface C++ template libraries with D. Nope. -- Andrei
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 00:08:19 UTC, H. S. Teoh via Digitalmars-d wrote: You *will* need SFINAE if you expect to interface C++ template libraries with D. Imagine that an existing codebase is using some C++ template library that depends on SFINAE. You'd like to start migrating to D, so you start writing new code in D. Eventually you need to make use of the C++ template library in order to interface with the C++ parts of the code, so you write a .di that declares template functions in an extern(c++) block. It works... some of the time. Other times you start getting weird errors or the wrong functions get called, because the C++ template library was written with SFINAE in mind, but D doesn't have that. So at the end of the day, it's a gigantic mess, and you go crawling back to C++. I think you can support a large part of C++ template without SFINAE. It is not that common and only matter for the binding if it changes the interface or the layout of something. If one want to map these, it can be done with some static if magic. But I'm fairly confident that it won't even be necessary is most situations.
Re: What are the worst parts of D?
On 9/23/2014 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. A continual adding of new stuff to try and appease the theoretical masses who will certainly come flocking to D if implemented, and a lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more. I find this hard to reconcile with what the changelog says. And inconsistency in how things work in the language. Oh, and function attributes. I'm sure someone likes them, but I'm drowning in pure system const immutable @nogc @illegitemate @wtf hell. Fortunately, those attributes are inferred for template functions. I did try to extend that to auto functions, but got a lot of resistance.
Re: What are the worst parts of D?
On 9/21/2014 3:16 PM, H. S. Teoh via Digitalmars-d wrote: On Sun, Sep 21, 2014 at 08:49:38AM +, via Digitalmars-d wrote: On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regressionlist_id=106988resolution=--- I filed over half of those... I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice hey, your PR broke this and that project would surely be helpful to detect the breakages early on. This has been suggested before. The problem is resources. If you're willing to donate equipment for running these tests, it would be greatly appreciated, I believe. No, that's not the problem. The problem is what to do when the larger project fails. Currently, it is the submitter's job to adjust the test suite, fix phobos code, whatever is necessary to get the suite running again. Sometimes, in the more convoluted Phobos code, this can be a real challenge. Now replace that with somewhere in a large project, which our poor submitter knows absolutely nothing about, it fails. You're asking him to go in, understand this large project, determine if it's a problem with his submission or a problem with the large project, and fix it. At some level, then WE become the maintainers of that large project. This is completely unworkable.
Re: What are the worst parts of D?
On 9/22/2014 10:16 AM, luminousone wrote: What is needed? The people who maintain large projects need to try them out with the beta compilers and file any regressions.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote: This is completely unworkable. Mister, please stop hurting the pool straw man. Let me quote the relevant part: They don't necessarily need to be blocking, just a notice hey, your PR broke this and that project would surely be helpful to detect the breakages early on. I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote: On 9/22/2014 10:16 AM, luminousone wrote: What is needed? The people who maintain large projects need to try them out with the beta compilers and file any regressions. Question: What's the point of testing betas if the release will occur even with known regressions? Blocking a pull being merged would be much more efficient than dealing with a pull merged long ago that by release time is difficult to revert.
Re: What are the worst parts of D?
On 9/23/2014 9:12 PM, Vladimir Panteleev wrote: On Wednesday, 24 September 2014 at 04:00:06 UTC, Walter Bright wrote: On 9/22/2014 10:16 AM, luminousone wrote: What is needed? The people who maintain large projects need to try them out with the beta compilers and file any regressions. Question: What's the point of testing betas if the release will occur even with known regressions? Framing the question that way implies that all regressions are equally deleterious. But this isn't true at all - some regressions are disastrous, some are just minor nits. Delaying the release has its costs, too, as it may fix a number of serious problems. It's a balancing act. We shouldn't hamstring our ability to do what is best by conforming to arbitrary rules whether they are right or wrong for the circumstances. Blocking a pull being merged would be much more efficient than dealing with a pull merged long ago that by release time is difficult to revert. Sure. I would block pulls that produce known regressions. The earlier regressions are known the better. But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program.
Re: What are the worst parts of D?
On 9/23/2014 9:08 PM, Vladimir Panteleev wrote: On Wednesday, 24 September 2014 at 03:59:10 UTC, Walter Bright wrote: This is completely unworkable. Mister, please stop hurting the pool straw man. Let me quote the relevant part: They don't necessarily need to be blocking, just a notice hey, your PR broke this and that project would surely be helpful to detect the breakages early on. I think that aside from the technical limitations, that's completely reasonable, and does not put any undue obligation on anyone. Who is going to maintain the autotester version of these projects? What I'd like to see is the autotester regularly build release packages out of HEAD. Then, large project maintainers can create their own scripts to download the latest compiler and attempt to build their project.
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright wrote: On 9/23/2014 7:29 AM, Sean Kelly wrote: The lack of clear direction or communication thereof. A continual adding of new stuff to try and appease the theoretical masses who will certainly come flocking to D if implemented, and a lack of attention paid to tightening up what we've already got and deprecating old stuff that no one wants any more. I find this hard to reconcile with what the changelog says. There's clearly been a lot of attention paid to bug fixes. But for the rest... I feel like the overall direction is towards whatever is currently thought to gain the most new users. The thing is that D has already *got* me. What I want is for the language I've already got to be polished until I can use it in a freaking space telescope. I'm sick of yes but languages. Every time I hit an obstacle in D I think oh great, D is way behind other languages in all these ways and D itself is broken to boot. Why am I using this again? And it could be a tiny thing. It doesn't matter. Every little issue like that is magnified a thousandfold because D is already such a hard sell. So in that respect I understand the push for C++ support because that's the speed bump that Andrei has hit. But here's the thing... by pursuing this we're effectively focusing all of our efforts *on another language*. And we're doing so when D itself still needs a lot of work. Maybe not in any truly immense ways, but as I said before, those tiny things can seem huge when you're already struggling to justify just using the language at all. Maybe all this will pull together into a cohesive whole, but so far it feels kind of disconnected. So that's part of what I meant by tightening up. And inconsistency in how things work in the language. Oh, and function attributes. I'm sure someone likes them, but I'm drowning in pure system const immutable @nogc @illegitemate @wtf hell. Fortunately, those attributes are inferred for template functions. I did try to extend that to auto functions, but got a lot of resistance. Yes, the inference is very nice. And I do see the use for each attribute. It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise. It's information for the compiler, not me as a user. I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely.
Re: What are the worst parts of D?
On 9/23/2014 9:46 PM, Sean Kelly via Digitalmars-d wrote: There's clearly been a lot of attention paid to bug fixes. But for the rest... I feel like the overall direction is towards whatever is currently thought to gain the most new users. The thing is that D has already *got* me. What I want is for the language I've already got to be polished until I can use it in a freaking space telescope. I'm sick of yes but languages. Every time I hit an obstacle in D I think oh great, D is way behind other languages in all these ways and D itself is broken to boot. Why am I using this again? And it could be a tiny thing. It doesn't matter. Every little issue like that is magnified a thousandfold because D is already such a hard sell. I agree with Sean quite a bit here. Let's turn the camera around and look at it from a different angle. I'm hard pressed to find a new feature from the last few years that's actually thoroughly complete. And by complete I mean that druntime and phobos use it everywhere it should be used. Shared libraries? nope. Any of the new attributes? nope. 64 bit support? nope. const? shared? cleaning up object? .. nope. And that's not even getting into the big gaps that exist. I understand quite thoroughly why c++ support is a big win, or will be, but the Oh Shiny focus is pretty discouraging for me as well. This isn't meant to say the c++ work shouldn't be done, but to point out that the shifting focus is a real problem.
Re: What are the worst parts of D?
On Wed, Sep 24, 2014 at 04:46:00AM +, Sean Kelly via Digitalmars-d wrote:
On Wednesday, 24 September 2014 at 03:44:52 UTC, Walter Bright wrote:
On 9/23/2014 7:29 AM, Sean Kelly wrote:
[...]
There's clearly been a lot of attention paid to bug fixes. But for
the rest... I feel like the overall direction is towards whatever is
currently thought to gain the most new users. The thing is that D has
already *got* me. What I want is for the language I've already got to
be polished until I can use it in a freaking space telescope. I'm
sick of yes but languages. Every time I hit an obstacle in D I
think oh great, D is way behind other languages in all these ways and
D itself is broken to boot. Why am I using this again? And it could
be a tiny thing. It doesn't matter. Every little issue like that is
magnified a thousandfold because D is already such a hard sell.
Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed out.
Like identifier lookup rules for local imports. And what to do about
dtors. And so many little niggling details that seem minor, but added
together, can form a pretty big mountain of frustration sometimes.
[...]
And inconsistency in how things work in the language. Oh, and
function attributes. I'm sure someone likes them, but I'm drowning
in pure system const immutable @nogc @illegitemate @wtf hell.
Fortunately, those attributes are inferred for template functions.
I did try to extend that to auto functions, but got a lot of
resistance.
I support attribute inference for auto functions. The more inference,
the better, I say. That's the only way attributes will become
practically useful.
Yes, the inference is very nice. And I do see the use for each
attribute. It's just... when I look at a function and there's a line
of attributes before the function declaration that have nothing to do
with what the function actually does but rather with how it's
implemented, it's just syntactic noise. It's information for the
compiler, not me as a user. I hope we'll eventually get to the point
where everything is inferred and the attributes disappear entirely.
I haven't actually tried this yet, but I'm been toying with the idea of
writing *all* functions as template functions (except where impossible,
like virtual functions), even if they would take only zero compile-time
arguments. This way, I reap the benefits of attribute inference, *and* I
also get automatic culling of unused functions from the executable ('cos
they wouldn't be instantiated in the first place).
T
--
Just because you survived after you did it, doesn't mean it wasn't stupid!
Re: What are the worst parts of D?
On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
Yeah, I wish that at least *some* attention would be paid to refining
existing features so that problematic corner cases could be ironed out.
It's kinda maddening to hear statements like that. Just in 2.066:
103 compiler regressions fixed
235 compiler bugs fixed
39 language enhancements
12 phobos regressions fixed
110 phobos bugs fixed
41 phobos enhancements
9 druntime regressions fixed
17 druntime bugs fixed
9 druntime enhancements
https://dlang.org/changelog.html#list2066
Like identifier lookup rules for local imports.
Suddenly this issue goes to a mountain overnight. Is it really the most
critical, important problem, overshadowing everything else?
And what to do about
dtors. And so many little niggling details that seem minor, but added
together, can form a pretty big mountain of frustration sometimes.
So help out!
I haven't actually tried this yet, but I'm been toying with the idea of
writing *all* functions as template functions (except where impossible,
like virtual functions), even if they would take only zero compile-time
arguments. This way, I reap the benefits of attribute inference, *and* I
also get automatic culling of unused functions from the executable ('cos
they wouldn't be instantiated in the first place).
Yup, give it a try.
Re: What are the worst parts of D?
On Tue, 23 Sep 2014 21:59:53 -0700 Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com wrote: I understand quite thoroughly why c++ support is a big win i believe it's not. so-called enterprise will not choose D for many reasons, and c++ interop is on the bottom of the list. seasoned c++ developer will not migrate to D for many reasons (or he already did that, but then he is not c++ developer anymore), and c++ interop is not on the top of the list, not even near the top. all that gory efforts aimed to c++ interop will bring three and a half more users. there will be NO massive migration due to better c++ interop. yet this feature is on the top of the list now. i'm sad. seems that i (we?) have no choice except to wait until people will get enough of c++ games and will became focused on D again. porting and merging CDGC is much better target which help people already using D, but... but imaginary future adopters seems to be the highest priority. too bad that they will never arrive. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 9/23/14, 9:46 PM, Sean Kelly wrote: So in that respect I understand the push for C++ support because that's the speed bump that Andrei has hit. But here's the thing... by pursuing this we're effectively focusing all of our efforts *on another language*. And we're doing so when D itself still needs a lot of work. Maybe not in any truly immense ways, but as I said before, those tiny things can seem huge when you're already struggling to justify just using the language at all. Maybe all this will pull together into a cohesive whole, but so far it feels kind of disconnected. So that's part of what I meant by tightening up. You need a spoon of rennet to turn a bucket of milk into a bucket of yogurt. No matter how much milk you add, that won't help. You want to add milk. I know we must add rennet. -- Andrei
Re: What are the worst parts of D?
On 21 September 2014 15:54, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/21/14, 1:27 AM, ponce wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? Proper D code is supposed to have lots of attributes (pure const nothrow @nogc) that brings little and makes it look bad. No because deduction. -- Andrei Agreed. The time when you want to explicitly use these attributes is if you want to enforce @nogc, pure ... As it turns out, it is a good idea to enforce these from the start, rather than after you've written your program. Iain
Re: What are the worst parts of D?
Timon Gehr wrote in message news:lvmh5b$eo9$1...@digitalmars.com... When was int x(T)=2; introduced? At the same time as enum x(T) = 2; I think. Also, C-style array syntax would actually be string results(T)[] = ;. Nah, array type suffix goes before the template argument list.
Re: What are the worst parts of D?
On 09/22/2014 03:26 PM, Daniel Murphy wrote: Timon Gehr wrote in message news:lvmh5b$eo9$1...@digitalmars.com... When was int x(T)=2; introduced? At the same time as enum x(T) = 2; I think. ... Is this documented? Also, C-style array syntax would actually be string results(T)[] = ;. Nah, array type suffix goes before the template argument list. It is results!T[2], not results[2]!T.
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote: On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim Grostad wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? 1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap. Not really a problem with the language. Just problems. 5. Too much focus on retaining C semantics (go does a bit better) 6. Inconsistencies and hacks (too many low hanging fruits) 7. More hacks are being added rather than removing existing ones. Definitely can agree, I think it has to do with the sentiment that it is too much like C++ It's really needed to keep C++-compatible as possible otherwise too few people are going to use it. If C++ wasn't C-compatible do you think it would be a successfully language it is today? I don't think so.
Re: What are the worst parts of D?
On Sunday, 21 September 2014 at 22:17:59 UTC, H. S. Teoh via Digitalmars-d wrote: On Sun, Sep 21, 2014 at 08:49:38AM +, via Digitalmars-d wrote: On Sunday, 21 September 2014 at 00:07:36 UTC, Vladimir Panteleev wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The regressions! https://issues.dlang.org/buglist.cgi?bug_severity=regressionlist_id=106988resolution=--- I filed over half of those... I guess you found them using your own code base? Maybe it would make sense to add one or more larger projects to the autotester, in addition to the unit tests. They don't necessarily need to be blocking, just a notice hey, your PR broke this and that project would surely be helpful to detect the breakages early on. This has been suggested before. The problem is resources. If you're willing to donate equipment for running these tests, it would be greatly appreciated, I believe. For my part, I regularly try compiling my own projects with git HEAD, and filing any regressions I find. T What is needed?
Re: What are the worst parts of D?
On Mon, 22 Sep 2014 14:28:47 + AsmMan via Digitalmars-d digitalmars-d@puremagic.com wrote: It's really needed to keep C++-compatible as possible otherwise too few people are going to use it. If C++ wasn't C-compatible do you think it would be a successfully language it is today? I don't think so. D is not c++-compatible anyway. and talking about compatibility: it's what made c++ such a monster. if someone wants c++ he knows where to download c++ compiler. the last thing D should look at is c++. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 9/22/14, 1:44 PM, ketmar via Digitalmars-d wrote: On Mon, 22 Sep 2014 14:28:47 + AsmMan via Digitalmars-d digitalmars-d@puremagic.com wrote: It's really needed to keep C++-compatible as possible otherwise too few people are going to use it. If C++ wasn't C-compatible do you think it would be a successfully language it is today? I don't think so. D is not c++-compatible anyway. D is ABI- and mangling-compatible with C++. and talking about compatibility: it's what made c++ such a monster. if someone wants c++ he knows where to download c++ compiler. the last thing D should look at is c++. Well what can I say? I'm glad you're not making the decisions. Andrei
Re: What are the worst parts of D?
On Mon, 22 Sep 2014 16:14:28 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: D is not c++-compatible anyway. D is ABI- and mangling-compatible with C++. but we were talking about syntactic compatibility. Well what can I say? I'm glad you're not making the decisions. i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Tuesday, 23 September 2014 at 01:39:00 UTC, ketmar via Digitalmars-d wrote: On Mon, 22 Sep 2014 16:14:28 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: D is not c++-compatible anyway. D is ABI- and mangling-compatible with C++. but we were talking about syntactic compatibility. Well what can I say? I'm glad you're not making the decisions. i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++. If you hate C++, you shouldn't have too much trouble to understand that offering a way out for people using C++ is key.
Re: What are the worst parts of D?
On Tue, Sep 23, 2014 at 04:38:51AM +0300, ketmar via Digitalmars-d wrote: On Mon, 22 Sep 2014 16:14:28 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: D is not c++-compatible anyway. D is ABI- and mangling-compatible with C++. but we were talking about syntactic compatibility. Well what can I say? I'm glad you're not making the decisions. i HATE c++. i want it to DIE, to disappear completely, with all the code written in it. so yes, it's good to D that i can't freely mess with mainline codebase. 'cause the first thing i'll do with it is destroying any traces of c++ interop. the world will be a better place without c++. For a moment, I read that as you'll destroy any traces of C++, so the first thing that would go is the DMD source code. :-P T -- Shin: (n.) A device for finding furniture in the dark.
Re: What are the worst parts of D?
On Mon, 22 Sep 2014 19:16:27 -0700 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: For a moment, I read that as you'll destroy any traces of C++, so the first thing that would go is the DMD source code. :-P but we have magicport! well, almost... i'll postpone c++ destruction until magicport will be complete and working. ;-) signature.asc Description: PGP signature
