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

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

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

Thanks for this very insightful post.

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


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
February 09, 2018
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

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


February 09, 2018
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 <http://dunkels.com/adam/pt/>, but with far nicer syntax.

>> - no dedicated syntax sugar for ranges;
> 
> What do you expect here?
> (also it's not entirely true - foreach already supports ranges)
> 

For input ranges (maybe even forward ranges), a stackless corountine 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.)
February 09, 2018
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.
February 09, 2018
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<int> Fibonacci(int limit)
>> {
>>    int a = 1, b = 1;
>>    while (a < limit)
>>    {
>>      yield return a;  //syntactic sugar
>>      var t = a;
>>      a = b;
>>      b = t + b;
>>    }
>> }
>
> So your point is that std.concurrency.Generator isn't so nice? Not advertised?
> Or do you simply want to have a keyword that wraps a function into generator like function* in ES6?
>
> ---
> auto fib = (int limit){
>     import std.concurrency;
>     return new Generator!int((){
>         int a = 1, b = 1;
>         while (a < limit)
>         {
>             a.yield; //syntactic sugar
>             auto t = a;
>             a = b;
>             b = t + b;
>         }
>     });
> };
> ---
>
> https://run.dlang.io/is/xQl0Ir


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

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.

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