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