February 09, 2018
On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> Which language futures by your opinion make D harder?

Not many! D is a fairly complex languague, but just about everything feels like to be here for a good reason. That includes many oft-hated things: inout, auto ref, goto, BetterC...

What I would like to remove, is auto-decoding (popular opinion, I know) and the heavy syntax when handling types: __traits, is expression, typeof and std.meta templates should be invokable in a more UFCS-like manner (But still avoiding context-dependant parsing, perhaps with a keyword before an expression used as a type in a declaration).
February 09, 2018
On Friday, 9 February 2018 at 15:25:51 UTC, jmh530 wrote:
> On Friday, 9 February 2018 at 13:47:51 UTC, Atila Neves wrote:
>> On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky
>>>
>>> And yes, things like "inout", "auto ref" or whatever, and such, strike me as indicative of more fundamental design flaws. (Not "flaw" in the sence of "mistakes" necessarily, but "flaw" in the sence of "there must be a better way to design these things...")
>>>
>>> [...]
>>
>> Yeah, something like traits in Rust or typeclasses in Haskell would be a lot better. Fortunately, one can kinda-sorta get there with a library solution. Check out `@implements` in https://github.com/atilaneves/concepts
>>
>
> I'm confused. While I get how @implements resolves the same issues as Rusts's traits, I don't see how traits resolve the same issues as inout/auto ref. My understanding is that inout and auto ref mean you don't have to write multiple versions of the relevant functions. Moreover, while one could use templates to do something similar, inout/auto ref are designed to reduce code bloat. I don't think Rust's traits can accomplish the same thing, but I'm not familiar enough with Haskell's typeclasses to know.

I must have quoted the wrong thing. I posted @implements in response to CT vs RT when it comes to interfaces. Think isInputRange vs an interface. Rust's traits allow one to use what looks like an interface in D (or Java, etc.) for compile-time contraints that also works at runtime. I wish we had that.

I wasn't saying anything about inout/auto ref although I like both of those.

Atila
February 09, 2018
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.

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

> […]

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


February 09, 2018
On Fri, 2018-02-09 at 16:17 +0000, jmh530 via Digitalmars-d wrote:
> 
[…]
> 
> He's written a build tool:
> 
> https://github.com/atilaneves/reggae

Indeed, but it seems to be gaining no traction in the community. Dub has the mindshare, because of the package repository.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


February 09, 2018
On Friday, 9 February 2018 at 15:55:27 UTC, Russel Winder wrote:
> On Fri, 2018-02-09 at 13:51 +0000, Atila Neves via Digitalmars-d wrote:
>> On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:
>> > On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
>> > > 
>> > > And not a language feature but I hate dub. Just saying.
>> > 
>> > Why do people hate dub? I think it's a great package manager and build tool
>> 
>> Great package manager? Yes.
>> 
>> Great build tool? No. For anything that's not trivial it's an exercise in frustration, pain, tears, waiting for builds to finish, and workarounds for bugs.
>
> Of course whilst people just moan nothing changes. It strikes me as time to actively evolve Dub or replace it.

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.

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

Atila

Atila
February 09, 2018
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.

/-/

* to!string, to!... requires "import std.conv"
* basic string manipulation requires "import std.string"
* join, replace, replaceInPlace, split, empty all require std.array
* ...

... these are basic language features, yet its required to included each of those libraries to every file you need it. A lot of languages have basic functions as standard or dynamically include the required code upon compilation ( or error if you have a double naming ). The time saved on auto compilation, can be reused to do the above mentioned. Two birds with one move.

/-/

* splitLines vs split .. std.array vs std.string

It confuses people because split is part of std.array but splitLines is part of std.string. Really! Most languages simply have split as a basic language feature and you indicate what you want to split.

Its not the only confusing or double function that is present in the standard library.

/-/

* 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.

/-/

If you have a few more weeks, this list is long :)

Unfortunately, because the code base it is impossible to fix these issues as too much code depends on it. The libraries, packages, ...
February 09, 2018
On Fri, Feb 09, 2018 at 05:56:38PM +0000, Dukc via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> > Which language futures by your opinion make D harder?
> 
> Not many! D is a fairly complex languague, but just about everything feels like to be here for a good reason. That includes many oft-hated things: inout, auto ref, goto, BetterC...

TBH, I'm not a fan of inout. Not because of how most people feel, that we shouldn't have it; IMO it doesn't go *far enough*.  For example, there's currently no way to express conveying the constness of a delegate argument's parameter to the return value, which would have been useful in some places in generic code.


> What I would like to remove, is auto-decoding (popular opinion, I
> know)

I would totally back up killing auto-decoding. With fire. And extreme prejudice. :-P

Unfortunately, that would also cause massive breakage of existing code, and worse yet, in some cases it will cause *silent* breakage, which is the worst of its kind.  So barring some kind of workable (probably very long) deprecation cycle, I just don't see it going away anytime in the foreseeable future.


> and the heavy syntax when handling types: __traits, is expression, typeof and std.meta templates should be invokable in a more UFCS-like manner (But still avoiding context-dependant parsing, perhaps with a keyword before an expression used as a type in a declaration).

AFAIK, __traits was never intended to be used directly in user code. The intention was to expose a raw interface into compiler internals, and then write nicer wrappers in Phobos that provide a more user-friendly API to users.

As for is-expressions, I think either Walter or Andrei (possibly both) have acknowledged that the syntax is a mess.  But too much code already depends on the current syntax, and changing that now will be far too disruptive.

As for UFCS-style template parameters, I would totally support that!! I've felt the need for it on more than one occasion.  Perhaps somebody could write up a DIP for a `.!` operator (tentative syntax) to complement the current `!` operator.  So you could write things like:

	AliasSeq!(1, 2, 3).!staticMap!(MyPredicate).!staticSort


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom
February 09, 2018
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

> /-/
>
> * to!string, to!... requires "import std.conv"
> * basic string manipulation requires "import std.string"
> * join, replace, replaceInPlace, split, empty all require std.array
> * ...
>
> ... these are basic language features, yet its required to included each of those libraries to every file you need it. A lot of languages have basic functions as standard or dynamically include the required code upon compilation ( or error if you have a double naming ). The time saved on auto compilation, can be reused to do the above mentioned. Two birds with one move.

We're getting there: https://github.com/dlang/phobos/pull/5916

> /-/
>
> * splitLines vs split .. std.array vs std.string
>
> It confuses people because split is part of std.array but splitLines is part of std.string. Really! Most languages simply have split as a basic language feature and you indicate what you want to split.
>
> Its not the only confusing or double function that is present in the standard library.

I assume you aren't aware of the superior splitter in std.algorithm?

tl;dr: split has been there before, but it's: `splitter.array`
However, we can't remove these things without breaking code.
We can only improve the documentation and tutorials, to which you are more than cordially invited.

> /-/
>
> * 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.

1) I only know about defer in Go. That's not a standard.

2) How do you do scope(failure) in Go?
Scope solves multiple uses with one nice keyword.
After all, the "thing" you are leaving is called scope.

> /-/
>
> If you have a few more weeks, this list is long :)

Please put any fixable issues / actionable ideas on Bugzilla. Thanks!

> Unfortunately, because the code base it is impossible to fix these issues as too much code depends on it. The libraries, packages, ...

Yes, but it looks like all these issues can be fixed / improved with better documentation
For example, for scope:

https://tour.dlang.org/tour/en/gems/scope-guards

If you don't like it, please improve it!
February 09, 2018
On Fri, Feb 09, 2018 at 06:44:08PM +0000, Meta via Digitalmars-d wrote:
> 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 ;-)

+1000!  (and by 1000! I mean factorial(1000) :-P)


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
February 09, 2018
On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
>
> [snip]
>
> * 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.
>
> 

I don't like any of your points, but this one stuck out...

D has had scope for years. I searched the change log and found it going back at least to 2007. What language had defer before 2007 that D could have possibly copied from?