www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Which language futures make D overcompicated?

reply Suliman <evermind live.ru> writes:
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?
Feb 08 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 02:54 AM, Suliman 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?
 


Auto-decode.

Dub.

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...")

Aside from that, I don't think features inherently make D complicated, 
but I do think there are features that are designed or implemented in 
overly-complicated ways. Or *missing* features, which by their absence 
make the langauge more complicated.

The biggest, by far, that comes to my mind is dealing with types:

- At runtime: Dealing with type infos at runtime is a mess compared to 
many other langauges (especially dynamic ones).

- At compile time: The mechanisms for dealing with type info at compile 
time seem...undesigned. It's kind of a clutter of various approaches and 
haphazard quirks, and std.traits is a testament that it's not very 
cleanly designed at the language-level.

- RT vs CT: The interfaces for dealing with types are completely 100% 
different depending whether you're working with runtime or compile-time.

Other things that come to mind:

Defining input ranges (one of my biggest pet peeves):


stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same 
approach couldn't be used in D for creating input ranges. But instead, D 
forces input ranges to be defined the same way as random-access ranges, 
which is a PITA (a necessary PITA for random-access, but unnecessary for 
mere generators like input ranges), and D provides no way around that 

from ten years ago puts us to complete shame here.

And Algebraic types. Yes, we technically have them, but compared to 
something like Nemerle, D claiming to have algebraic or pattern matching 
is like C claiming to support OO: 
Umm...sorta...technically...kinda...but...uhhh...no, not really.
Feb 09 2018
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky 
(Abscissa) wrote:


 Defining input ranges (one of my biggest pet peeves):


 stackless!!! (ie no-fibers) coroutine syntax. There's no reason 
 the same approach couldn't be used in D for creating input 
 ranges.


I'm missing too the yield return and await syntax in D every 
time. In my current asp.net project I counted around 800 await 
calls. I don't even imagine how difficult should be to translate 
this in D style.

But back to the subject:
- pure  safe nothrow  nogc
- auto const ref
- __ctfe is a variable
- traits as a library solution;
- alias this;
- calling conventions are a best kept secret.
- everything is a range. If not, we will rangify it. Autodecoded 
eventually.
- no dedicated syntax sugar for ranges;
- no dedicated syntax sugar for coroutines;
- no dedicated syntax sugar for events;
- GC is evil. OO is outdated.
- last integer promotion rules.


And not a language feature but I hate dub. Just saying.
Feb 09 2018
next sibling parent reply tetyys <tetyys tetyys.com> writes:
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
Feb 09 2018
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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.

Atila
Feb 09 2018
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
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:

=20
 And not a language feature but I hate dub. Just saying.


=20
 Why do people hate dub? I think it's a great package manager=20
 and build tool


=20
 Great package manager? Yes.
=20
 Great build tool? No. For anything that's not trivial it's an=20
 exercise in frustration, pain, tears, waiting for builds to=20
 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.


 Atila


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Feb 09 2018
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 9 February 2018 at 15:55:27 UTC, Russel Winder wrote:

 
 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.



He's written a build tool:

https://github.com/atilaneves/reggae
Feb 09 2018
parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-09 at 16:17 +0000, jmh530 via Digitalmars-d wrote:

=20


[=E2=80=A6]

=20
 He's written a build tool:
=20
 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.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Feb 09 2018
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Feb 09 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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!
Feb 09 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 02:01 PM, H. S. Teoh wrote:

 
 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.
 


I'm kind of envious of that approach, and REALLY tempted to adopt it 
myself, but there are some unfortunate probelms with it (which are 
incidentally the exact same reasons I eventually conformed and 
begrudgingly strated using dub as my main build tool, as much as I 
dislike doing so):

1. From a compiler command-line perspective, trying to incorporate 
vibe.d in a project that isn't built with dub proved in my experience to 
be a royal pain. And then upgrading to newer versions of vibe.d had a 
tendency to break it in non-obvious ways.

2. If you want your project (especially if it's a lib) to participate in 
the the dub package repository ecosystem, you pretty much have to 
support dub as a build tool. Otherwise, anyone who DOES use dub as a 
build tool will have major trouble trying to use your lib.

So even as a package manager, dub is viral. And the unfortunate 
consequence of that is that it completely divides D package ecosystem in 
two.
Feb 09 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

 On 02/09/2018 02:01 PM, H. S. Teoh wrote:

 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.


 
 I'm kind of envious of that approach, and REALLY tempted to adopt it
 myself, but there are some unfortunate probelms with it (which are
 incidentally the exact same reasons I eventually conformed and
 begrudgingly strated using dub as my main build tool, as much as I
 dislike doing so):
 
 1. From a compiler command-line perspective, trying to incorporate
 vibe.d in a project that isn't built with dub proved in my experience
 to be a royal pain. And then upgrading to newer versions of vibe.d had
 a tendency to break it in non-obvious ways.


Really?  I haven't had too much trouble with it.  I've been updating
vibe.d from git master occasionally, and the worst that has happened is
that I need to run `dub build --force` to force rebuild of all dependent
libraries, and/or parse dub's output to update the list of libraries /
import paths in my build script.  Sometimes updating Phobos will break
the build because of changes in template symbols and what-not, but so
far `dub build --force` has been the escape ticket.

The biggest up-front cost is to generate that initial list of import
paths and libraries needed to get the thing to build.  It's not *hard*,
but does require parsing the last few (very long) lines of dub output
(IIRC you need -v to see it).  But since that list changes from time to
time, I'm actually tempted to write a script to parse the dub output and
generate the import/library list automatically.  Then it will become
painless to build things this way. :-D



 2. If you want your project (especially if it's a lib) to participate
 in the the dub package repository ecosystem, you pretty much have to
 support dub as a build tool. Otherwise, anyone who DOES use dub as a
 build tool will have major trouble trying to use your lib.
 
 So even as a package manager, dub is viral. And the unfortunate
 consequence of that is that it completely divides D package ecosystem
 in two.


Yeah, more and more, it's giving me the impression of being a walled
garden.  You either have to buy into it wholesale, or you're left out in
the cold. :-(  It wouldn't have been such a bad proposal if said walled
garden had nice things going for it... but given dub's limitations, it
feels almost like a prison sentence.


T

-- 
Two wrongs don't make a right; but three rights do make a left...
Feb 09 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 06:03 PM, H. S. Teoh wrote:

 On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

 On 02/09/2018 02:01 PM, H. S. Teoh wrote:

 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.


 I'm kind of envious of that approach, and REALLY tempted to adopt it
 myself, but there are some unfortunate probelms with it (which are
 incidentally the exact same reasons I eventually conformed and
 begrudgingly strated using dub as my main build tool, as much as I
 dislike doing so):

 1. From a compiler command-line perspective, trying to incorporate
 vibe.d in a project that isn't built with dub proved in my experience
 to be a royal pain. And then upgrading to newer versions of vibe.d had
 a tendency to break it in non-obvious ways.


 
 The biggest up-front cost is to generate that initial list of import
 paths and libraries needed to get the thing to build.  It's not *hard*,
 but does require parsing the last few (very long) lines of dub output
 (IIRC you need -v to see it).  But since that list changes from time to
 time, I'm actually tempted to write a script to parse the dub output and
 generate the import/library list automatically.  Then it will become
 painless to build things this way. :-D


Yea, *that's* the stuff that gave me trouble. It was also the motivation 
for my "dub describe --data=..." PR, but afterwords I felt like that 
still wasn't quite as good as I wanted, and dub's internal code just 
didn't seem designed to handle that sort of thing anyway (though maybe 
that's improved now?).


 Yeah, more and more, it's giving me the impression of being a walled
 garden.  You either have to buy into it wholesale, or you're left out in
 the cold. :-(  It wouldn't have been such a bad proposal if said walled
 garden had nice things going for it... but given dub's limitations, it
 feels almost like a prison sentence.


Definitly. A big part of the problem was, at least in the early days, 
the author was very clear that it expressly wasn't intended to cover the 
needs of 100% of packages, just like 99% or whatever. On top of that, 
certain design considerations which were *intended* to avoid 
fragmentation within the dub package ecosystem had the unintended 
consequence of forcing a divide between "dub packages which have the 
luxury of playing by dub's rules" and "non-dub packages which *don't* 
have that luxury". I think that's ultimately what led to the probelms we 
have with dub, and I think solving them properly requires undoing years 
fundamental dub design was that built directly upon those early 
philosophies.
Feb 09 2018
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 9 February 2018 at 19:01:30 UTC, H. S. Teoh wrote:


 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


I've paid John Colvin in the past out of my own pocket to work on 
dub.  Some of our pull requests were accepted, some are stuck in 
the queue. We have too much to do currently for core people to 
work on it, but if there are things that would make a difference 
for us and others we could explore sponsoring further development.

If we could make a list of what needs doing that is interesting 
to you to fix and order of magnitude how long things might take, 
I could consider that.  I think you have my email.


Laeeth
Feb 17 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 10:55 AM, Russel Winder wrote:

 
 Of course whilst people just moan nothing changes. It strikes me as
 time to actively evolve Dub or replace it.
 


A replacement package manager[1] has been on my pet project wish list 
for awhile, but so are a ton of other things and there's not much of me 
to go around. :(

[1] Hopefully backwards compatable with dub packages as much as 
possible, though I don't know how realistic that is given dub's enormous 
complexity.
Feb 09 2018
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
Dub is getting some flak here. This is unsurprising because it is 
really hard to write a good package manager and build system. I 
use a lot of languages and not one has a satisfactory package 
manager. Mostly they try to do too much and get in the way or 
they do too little and people complain (I prefer the second 
option). And when there are 100+ dependencies, like with Go and 
Node, it just becomes impossible to say anything about the state 
of the system (security, anyone?).

Package management is mostly dependency management. This I handle 
with GNU Guix (and Nix) package managers. They are great at that. 
This also leaves people to choose any old build system. Inside 
GNU Guix the build system is consistent, which is really nice. 
I'll write a blog some time this year.

What you really want is to be able to discover packages (i.e., a 
website such as Dub provides), pull them into your tree (which is 
just a path and can be handled by git submodules, though I don't 
like those much either), and when you distribute: add them to 
Guix or Nix and provide those packages with build system and as 
binary deployments to others. These package managers give control 
over the full dependency graph, including shared libraries all 
the way down to glibc.

I am not posting this to plug these systems per se. Just saying 
that writing a generic package manager is hard and is better left 
to systems that solve handling the full dependency graph 
correctly. Personally, I am happy very happy with what Guix gives 
me. Can't think of a better way. I have no reason to use dub.
Feb 10 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/11/2018 01:54 AM, Pjotr Prins wrote:

 Dub is getting some flak here. This is unsurprising because it is really 
 hard to write a good package manager and build system. I use a lot of 
 languages and not one has a satisfactory package manager. Mostly they 
 try to do too much and get in the way or they do too little and people 
 complain (I prefer the second option). And when there are 100+ 
 dependencies, like with Go and Node, it just becomes impossible to say 
 anything about the state of the system (security, anyone?).
 
 Package management is mostly dependency management. This I handle with 
 GNU Guix (and Nix) package managers. They are great at that.



around distros, never finding one I like:

They're all completely fucking non-standard. Every fucking distro has 
it's own damn package manager (and then there's mac and win and the 
mobiles), and on top of that, most of those system managers are almost 
completely worthless *when* you need something other then "the latest 
version" let alone multiple versions (because "newer is always better" 

programming langauges have NEEDED to start rolling their own damn 
package managers, because relying on the goddamn system managers for 
libs is a complete fucking non-starter.

(Hmm, Can you tell I'm not happy with system package managers? ;) )

The langauge-based package managers just simply need to keep 
"buildsystem" OUT of the package manager's scope. That's all. THAT is 
why system-level packages can be built with whatever tool: because the 
one thing the system package managers actually do get right is NOT 
rolling their own mandatory buildsystem.

One of the things on my master list of "project's I'll probably never 
get around to" is a CLI front-end to unify all this fractured 
apt/pacman/yum crap.


 This also 
 leaves people to choose any old build system. Inside GNU Guix the build 
 system is consistent, which is really nice. I'll write a blog some time 
 this year.
 
 What you really want is to be able to discover packages (i.e., a website 
 such as Dub provides), pull them into your tree (which is just a path 
 and can be handled by git submodules, though I don't like those much 
 either),


Agreed.


 and when you distribute: add them to Guix or Nix and provide 
 those packages with build system and as binary deployments to others. 


And fracture the hell out of your user-base, forcing even Linux alone to 
be treated as 100 different fucking incompatable operating systems for 
which each package only supports one or two? Ugh, god no. Spare me. Even 
dub, for all it's shortcomings at LEAST has absolutely no trouble 
treating nearly all of Linux as ONE unified target.
Feb 11 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d 
wrote:

 The langauge-based package managers just simply need to keep
 "buildsystem" OUT of the package manager's scope. That's all. THAT is
 why system-level packages can be built with whatever tool: because the
 one thing the system package managers actually do get right is NOT
 rolling their own mandatory buildsystem.


I'm not sure that it's entirely a bad thing that dub includes a build system
in it, since it's the ease of use of its build system that is part of why
it's so worth using. It's just that its simplicity is also part of why it
doesn't work well once you get out of the basic situation of "here's a group
of D files that need to be compiled together as a library or application."

So, I do agree that in principle, we would be much better off if dub weren't
so tightly coupled with its build system. If dub were defined in a way that
allowed packages to use whatever build system they wanted so long as they
provided the build artifacts in a standard way to the package manager so
that they could be linked into other dub projects, we'd have something a lot
more flexible. And if done right, I think that it would be much better.
dub's default build system could still be used, but it wouldn't be forced.

The problem with that approach though (and part of why I think dub doesn't
do that) is that if dub really is set up with the idea that you use whatever
build system you want, then you have the issue of whether the system doing
the build has all of the necessary software to do the build. Dub doesn't
completely avoid that as-is, since you can depend on certain libraries being
on the system, and you can't write scripts to be run as part of the build
which could then require who-knows-what on the system (they're just
difficult to get to work with dub in a number of cases because of how much
dub assumes). But if dub itself were designed with the idea that you could
use cmake, scons, make, or whatever build system anyone felt like putting
together, then there's a fairly high chance when you go to pull in a package
from dub that it's going to require stuff to build that you don't have on
your system, and since you frequently end up pulling in packages recursively
such that you could be using dub packages that you've never even heard of,
it could become difficult to ensure that you have everything you need to
build everything in the dub package chain.

So, dub's solution of targeting a single build system side steps that issue
to a great extent - not entirely, but enough that it doesn't tend to be a
problem. And on some level, that's a good thing, but it comes at a definite
cost when you actually need something fancier.

So, I don't know what the right solution is. I'd like to see dub do better
interacting with arbitrary build systems, and if that can be done well, I
think that dub would be much better, but it's a hard problem. Ultimately
though, dub seems to have been designed to solve the common case while not
really making the general case very tractable (maybe not impossible, but
definitely difficult), but its place as the way the way to pull in 3rd party
libraries in D means that it arguably needs to be doing more than just solve
the common case, or 3rd party libraries that don't work with the common case
become intractable, which is definitely not good.

We would probably be better off if someone could come up with an alternate
package manager that was at least compatible enough with dub to use
libraries that use dub so that it could both work with dub and compete with
it and maybe ultimatelly get things right, but package and build management
is one of those hard problems that no one wants to work on, and plenty of
folks like to complain about.

As with too much around here, a big part of the issue is ultimately man
power. Even if we could all agree on exactly how D's build and package
management situation should be solved, actually get the work done is a huge
problem.

- Jonathan M Davis
Feb 11 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/11/2018 09:01 PM, Jonathan M Davis wrote:

 On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d
 wrote:

 The langauge-based package managers just simply need to keep
 "buildsystem" OUT of the package manager's scope. That's all. THAT is
 why system-level packages can be built with whatever tool: because the
 one thing the system package managers actually do get right is NOT
 rolling their own mandatory buildsystem.


 
 I'm not sure that it's entirely a bad thing that dub includes a build system
 in it, since it's the ease of use of its build system that is part of why
 it's so worth using. It's just that its simplicity is also part of why it
 doesn't work well once you get out of the basic situation of "here's a group
 of D files that need to be compiled together as a library or application."


You're right, of course. I guess I wasn't clear about this, and frankly 
I even lost sight of it, but if it HAD been easy and clear to just say 
"hey, dub, I'm bringing along my own buildsystem and opting out of 
yours, ok? thanks dude" and that was that, no muss, no fuss, no 
"tricking" dub into doing what I need, I would've been fine with that.

The problem is that, in my experience, dub's assumptions about it doing 
your build for you tend to be so deeply ingrained into the way it and 
its configuration format all work, that I just don't see attempts to 
separate them out as likely work out all that well. If even at all.

Heck, at this point I feel like most of my attempts to get dub to do 
anything I have in mind have wound up being less "what is the directive 
to do that?" and more "How to I nudge, persuade, or outright trick dub 
into doing what I need?" Even if I just have a compiler switch I want to 
use, or not use, I can't *just use it*. Best case scenario, dub will 
brand my library with a big ugly warning when anyone uses it. More 
likely, I have to go translate it into dub-speak (if I'm LUCKY), or, all 
too frequently, I find myself flailing around, trying to find just the 
right combination of settings to *coax* dub's behavior.

This is a completely *typical* dub experience for me, and frankly, one 
of the more *pleasant* ones:
https://github.com/atilaneves/unit-threaded/issues/106

Did you know dub behaves *differently* if your test configuration is 
named "unittest" verses when it has a different name? I didn't. 
Principle of most surprise, I guess.

THIS is me using dub. Flawless illustration:
https://www.youtube.com/watch?v=QvcFRgJwE2k&t=0m12s


 The problem with that approach though (and part of why I think dub doesn't
 do that) is that if dub really is set up with the idea that you use whatever
 build system you want, then you have the issue of whether the system doing
 the build has all of the necessary software to do the build.  Dub doesn't
 completely avoid that as-is, since you can depend on certain libraries being
 on the system,
 [...]But if dub itself were designed with the idea that you could
 use cmake, scons, make, or whatever build system anyone felt like putting
 together, then there's a fairly high chance when you go to pull in a 


package

 from dub that it's going to require stuff to build that you don't have on
 your system, and since you frequently end up pulling in packages 


recursively

That's why the way it *should* work is: If your build has a dependency 
(another .d lib, a C lib, cmake, rake, scons, whatever), you make a dub 
package for it if there isn't already one. Problem solved.

But once again, dub's assumption that *everything* is a set of *.d files 
for it to complile gets in the way here too.


 So, dub's solution of targeting a single build system side steps that issue
 to a great extent - not entirely, but enough that it doesn't tend to be a
 problem. And on some level, that's a good thing,


No, all it does it create problems and prevent workarouds, as described 
above. If a package needs, ex, scons, to build, it should be simple to 
create a dummy dub package for scons that (best case) offers to install 
scons for you, maybe even a local non-system-wide installation, or at 
the very least, tells the user, "hey, scons not detected, it's a 
dependncy of this package, so you need to install it."

After all, managing dependencies are what package managers are all 
about, and dub isn't handling it very well when it comes to tool 
dependencies (as opposed to "a library of .d files to be linked in" 
dependencies, which is really all it's designed for).


 
 So, I don't know what the right solution is.


The right solution is to give up on dub, as it's too far down the wrong 
design road, and have a package manager that's designed from the ground 
up to be a package manager (not a simplified buildsystem that happens to 
also include dependency-handling features). As a package manager, 
*anything* the package needs, a D library, a C library, an external 
tool, even a compiler version and the package manager itself...is just 
another dependency for the package manager to handle.

I should point out, strong as I may feel about all this, I don't mean to 
be too much of a dick about dub. I'm well aware how much effort went 
into dub, and I *do* respect that. Frankly, I've always been absolutely 
*stunned* by just how much Sonke accomplishes. Beyond me how he manages 
to do all that: I know I certainly couldn't. It seems superhuman! And I 
am grateful there's been at least SOMETHING for D package management.

It's just, from a technical perspective looking toward the 
near/mid-future, I just have a hard time seeing dub getting to where we 
really need a D package manager to be, and I admit I've gotten to the 
point of real frustration.
Feb 11 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, February 11, 2018 19:01:09 Jonathan M Davis via Digitalmars-d 
wrote:

 As with too much around here, a big part of the issue is ultimately man
 power. Even if we could all agree on exactly how D's build and package
 management situation should be solved, actually get the work done is a
 huge problem.


On that note, I feel that I really should thank Sonke and those few that
have helped him write dub. As much as I think that some aspects of dub need
to be redesigned, at least they actually went and did something and managed
to get it to take off enough that there are quite a few D libraries
available using dub. So, while the solution may not be what we want, at
least we have a solution.

And even if someone else does come along and put in the time and effort like
the dub folks did but comes up with a solution that we like better, the new
solution will undoubtedly benefit from seeing what has and hasn't worked for
us with dub.

And maybe dub itself will be reworked to be where we want things to do be,
but either way, it requires more manpower, and at least right now, we have
_something_, even if it's far from perfect.

- Jonathan M Davis
Feb 11 2018
parent Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Monday, 12 February 2018 at 02:31:38 UTC, Jonathan M Davis 
wrote:

 On Sunday, February 11, 2018 19:01:09 Jonathan M Davis via 
 Digitalmars-d wrote:

 As with too much around here, a big part of the issue is 
 ultimately man power. Even if we could all agree on exactly 
 how D's build and package management situation should be 
 solved, actually get the work done is a huge problem.


 On that note, I feel that I really should thank Sonke and those 
 few that have helped him write dub. As much as I think that 
 some aspects of dub need to be redesigned, at least they 
 actually went and did something and managed to get it to take 
 off enough that there are quite a few D libraries available 
 using dub. So, while the solution may not be what we want, at 
 least we have a solution.


Absolutely. Dub gets criticism because it is used which is an 
indicator of a successful piece of work. Kudos for anyone who 
pulls that off. Now we just find it is hard to do this well.

As someone involved with software distribution and deployment in 
production systems, my suggestion is to limit the scope of the 
package manager. Best have to do it little, but do it well and 
make most of existing solutions. The goal should really be 
package discovery and making it easy for beginners (autotools and 
configure does not do today, though C gets away with it). 
Thereafter comes a point you have to hand over the deployment 
issue. I strongly suggest not to make it complicated and not to 
try to create a homogeneous development system for all targets. 
I'll write up how I manage my development and deployment some 
time later this year, it may or may not be a good example ;)
Feb 11 2018
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2018-02-11 at 19:31 -0700, Jonathan M Davis via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 On that note, I feel that I really should thank Sonke and those few
 that
 have helped him write dub. As much as I think that some aspects of
 dub need
 to be redesigned, at least they actually went and did something and
 managed
 to get it to take off enough that there are quite a few D libraries
 available using dub. So, while the solution may not be what we want,
 at
 least we have a solution.


Indeed.

And so inexorably an email thread fades into the distance and nothing
gets done because nobody with an opinion writes code, they just write
emails.=20

Your working on dxml is excellent proof of this. Once someone actually
starts writing code things happen. It is after all how we ended up with
Dub. Sonke et al. wrote code whilst everyone else just sounded off
writing emails. Atila wrote code to solve his pain with Dub.

I am happy to write code rather than emails, well once ACCU 2018 is
over anyway. But I am not going to do anything of this sort purely on
my own, it is too big, it needs people supporting as well as one (or
preferably more) doing. To date no-one other than me seems to have
shown any intention of writing code in support of the professed pain
with Dub.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Feb 12 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 08:51 AM, Atila Neves wrote:

 On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:

 Why do people hate dub? I think it's a great package manager and build 
 tool


 
 Great package manager? Yes.
 
 Great build tool? No.


I used to feel the same way, but honestly, at this point, I have to 
conclude dub sucks as a package manager too just *because* it's such a 
rediculous pain to opt-out of all it's weak points, like using it as a 
build tool. Particularly if you're a library author.
Feb 09 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 09, 2018 13:34:01 tetyys via Digitalmars-d 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


I don't know what all of the reasons are, but as a build tool, it needs
work. It works well for the common case, but as soon as you need to do
anything fancier than simply building every module in your project, it
starts getting really hard to do with dub if it's possible at all. It really
isn't very flexible. The other issue that gets complained about a lot is how
slow it is, which if I understand correctly is primarily due to how much
network traffic it has in order to check the status of repos, but
regardless, it's generally far slower than simply using dmd or rdmd
directly. I don't think that any of dub's problems are fatal, but I also
don't think that dub gets a lot of attention, particularly since the guy
behind it is the same guy who's behined vibe.d, and there's only so much of
him to go around. It could really use more people taking the time to improve
it - but that's true of far too much around here. Fortunately, in spite of
that, dub has improved over time, but not quickly.

- Jonathan M Davis
Feb 09 2018
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
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


1. Keeps data in the %APPDATA%/Roaming folder. Connecting my 
computer to the company network means that AD will sync zillions 
of files on the company profile server. This issue is 4 years 
old: https://github.com/dlang/dub/issues/229
2. It's painfully slow.
3. As a library provider, you have a lot to learn about 
configuration file format (2 formats).
4. Not integrated in Visual Studio. I know, I am a lazy and 
convenient Windows user and the small black window called cmd 
scares the sh*t out of me.
Feb 09 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-09 at 14:04 +0000, rumbu via Digitalmars-d wrote:

=20


[=E2=80=A6]

 1. Keeps data in the %APPDATA%/Roaming folder. Connecting my=20
 computer to the company network means that AD will sync zillions=20
 of files on the company profile server. This issue is 4 years=20
 old: https://github.com/dlang/dub/issues/229


Have you put forward a pull request to fix it, and tests obviously.

4 year old issues just mean no-one cares about it enough to do
something.

4 year old pull requests is time to fork the project with a new team of
developers.


 2. It's painfully slow.
 3. As a library provider, you have a lot to learn about=20
 configuration file format (2 formats).


Neither of which are really acceptable. :-(


 4. Not integrated in Visual Studio. I know, I am a lazy and=20
 convenient Windows user and the small black window called cmd=20
 scares the sh*t out of me.


Isn't that a "create a VS plugin" problem?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Feb 09 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Friday, 9 February 2018 at 15:53:47 UTC, Russel Winder wrote:

 Have you put forward a pull request to fix it, and tests 
 obviously.

 4 year old issues just mean no-one cares about it enough to do 
 something.

 4 year old pull requests is time to fork the project with a new 
 team of developers.


Dub is not dead, it just has limited resources.
In fact, we fixed quite an annoying ecosystem bug a few days ago:

https://github.com/dlang/dub/pull/1339

 Russel: AFAICT there wasn't a PR.
Feb 09 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-02-09 at 16:10 +0000, Seb via Digitalmars-d wrote:

=20


[=E2=80=A6]

 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.


 [=E2=80=A6]


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Feb 09 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
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)
Feb 09 2018
parent reply John Gabriele <jgabriele fastmail.fm> writes:
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?
Feb 09 2018
parent John Gabriele <jgabriele fastmail.fm> writes:
On Friday, 9 February 2018 at 19:08:36 UTC, John Gabriele wrote:

 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?


Ah. I see that I should probably first look into Meson and SCons 
as well as Reggae.
Feb 09 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2018 01:13 PM, 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.
 
 Whilst grumbles on the email list are not turned into evolution of Dub,
 the D ecosystem does progress.
 

 […]


 


Been there, done that, put enormous work into it, a TON of arguing to 
little avail, found the code architecture difficult to work with, and 
ultimately my merged PRs barely made a dent at solving my issues. Gave 
up. I'm convinced the problems with dub are fundamental and often 
philosophical.

After my experience tring to improve dub, I'm 100% convinced what we 
need is a package manager designed from the ground up to NOT be anything 
but a package manager.



 Feb 09 2018



  parent reply Russel Winder <russel winder.org.uk>  writes:


On Fri, 2018-02-09 at 17:20 -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

=20


[=E2=80=A6]

 Been there, done that, put enormous work into it, a TON of arguing
 to=20
 little avail, found the code architecture difficult to work with,
 and=20
 ultimately my merged PRs barely made a dent at solving my issues.
 Gave=20
 up. I'm convinced the problems with dub are fundamental and often=20
 philosophical.


The vocal minority of the moment is very anti-Dub as build tool, hence
Atila wrote Reggae, and may put renewed effort into D support for
SCons, CMake, and Meson.

To have the debate now is different to having the debate then. Then
there was no data, just effort that created Dub, Dub was the only
constructive activity at the time.=20

Now we have a package system, that perhaps needs evolution, Dub as a
build system, plus further work on SCons, CMake, Meson, the creation of
Reggae, and Cargo which proves that what Dub was trying to do is not
impossible.


 After my experience tring to improve dub, I'm 100% convinced what we=20
 need is a package manager designed from the ground up to NOT be
 anything=20
 but a package manager.


Given Cargo is that actually true?

It is though a crucial question, along with, should the D community
line up behind Reggae as a build framework?

Clearly SCons, CMake, and Meson will continue to be there, but efforts
to evolve them could be redirected in a combined effort to create a
better standard system.

Whilst Cargo is the Rust default system, many use it just for package
management, not as a build system =E2=80=93 though I don't I just use Cargo=
.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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



 Feb 11 2018



  parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 11/02/2018 10:54 AM, Russel Winder wrote:

 On Fri, 2018-02-09 at 17:20 -0500, Nick Sabalausky (Abscissa) via
 Digitalmars-d wrote:


 […]

 Been there, done that, put enormous work into it, a TON of arguing
 to
 little avail, found the code architecture difficult to work with,
 and
 ultimately my merged PRs barely made a dent at solving my issues.
 Gave
 up. I'm convinced the problems with dub are fundamental and often
 philosophical.


 
 The vocal minority of the moment is very anti-Dub as build tool, hence
 Atila wrote Reggae, and may put renewed effort into D support for
 SCons, CMake, and Meson.
 
 To have the debate now is different to having the debate then. Then
 there was no data, just effort that created Dub, Dub was the only
 constructive activity at the time.


It wasn't.
I was working on my own build system with dependency management when dub 
was created. I stopped after dub was first released because it meet my 
every need for a D build manager.



 Feb 11 2018



  parent reply Russel Winder <russel winder.org.uk>  writes:


On Sun, 2018-02-11 at 10:59 +0000, rikki cattermole via Digitalmars-d
wrote:

=20


[=E2=80=A6]


 I was working on my own build system with dependency management when
 dub=20
 was created. I stopped after dub was first released because it meet
 my=20
 every need for a D build manager.


Hopefully it still works for you.

Clearly though there is a problem with Dub as a build system for many
of it's users =E2=80=93 or rather people who try and reject.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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



 Feb 11 2018



 next sibling parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 11/02/2018 11:18 AM, Russel Winder wrote:

 On Sun, 2018-02-11 at 10:59 +0000, rikki cattermole via Digitalmars-d
 wrote:


 […]
 

 I was working on my own build system with dependency management when
 dub
 was created. I stopped after dub was first released because it meet
 my
 every need for a D build manager.


 
 Hopefully it still works for you.


Perfectly.


 Clearly though there is a problem with Dub as a build system for many
 of it's users – or rather people who try and reject.


Put simply, they expect far too much.
Dub's scope is limited, lets not forget that.



 Feb 11 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d 
wrote:

 On 11/02/2018 11:18 AM, Russel Winder wrote:

 Clearly though there is a problem with Dub as a build system for many
 of it's users – or rather people who try and reject.


 Put simply, they expect far too much.
 Dub's scope is limited, lets not forget that.


The problem with that is that if dub is the way to build D projects in
general, then it needs to be able to do pretty much whatever you need to do
for pretty much any project - even if that involves backdoors. You need to
be able to do arbitrary stuff with your builds.

It's not as critical for applications so long as dub provides an easy way to
link in any libraries that it pulls in, but dub needs to be able to build
libraries no matter what crazy stuff you need to do, otherwise, those
libraries can't interact with the dub ecosystem, and dub is how D projects
in general pull in their dependencies.

So, for instance, if your D library has to build C or C++ code and link that
in as part of what it does, that needs to be possible with dub, even if dub
itself doesn't handling building code that isn't D. Also, if you need to
generate code as part of your build and then build those files, that needs
to be possible. And the way that dub is set up at this point, that sort of
stuff is rather difficult to do.

dub wouldn't have to be all that powerful if it were simply a handy build
tool for the average use case, but when it's tied in to package management
for D libraries and is the primary way that D projects pull in libraries, it
needs to be far more than a simple build tool. And right now, it's not far
enough away from being a simple build tool.

- Jonathan M Davis



 Feb 11 2018



  parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 11/02/2018 11:40 AM, Jonathan M Davis wrote:

 On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d
 wrote:

 On 11/02/2018 11:18 AM, Russel Winder wrote:

 Clearly though there is a problem with Dub as a build system for many
 of it's users – or rather people who try and reject.


 Put simply, they expect far too much.
 Dub's scope is limited, lets not forget that.


 
 The problem with that is that if dub is the way to build D projects in
 general, then it needs to be able to do pretty much whatever you need to do
 for pretty much any project - even if that involves backdoors. You need to
 be able to do arbitrary stuff with your builds.
 
 It's not as critical for applications so long as dub provides an easy way to
 link in any libraries that it pulls in, but dub needs to be able to build
 libraries no matter what crazy stuff you need to do, otherwise, those
 libraries can't interact with the dub ecosystem, and dub is how D projects
 in general pull in their dependencies.
 
 So, for instance, if your D library has to build C or C++ code and link that
 in as part of what it does, that needs to be possible with dub, even if dub
 itself doesn't handling building code that isn't D. Also, if you need to
 generate code as part of your build and then build those files, that needs
 to be possible. And the way that dub is set up at this point, that sort of
 stuff is rather difficult to do.
 
 dub wouldn't have to be all that powerful if it were simply a handy build
 tool for the average use case, but when it's tied in to package management
 for D libraries and is the primary way that D projects pull in libraries, it
 needs to be far more than a simple build tool. And right now, it's not far
 enough away from being a simple build tool.
 
 - Jonathan M Davis


Dub can do everything that you have described.
You are fully free to run cmake if you wish before the build. Will it 
result in binaries that are decent? Probably not for most use cases.

Its a hard problem to solve, I just wish people respected dub's scope 
more. Because it is very decently well scoped for its job already.



 Feb 11 2018



 next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/11/2018 06:47 AM, rikki cattermole wrote:

 
 Dub can do everything that you have described.


No it can't. Not if you value your time and sanity.


 You are fully free to run cmake if you wish before the build. Will it 
 result in binaries that are decent? Probably not for most use cases.
 


I *have* taken exactly that approach. It caused me literally years of 
unending greif, even single-handedly turned me away from doing much in D 
for a long while, and ultimately just proved intractable. Abandoning dub 
*entirely* is actually *easier* than trying to use it *only* as a 
package manager. But if you're putting out a D lib, you can't do that 
because people expect a lib to be part of a package system (for good 
reason).



 Feb 11 2018



  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


On Monday, 12 February 2018 at 01:45:42 UTC, Nick Sabalausky 
(Abscissa) wrote:

 But if you're putting out a D lib, you can't do that because 
 people expect a lib to be part of a package system (for good 
 reason).


Yeah, this drives me nuts too. Most "bugs" I hear are just dub 
being weird (like mine I put as "Sourcelibrary" and it works fine 
if you use one... but if it is included by some other lib as some 
other build, it now conflicts. What I wish it did was just 
realize the package is already a dependency and reuse it! But it 
doesn't seem to work that way.)

And dub's search is kinda bad and the index is just flat-out 
awful, which does more harm than good. People do the 
code.dlang.org search, something doesn't come up, so they assume 
it isn't there even when it is.

I've considered doing a new package website with a new search, 
using dub's official stuff just as a backend api, coupled with 
docs available online. I think I can fix a bunch of those 
frontend problems with it. But I just a lot of higher priority 
stuff to do (like actually writing my libs!) so I haven't gotten 
around to it.



 Feb 11 2018



prev sibling  parent reply aberba <karabutaworld gmail.com>  writes:


On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole 
wrote:

 On 11/02/2018 11:40 AM, Jonathan M Davis wrote:

 On Sunday, February 11, 2018 11:26:30 rikki cattermole via 
 Digitalmars-d
 wrote:

 On 11/02/2018 11:18 AM, Russel Winder wrote:

 Clearly though there is a problem with Dub as a build system 
 for many
 of it's users – or rather people who try and reject.


 Put simply, they expect far too much.
 Dub's scope is limited, lets not forget that.


 
 The problem with that is that if dub is the way to build D 
 projects in
 general, then it needs to be able to do pretty much whatever 
 you need to do
 for pretty much any project - even if that involves backdoors. 
 You need to
 be able to do arbitrary stuff with your builds.
 
 It's not as critical for applications so long as dub provides 
 an easy way to
 link in any libraries that it pulls in, but dub needs to be 
 able to build
 libraries no matter what crazy stuff you need to do, 
 otherwise, those
 libraries can't interact with the dub ecosystem, and dub is 
 how D projects
 in general pull in their dependencies.
 
 So, for instance, if your D library has to build C or C++ code 
 and link that
 in as part of what it does, that needs to be possible with 
 dub, even if dub
 itself doesn't handling building code that isn't D. Also, if 
 you need to
 generate code as part of your build and then build those 
 files, that needs
 to be possible. And the way that dub is set up at this point, 
 that sort of
 stuff is rather difficult to do.
 
 dub wouldn't have to be all that powerful if it were simply a 
 handy build
 tool for the average use case, but when it's tied in to 
 package management
 for D libraries and is the primary way that D projects pull in 
 libraries, it
 needs to be far more than a simple build tool. And right now, 
 it's not far
 enough away from being a simple build tool.
 
 - Jonathan M Davis


 Dub can do everything that you have described.
 You are fully free to run cmake if you wish before the build.


I wish complaints about Dub would include exactly what was 
impossible with it. There's no reason to throw dub away and start 
something new. If one can run cmake before build in dub,  then a 
lot is possible. Those edge cases can be ironed out.

Dub fulfills all my use cases so I don't complain. Those here 
with not much issue with dub will also not complain. And that 
does not make it a minority opinion without stats to prove dub 
usage.

At point, dub will likely remain the default package management 
tool. The build functionality can be improved for those who deal 
with such stuff often. Manpower is what remains.



 Will it result in binaries that are decent? Probably not for 
 most use cases.


Can you file a bug report on this?


 Its a hard problem to solve, I just wish people respected dub's 
 scope more. Because it is very decently well scoped for its job 
 already.


Same opinion here.



 Feb 13 2018



 next sibling parent  rikki cattermole <rikki cattermole.co.nz>  writes:


On 13/02/2018 10:45 AM, aberba wrote:

 On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole wrote:


snip


 Will it result in binaries that are decent? Probably not for most use 
 cases.


 Can you file a bug report on this?


Nah this should remain out of scope.
If binary (from e.g. cmake) exists, do not run cmake. Easy!



 Feb 13 2018



prev sibling  parent reply Russel Winder <russel winder.org.uk>  writes:


On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:

=20


[=E2=80=A6]

 I wish complaints about Dub would include exactly what was=20
 impossible with it. There's no reason to throw dub away and start=20
 something new. If one can run cmake before build in dub,  then a=20
 lot is possible. Those edge cases can be ironed out.


I think there have been many actual complaints made in detail in this
thread.

There is always a reason to replace, because you can build on what has
gone before and do better. CMake is part of the problem.


 Dub fulfills all my use cases so I don't complain. Those here=20
 with not much issue with dub will also not complain. And that=20
 does not make it a minority opinion without stats to prove dub=20
 usage.


No problem, and I guess you'll be happy to carry on using Dub after
something new and better appears. In the case of Maven =E2=86=92 Gradle, ma=
ny
people still use Maven even though it is provably inferior to Gradle
simply because they cannot be bothered to change.


 At point, dub will likely remain the default package management=20
 tool. The build functionality can be improved for those who deal=20
 with such stuff often. Manpower is what remains.


[=E2=80=A6]

Why should Dub remain the one true way? Just because it was the first
doesn't mean it is the best.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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



 Feb 13 2018



  parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 13/02/2018 11:11 AM, Russel Winder wrote:

 On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d wrote:


 […]

 I wish complaints about Dub would include exactly what was
 impossible with it. There's no reason to throw dub away and start
 something new. If one can run cmake before build in dub,  then a
 lot is possible. Those edge cases can be ironed out.


 
 I think there have been many actual complaints made in detail in this
 thread.
 
 There is always a reason to replace, because you can build on what has
 gone before and do better. CMake is part of the problem.
 

 Dub fulfills all my use cases so I don't complain. Those here
 with not much issue with dub will also not complain. And that
 does not make it a minority opinion without stats to prove dub
 usage.


 
 No problem, and I guess you'll be happy to carry on using Dub after
 something new and better appears. In the case of Maven → Gradle, many
 people still use Maven even though it is provably inferior to Gradle
 simply because they cannot be bothered to change.
 

 At point, dub will likely remain the default package management
 tool. The build functionality can be improved for those who deal
 with such stuff often. Manpower is what remains.


 […]
 
 Why should Dub remain the one true way? Just because it was the first
 doesn't mean it is the best.


It wasn't the first and it was the best in over a 10 year period.



 Feb 13 2018



  parent reply Andre Pany <andre s-e-a-p.de>  writes:


On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole 
wrote:

 On 13/02/2018 11:11 AM, Russel Winder wrote:

 On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d 
 wrote:


 […]

 I wish complaints about Dub would include exactly what was
 impossible with it. There's no reason to throw dub away and 
 start
 something new. If one can run cmake before build in dub,  
 then a
 lot is possible. Those edge cases can be ironed out.


 
 I think there have been many actual complaints made in detail 
 in this
 thread.
 
 There is always a reason to replace, because you can build on 
 what has
 gone before and do better. CMake is part of the problem.
 

 Dub fulfills all my use cases so I don't complain. Those here
 with not much issue with dub will also not complain. And that
 does not make it a minority opinion without stats to prove dub
 usage.


 
 No problem, and I guess you'll be happy to carry on using Dub 
 after
 something new and better appears. In the case of Maven → 
 Gradle, many
 people still use Maven even though it is provably inferior to 
 Gradle
 simply because they cannot be bothered to change.
 

 At point, dub will likely remain the default package 
 management
 tool. The build functionality can be improved for those who 
 deal
 with such stuff often. Manpower is what remains.


 […]
 
 Why should Dub remain the one true way? Just because it was 
 the first
 doesn't mean it is the best.


 It wasn't the first and it was the best in over a 10 year 
 period.


While I am really suffer from some painful behavior of dub, in my 
opinion it is a great tool and it would damage the D ecosystem to 
go away from dub. Companies already starting investing into this 
tool. In my case, without dub it would not be possible at all to 
use D at work.

The involved developers doing a great job.

Kind regards
André



 Feb 13 2018



  parent  bauss <jj_1337 live.dk>  writes:


On Tuesday, 13 February 2018 at 11:36:50 UTC, Andre Pany wrote:

 On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole 
 wrote:

 On 13/02/2018 11:11 AM, Russel Winder wrote:

 On Tue, 2018-02-13 at 10:45 +0000, aberba via Digitalmars-d 
 wrote:


 […]

 I wish complaints about Dub would include exactly what was
 impossible with it. There's no reason to throw dub away and 
 start
 something new. If one can run cmake before build in dub,  
 then a
 lot is possible. Those edge cases can be ironed out.


 
 I think there have been many actual complaints made in detail 
 in this
 thread.
 
 There is always a reason to replace, because you can build on 
 what has
 gone before and do better. CMake is part of the problem.
 

 Dub fulfills all my use cases so I don't complain. Those here
 with not much issue with dub will also not complain. And that
 does not make it a minority opinion without stats to prove 
 dub
 usage.


 
 No problem, and I guess you'll be happy to carry on using Dub 
 after
 something new and better appears. In the case of Maven → 
 Gradle, many
 people still use Maven even though it is provably inferior to 
 Gradle
 simply because they cannot be bothered to change.
 

 At point, dub will likely remain the default package 
 management
 tool. The build functionality can be improved for those who 
 deal
 with such stuff often. Manpower is what remains.


 […]
 
 Why should Dub remain the one true way? Just because it was 
 the first
 doesn't mean it is the best.


 It wasn't the first and it was the best in over a 10 year 
 period.


 While I am really suffer from some painful behavior of dub, in 
 my opinion it is a great tool and it would damage the D 
 ecosystem to go away from dub. Companies already starting 
 investing into this tool. In my case, without dub it would not 
 be possible at all to use D at work.

 The involved developers doing a great job.

 Kind regards
 André


Well backward compatibility with dub could always be a 
possibility.



 Feb 13 2018



prev sibling  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/11/2018 06:18 AM, Russel Winder wrote:

 
 Clearly though there is a problem with Dub as a build system for many
 of it's users – or rather people who try and reject.
 


The problem isn't just "dub as a buildsystem". The other equally big 
problem here is that "dub as a package manager" pretty much forces "dub 
as a buildsystem" for library authors. Yes, *officially* it doesn't, but 
realistically, yea it does. And I don't see how dub can fix in any sane 
way without a major, fundamental redesign.



 Feb 11 2018



prev sibling  parent reply rumbu <rumbu rumbu.ro>  writes:


On Friday, 9 February 2018 at 15:53:47 UTC, Russel Winder wrote:

 On Fri, 2018-02-09 at 14:04 +0000, rumbu via Digitalmars-d 
 wrote:

 


 […]

 1. Keeps data in the %APPDATA%/Roaming folder. Connecting my 
 computer to the company network means that AD will sync 
 zillions of files on the company profile server. This issue is 
 4 years old: https://github.com/dlang/dub/issues/229


 Have you put forward a pull request to fix it, and tests 
 obviously.

 4 year old issues just mean no-one cares about it enough to do 
 something.

 4 year old pull requests is time to fork the project with a new 
 team of developers.


 2. It's painfully slow.
 3. As a library provider, you have a lot to learn about
 configuration file format (2 formats).


 Neither of which are really acceptable. :-(


I wrote a massive decimal library. 90% of reported problems were 
not about the library itself, but about the fact that does not 
compile with dub, does not run with dub, dub doesn't recognize 
package.d and so on. I invested a lot of time in providing a 
clear documentation 
(http://rumbu13.github.io/decimal/doc/decimal.html). Guess what's 
the last issue? Documentation is not visible in the dub registry 
:)


 4. Not integrated in Visual Studio. I know, I am a lazy and 
 convenient Windows user and the small black window called cmd 
 scares the sh*t out of me.


 Isn't that a "create a VS plugin" problem?


Personally, I don't use dub. If I need some library, I download 
and add it to my library import path. The only way that dub will 
convince me will be a right click context menu on my VS project 
entitled "Manage DUB packages". It's an productivity issue: I 
just press F5 to debug my project, why should I go to the command 
line and type manually what I want?



 Feb 09 2018



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 09, 2018 at 10:22:01PM +0000, rumbu via Digitalmars-d wrote:
[...]

 Personally, I don't use dub. If I need some library, I download and
 add it to my library import path. The only way that dub will convince
 me will be a right click context menu on my VS project entitled
 "Manage DUB packages".  It's an productivity issue: I just press F5 to
 debug my project, why should I go to the command line and type
 manually what I want?


[...]

Your last sentence boggled my mind.  Doesn't VS have the ability for you
to define a macro bound to some hotkey that will automatically go into
the command-line and "type" whatever it is you need to type?

If it doesn't, then all I can say is, no wonder I hate using IDEs.


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects
such as wickerwork picnic baskets.  Imagination without skill gives us modern
art. -- Tom Stoppard



 Feb 09 2018



prev sibling next sibling parent  Atila Neves <atila.neves gmail.com>  writes:


On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:

 On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky 
 (Abscissa) wrote:


 [...]


 I'm missing too the yield return and await syntax in D every 
 time. In my current asp.net project I counted around 800 await 
 calls. I don't even imagine how difficult should be to 
 translate this in D style.

 But back to the subject:
 - pure  safe nothrow  nogc
 - auto const ref
 - __ctfe is a variable
 - traits as a library solution;
 - alias this;
 - calling conventions are a best kept secret.
 - everything is a range. If not, we will rangify it. 
 Autodecoded eventually.
 - no dedicated syntax sugar for ranges;
 - no dedicated syntax sugar for coroutines;
 - no dedicated syntax sugar for events;
 - GC is evil. OO is outdated.
 - last integer promotion rules.


 And not a language feature but I hate dub. Just saying.


The GC is awesome, and trivially avoided. And once it is, 
programs crash and remind me of programming in C and C++ in the 
90s.

At least LDC has address sanitizer now.

Atila



 Feb 09 2018



prev sibling  parent reply Seb <seb wilzba.ch>  writes:


On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:

 On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky 
 (Abscissa) wrote:


 Defining input ranges (one of my biggest pet peeves):


 stackless!!! (ie no-fibers) coroutine syntax. There's no 
 reason the same approach couldn't be used in D for creating 
 input ranges.


 I'm missing too the yield return and await syntax in D every 
 time.


What's wrong with the library solution from std.concurrency?


 But back to the subject:


All good point. A few questions:


 - alias this;


Do you mean no multiple alias this or the problem with 
overloading?


 - everything is a range. If not, we will rangify it.



 Autodecoded eventually.


No one likes it, but you can opt-out with byCodeUnit - that 
doesn't work for you?


 - no dedicated syntax sugar for ranges;


What do you expect here?
(also it's not entirely true - foreach already supports ranges)


 - no dedicated syntax sugar for coroutines;


What syntax sugar that can't be done by a library do you expect?


 - no dedicated syntax sugar for events;


What syntax sugar that can't be done by a library do you expect?
await?



 Feb 09 2018



 next sibling parent reply rumbu <rumbu rumbu.ro>  writes:


On Friday, 9 February 2018 at 13:53:51 UTC, Seb wrote:

 On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:

 On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky 
 (Abscissa) wrote:


 Defining input ranges (one of my biggest pet peeves):


 stackless!!! (ie no-fibers) coroutine syntax. There's no 
 reason the same approach couldn't be used in D for creating 
 input ranges.


 I'm missing too the yield return and await syntax in D every 
 time.


 What's wrong with the library solution from std.concurrency?



let's take the D's example from std.concurrency:

static void spawnedFunc(Tid ownerTid)
{
     receive((int i){
         received = text("Received the number ", i);

         // Send a message back to the owner thread
         // indicating success.
         send(ownerTid, true);
     });
}



async void spawnedFunc()
{
     int i = await receive();
}



 All good point. A few questions:


 - alias this;


 Do you mean no multiple alias this or the problem with 
 overloading?


When I learnt D first time, it was a very difficult concept for 
me. Personally I don't find any use of it today.


 - everything is a range. If not, we will rangify it.



 Autodecoded eventually.


 No one likes it, but you can opt-out with byCodeUnit - that 
 doesn't work for you?


This topic was about how difficult is D to learn. Due to the 
obsessive "range them all" politics, you cannot really use most 
of the D library functions if you don't understand very well 
range concepts. And after you learn them, you'll have 
autodecoding surprises.


 - no dedicated syntax sugar for ranges;


 What do you expect here?
 (also it's not entirely true - foreach already supports ranges)


 - no dedicated syntax sugar for coroutines;


 What syntax sugar that can't be done by a library do you expect?


Let's take a classic range in D:

struct FibonacciRange(int limit)
{
     int a = 1, b = 1;

     bool empty() const  property
     {
        return a > limit;
     }

     int front() const  property
     {
         return a;
     }

     void popFront()
     {
         auto t = a;
         a = b;
         b = t + b;
     }
}



IEnumerable<int> Fibonacci(int limit)
{
    int a = 1, b = 1;
    while (a < limit)
    {
      yield return a;  //syntactic sugar
      var t = a;
      a = b;
      b = t + b;
    }
}


 - no dedicated syntax sugar for events;


 What syntax sugar that can't be done by a library do you expect?
 await?


D library is using signals instead of events. Personally I find 
events easier to learn.



 Feb 09 2018



  parent reply Seb <seb wilzba.ch>  writes:


 On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:


All understood, but just to get your mind set better, I would 
have two quick follow-up questions if you don't mind.

On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:


 
 async void spawnedFunc()
 {
     int i = await receive();
 }


OK, but that's because Phobos has no eventloop.
With Vibe.d it looks like this:


```d
auto val = async({
      return 32;
}).getResult;
```

Is this really so different or what exactly do you miss from the 
language?




 IEnumerable<int> Fibonacci(int limit)
 {
    int a = 1, b = 1;
    while (a < limit)
    {
      yield return a;  //syntactic sugar
      var t = a;
      a = b;
      b = t + b;
    }
 }


So your point is that std.concurrency.Generator isn't so nice? 
Not advertised?
Or do you simply want to have a keyword that wraps a function 
into generator like function* in ES6?

---
auto fib = (int limit){
     import std.concurrency;
     return new Generator!int((){
         int a = 1, b = 1;
         while (a < limit)
         {
             a.yield; //syntactic sugar
             auto t = a;
             a = b;
             b = t + b;
         }
     });
};
---

https://run.dlang.io/is/xQl0Ir



 Feb 09 2018



  parent reply rumbu <rumbu rumbu.ro>  writes:


On Friday, 9 February 2018 at 16:35:47 UTC, Seb wrote:

 On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:


 All understood, but just to get your mind set better, I would 
 have two quick follow-up questions if you don't mind.

 On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:


 
 async void spawnedFunc()
 {
     int i = await receive();
 }


 OK, but that's because Phobos has no eventloop.
 With Vibe.d it looks like this:


 ```d
 auto val = async({
      return 32;
 }).getResult;
 ```

 Is this really so different or what exactly do you miss from 
 the language?




 IEnumerable<int> Fibonacci(int limit)
 {
    int a = 1, b = 1;
    while (a < limit)
    {
      yield return a;  //syntactic sugar
      var t = a;
      a = b;
      b = t + b;
    }
 }


 So your point is that std.concurrency.Generator isn't so nice? 
 Not advertised?
 Or do you simply want to have a keyword that wraps a function 
 into generator like function* in ES6?

 ---
 auto fib = (int limit){
     import std.concurrency;
     return new Generator!int((){
         int a = 1, b = 1;
         while (a < limit)
         {
             a.yield; //syntactic sugar
             auto t = a;
             a = b;
             b = t + b;
         }
     });
 };
 ---

 https://run.dlang.io/is/xQl0Ir



It's not about how nice is a solution, it's about how easy is for 
someone to find out about a language feature and use it. D has a 
library solution for everything that is missing from the core 
language instead to include in the language well proven patterns. 
  That's why is complicated: one must learn about fibers, ask 
himself why in the world he must use std.concurrency to obtain a 
list of numbers and so on. Even the cluttered ((){ will scare a 
potential learner.


You use a *yield return* statement to return each element one at 
a time.
You can use a *yield break* statement to end the iteration.

Now, as an exercise, please explain for a newbie in two sentences 
the Generator class, the yield function and why should we need 
concurrency and fibers stuff for this.

Modern languages are evolving over time, D had a good start 
inspiring himself from popular language features (at that time I 
suppose it was Java), now it's stalling trying to win an 
impossible bet on C/C++ compatibility instead of evolving in its 
own way. Features are dropped from the language and moved to 
library solutions. Library solutions often result in 
incomprehensible compiler error messages, and that's normal, the 
compiler has not enough information to provide a decent error 
message.

Is the concept of range a first class citizen in D? If yes, the 
language must provide the necessary syntax for repetitive 
patterns linked to ranges and hide behind the scene the details. 
Are the fibers the de facto way to deal with concurrency in D? If 
yes, the language must provide the necessary syntax to write 
fiber-oriented code. This will not stop anyone to write his 
state-of-the-art-hand-made range or fiber solution, but it will 
help the potential learner to understand immediately how to deal 
with ranges or fibers.

A similar remark I have for traits: a lot of emphasis is put on 
compile time reflection, but to use it, you need to import 8200 
lines of code from std.traits.



 Feb 09 2018



  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 04:58 PM, rumbu wrote:

 
 It's not about how nice is a solution, it's about how easy is for 
 someone to find out about a language feature and use it. D has a library 
 solution for everything that is missing from the core language instead 
 to include in the language well proven patterns.  That's why is 
 complicated: one must learn about fibers, ask himself why in the world 
 he must use std.concurrency to obtain a list of numbers and so on. Even 
 the cluttered ((){ will scare a potential learner.
 


I agree with this. Though I understand why it ended, I miss the days 
when D was more open to language enhancements. Library solutions are 
often possible, and better then nothing, but by necessity they're also 
frequently sub-optimal (design-wise) as well. One of the most common 
offenders is that all that ((){ *is* visual clutter compared to other 
langauges' takes on equivalent ideas.



 Feb 09 2018



prev sibling  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 08:53 AM, Seb wrote:

 On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:

 I'm missing too the yield return and await syntax in D every time.


 
 What's wrong with the library solution from std.concurrency?
 





std.concurrency version is that it introduces the overhead of fibers and 
context-switching. Sometimes that's ok (network/file i/o), sometimes 
it's not (parsing). (You *can* switch to foreach/apply to do it, but 
then you lose the ability to offer a range-based interface...unless you 
re-introduce fibers.)


Internally, it works the same way as C's protothreads 
<http://dunkels.com/adam/pt/>, but with far nicer syntax.


 - no dedicated syntax sugar for ranges;


 
 What do you expect here?
 (also it's not entirely true - foreach already supports ranges)
 


For input ranges (maybe even forward ranges), a stackless corountine 


But even for all-out random-access, defining them is quite boiler-plate 
heavy (by D standards anyway) and could really use some sugar. Exactly 
what that sugar would be like, I don't know, but it could definitely use 
some.


 - no dedicated syntax sugar for coroutines;


 
 What syntax sugar that can't be done by a library do you expect?
 


Doing it without the overhead of fibers. This requires either a C-style 
preprocesser (yuck, and note string mixins aren't sufficient here) or 
lowering. (I guess if we had AST macros, maybe we could do this lowering 
in the library, but we don't.)



 Feb 09 2018



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 02/09/2018 02:54 AM, Suliman wrote:

 [...]


 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



 And Algebraic types. Yes, we technically have them, but 
 compared to something like Nemerle, D claiming to have 
 algebraic or pattern matching is like C claiming to support OO: 
 Umm...sorta...technically...kinda...but...uhhh...no, not really.


Proper sum types and pattern matching would be nice.

Atila



 Feb 09 2018



  parent reply jmh530 <john.michael.hall gmail.com>  writes:


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.



 Feb 09 2018



  parent  Atila Neves <atila.neves gmail.com>  writes:


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



 Feb 09 2018



prev sibling next sibling parent  Abdulhaq <alynch4047 gmail.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


This is a great question. The hard part of good language design 
is making things simple.



 Feb 09 2018



prev sibling next sibling parent reply Andrea Fontana <nospam example.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


My top 4:

- Unclear error messages
- Unfinished parts of language  (ex: shared?)
- Ambiguous things (ex:  property)
- Things that need an upgrade but are still there (ex: 
containers, xml, ...)



 Feb 09 2018



  parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Friday, 9 February 2018 at 14:01:23 UTC, Andrea Fontana wrote:

 [snip]
 - Unfinished parts of language  (ex: shared?)


I see this a lot, but I don't really use shared so I always 
forget how exactly it is unfinished. If there are unfinished 
parts of the language, it couldn't hurt to put in the wiki how 
exactly they are unfinished so that people don't need to keep 
asking.



 Feb 09 2018



  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Friday, February 09, 2018 14:48:36 jmh530 via Digitalmars-d wrote:

 On Friday, 9 February 2018 at 14:01:23 UTC, Andrea Fontana wrote:

 [snip]
 - Unfinished parts of language  (ex: shared?)


 I see this a lot, but I don't really use shared so I always
 forget how exactly it is unfinished. If there are unfinished
 parts of the language, it couldn't hurt to put in the wiki how
 exactly they are unfinished so that people don't need to keep
 asking.


The memory model needs to be properly defined like C++ finally did. It works
without that, but as I understand it, it's technically relying too much on
implementation-defined behavior.

I'm not sure if shared produces an error in all of the cases that it's
supposed to, but it might.

The druntime stuff related to shared (like mutexes, conditional variables,
and threads) isn't necessarily marked up like it should be, though some work
has been done on that with the past few releases, so it's at least better,
and it might be finished, but I'd have to dig through it to be sure.

There are some issues with shared with regards to stuff like destructors
which need to be sorted out. IIRC, a partial fix for that went in a few
months ago but causes other problems.

Synchronized classes haven't been fully implemented, so there is no
mechanism for shared to be implicitly cast away (though honestly, I don't
think that synchronized classes would do a good enough job of that to make a
significant difference, since they can only strip away the outer layer of
shared).

I think that the biggest thing is simply that too many folks don't
understand how to use it properly. They get compilation errors when they try
to use it and get mad about it and end up using __gshared, which is just
begging for bugs, because unless you're dealing with a C global, you're
almost certainly subverting the type system, since the variable is still
treated as thread-local by the type system even though it isn't.

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.

It would be really nice if the language had a better way to implicitly
remove shared when the object was properly protected by a mutex rather than
requiring an explicit cast, but that's _really_ hard to do (which is why
synchronized classes can only strip away the outer layer of shared). So,
ultimately, I expect that we're going to be stuck with having to use
explicit casts when using shared objects.

So, there are some rough edges in the implementation (both in the compiler
and the runtime) which need to be fixed for shared to work as well as it
should, but the design itself is generally solid. It's more a question of
folks not understanding how to use it properly and getting mad when the
compiler prevents them from doing stuff that's not thread-safe.

I suspect that part of why the lingering implementation issues haven't been
fixed is simply because so few programs actually need shared objects. It's
debatable how much of a success shared has been, but having everything be
thread-local by default has been a smashing success for the most part.

- Jonathan M Davis



 Feb 09 2018



 next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


On Friday, 9 February 2018 at 15:05:05 UTC, Jonathan M Davis 
wrote:

 The memory model needs to be properly defined like C++ finally 
 did. It works without that, but as I understand it, it's 
 technically relying too much on implementation-defined behavior.
 [snip]



Thanks for the write-up!



 Feb 09 2018



prev sibling  parent reply Andrea Fontana <nospam example.com>  writes:


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?

Andrea



 Feb 09 2018



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


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



 Feb 09 2018



prev sibling next sibling parent  bauss <jj_1337 live.dk>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

 Which language futures by your opinion make D harder?


shared.



 Feb 09 2018



prev sibling next sibling parent  Guillaume Piolat <notthat email.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


Is D really over-complicated? I'm not really sure.

As someone who writes a bit about corner-cases and traps, I feel 
that there isn't nearly enough content to author an "Effective D" 
book.

However I feel like D is very long to learn because, like a 
control panel with many buttons, you have to become intimate with 
every feature and where to apply them - and D has a lot of 
buttons. For example when to use "alias this" is a blurry 
judgement call that have to be finetuned.

It's a long integrative process to use D effectively, but you can 
mostly write useful programs from day one which I think is 
interesting.

Of course I've a personal list of things that could be removed, 
but let's bet it won't match anybody else's kill list :)



 Feb 09 2018



prev sibling next sibling parent reply Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

 Which language futures by your opinion make D harder?


Too many choices.  I tend to obsess over the best way to do 
something, and when the language gives me several options I want 
to try them all.  One example is constants (that would typically 
be #define in C).  From reading forum posts, I've seen many 
suggest:
const auto MAX_IN = 20;

Others say to use enums.  It turns out enums seems to be the 
best, as they don't create a symbol in the object file, but const 
auto does.  The docs say using "private" will keep the symbol out 
of the file, but that is not true.
https://dlang.org/spec/attribute.html#static



 Feb 09 2018



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster wrote:

 The docs say using "private" will keep the symbol out of the 
 file, but that is not true.
 https://dlang.org/spec/attribute.html#static


That sentence isn't well written since D's private and C's static 
  are different... what D's private does is make the symbol 
invisible to other D files; when you import the module, it 
doesn't import the private names so it acts like they don't exist.

But they do still exist in the object file. I'm pretty sure C's 
statics do too actually just without an exported name...



 Feb 09 2018



  parent reply Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 15:03:02 UTC, Adam D. Ruppe wrote:

 On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster 
 wrote:

 The docs say using "private" will keep the symbol out of the 
 file, but that is not true.
 https://dlang.org/spec/attribute.html#static


 That sentence isn't well written since D's private and C's 
 static
  are different... what D's private does is make the symbol 
 invisible to other D files; when you import the module, it 
 doesn't import the private names so it acts like they don't 
 exist.

 But they do still exist in the object file. I'm pretty sure C's 
 statics do too actually just without an exported name...


Yes, C's "const static" will still create a symbol in the object 
file.  I just checked with gcc5, and it creates a local readonly 
symbol "r".

My point is that in D, the docs say "private" will keep the 
definition out of the object file.  I think you'll have to agree 
that it's at least confusing.



 Feb 09 2018



  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


On Friday, 9 February 2018 at 15:29:52 UTC, Ralph Doncaster wrote:

 My point is that in D, the docs say "private" will keep the 
 definition out of the object file.  I think you'll have to 
 agree that it's at least confusing.


The exact quote is: "Static does not have the additional C 
meaning of being local to a file. Use the private attribute in D 
to achieve that."

It doesn't say anything about object files.



 Feb 09 2018



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster wrote:


 const auto MAX_IN = 20;


const MAX_IN = 20;

The auto is superfluous and is only needed when there's no 
storage class or type.


 Others say to use enums.  It turns out enums seems to be the 
 best, as they don't create a symbol in the object file, but 
 const auto does.


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.



 Feb 09 2018



 next sibling parent reply Andrea Fontana <nospam example.com>  writes:


On Friday, 9 February 2018 at 15:09:10 UTC, Mike Parker wrote:

 On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster 
 wrote:


 const auto MAX_IN = 20;


 const MAX_IN = 20;

 The auto is superfluous and is only needed when there's no 
 storage class or type.


 Others say to use enums.  It turns out enums seems to be the 
 best, as they don't create a symbol in the object file, but 
 const auto does.


 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?



 Feb 09 2018



  parent reply Mike Parker <aldacron gmail.com>  writes:


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



 Feb 09 2018



  parent reply Andrea Fontana <nospam example.com>  writes:


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?



 Feb 09 2018



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


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



 Feb 09 2018



prev sibling  parent reply Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 15:09:10 UTC, Mike Parker wrote:

 On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster 
 wrote:


 const auto MAX_IN = 20;


 const MAX_IN = 20;

 The auto is superfluous and is only needed when there's no 
 storage class or type.


 Others say to use enums.  It turns out enums seems to be the 
 best, as they don't create a symbol in the object file, but 
 const auto does.


 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.


I think you are proving my point.  You say there is no difference 
between:
const MAX_IN = 20;
vs
immutable MAX_IN = 20;

So now I have to try both, and look at the generated code to be 
sure.
p.s. I prefer const since it is easier for C/C++ coders to 
understand.  Using immutable invites the coder to go down the 
whole rat hole of trying to understand how is it different than 
const.



 Feb 09 2018



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster wrote:



 I think you are proving my point.  You say there is no 
 difference between:
 const MAX_IN = 20;
 vs
 immutable MAX_IN = 20;

 So now I have to try both, and look at the generated code to be 
 sure.


Or read the docs:

https://dlang.org/spec/const3.html


 p.s. I prefer const since it is easier for C/C++ coders to 
 understand.  Using immutable invites the coder to go down the 
 whole rat hole of trying to understand how is it different than 
 const.


It's not a rathole. The document page above explains the 
differences rather well. They only happen to be identical when 
initialized with compile-time constants.



 Feb 09 2018



  parent reply Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 15:46:56 UTC, Mike Parker wrote:

 On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster 
 wrote:



 I think you are proving my point.  You say there is no 
 difference between:
 const MAX_IN = 20;
 vs
 immutable MAX_IN = 20;

 So now I have to try both, and look at the generated code to 
 be sure.


 Or read the docs:

 https://dlang.org/spec/const3.html


 p.s. I prefer const since it is easier for C/C++ coders to 
 understand.  Using immutable invites the coder to go down the 
 whole rat hole of trying to understand how is it different 
 than const.


 It's not a rathole. The document page above explains the 
 differences rather well. They only happen to be identical when 
 initialized with compile-time constants.


Well this part of the docs is a rathole to me:
https://dlang.org/spec/const3.html#implicit_qualifier_conversions

It might be clear and simple to you, but it's not to me.  And I'm 
a rather advanced developer.
While there are lots of things I like about D compared to C++ 
such as getting rid of #include hell, there's too many "messy" 
things and the learning curve is too steep for me to consider 
suggesting it for any consulting projects.  I think it could've 
been better if there was more focus on keeping the language (and 
standard library) clean and simple instead of making it more like 
a swiss army knife.



 Feb 09 2018



 next sibling parent reply bachmeier <no spam.net>  writes:


On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster wrote:


 It might be clear and simple to you, but it's not to me.  And 
 I'm a rather advanced developer.
 While there are lots of things I like about D compared to C++ 
 such as getting rid of #include hell, there's too many "messy" 
 things and the learning curve is too steep for me to consider 
 suggesting it for any consulting projects.  I think it could've 
 been better if there was more focus on keeping the language 
 (and standard library) clean and simple instead of making it 
 more like a swiss army knife.


When I read things like that page, I think "Haskell's not that 
bad".

So far a strategy that has worked for me is to ignore most of 
that stuff. Must be my C background.



 Feb 09 2018



  parent  Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 16:33:21 UTC, bachmeier wrote:

 On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster 
 wrote:


 It might be clear and simple to you, but it's not to me.  And 
 I'm a rather advanced developer.
 While there are lots of things I like about D compared to C++ 
 such as getting rid of #include hell, there's too many "messy" 
 things and the learning curve is too steep for me to consider 
 suggesting it for any consulting projects.  I think it 
 could've been better if there was more focus on keeping the 
 language (and standard library) clean and simple instead of 
 making it more like a swiss army knife.


 When I read things like that page, I think "Haskell's not that 
 bad".

 So far a strategy that has worked for me is to ignore most of 
 that stuff. Must be my C background.


What I enjoy most is assembler programming in RISC-like 
instruction sets.  Due to the cost of silicon, it's much less 
common for them have multiple different instructions for doing 
exactly the same thing.



 Feb 09 2018



prev sibling  parent reply Seb <seb wilzba.ch>  writes:


On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster wrote:

 On Friday, 9 February 2018 at 15:46:56 UTC, Mike Parker wrote:

 On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster 
 wrote:



 I think you are proving my point.  You say there is no 
 difference between:
 const MAX_IN = 20;
 vs
 immutable MAX_IN = 20;

 So now I have to try both, and look at the generated code to 
 be sure.


 Or read the docs:

 https://dlang.org/spec/const3.html


 p.s. I prefer const since it is easier for C/C++ coders to 
 understand.  Using immutable invites the coder to go down the 
 whole rat hole of trying to understand how is it different 
 than const.


 It's not a rathole. The document page above explains the 
 differences rather well. They only happen to be identical when 
 initialized with compile-time constants.


 Well this part of the docs is a rathole to me:
 https://dlang.org/spec/const3.html#implicit_qualifier_conversions

 It might be clear and simple to you, but it's not to me.  And 
 I'm a rather advanced developer.
 While there are lots of things I like about D compared to C++ 
 such as getting rid of #include hell, there's too many "messy" 
 things and the learning curve is too steep for me to consider 
 suggesting it for any consulting projects.  I think it could've 
 been better if there was more focus on keeping the language 
 (and standard library) clean and simple instead of making it 
 more like a swiss army knife.


The graphic is way too complicated.
Forget inout, it's seldomly used and there have even attempts to 
remove it from the language.

Without inout:

- any type can be implicitly converted to const X
- shared can't be implicitly removed
- immutable can't be implicitly removed

There's also: https://dlang.org/articles/const-faq.html



 Feb 09 2018



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


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;
}


inout is like const, just paired return value to arg, so notice 
that inout will appear twice in the typical signature when you 
use it.

3) use const when declaring function parameters. Exception: if 
you need to store the passed reference or pass it to another 
thread, then immutable may be the better choice.

void inspect(const char[] data) {}



Implicit conversion flowcharts are useful for a deeper 
understanding but are unnecessary for most effective use...



 Feb 09 2018



 next sibling parent reply Bo <bo41 bo0041.com>  writes:


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



 Feb 09 2018



 next sibling parent reply Seb <seb wilzba.ch>  writes:


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!



 Feb 09 2018



 next sibling parent  Mark <smarksc gmail.com>  writes:


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.



 Feb 09 2018



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 09.02.2018 19:34, 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.


On top of that, the penalty is _negative_. If there is no type 
specified, there is no overhead to check that it matches the type of the 
initializer. I can find zero ways in which the above criticism of "auto" 
makes any sense.



 Feb 09 2018



prev sibling next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


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?



 Feb 09 2018



prev sibling  parent reply Meta <jared771 gmail.com>  writes:


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 ;-)



 Feb 09 2018



 next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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.



 Feb 09 2018



prev sibling  parent  Patrick Schluter <Patrick.Schluter bbox.fr>  writes:


On Friday, 9 February 2018 at 18:44:08 UTC, Meta 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 ;-)


And defer is so vague. Defer to when? scope is obvious. Of 
course, one has to know what a scope is in the first place.



 Feb 09 2018



prev sibling  parent  Meta <jared771 gmail.com>  writes:


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.



 Feb 09 2018



prev sibling next sibling parent reply Dukc <ajieskola gmail.com>  writes:


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



 Feb 09 2018



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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



 Feb 09 2018



 next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 09.02.2018 19:31, H. S. Teoh wrote:

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


Actually, it goes way too far. :o)

https://issues.dlang.org/show_bug.cgi?id=17743
https://issues.dlang.org/show_bug.cgi?id=17744



 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.
 
 


The fundamental issue is that D's type system has no parametric 
polymorphism, and 'inout' is an approximation to some special case of 
it, but it is not so clear which special case. It actually differs based 
on context. (IIRC the meaning of 'inout' has subtly changed in the past 
to fix bugs caused by some typing rules assuming one thing when others 
assumed another, and one of them was randomly given precedence.)



 Feb 09 2018



  parent reply Nick Sabalausky <a a.a>  writes:


On Saturday, 10 February 2018 at 01:24:55 UTC, Timon Gehr wrote:

 The fundamental issue is that D's type system has no parametric 
 polymorphism,


Pardon my ignorance, but isn't that what D's templated functions 
do? This sounds interesting but unclear exactly what you mean 
here and how it relates to inout and its problems.



 Feb 09 2018



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 10.02.2018 03:12, Nick Sabalausky wrote:

 On Saturday, 10 February 2018 at 01:24:55 UTC, Timon Gehr wrote:

 The fundamental issue is that D's type system has no parametric 
 polymorphism,


 
 Pardon my ignorance, but isn't that what D's templated functions do? 
 This sounds interesting but unclear exactly what you mean here and how 
 it relates to inout and its problems.


TL;DR: Parametrically polymorphic functions have /runtime/ type 
parameters. inout can be interpreted as a dependent function of type 
"{type y | y.among(x, const(x), immutable(x)) } delegate(type x)" and an 
inout function can be thought of as a function that takes inout as an 
argument and produces the function as the return value. This formulation 
is more powerful than what the inout syntax can capture, and this is 
what causes problems with type safety. In particular, 'inout' does not 
support proper lexical scoping.

TS;NM: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3 
(Some version of this was originally intended to go to the D blog, but I 
wanted to wait until inout has an obviously type safe definition. It 
also highlights other inout issues than just type unsafety and shows how 
all of them might be fixed in principle by adding polymorphism.)

---

I'll first explain parametric polymorphism, and then what the inout 
problem is.

The template

int foo(int x)(int y){
     return x + y;
}

relates to the function

int delegate(int) foo(int x){
     return (int y) => x + y;
}

just like the template

T foo(T)(T x){
     return x;
}

relates to the polymorphic function (fictional syntax):

T delegate(T) foo(type T){ // type is the type of types
     return (T x) => x;
}

Here, 'foo' takes a type T and produces an identity function for type T:

int delegate(int) idInt = foo(int);
int x = foo(int)(y);
writeln(foo(int)(2)); // 2

string delegate(string) idString = foo(string);
string y = foo(string)("b");
writeln(foo(string)("b")); // b


Alternatively, one might write

void id[T](T x){
     return x;
}

and then rely on implicit instantiation of the 'T' parameter:

int delegate(int) idInt = id![int]; // or something like this
int x = id(2);
writeln(id(2)); // 2

string delegate(string) idString = id![string];
string y = id("b");
writeln(id("2"));

As you will have noticed, all of this works just fine with templates, so 
what is the big difference?

For a polymorphic function, the type is a /runtime/ parameter. Some 
languages however enforce that polymorphic functions don't depend on the 
type T at runtime: just don't give any runtime methods or fields to the 
'type' type).

The most obvious benefit of parametric polymorphism is that 
parametrically polymorphic functions exist at runtime (while templates 
only exist at compile time). For example, one can define a 
parametrically polymorphic delegate:

T delegate[T](T x) = [T](T x) => x;

Or, a parametrically polymorphic virtual function

class Base{
     bool pickFirst;
     abstract T pickOne[T](T a, T b);
}

class Honest: Base{
     bool pickFirst;
     override T pickOne[T](T a, T b){
         return pickFirst ? a : b;
     }
}

class Dishonest: Base{
     override T pickOne[T](T a, T b){
         return pickFirst ? b : a;
     }
}

class Confused: Base{
     override T pickOne[T](T a, T b){
         return uniform(0,2) ? a : b;
     }
}

So as expected, the difference is that for parametrically polymorphic 
functions, the type T /does not need to be known at compile time/.


Now, what is 'inout'? If it was a first-class entity, it might have the 
type:

alias Inout = { type y | y.among(x, const(x), immutable(x)) } 
delegate(type x);

I.e. it takes a type x and produces a type y such that y is either x, 
const(x) or immutable(x).

(This is not necessarily the most restricted possible type, depending on 
the details of the polymorphic type system. inout additionally enforces 
that the qualifier applied is the same for all argument types x.)

Consider the following 'inout' function:

inout(int*) id(inout(int*) x){
     return x;
}

This might be expressed as:

inout(int*) id[Inout inout](inout(int*) x){
     return x;
}

I.e., we can make 'inout' an explicit polymorphic parameter.


What is the problem with 'inout'? Let's look at the first counterexample 
to type safety:

 safe:
int a;
immutable(int) b=2;

inout(int)* delegate(inout(int)*) dg;
inout(int)* prepare(inout(int)* x){
     dg = y=>x;
     return x;
}
void main(){
     prepare(&b);
     int* y=dg(&a);
     assert(&b is y); // passes. ouch.
     *y=3;
     assert(b is *&b); // fails!
}

We will express this using explicit polymorphism and see where the type 
error occurs. (For readability, I have named the two versions of 'inout' 
differently, but this is not strictly necessary. The compiler knows that 
they are different, because they are associated to different 
declarations in the AST.)

inout1(int)* delegate[Inout inout1](inout1(int)*) dg;

inout2(int)* prepare[Inout inout2](inout2(int)* x){
     dg = [Inout inout1](inout1(int)* y)=>x;
     return x;
}

Here, the error would be:

Error: cannot implicitly convert '[Inout inout1](inout1(int)* y)=>x;' of 
type 'inout2(int)* delegate[Inout inout1](inout1(int)* y)' to 
'inout1(int)* delegate[Inout inout1](inout1(int)*)'.

Note how the type error crucially depends on the fact that the type of 
the delegate contains _two incompatible functions_ of type Inout.

You can't have that if the only function of type Inout is the built-in 
inout!


Now let's look at the second counterexample to type safety:

 safe:
int a;
immutable(int) b=2;

inout(int)* delegate(inout(int)*) safe delegate() safe foo(inout(int)* y){
     inout(int)* bar(inout(int)* p){
         return y;
     }
     return ()=>&bar;
}
void main(){
     int* y=foo(&b)()(&a);
     *y=3;
     assert(&b is y); // passes. ouch.
     assert(b is *&b); // fails!
}

The problem is very similar. Can you spot it?

In summary, the issue is that there is only one 'inout' and therefore it 
is not properly lexically scoped. It is a bit like having a language 
where all variables are implicit function parameters and they all have 
the same, global, name. This sort of works fine until you want a 
function with two parameters or until you want to nest functions in a 
non-trivial way.

Also see: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3



 Feb 10 2018



 next sibling parent reply Mark <smarksc gmail.com>  writes:


On Saturday, 10 February 2018 at 12:35:39 UTC, Timon Gehr wrote:

 So as expected, the difference is that for parametrically 
 polymorphic functions, the type T /does not need to be known at 
 compile time/.


According to this definition C++ doesn't support parametric 
polymorphism either, does it? Are there any C-style languages 
that allow that?



 Feb 10 2018



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 10.02.2018 14:05, Mark wrote:

 On Saturday, 10 February 2018 at 12:35:39 UTC, Timon Gehr wrote:

 So as expected, the difference is that for parametrically polymorphic 
 functions, the type T /does not need to be known at compile time/.


 
 According to this definition C++ doesn't support parametric polymorphism 
 either, does it?


It does not. C++ templates are a kind of restricted hygienic macro 
system, similar to D templates. It is however common for programmers to 
apply PL-theoretical terms in a somewhat sloppy way, e.g. here: 
https://rosettacode.org/wiki/Parametric_polymorphism

(Fun fact: it is actually only called "polymorphism". "Parametric" is 
added to distinguish the term from its usage related to virtual method 
calls in object-oriented programming languages.)

To be fair, templates quite successfully simulate parametric 
polymorphism for a large subset of its use cases and the compile-time 
code generation aspect can be very useful too.


 Are there any C-style languages that allow that?
 






 Feb 10 2018



prev sibling next sibling parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/10/2018 07:35 AM, Timon Gehr wrote:

 
 TL;DR: Parametrically polymorphic functions have /runtime/ type 
 parameters. inout can be interpreted as a dependent function of type 
 "{type y | y.among(x, const(x), immutable(x)) } delegate(type x)" and an 
 inout function can be thought of as a function that takes inout as an 
 argument and produces the function as the return value. This formulation 
 is more powerful than what the inout syntax can capture, and this is 
 what causes problems with type safety. In particular, 'inout' does not 
 support proper lexical scoping.
 
 TS;NM: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3 
 (Some version of this was originally intended to go to the D blog, but I 
 wanted to wait until inout has an obviously type safe definition. It 
 also highlights other inout issues than just type unsafety and shows how 
 all of them might be fixed in principle by adding polymorphism.)
 
 ---
 
 I'll first explain parametric polymorphism, and then what the inout 
 problem is.
 


Ahh, thanks. I'm still not *completely* 100%, but those explanations 
definitely helped a lot. Very insightful.

Side questions:

- Does this mean that fixing the issues with inout (even if done via 
some replacement of inout) would necessarily involve some runtime 
processing in at least certain cases?

- Though I realize this may contradict the definition of "parametric 
polymorphism" as you've described (and also ignoring the matter of 
virtual functions): Would it be theoretically possible to have 
parametric polymorphism that's *implemented* entirely via compile-time 
mechanisms such as templates? Or does our template system as D has it 
already represent the fundamental limits of such an approach?

Incidentally, I've felt for a long while it would've been really nice if 
D had first-class types (for both runtime and compile time). I think a 
system like that, if done right, could have gone a long way to 
alleviating all the awkwardness and asymmetries of reflection and type 
handling in D. It's also why I can understand people coming from certain 
dynamic languages who may find our metaprogramming combersome.



 Feb 11 2018



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/10/2018 4:35 AM, Timon Gehr wrote:

 In summary, the issue is that there is only one 'inout' and therefore it is
not 
 properly lexically scoped. It is a bit like having a language where all 
 variables are implicit function parameters and they all have the same, global, 
 name. This sort of works fine until you want a function with two parameters or 
 until you want to nest functions in a non-trivial way.


This needs to be filed on bugzilla. Shall I do it, or do you want to?



 Feb 15 2018



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 15.02.2018 21:38, Walter Bright wrote:

 On 2/10/2018 4:35 AM, Timon Gehr wrote:

 In summary, the issue is that there is only one 'inout' and therefore 
 it is not properly lexically scoped. It is a bit like having a 
 language where all variables are implicit function parameters and they 
 all have the same, global, name. This sort of works fine until you 
 want a function with two parameters or until you want to nest 
 functions in a non-trivial way.


 
 This needs to be filed on bugzilla. Shall I do it, or do you want to?


I had already filed the concrete counterexamples:

https://issues.dlang.org/show_bug.cgi?id=17743
https://issues.dlang.org/show_bug.cgi?id=17744

Should there be more?



 Feb 15 2018



prev sibling  parent  Dukc <ajieskola gmail.com>  writes:


On Friday, 9 February 2018 at 18:31:18 UTC, H. S. Teoh wrote:

 
 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.


So it's in your list of wanted stuff, not in your list of excess 
stuff. We're in agreement here.


 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

 barring some kind of workable (probably very long) deprecation 
 cycle, I just don't see it going away anytime in the 
 foreseeable future.


If we had something similar to c++ template lookup, it would, as 
I see it, finally solve that, along with many other problems. But 
bring some others, it's said... Better wrapper writing way than 
alias this would also solve it mostly and without the ADL 
problems, but there would still remain a problem with string and 
char literals.


 __traits, is expression, typeof and std.meta templates should 
 be invokable in a more UFCS-like manner


 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.


But UFCS style also allows the traditional way, there would be no 
breakage. So I quess that even here the existing thing is there 
for a reason after all.



After reading Manus list, I think I agree with his point 1.



 Feb 10 2018



prev sibling next sibling parent reply Manu <turkeyman gmail.com>  writes:


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



 Feb 09 2018



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/9/2018 11:13 AM, Manu wrote:

 1. Storage class as a concept separate to the type;


void test() {
     int x;
     static int y;

     typeof(x) != typeof(y) ???
}



 Feb 11 2018



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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



 Feb 09 2018



  parent  Tony <tonytdominguez aol.com>  writes:


On Friday, 9 February 2018 at 19:19:03 UTC, H. S. Teoh wrote:

 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.


That's true for writing your own code, but when you look at other 
code like the standard library and are trying to understand it - 
if it's written using a plethora of features, then you have to 
learn a plethora of features.

Ali G



 Feb 15 2018



prev sibling next sibling parent reply Meta <jared771 gmail.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


I can't say that I've ever really found D complicated. I think 
the main reason for that is because my first language was C++, 
and there's really nowhere to go but up from there (I was 
experienced with a few other languages as well like Java, Scheme, 
Basic, etc. but none I would regard as complex).

I think the perception of D being complicated is more from 
programmers coming from Python/Ruby/JS (and to a lesser extent, 
Haskell/Scheme/Java). D is quite different if you're coming from 
a "VM" or "scripting" language because it exposes you to a lot of 
new concepts such as static typing, value types, templates, 
monomorphization, immutability, memory layout, linking and 
compilation, compile-time vs. runtime, etc. It's not that these 
programmers are less skilled or less knowledgeable; it's that if 
they've never used a language that has forced them to consider 
these concepts, then it looks to them like D is a massive step up 
in complexity compared to the language that they're used to.

I think if you asked 100 C++ programmers whether they thought D 
was a complicated language, 99 of them would say no. If you ask 
100 Python programmers, 99 would probably say yes.



 Feb 09 2018



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 09, 2018 at 08:49:24PM +0000, Meta via Digitalmars-d wrote:
[...]

 I think the perception of D being complicated is more from programmers
 coming from Python/Ruby/JS (and to a lesser extent,
 Haskell/Scheme/Java). D is quite different if you're coming from a
 "VM" or "scripting" language because it exposes you to a lot of new
 concepts such as static typing, value types, templates,
 monomorphization, immutability, memory layout, linking and
 compilation, compile-time vs. runtime, etc. It's not that these
 programmers are less skilled or less knowledgeable; it's that if
 they've never used a language that has forced them to consider these
 concepts, then it looks to them like D is a massive step up in
 complexity compared to the language that they're used to.
 
 I think if you asked 100 C++ programmers whether they thought D was a
 complicated language, 99 of them would say no. If you ask 100 Python
 programmers, 99 would probably say yes.


Thanks for this very insightful post.

Before reading this, I couldn't understand why people thought D was
complex... I come from a strong C/C++ background, so to me D is like a
breath of fresh air in terms of understandability, flexibility, and
verbosity level. "Complex" certainly isn't what I'd think of when I
think about D.  But I suppose if someone is coming primarily from a
Python background, D could certainly be considered quite a step up in
perceived complexity!


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see
through walls. It was called the "window".



 Feb 09 2018



  parent reply Ralph Doncaster <nerdralph github.com>  writes:


On Friday, 9 February 2018 at 21:05:10 UTC, H. S. Teoh wrote:

 On Fri, Feb 09, 2018 at 08:49:24PM +0000, Meta via 
 Digitalmars-d wrote: [...]

 I think the perception of D being complicated is more from 
 programmers coming from Python/Ruby/JS (and to a lesser 
 extent, Haskell/Scheme/Java). D is quite different if you're 
 coming from a "VM" or "scripting" language because it exposes 
 you to a lot of new concepts such as static typing, value 
 types, templates, monomorphization, immutability, memory 
 layout, linking and compilation, compile-time vs. runtime, 
 etc. It's not that these programmers are less skilled or less 
 knowledgeable; it's that if they've never used a language that 
 has forced them to consider these concepts, then it looks to 
 them like D is a massive step up in complexity compared to the 
 language that they're used to.
 
 I think if you asked 100 C++ programmers whether they thought 
 D was a complicated language, 99 of them would say no. If you 
 ask 100 Python programmers, 99 would probably say yes.


 Thanks for this very insightful post.

 Before reading this, I couldn't understand why people thought D 
 was complex... I come from a strong C/C++ background, so to me 
 D is like a breath of fresh air in terms of understandability, 
 flexibility, and verbosity level. "Complex" certainly isn't 
 what I'd think of when I think about D.  But I suppose if 
 someone is coming primarily from a Python background, D could 
 certainly be considered quite a step up in perceived complexity!


I've done lots of C++ (though more in the earlier years), and I 
have to disagree.  I'd agree C++11 is more complicated than D, 
but D is still complicated.  I think I've programmed in enough 
languages (from asm, Perl, Java,...) and in large enough projects 
to have a good idea of what languages can be like.

I'll probably continue to stick it out and play with D for 
personal projects because of the things I like and find 
interesting, but professionally it's a no-go (pardon the pun).

Frankly, I think it is doomed to be a niche-use language.  While 
many more things were done right compared to C++, too many things 
were done wrong and there doesn't seem to be interest in breaking 
backward compatibility to excise them from D.



 Feb 09 2018



 next sibling parent reply rjframe <dlang ryanjframe.com>  writes:


On Fri, 09 Feb 2018 22:36:19 +0000, Ralph Doncaster wrote:


 Frankly, I think it is doomed to be a niche-use language.  While many
 more things were done right compared to C++, too many things were done
 wrong and there doesn't seem to be interest in breaking backward
 compatibility to excise them from D.


Yes.

If the current "let's get C++ programmers to like us" stuff continues, 
some of these problems will have to be fixed. I'm expecting C++20 to be a 
nice language for new projects, where you can ignore a lot of the blech 
(though not quite enough of it), and moving to C++20 will be easier than 
moving to D. The ROI just won't be there for most people (for many, it 
doesn't seem to be there today...).

I'm not sure that being a niche language is a bad thing; if we just say, 
"this is D; if you like it come and use it, come help make it better, but 
if it doesn't help you -- that's OK. There are other languages too" -- we 
may have more freedom to explore what D can do best. I've done compile-
time stuff in D I would never have even considered attempting with C++ - 
and I haven't done nearly as much as others here. I don't think we've 
really explored the fullness of the language yet, and I wonder if that's 
only going to be possible if we quit comparing ourselves so much to C++.

My code still looks a lot like C and Python; it doesn't look like D yet. 
If we keep setting our sights on C++/Rust/whatever, we're going to 
artificially limit ourselves to their limitations, and that would be sad.



 Feb 10 2018



  parent reply John Gabriele <jgabriele fastmail.fm>  writes:


On Saturday, 10 February 2018 at 12:44:14 UTC, rjframe wrote:

 On Fri, 09 Feb 2018 22:36:19 +0000, Ralph Doncaster wrote:


 Frankly, I think it is doomed to be a niche-use language.  
 While many more things were done right compared to C++, too 
 many things were done wrong and there doesn't seem to be 
 interest in breaking backward compatibility to excise them 
 from D.


 Yes.

 If the current "let's get C++ programmers to like us" stuff 
 continues, some of these problems will have to be fixed. I'm 
 expecting C++20 to be a nice language for new projects, where 
 you can ignore a lot of the blech (though not quite enough of 
 it), and moving to C++20 will be easier than moving to D. The 
 ROI just won't be there for most people (for many, it doesn't 
 seem to be there today...).


I also agree. One of the prime benefits of a language with a 
smaller community is that you can make it _better_ *faster*, 
breaking backcompat more easily and more often, and getting a 
better language in the process. After all, if its users wanted 
something slow to evolve, they'd be using one of the 
industry-accepted behemoths.


 I'm not sure that being a niche language is a bad thing; if we 
 just say, "this is D; if you like it come and use it, come help 
 make it better, but if it doesn't help you -- that's OK. There 
 are other languages too" -- we may have more freedom to explore 
 what D can do best. I've done compile- time stuff in D I would 
 never have even considered attempting with C++ - and I haven't 
 done nearly as much as others here. I don't think we've really 
 explored the fullness of the language yet, and I wonder if 
 that's only going to be possible if we quit comparing ourselves 
 so much to C++.


I don't think D is designed to be a niche language. It's a 
general purpose language, open source with multiple 
implementations, solid engineering, and even has good-looking 
syntax. It's not niche at all, it just doesn't have hoards of 
users. D is well-positioned to be hugely popular, but I think to 
succeed its leadership needs to be willing to fix things they 
want to fix and not worry about breaking backcompat.



 Feb 10 2018



  parent reply John Gabriele <jgabriele fastmail.fm>  writes:


On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele 
wrote:

 {snip} It's not niche at all, it just doesn't have hoards of 
 users. D is well-positioned to be hugely popular, but I think 
 to succeed its leadership needs to be willing to fix things 
 they want to fix and not worry about breaking backcompat.


Augh! "hordes", not "hoards".



 Feb 10 2018



  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Saturday, February 10, 2018 20:57:44 John Gabriele via Digitalmars-d 
wrote:

 On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele

 wrote:

 {snip} It's not niche at all, it just doesn't have hoards of
 users. D is well-positioned to be hugely popular, but I think
 to succeed its leadership needs to be willing to fix things
 they want to fix and not worry about breaking backcompat.


 Augh! "hordes", not "hoards".


Clearly, someone is hoarding our hordes, which is why we don't see enough of
them. ;)

- Jonathan M Davis



 Feb 10 2018



prev sibling  parent  bachmeier <no spam.net>  writes:


On Friday, 9 February 2018 at 22:36:19 UTC, Ralph Doncaster wrote:


 While many more things were done right compared to C++, too 
 many things were done wrong and there doesn't seem to be 
 interest in breaking backward compatibility to excise them from 
 D.


I agree. Some users might shout because they recompiled a piece 
of code for the first time in eight years and got an error. The 
users that don't shout are the ones that try out the language, 
see rough edges that should have been removed, and move on.

Enterprise users that want guaranteed language stability should 
pay to support a compiler for that version of the language. 
Archive a version of the compiler every two years and paying 
companies can be guaranteed to use that compiler forever. There's 
no reason to shut down the evolution of the language to satisfy 
one (currently very small) group of users.



 Feb 10 2018



prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Friday, February 09, 2018 20:49:24 Meta via Digitalmars-d wrote:

 On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


 I can't say that I've ever really found D complicated. I think
 the main reason for that is because my first language was C++,
 and there's really nowhere to go but up from there (I was
 experienced with a few other languages as well like Java, Scheme,
 Basic, etc. but none I would regard as complex).

 I think the perception of D being complicated is more from
 programmers coming from Python/Ruby/JS (and to a lesser extent,
 Haskell/Scheme/Java). D is quite different if you're coming from
 a "VM" or "scripting" language because it exposes you to a lot of
 new concepts such as static typing, value types, templates,
 monomorphization, immutability, memory layout, linking and
 compilation, compile-time vs. runtime, etc. It's not that these
 programmers are less skilled or less knowledgeable; it's that if
 they've never used a language that has forced them to consider
 these concepts, then it looks to them like D is a massive step up
 in complexity compared to the language that they're used to.

 I think if you asked 100 C++ programmers whether they thought D
 was a complicated language, 99 of them would say no. If you ask
 100 Python programmers, 99 would probably say yes.


I have to agree with all of this. I've never found D as a whole to be overly
complicated. C++ wins _that_ contest hands down. And I've found languages
like Java to be overly simple (e.g. one of my professors in college said
that Java didn't become a real language until they added generics, because
that actually added some complexity to it). IMHO, any language that's really
worth using isn't going to be simple.

Now, that's not to say that I think that every feature in D should be there
(e.g. I'd rather that template specializations not exist, because template
constraints make them completely unnecessary and ultimately an unnecessary
complication), and there have certainly been mistakes made along the way
(e.g. auto-decoding was a mistake, and  property never went anywhere like it
was supposed to, leaving it there kind of like an appendix). But I wouldn't
really say that D is overly complicated, just that it could be better.

But I also come from a C++ background, which significantly colors my view of
things. I suspect that I'd have a very different viewpoint if I'd started
with something like Java, python, or Go, since those languages are all far
simpler. But then again, maybe I'd still end up finding D's level of power
and complexity refreshing. I originally ended up finding D, because I wanted
a language with some of the safety features that Java had but without losing
all of the power of C++. C++ had too many problems that resulted in bugs,
and Java had stripped out too many features in comparison. Fortunately, D
has proven to provide a good balance in that respect - not perfect, but by
far the best I've encountered.

- Jonathan M Davis



 Feb 09 2018



  parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 04:27 PM, Jonathan M Davis wrote:

 
 I have to agree with all of this. I've never found D as a whole to be overly
 complicated. C++ wins _that_ contest hands down. And I've found languages
 like Java to be overly simple (e.g. one of my professors in college said
 that Java didn't become a real language until they added generics, because
 that actually added some complexity to it). IMHO, any language that's really
 worth using isn't going to be simple.
 


*nod, nod*

Any task has an inherent level of complexity. That complexity can be 
either be in the language, or in the user code. Your choice.

And then there's C++ which manages to CREATE extra needless complexity 
on both sides, thereby falsely convincing entire generations of 
programmers that langauge complexity is inherently bad. No, it's 
*unnecessary* complexity that's bad.



 I originally ended up finding D, because I wanted
 a language with some of the safety features that Java had but without losing
 all of the power of C++. C++ had too many problems that resulted in bugs,
 and Java had stripped out too many features in comparison.


*Exactly* what led me to D, too. :)



 Feb 09 2018



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 09, 2018 at 05:41:28PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

 On 02/09/2018 04:27 PM, Jonathan M Davis wrote:

 
 I have to agree with all of this. I've never found D as a whole to
 be overly complicated. C++ wins _that_ contest hands down. And I've
 found languages like Java to be overly simple (e.g. one of my
 professors in college said that Java didn't become a real language
 until they added generics, because that actually added some
 complexity to it). IMHO, any language that's really worth using
 isn't going to be simple.




/// ditto :-)


[...]

 Any task has an inherent level of complexity. That complexity can be
 either be in the language, or in the user code. Your choice.
 
 And then there's C++ which manages to CREATE extra needless complexity
 on both sides, thereby falsely convincing entire generations of
 programmers that langauge complexity is inherently bad. No, it's
 *unnecessary* complexity that's bad.


And this in the name of backward compatibility with C, with which it is
not strictly backward-compatible. :-D



 I originally ended up finding D, because I wanted a language with
 some of the safety features that Java had but without losing all of
 the power of C++. C++ had too many problems that resulted in bugs,
 and Java had stripped out too many features in comparison.


 
 *Exactly* what led me to D, too. :)


/// ditto :-)

When I found D, I had already been chafing for *years* under the hell
that C++ development was, but could not stand the thought of moving to
Java, because it was just (1) too verbose, and (2) not powerful enough
to express what I want. (That was in the days before Java generics...
though even with generics, I doubt I would've been convinced. It's just
... not quite "there" in terms of expressive power.)

D does have its warts, yeah, but I'm sticking with it for now because it
represents the closest thing to what I consider an ideal programming
language.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in
common: they don't depend on the language. -- Luca De Vitis



 Feb 09 2018



  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 05:55 PM, H. S. Teoh wrote:

 
 When I found D, I had already been chafing for *years* under the hell
 that C++ development was, but could not stand the thought of moving to
 Java, because it was just (1) too verbose, and (2) not powerful enough
 to express what I want. (That was in the days before Java generics...
 though even with generics, I doubt I would've been convinced. It's just
 ... not quite "there" in terms of expressive power.)
 


After beginning mainly with various BASICs, I started learning about 
game development which, at the time, meant C (and "C++ as a 
C-with-classes"). So I was pretty deeply into C/C++ stockholm-syndromne 
for a good long while, just 'cause I didn't know any better.

Then a crop of new (at the time) features of C++ started perplexing me, 
but I still didn't know much better. At that point, I was in college at 
the height of the Java craze, so when I inevitably tried Java (v2), it 
was eye-opening: Ruined me on much of C++ almost instantly, and 
simultaneously ruined me on Java itself due to chafing at everything it 
deliberately couldn't do. Nearly ruined me on programming until a search 
for a happy-middle language led me to a very early D (not long after 
templates IIRC, but WELL before v1.0), and I was like "Yes! *This* is 
what I wanted!" :)


but no proverbial cigar.)



 Feb 09 2018



prev sibling  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Friday, 9 February 2018 at 20:49:24 UTC, Meta wrote:

 was a complicated language, 99 of them would say no. If you ask 
 100 Python programmers, 99 would probably say yes.


Yes, but objectively speaking I'd say modern Python is more 
complicated than C++ and D.

What Python got right is that you don't have to deal with the 
complicated stuff unless you are hellbent on dealing with it. 
Python affords a very smooth incremental learning curve, but it 
is still a long learning curve...



 Feb 09 2018



  parent  Bo <bo41 bo0041.com>  writes:


On Friday, 9 February 2018 at 23:01:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 9 February 2018 at 20:49:24 UTC, Meta wrote:

 was a complicated language, 99 of them would say no. If you 
 ask 100 Python programmers, 99 would probably say yes.


 Yes, but objectively speaking I'd say modern Python is more 
 complicated than C++ and D.

 What Python got right is that you don't have to deal with the 
 complicated stuff unless you are hellbent on dealing with it. 
 Python affords a very smooth incremental learning curve, but it 
 is still a long learning curve...


^ This ...

I am seeing some responses that a language that is not loaded 
with all the options is not really real language. Yet, those 
languages are used for productivity all over the world.

Go is horrible limited and yet loved by many. And many really 
push the boundaries very far. But why do Python, PHP, Ruby, Go 
and others rank so high. Its because they are designed with a 
easy learning curve and documentation to match this curve.

D has the issue its designed to trow people into the deep end of 
the pool. Reading the responses on the basic nitpicking issues 
with D ( that i posted here ), you can tell that people "do not 
get it". Its small issues but a lot of small issues simply 
increase complexity. One mole in a garden is not a issue and can 
be overlooked. A hundred and people prefer the garden next door.

D will never be a language that draws in a lot of people from 
scripting languages like Python, PHP, Ruby simply because its 
clearly not designed with this mindset. It also does not help how 
much strange code decisions have been made in the past, that 
result in awkward library issues.

The problem is most languages allow you to program 80 to 90% of 
the task with eases.

D is focused on providing those extra 10 a 20% but in doing so 
the language has gotten complex, the library filled with years of 
scruff and because it focused on that extra 20%, it only draws in 
a selective crowd that keeps pushing more and more into that 
boundary. And that same crowd is not focused on leaving C++ any 
time soon, as C++ keeps evolving and improving. Anybody really 
focused on going into this 20% market, will look at the players, 
the tools and simply say: "Why D? Why not C++ 14/17/20".

This very much compact the issue that D has in attracting new 
users.



 Feb 10 2018



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


On 9 February 2018 at 11:19, H. S. Teoh via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


    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


I feel like the keyword there was MORE sanitary.
Writing functions that assemble code into a string is definitely not the
best way... you lose syntax highlighting, code completion/suggestion,
refactoring, etc, in any meaningful way.
The less your meta requires you resort to strings, the better... and that

the greatest complexity on meta; almost always leads to text mixins,
because there's no machinery for storage classes (or attributes). Can not
alias, compound, aggregate... anything.



 Feb 09 2018



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 09, 2018 at 01:36:50PM -0800, Manu wrote:

    On 9 February 2018 at 11:19, H. S. Teoh via Digitalmars-d
    <[1]digitalmars-d puremagic.com> wrote:
 
      >    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
 
    I feel like the keyword there was MORE sanitary.
    Writing functions that assemble code into a string is definitely
    not the best way... you lose syntax highlighting, code
    completion/suggestion, refactoring, etc, in any meaningful way.


AFAIK, the original intent was that string mixins would only rarely be
used... At least, that's the impression I got from reading TDPL.  Sadly,
these days it seems almost every other day somebody else stumbles into a
problem to which string mixins seem to be the default answer.



    The less your meta requires you resort to strings, the better...

    the type system is the greatest complexity on meta; almost always
    leads to text mixins, because there's no machinery for storage
    classes (or attributes). Can not alias, compound, aggregate...
    anything.


[...]

Truth be told, while I do greatly enjoy D's powerful metaprogramming
features, I also can't help noticing that in some areas it's a little
rough around the edges, and has seemingly-arbitrary asymmetries that
leads to ugliness in generic code. The whole storage class thing is one
example.  As well as historical asymmetries in attributes. Or the
convoluted paraphrases required to do meta coding with attributes. The
functionality is there, but it just needs lots of hoop-jumping,
asymmetric workarounds, and, sadly, string mixins in some cases.

One of the most powerful innovations in D, IMO, is how CTFE allows you
to do compile-time computations *without needing to switch to a special
sub-syntax*.  You just write the code as if it were runtime code, and it
Just Works(tm). This symmetry is what makes it so compelling.  While C++
does offer constexpr, the last time I checked it comes with a number of
syntactic and semantic asymmetries that produce friction and makes it a
little less desirable to work with.

Similarly, compile-time parameters sharing (most of) the runtime
parameter syntax is another winning move that increases symmetry,
reduces friction, and thereby makes it more compelling to work with.

Continuing in the same vein, the syntax required to work directly with
AST entities (as opposed to runtime entities in CTFE) is still a source
of friction. If I want to, say, generate different declarations
depending on what I find in an AliasSeq aka "type tuple", I have to
resort to writing a recursive template instead of just looping over the
sequence.  This is asymmetric, generates friction, and makes it less
pleasant to work with.

In this case, `static foreach` lets you continue using loop syntax, and
is a step in the right direction.  But still, things are still rough
around the edges (e.g., generating unique identifiers to prevent
collision errors, etc.). For example, implementing .map or .joiner over
AliasSeq's would require a lot of ugly paraphrases with recursive
templates, or (shudder) string mixins.

Ideally, compile-time entities should be put on the same level as
runtime entities, so that, for example, you can assign types, storage
classes, function attributes, or indeed AliasSeq's, into compile-time
variables, manipulate them with runtime-like syntax, etc..  This would
remove the unnecessary asymmetries between compile-time / runtime
constructs, reducing friction and thus making it more compelling to work
with.  We may not be able to attain to this ideal given the current
state of things or for historical reasons, but it should be at least a
goal we aim for, rather than introduce more asymmetries to the language.


T

-- 
Fact is stranger than fiction.



 Feb 09 2018



  parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 05:20 PM, H. S. Teoh wrote:

 
 Sadly,
 these days it seems almost every other day somebody else stumbles into a
 problem to which string mixins seem to be the default answer.
 


Really? That's not been my perception.

 From what I've seen, anything that requires the user to mixin a string, 
is pretty much automatically granted the black mark of death - no one 
will touch it.



 Feb 09 2018



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

 On 02/09/2018 05:20 PM, H. S. Teoh wrote:

 
 Sadly, these days it seems almost every other day somebody else
 stumbles into a problem to which string mixins seem to be the
 default answer.
 


 
 Really? That's not been my perception.
 
 From what I've seen, anything that requires the user to mixin a
 string, is pretty much automatically granted the black mark of death -
 no one will touch it.


Well no, the mixin is not exposed to the user.

But I do see it used quite a lot inside libraries, specifically Phobos.
Well, "quite a lot" is not a fair statement; perhaps I should better say
"more often than it probably should be".  While a mixin-based hack
certainly gains brownie points for cleverness, in the long term it
incurs a maintainability cost, and sometimes a hefty one.  If the mixin
is of significant length, it can be a nightmare to debug / fix / extend.
(And I say that because, yes, to my shame I've also done that in my own
code.)


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.



 Feb 09 2018



  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 02/09/2018 05:49 PM, H. S. Teoh wrote:

 On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:

 Really? That's not been my perception.

  From what I've seen, anything that requires the user to mixin a
 string, is pretty much automatically granted the black mark of death -
 no one will touch it.


 
 Well no, the mixin is not exposed to the user.
 
 But I do see it used quite a lot inside libraries, specifically Phobos.
 Well, "quite a lot" is not a fair statement; perhaps I should better say
 "more often than it probably should be".  While a mixin-based hack
 certainly gains brownie points for cleverness, in the long term it
 incurs a maintainability cost, and sometimes a hefty one.  If the mixin
 is of significant length, it can be a nightmare to debug / fix / extend.
 (And I say that because, yes, to my shame I've also done that in my own
 code.)
 


Ahh, I see. I wonder if the immediate "reach for string mixins" reaction 
is larely, perhaps subconciously, due to impedance of all the asymetric 
mess that dealing with types can otherwise be?



 Feb 09 2018



prev sibling  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Friday, February 09, 2018 14:49:42 H. S. Teoh via Digitalmars-d wrote:

 On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via 


Digitalmars-d wrote:

 On 02/09/2018 05:20 PM, H. S. Teoh wrote:

 Sadly, these days it seems almost every other day somebody else
 stumbles into a problem to which string mixins seem to be the
 default answer.


 Really? That's not been my perception.

 From what I've seen, anything that requires the user to mixin a
 string, is pretty much automatically granted the black mark of death -
 no one will touch it.


 Well no, the mixin is not exposed to the user.

 But I do see it used quite a lot inside libraries, specifically Phobos.
 Well, "quite a lot" is not a fair statement; perhaps I should better say
 "more often than it probably should be".


Really? I don't recall seeing the often in Phobos at all. Certainly, some
stuff is best-suited to string mixins (and in the case of overloaded
operators the design calls for using string mixins in order to reduce the
number of declarations you have), but I don't recall seeing them often or
ever having the impression that they were used when they shouldn't be. But I
haven't thought about it a lot either. Personally, I just use them when they
seem most appropriate, and they usually aren't needed much unless I'm doing
something on the crazier side, which isn't often.

- Jonathan M Davis



 Feb 09 2018



prev sibling next sibling parent reply Jon Degenhardt <jond noreply.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

 Which language futures by your opinion make D harder?


For me, one of the attractive qualities of D is its relative 
simplicity. Key comparison points are C++, Scala, and Python. 
Python being the simplest, then D, not far off, with Scala and 
C++ being more complex. Entirely subjective, not measured in any 
empirical way.

That said, a couple of D constructs that I personally find 
increases friction:

* Static arrays aren't not ranges. I continually forget to slice 
them when I want to use them as ranges. The compiler errors are 
often complex template instantiation failure messages.

* Template instantiation failures - It takes longer than I'd like 
to figure out why a template failed to instantiate. This is 
especially true when there are multiple overloads, each with 
multiple template constraints.

* Auto-decoding - Mentioned by multiple people. It's mainly an 
issue after you've decided you need to avoid it. Figuring out how 
out to utilize Phobos routines without having them engage 
auto-decoding on your behalf is challenging.

--Jon



 Feb 10 2018



  parent  Nicholas Wilson <iamthewilsonator hotmail.com>  writes:


On Saturday, 10 February 2018 at 20:50:37 UTC, Jon Degenhardt 
wrote:

 On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

 Which language futures by your opinion make D harder?


 * Static arrays aren't not ranges. I continually forget to 
 slice them when I want to use them as ranges. The compiler 
 errors are often complex template instantiation failure 
 messages.


File a bug report! This should be relatively straightforward
to improve the error message.



 Feb 11 2018



prev sibling next sibling parent  Arun Chandrasekaran <aruncxy gmail.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


Sorry for being pessimistic, but this has already been discussed 
many times here. This is just a waste of time and it doesn't 
produce any results.

Having coded in C++ all my life, I can definitely say C++ is way 
too complex. So D can't win it in that aspect. :-)

The main thing confused me a LOT, as ketmar rightly said, was 
struct (it was not TLS, it was not static, it was not GC). Other 
than that, there are a few that I can point in D that I consider 
are complex.

* auto decoding - given that ranges are the idiomatic way, it's 
simply unacceptable.
* shared
* immutable vs const
* lack of consistency and orthogonality. Past discussions: 
https://forum.dlang.org/post/iysrtqzytdnrxsqtfwvk forum.dlang.org

 From the perspective of language complexity, I'm already living 
with C++, so I can live with D as well. But the difficult thing 
to live with is

* Dearth of libraries (features, performance and quality)
* Dearth of libraries
* Dearth of libraries



 Feb 10 2018



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2018-02-09 08:54, Suliman 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. Metaprogramming is a mess. Metaprogramming in D is split across many 
features: like templates, __traits, the "is" expression, .tupleof 
TypeInfo and probably others I have forgot.

2. The "is" expression. This is one of the most complicated features in 
D. I understand most of the examples in the spec [1], but then when you 
see how this feature is used in the wild, it's like: what!... how did 
you... that doesn't make sense.

3. Ranges only works with mutable arrays and don't work with tuples

4. "alias" parameters don't accept all values/types/symbols that "T..." does

5. Lambdas don't work, as far as I know, with alias or type parameters. 
That is, it's not possible to use a lambda to as a predicate to, for 
example, filter a tuple of types

These are all annoying issues when you work with metaprogramming 
resulting to add workarounds that makes the code unnecessary complicated.

[1] https://dlang.org/spec/expression.html#is_expression

-- 
/Jacob Carlborg



 Feb 12 2018



prev sibling  parent  psychoticRabbit <meagain meagain.com>  writes:


On Friday, 9 February 2018 at 07:54:49 UTC, Suliman 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?


right now.. compile time function execution ;-)



 Feb 20 2018