On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:
> On Fri, 2018-02-09 at 16:10 +0000, Seb via Digitalmars-d wrote:
>> 
> […]
>> Dub is not dead, it just has limited resources.
>
> So , if the D community want Dub to work as a build system as well as a package manager, extend the resources by corralling the grumblers and support them into fixing code and creating pull requests.


I already but my limited resources into real and _merged_ pull requests for actual bugs at dlang/dub
Please if you have ideas to motivate the grumblers to do so as well, act!


> Whilst grumbles on the email list are not turned into evolution of Dub, the D ecosystem does progress.

Yes, we are making  progress. With more people contributing, things would go a lot faster though ...

An example, remember how code.dlang.org looked in 2016?

https://web.archive.org/web/20160129060825/http://code.dlang.org/

(apart from the design - compare the number of packages with the number it has today)

On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
> * scope() .. just call it "defer" just as every other language now does. It only confuses people who come from other languages. Its now almost a standard. By using scope people have have no clue that D has a defer. Took even me a while to know that D had a defer system in place.

The funny thing is that D had this feature long before any other language that I can think of (of course Lisp has probably had 6 different implementations of it since 1972). They're the ones that need to get with the program ;-)

On Friday, 9 February 2018 at 17:31:47 UTC, Adam D. Ruppe wrote:
> On Friday, 9 February 2018 at 16:44:32 UTC, Seb wrote:
>> Forget inout, it's seldomly used and there have even attempts to remove it from the language.
>
> inout rox. I think this is more of a documentation discoverability problem. We should be having people read the spec, which is written toward compiler authors [!], when they want to just know how to use it.
>
> Here's the basic rules of thumb:
>
> If you don't need to change a variable:
>
> 1) use immutable when declaring a new variable
>
> immutable myvar = "never gonna change";
>
> 2) if you are returning a member variable or function argument, use inout on both
>
> class myclass {
>    Object member;
>    inout(Object) getMember() inout {
>        return member;
>    }
> }
>
> inout(char)* identity(inout(char)* s) {
>    return s;
> }

My main issue with inout is the following:

struct Option(T)
{
    bool isNull;
    T payload;

    this(inout(T) val) inout
    {
        payload = val;
    }

    bool opEquals(inout(T) val) inout
    {
        return !this.isNull && (this.get() == val);
    }

    inout(T) get() inout
    {
        return payload;
    }
}

struct InoutHeaven
{
    int n;
}

void main()
{
    immutable Option!InoutHeaven v1 = InoutHeaven(1);
    assert(v1 == InoutHeaven(1));
}

Everything is fine until InoutHeaven defines a custom opEquals:

struct InoutHell
{
    int n;

    bool opEquals(InoutHell other)
    {
        return n == other.n;
    }
}

void main()
{
    immutable Option!InoutHell v1 = InoutHell(1);
    //Welcome to Inout Hell >:^)
    //Error: mutable method onlineapp.InoutHell.opEquals is not callable using a inout object
    assert(v1 == InoutHell(1));
}

The really frustrating thing is that as far as I know, there's nothing you can do if you don't have control over the wrapped type. If you can't add your own inout or const opEquals method, you're screwed.

I might be wrong about this though, as I think Steven has debunked this on at least one occasion. However, I can't remember what his solution was, if there was one.

On Fri, Feb 09, 2018 at 06:20:32PM +0000, Atila Neves via Digitalmars-d wrote: [...]
> I'm perfectly happy with dub-the-package-manager.
> 
> As for dub-the-build-system, I already did something about it: I wrote reggae. Nearly all of the problems I've had with using dub to build have disappeared by just using reggae instead. There's still a few things that aren't great (`dub describe` needs some love, probably because I'm the only one parsing the output), and sometimes I run into issues that only happen using reggae, but overall, it's been a good choice. For starters, I'd much rather have all our code build in 6min as it does now than over an hour as it was before.

I've only recently started using dub, and yeah, it *may* be great as a package manager, but as a build tool, I found it extremely frustrating, slow, and not easily reconfigurable.  So much so that after struggling with it for about a week or so, I threw my hands up and went back to SCons as my go-to build system of choice.

Currently, my vibe.d project has a subdirectory containing an empty dummy dub project, the sole purpose of which is to declare vibe.d dependencies so that `dub build` in that subdirectory will fetch and build vibe.d and whatever else it may depend on, and build it into a linkable state.  Once that's done, I leave dub aside and use SCons to actually build and link my program with the libraries built by dub. This resulted in an instant improvement in my build times by (at least) half, as well as free me from needless network lookups when I'm actually coding locally and don't *need* to be upgrading dependent libraries.

This setup currently serves its purpose well enough.  But, glancing at reggae, it seems to be a flexible and interesting idea that might just suit my needs.  So I'm going to put it on my list of things to try out.


> There are assumptions in the codebase that make solving some of the issues so hard as to practically be impossible, and:
> 
> 1. I don't get paid to work on dub (I have a hard time supporting all my
> open source projects as it is!)
> 2. There are tons of things I want to do in/for D that I'm more interested
> in
> 3. As mentioned above, it's easier for me to just use reggae
[...]

Yeah, if I'm already so disinclined to use dub (or insert any other disliked software of your choice), then imagine how much motivation I have to actually invest my limited time and energy into it, as opposed to doing something else that is more interesting and more immediately relevant to my needs.

If somebody *paid* me to work on dub, then perhaps I will.  But right now, my level of motivation and interest in doing so is pretty low, and is on the losing side of the competition against the myriad other projects that I could be working on.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!

On Friday, 9 February 2018 at 18:40:25 UTC, Seb wrote:
> On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:
>> On Fri, 2018-02-09 at 16:10 +0000, Seb via Digitalmars-d wrote:
>>> 
>> […]
>>> Dub is not dead, it just has limited resources.
>>
>> So , if the D community want Dub to work as a build system as well as a package manager, extend the resources by corralling the grumblers and support them into fixing code and creating pull requests.
>
>
> I already but my limited resources into real and _merged_ pull requests for actual bugs at dlang/dub
> Please if you have ideas to motivate the grumblers to do so as well, act!

Would it make sense to split out dub's build functionality from its package management? Separate sharp tools for separate jobs.

I've only heard of Atila's reggae today. Is reggae commonly used among D users? Are there any show stoppers to using it in place of dub for building dub-managed projects?

On 8 February 2018 at 23:54, Suliman via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?
>

1. Storage class as a concept separate to the type; in my experience
responsible for almost all complexity and special casing in my generic code
2. Wrong defaults for attributes
3. string mixins always used in place of some sort of more sanitary macro
system

On 8 February 2018 at 23:54, Suliman via Digitalmars-d <[1]digitalmars-d@puremagic.com> wrote:
> 
>      I like D, but sometimes it's look like for me too complicated. Go
>      have a lot of fans even it not simple, but primitive. But some D
>      futures make it very hard to learning.
> 
>      Small list by me:
>      1. mixins
>      2. inout
>      3. too many attributes like: @safe @system @nogc etc

But none of these features are *necessary* to start coding in D. They are optional extras that are nice once you're comfortable with the language.  I got by fine for *years* without even using a single mixin, or knowing what 'inout' does, or use any attributes.

It's like human language, there's a set of core words ("basic features") that you have to know to hold a conversation, but there's a vast vocabulary of more specialized words ("advanced features") to draw from when you need to be more precise or in special situations. You don't need to know the *entire* language to be functional in it. E.g., there's a vast body of scientific vocabulary that 90% of the general population (of native English speakers) has no idea about.  Yet they can live and function in society just fine.  But that vocabulary is there when you *do* need it.

It would be a worthless language if it's extremely easy to learn but can only attain to the complexity level of baby-talk.  Turing machines technically can compute the same thing as D can, and they are about as simple as it can possibly get while still being Turing-complete.  But do you really want to write non-trivial program in Turing machine? Probably not.


On Fri, Feb 09, 2018 at 11:13:13AM -0800, Manu via Digitalmars-d wrote: [...]
>    2. Wrong defaults for attributes

Unfortunately, this is a historical accident that's not easy to fix. Short of doing a D3 iteration, but I don't see that happening anytime soon.


>    3. string mixins always used in place of some sort of more sanitary
>    macro system
[...]

That gave me a double-take.  "Sanitary" and "macro" in the same sentence?!  That's just ... I know what you *mean*, but the thought is just, wow. :-D


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

On Friday, 9 February 2018 at 18:34:33 UTC, Seb wrote:
> On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
>> Here are a few more "basics" that are unneeded or confusing. Lets not even talk about the more advanced features like inout, ...
>>
>> /-/
>>
>> * auto: Static typed language yet we fall back on the compiler to figure out what is being assigned. Can just as well have a interpreter language. It only encourages lazy writing and has a penalty on the compilation.
>
> There's almost zero/no penalty on the compilation cost.
> What's wrong with letting the compiler help you?
> If you don't like auto, simply don't use it :O

auto is prevalent in Phobos, especially in the form of Voldemort types. Speaking of which, Voldemort types are an awful idea. Often when I use Phobos, what happens is:

1. I write something like:

import somemodule : foo, bar;
bar(foo(x)); // assume a variable x is defined beforehand

2. I get a weird, long compilation error.
3. After a lot of head scratching I realize that the problem is that foo(x) doesn't satisfy bar's signature constraints.
4. I go look at the signature of foo and it tells me nothing useful because it returns a Voldemort type.
5. I go look at the documentation of foo. Usually it is frustratingly terse. Can't figure out what foo promises about its return type (is it a forward range? If my parameter type was a bidirectional range, do I get a bidirectional range back?)
6. I go to the implementation of foo and look at the definition of its return type.

So Voldemort types make you dependent on the documentation capabilities of the library author. If the documentation is bad/outdated and you don't have the source code, well, good luck with that.

On Friday, February 09, 2018 15:33:30 Andrea Fontana via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 15:05:05 UTC, Jonathan M Davis
>
> wrote:
> > [...]
> > The reality of the matter is that shared is _supposed_ to
> > result in a bunch of compilation errors when you try to do
> > stuff to it. You're supposed to either use atomics to mutate a
> > shared object or protect it with a mutex and temporarily cast
> > away shared so that you can actually do stuff with it. You're
> > really not supposed to do much with a shared object while it's
> > shared, and a lot of folks don't understand that.
> > [...]
> > - Jonathan M Davis
>
> Time to write an article/tutorial about this! Did I miss it?

No. The only article that I've actually written is the "Introduction to std.datetime" that's on the main site and really should be rewritten now that std.date is long gone. I've been intending to write more but haven't gotten around to it (in part due to a lack of time and in part, because I wanted to get my own website up so that I had a place to put articles, and I only got that up finally this morning even though I've been intending to do it for ages). I'll probably do a write-up on shared at some point precisely because we need one, but I don't know when.

- Jonathan M Davis

On Friday, February 09, 2018 15:48:42 Andrea Fontana via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 15:35:38 UTC, Mike Parker wrote:
> > On Friday, 9 February 2018 at 15:27:18 UTC, Andrea Fontana
> >
> > wrote:
> >>> If you need to take the address of a constant, use immutable or const (doesn't really matter, but I prefer immutable). If you don't need the address, use enum.
> >>
> >> Why not static immutable?
> >
> > For global scope? static has no effect there as far as I know. Looking at the ASM output on run.dlang.io, I see no difference between the two:
> >
> > static immutable foo = 10;
> > immutable bar = 20;
> >
> > LAT group
> > ;File = onlineapp.d
> >
> >     public  immutable(int) onlineapp.foo
> >     public  immutable(int) onlineapp.bar
> >
> > ...
> >
> >                 mov EDI,0Ah
> >
> >         call      @safe void
> >
> > std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
> >
> >         mov EDI,014h
> >         call      @safe void
> >
> > std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
>
> If I'm right on classes/structs static immutable != immutable. So if you need to replace enum in those cases too, static immutable works fine everywhere. Right?

static immutable works fine everywhere, but it's pointless to have the static at the module level. It's a no-op there. But for most types, enum is better, because it doesn't result in there being an object in the binary, whereas static immutable would. The cases where you'd want to avoid enums are when you really want there to be an address (e.g. for arrays other than strings, you don't want to use enums, because for them, a new dynamic array gets alloced every time you use the enum), but something like int, an enum is definitely better.

- Jonathan M Davis