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


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

February 09, 2018
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!" :)

Nothing else ever lived up since. (C#, and later Nemerle, came close, but no proverbial cigar.)
February 09, 2018
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?
February 09, 2018
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.
February 10, 2018
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.
February 10, 2018
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.)
February 10, 2018
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.