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=symdeb&list_id=109316&resolution=---
>
> 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 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.

On Wed, 24 Sep 2014 14:56:10 +0000
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.

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 +0000, 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

On Wednesday, 24 September 2014 at 21:53:34 UTC, ketmar via Digitalmars-d wrote:
> On Wed, 24 Sep 2014 14:56:10 +0000
> 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.

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.

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

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.1573.1411584389.5783.digitalmars-d@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. 

On Wed, 24 Sep 2014 21:59:08 +0000
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. ;-)

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.digitalmars-d@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

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.1605.1411597973.5783.digitalmars-d@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.