Re: Which language futures make D overcompicated?

2018-02-20 Thread psychoticRabbit via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-17 Thread Laeeth Isharc via Digitalmars-d

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




Re: Which language futures make D overcompicated?

2018-02-15 Thread Timon Gehr via Digitalmars-d

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?


Re: Which language futures make D overcompicated?

2018-02-15 Thread Walter Bright via Digitalmars-d

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?


Re: Which language futures make D overcompicated?

2018-02-15 Thread Tony via Digitalmars-d

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




Re: Which language futures make D overcompicated?

2018-02-13 Thread bauss via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-13 Thread Andre Pany via Digitalmars-d
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 +, 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é


Re: Which language futures make D overcompicated?

2018-02-13 Thread rikki cattermole via Digitalmars-d

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

On Tue, 2018-02-13 at 10:45 +, 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.



Re: Which language futures make D overcompicated?

2018-02-13 Thread Russel Winder via Digitalmars-d
On Tue, 2018-02-13 at 10:45 +, 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. 

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-13 Thread rikki cattermole via Digitalmars-d

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!



Re: Which language futures make D overcompicated?

2018-02-13 Thread aberba via Digitalmars-d
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.




Re: Which language futures make D overcompicated?

2018-02-12 Thread Jacob Carlborg via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-12 Thread Russel Winder via Digitalmars-d
On Sun, 2018-02-11 at 19:31 -0700, Jonathan M Davis via Digitalmars-d
wrote:
> 
[…]
> 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. 

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.

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-11 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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=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 

Re: Which language futures make D overcompicated?

2018-02-11 Thread Pjotr Prins via Digitalmars-d
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 ;)


Re: Which language futures make D overcompicated?

2018-02-11 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-11 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-11 Thread Adam D. Ruppe via Digitalmars-d
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.




Re: Which language futures make D overcompicated?

2018-02-11 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-11 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Ugh, system-level package managers. That's the #1 reason I keep hopping 
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" 
is software's #1 sacred cow). Those are *exactly* the reasons why 
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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread rikki cattermole via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread Jonathan M Davis via Digitalmars-d
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




Re: Which language futures make D overcompicated?

2018-02-11 Thread rikki cattermole via Digitalmars-d

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

On Sun, 2018-02-11 at 10:59 +, 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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread Russel Winder via Digitalmars-d
On Sun, 2018-02-11 at 10:59 +, 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.

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.

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-11 Thread Walter Bright via Digitalmars-d

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) ???
}


Re: Which language futures make D overcompicated?

2018-02-11 Thread rikki cattermole via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-11 Thread Russel Winder via Digitalmars-d
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. 

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 
> need is a package manager designed from the ground up to NOT be
> anything 
> 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 – though I don't I just use Cargo.

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-11 Thread Nicholas Wilson via Digitalmars-d
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.




Re: Which language futures make D overcompicated?

2018-02-10 Thread Pjotr Prins via Digitalmars-d
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.


Re: Which language futures make D overcompicated?

2018-02-10 Thread Arun Chandrasekaran via Digitalmars-d

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/iysrtqzytdnrxsqtf...@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



Re: Which language futures make D overcompicated?

2018-02-10 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-10 Thread John Gabriele via Digitalmars-d
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".



Re: Which language futures make D overcompicated?

2018-02-10 Thread John Gabriele via Digitalmars-d

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

On Fri, 09 Feb 2018 22:36:19 +, 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.




Re: Which language futures make D overcompicated?

2018-02-10 Thread Jon Degenhardt via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-10 Thread Timon Gehr via Digitalmars-d

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?



C#. Also, to some extent, Java.


Re: Which language futures make D overcompicated?

2018-02-10 Thread Bo via Digitalmars-d
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.


Re: Which language futures make D overcompicated?

2018-02-10 Thread bachmeier via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-10 Thread Mark via Digitalmars-d

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?




Re: Which language futures make D overcompicated?

2018-02-10 Thread rjframe via Digitalmars-d
On Fri, 09 Feb 2018 22:36:19 +, 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.


Re: Which language futures make D overcompicated?

2018-02-10 Thread Timon Gehr via Digitalmars-d

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();
int* y=dg();
assert( is y); // passes. ouch.
*y=3;
assert(b is *); // 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 

Re: Which language futures make D overcompicated?

2018-02-10 Thread Dukc via Digitalmars-d

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.




Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Timon Gehr via Digitalmars-d

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

On Fri, Feb 09, 2018 at 05:56:38PM +, 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.)


Re: Which language futures make D overcompicated?

2018-02-09 Thread Timon Gehr via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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?


Re: Which language futures make D overcompicated?

2018-02-09 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
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...


Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Ola Fosheim Grøstad via Digitalmars-d

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





Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 09, 2018 at 10:22:01PM +, 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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Ralph Doncaster via Digitalmars-d

On Friday, 9 February 2018 at 21:05:10 UTC, H. S. Teoh wrote:
On Fri, Feb 09, 2018 at 08:49:24PM +, 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.




Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-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. :)



Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

On 02/09/2018 01:13 PM, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, 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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread rumbu via Digitalmars-d

On Friday, 9 February 2018 at 15:53:47 UTC, Russel Winder wrote:
On Fri, 2018-02-09 at 14:04 +, 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?





Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread rumbu via Digitalmars-d

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:

rough C# translation:

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?



C#:

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


This is the documentation for C#:
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.




Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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?



I can't speak for await, as I left C# for D long before it was introduced.

But as far as yield return (ie, C#'s coroutines): The problem with the 
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.)


But the C# version, OTOH, lacks this fiber overhead entirely: 
Internally, it works the same way as C's protothreads 
, 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 
approach like C#.


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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Manu via Digitalmars-d
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
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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 09, 2018 at 08:49:24PM +, 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".


Re: Which language futures make D overcompicated?

2018-02-09 Thread John Gabriele via Digitalmars-d

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.




Re: Which language futures make D overcompicated?

2018-02-09 Thread Meta via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Patrick Schluter via Digitalmars-d

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.




Re: Which language futures make D overcompicated?

2018-02-09 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-09 Thread Jonathan M Davis via Digitalmars-d
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



Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Mark via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Manu via Digitalmars-d
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


Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 09, 2018 at 06:20:32PM +, 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!


Re: Which language futures make D overcompicated?

2018-02-09 Thread John Gabriele via Digitalmars-d

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 +, 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?




Re: Which language futures make D overcompicated?

2018-02-09 Thread Meta via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 09, 2018 at 06:44:08PM +, 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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Seb via Digitalmars-d

On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, 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)


Re: Which language futures make D overcompicated?

2018-02-09 Thread Meta via Digitalmars-d

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




Re: Which language futures make D overcompicated?

2018-02-09 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 09, 2018 at 05:56:38PM +, 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


Re: Which language futures make D overcompicated?

2018-02-09 Thread jmh530 via Digitalmars-d

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?


Re: Which language futures make D overcompicated?

2018-02-09 Thread Seb via Digitalmars-d

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!


Re: Which language futures make D overcompicated?

2018-02-09 Thread Bo via Digitalmars-d
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, ...


Re: Which language futures make D overcompicated?

2018-02-09 Thread Atila Neves via Digitalmars-d

On Friday, 9 February 2018 at 15:55:27 UTC, Russel Winder wrote:
On Fri, 2018-02-09 at 13:51 +, 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


Re: Which language futures make D overcompicated?

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

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

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-09 Thread Atila Neves via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Russel Winder via Digitalmars-d
On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:
> 
[…]
> Dub is not dead, it just has limited resources.

So , if the D community want Dub to work as a build system as well as a
package manager, extend the resources by corralling the grumblers and
support them into fixing code and creating pull requests.

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

> […]

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


signature.asc
Description: This is a digitally signed message part


Re: Which language futures make D overcompicated?

2018-02-09 Thread Dukc via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Adam D. Ruppe via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Ralph Doncaster via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread Seb via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Seb via Digitalmars-d

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:

rough C# translation:

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?



C#:

IEnumerable 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


Re: Which language futures make D overcompicated?

2018-02-09 Thread bachmeier via Digitalmars-d

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.


Re: Which language futures make D overcompicated?

2018-02-09 Thread jmh530 via Digitalmars-d

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


Re: Which language futures make D overcompicated?

2018-02-09 Thread Seb via Digitalmars-d

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.


  1   2   >