On Tuesday, 5 January 2021 at 15:31:34 UTC, welkam wrote:
> On Tuesday, 5 January 2021 at 12:58:58 UTC, aberba wrote:
>> D for scripting and productivity is hugely unexploited.
>
> I have the same feeling

Aberba's blog will be a good start to showcase D in that light. I remember that there was also the suggestion to turn the "one-line-usage of dmd from within shell" into a blog (in a response to how H. S. Teoh and probably others use dmd for one-line shell-scripting). Could be a nice mini-series.

On Tuesday, 5 January 2021 at 13:05:30 UTC, Andre Pany wrote:
> On Tuesday, 5 January 2021 at 11:46:06 UTC, Tobias Pankrath wrote:
>> [...]
>
> Yes, tuples are a core strength of D, but the syntax is not great. My hope is with the tuple dip we will be able to have a python like syntax:
>
> (Python numpy example)
> arr = numpy.array([('a', 0), ('b', 1)])
>
> My gut feeling is, we will be able to compete with numpy if we can provide tuple syntax as python can provide.
>
> Also named arguments is really important here, fortunately there is already someone working on the implementation of the approved dip.
>
> Kind regards
> Andre

+1 here. I think "modern" data science should be done with D! Think of performance 🍀

On 2021-01-05 14:05, Andre Pany wrote:

> Yes, tuples are a core strength of D, but the syntax is not great. My hope is with the tuple dip we will be able to have a python like syntax:
> 
> (Python numpy example)
> arr = numpy.array([('a', 0), ('b', 1)])
> 
> My gut feeling is, we will be able to compete with numpy if we can provide tuple syntax as python can provide.

I would love to have a better syntax for tuples in D but I'm very skeptical that D would be anymore or less suitable to do the same things as numpy does only based on getting a better tuple syntax.

The above example could be implemented as a variadic template in D:

auto arr = array('a', 0, 'b', 1); // less syntax then the Python example

Template constraints can be used to make sure there are even number of arguments and of the correct types.

-- 
/Jacob Carlborg

On Wednesday, 6 January 2021 at 17:56:59 UTC, Jacob Carlborg wrote:
> On 2021-01-05 14:05, Andre Pany wrote:
>
>> Yes, tuples are a core strength of D, but the syntax is not great. My hope is with the tuple dip we will be able to have a python like syntax:
>> 
>> (Python numpy example)
>> arr = numpy.array([('a', 0), ('b', 1)])
>> 
>> My gut feeling is, we will be able to compete with numpy if we can provide tuple syntax as python can provide.
>
> I would love to have a better syntax for tuples in D but I'm very skeptical that D would be anymore or less suitable to do the same things as numpy does only based on getting a better tuple syntax.
>
> The above example could be implemented as a variadic template in D:
>
> auto arr = array('a', 0, 'b', 1); // less syntax then the Python example
>
> Template constraints can be used to make sure there are even number of arguments and of the correct types.

Maybe yes, but I am not 100 % sure, as in your example the information about the dimension count is lost.

In the numpy example you can see there are 2 columns with 2 rows. Your example is an 1 dimension array.

Here I am not sure how the n-dimendions info can be specified in a readable way using variadic templates.

King regards
Andre

On Monday, 4 January 2021 at 18:21:59 UTC, Ali Çehreli wrote:
> On 1/4/21 4:51 AM, ddcovery wrote:
> ...
> I totally agree. Just to make sure you are aware that 'body' is optional for a while:
>
> int foo(int i)
> in (i > 42, format!"invalid: %s"(i))
> out (result; result > 100, "oops")
> {
>   // ...
> }
>
Yes, it is really compact: thanks for the tip Ali.

I have a "personal" conflict between the compact and extended version:
* The use of brackets ensures an equivalent indentation between precondition, post-condition and body (it is like writing an if/else):  I find it more readable.
* The compact version, after getting used to its syntax, allows a more compact code, but VSCode "code-d" is really intrusive when formatting and does "strange" things when in/out statements are too small:  it moves them to the same line!!!.
* Finally, with the "extended" version,  I use "body" instead "do":  in/out/body are not verbs... "do" is a verb.  it's a subtle difference, but it's very important to me.

Basically it is:

void zipTo(string srcPath, string zipPath)
in (srcPath.exists()) out(;zipPath.exists())  //<- VSCode moves "out" to the same line!!!
{
  scope (failure)
    "Problems generating 7z file".writeln();

  ...
}

vs

void zipTo(string srcFolder, string zipFile)
in
{
  assert(srcFolder.exists());
}
out
{
  assert(zipPath.exists());
}
body
{
  scope (failure)
    "Problems generating 7z file".writeln();

  ...
}


The good thing is that D offers enough syntax flexibility allowing you to use the one that best suits your needs/preferences.

This is a great feature that other "modern" languages are ignoring.
* May be it is because they prefer to use "unit" testing instead a "rich" contract mechanism (because the two ones conflict when used simultaneously):  contracts are the best "auto-document" mechanism although it may introduce some inefficiencies in the code when used "exhaustively" as a substitute for unit-testing (they are "run-time" contract checking, not "compile-time").  I find it is a good practice to use the two ones and decide witch checks are really "preconditions"/"postconditions" and witch checks are tests.

* Other question is how other languages could use precondition/postcondition with some new paradigms like "generators" or "corutines" where a function acts as an stream asynchronous consumer/producer:  D generators are really Ranges and precondition/postcondition/invariant fits nicely (I'll think about it when I really need it, I'm not experienced enought :-))

On Monday, 4 January 2021 at 18:21:59 UTC, Ali Çehreli wrote:
> On 1/4/21 4:51 AM, ddcovery wrote:
>
> > * The in/out/body (and scope) mechanism/syntax is awesome (I
> really love
> > it)
>
> I totally agree. Just to make sure you are aware that 'body' is optional for a while:
>
> int foo(int i)
> in (i > 42, format!"invalid: %s"(i))
> out (result; result > 100, "oops")
> {
>   // ...
> }
>
> > May be I will appreciate not opening brackets on new line
>
> I agree with you. I use "Egyption brackets" throughout my own code except when it helps with separation like in the code above. Otherwise, in/out and template constraints look too close to the body of the function.
>
> Ali

thanks again for the tip.

A question (May be this is something to the learn forum):

Is it possible to us in/out in a lambda expression?

On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:
> ...
> * Finally, with the "extended" version,  I use "body" instead "do":  in/out/body are not verbs... "do" is a verb.  it's a subtle difference, but it's very important to me.
> ...
Oh my God, I found https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md

It seems that "body" will be deprecated in favor of "do"... I find this decision specially bad but I suppose I will eat it with potatoes (spanish expression).

Imagine someone saying "Because we want to use 'catch' for catching errors with promises in JavaScript, we decide to deprecate 'catch' in the try/catch structure).   Internet Explorer was this incompatibility and everybody was to write ["catch"] for bypassing the IE problem... actually "catch" is used in promises and as language itself and there is no problems.

what "do" signifies?  "if precondition, then do... and check postcondition" it is a "sequential" way to express something that, in my opinion, must be declarative:  "this method has a precondition, a postcondition and a body"

As I say... I will adapt to the new term... but it is clearly how "imperative" developers doesn't accept "declarative" way of thinking... sometimes

In special this kind of affirmation:

"Furthermore, D's contract programming features are rarely used compared to how useful and desirable it is to be able to name a symbol "body"

Oh my God... one of the most powerful tools of D are belittled.

Seriously?... this is the kind of decisions that makes me doubt about D future.

On Monday, 11 January 2021 at 13:43:38 UTC, ddcovery wrote:
>
> Seriously?... this is the kind of decisions that makes me doubt about D future.

On the contrary :)
in/out/body is barely more useful than simply... assert()
hence it ended up not being used in a meaningful capacity, apart from curiosity

On 1/11/21 8:43 AM, ddcovery wrote:
> On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:
>> ...
>> * Finally, with the "extended" version,  I use "body" instead "do":  in/out/body are not verbs... "do" is a verb.  it's a subtle difference, but it's very important to me.
>> ...
> Oh my God, I found https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md
> 
> It seems that "body" will be deprecated in favor of "do"... I find this decision specially bad but I suppose I will eat it with potatoes (spanish expression).
> 
> Imagine someone saying "Because we want to use 'catch' for catching errors with promises in JavaScript, we decide to deprecate 'catch' in the try/catch structure).   Internet Explorer was this incompatibility and everybody was to write ["catch"] for bypassing the IE problem... actually "catch" is used in promises and as language itself and there is no problems.
> 
> what "do" signifies?  "if precondition, then do... and check postcondition" it is a "sequential" way to express something that, in my opinion, must be declarative:  "this method has a precondition, a postcondition and a body"
> 
> As I say... I will adapt to the new term... but it is clearly how "imperative" developers doesn't accept "declarative" way of thinking... sometimes
> 
> In special this kind of affirmation:
> 
> "Furthermore, D's contract programming features are rarely used compared to how useful and desirable it is to be able to name a symbol "body"
> 
> Oh my God... one of the most powerful tools of D are belittled.
> 
> Seriously?... this is the kind of decisions that makes me doubt about D future.

I highly doubt we will remove body in that syntax. The DIP proposed that, but that was under the expectation that we couldn't remove body as a keyword without also removing its support in that position.

Today, body is *not* a keyword, but can be used there. I don't think it will ever change. See the PR that was reverted because it affected a lot of code: https://github.com/dlang/dmd/pull/10763

And I have to say, this is quite the overreaction. "body" vs. "do" is not the thing that makes contracts function, let alone should cause you to doubt the future of D.

But this is kind of a side-thing, I'm glad you are loving the language, I share that emotion completely!

-Steve

On Monday, 11 January 2021 at 13:43:38 UTC, ddcovery wrote:
> It seems that "body" will be deprecated in favor of "do"

Both work equally well, have for a long time now, and I expect will continue to.

It used to be you couldn't name a variable `body` or whatever because of the keyword status. That's fixed. It doesn't affect other things.

Don't get too worked up about DIPs.