On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
> Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.

Yes, it's regularly mentioned, and indeed D makes a nice Python rival in some use-cases like scientific computing.
Usually you don't need a fast native language for scripts though, but having to only learn a single language ecosystem can still be helpful.

On Friday, February 23, 2018 09:48:33 Norm via Digitalmars-d-announce wrote:
> [snip]
> On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit
>
> wrote:
> > Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.
>
> This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.

I don't know that scripts are really all that big a deal, since being able to slap #/usr/bin/env rdmd at the top really just saves you from having to compile the binary yourself, but I do use that functionality from time to time, and regardless of whether that functionality is supported, being able to write small programs to do stuff is invaluable. I do frequently use shell scripts when stuff is simple, but it doesn't take much before it's just easier to write them in D, and on Windows, I sure don't want to be writing batch scripts. So, being able to reasonably write small D programs to perform simple tasks is huge. And regardless of the scripting support, D itself makes that _way_ nicer than C/C++ does.

Writing programs that are hundreds of thousands or millions of lines long is definitely not D's only use case.

- Jonathan M Davis

On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
>
> This import feature and surrounding discussion I couldn't care less about ...

I actually spend far more time reading large chunks of code, than writing code, and I certainly do NOT want to spend extra time deciphering imports, due to an unpopular and confusing syntax change.

If I were mainly writing 'scripts', then I too would probably not care less ;-)

If D just wants to become a compiled scripting language...good luck to it.

I'll go find a proper progamming langauge long before that happens.

On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit wrote:
> If D just wants to become a compiled scripting language...good luck to it.

That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.

On Friday, February 23, 2018 10:57:21 Martin Nowak via Digitalmars-d- announce wrote:
> On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit
>
> wrote:
> > If D just wants to become a compiled scripting language...good luck to it.
>
> That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.

And D has a lot of the easy-of-use that folks like to attribute to scripting languages. Thanks to how hard stuff like string processing is in C/C++, there's frequently a perception that compiled languages are hard to use for a lot of stuff that folks like to use scripting languages for, whereas that really has nothing to do with whether the language is compiled or not. And D is much more on-par with scripting languages in that regard even though it's compiled. So, if someone uses a scripting language because of its use-of-use, D frequently works for those use cases just as well.

There's no requirement that a compiled language be used for large programs or that it be hard to use for simple tasks. And D can be used for a whole range of program sizes and tasks. It's a solid general purpose language, and small scripts fit into that just as well as large applications do.

- Jonathan M Davis

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
> 17. Allow multiple selective imports from different modules in a single import statement

Let me hopefully conclude this discussion :).

We have an existing ambiguity in the language since at least dmd 1.0. This is unfortunate but seems costly to remove and minor in impact (after learning this behavior).

    import trees, fruits : apple, birds;

A newcomer to D could rightfully conclude that comma is a module separator and the following is the correct syntax to import multiple symbols.

    import std.stdio, std.conv : to, std.conv : parse;

Embracing that existing ambiguity to support multi-module selective imports wasn't well received, partly because it amplifies the ambiguity and partly because multi-module imports are frowned upon.

On the plus side, we've understood that the actual wish for that syntax arised from scripting and example contexts, which might be better addressed by https://dlang.org/changelog/2.079.0.html#std-experimental-scripting, lazy import resolution by the compiler or a library, or automatic imports (https://github.com/CyberShadow/AutoFix).

Furthermore there remain various ideas that would avoid the original ambiguity. Whether such changes are worthwhile is up for discussion and would benefit from someone taking the lead.

I still think that local imports are nice for being explicit and toolable but have the downside of being brittle.
Something like bash style expansion could help to hit a sweet spot IMHO.

    import std.{algorithm : {find, findSplit}, stdio : writeln};
    import std.experimental.allocator.building_blocks.{free_list, region};

But certainly anything in that direction requires time and research, which I don't have for that topic.

In hindsight the voting experiment on https://github.com/dlang/dmd/pull/6589 might have prevented useful early feedback and thinking.

Given the effort required for a language change, it's seductive to streamline seemingly small changes, but it certainly increases the risk of design mistakes, thanks for appealing against this one.

-Martin

On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
> [snip]
> On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit wrote:
>>
>> Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.
>
> This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.
>
Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice.

On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
> But certainly anything in that direction requires time and research, which I don't have for that topic.

Also new syntax would likely be met with strong resistance due to the amount of induced churn.

On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
>
> A newcomer to D could rightfully conclude that comma is a module separator and the following is the correct syntax to import multiple symbols.
>
>     import std.stdio, std.conv : to, std.conv : parse;
>

What if you have something like
import std.stdio, std.conv : to, parse;
and there is a module at the top-level named parse?

On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
> On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:

> Given the effort required for a language change, it's seductive to streamline seemingly small changes, but it certainly increases the risk of design mistakes, thanks for appealing against this one.
>
> -Martin

Thanks to you, sincerely, It was a nice try to solve a problem, and trying to solve problems is the 'right thing to do'.

I'm really pleased to see the D community developing the antibodies needed to support a strong and sane  grown of D!

/Paolo