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.

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.

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...
>    and that folds back into my #1 point; storage class separate from
>    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.

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?

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.

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.

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

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

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.

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.