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?

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.

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

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

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.

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.

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.

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.

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

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.