On 7/1/22 02:06, welkam wrote:
> On Tuesday, 28 June 2022 at 16:32:46 UTC, Timon Gehr wrote:
>>> Go language is the way it is for valid reasons. Don't dismiss them easily.
>>
>> Why not? I dislike Go for valid reasons.
> 
> I dont like Go as a language as well but I can still recognize that simplicity and uniformity is a valuable thing.

Go is neither simple nor uniform. The DIP is making D a bit simpler and more uniform.

> Now its crystal clear that I was unable to effectively communicate what I was thinking. The problem is that I dont know how else should I did it.
> 
> Google has a problem that they constantly are hiring new programmers and those programmers write code in their own way. Code bases written this way are not optimal. Go being the way it is makes its so that it easier to teach the language and its easier to onboard new programmer onto the project.

I don't buy it, and neither should you or anyone else.

https://programming.guide/go/go-gotcha.html
https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang

> I'm not going to list the negative trade offs of Go`s design decisions as I believe its obvious for people in this forum. On the other hand the benefits of Go or C designs seem to be valued at 0.
> 
> Discussions here revolved around question "do you want these benefits or not?" while it should have been "do you think the benefits are worth the tradeoffs?". Instead of talking about the best case scenario of one line functions in classes more time should have given to other possible uses and its effects on readability.
> 
> ```d
> auto bar() => iota(1, 100)
>                      .map!(x => x + 1)
>                      .filter!(x => x > 4)
>                      .foo();
> ```
> 
> ```d
> auto bar = iota(1, 100)
>                  .map!(x => x + 1)
>                  .filter!(x => x > 4)
>                  .foo();
> ```
> Code like this is going to be written and I didnt saw discussions about it or any other potential reduction in scanability of a code as a result of the proposed changes.
> ...

I guess that's mostly because everyone else who has been inclined to join the discussion understands that this is very readable code. Also, I don't think you even understand what this DIP is proposing. The second snippet is already valid D code with or without this DIP.

> Before starting to write in this thread I looked at how setters and getters are taught in C# as that language has implemented shorter syntax. 3 out of 3 videos did not feature this shorter syntax for one line functions. Any guesses as to why?

They did not bother to update the videos. The shorthand syntax is a bit less general, and chances are people will just pick it up from encountering it in the wild. It's very obvious what it means.

There is just not much to see here. There's much more productive things to argue about.

On Friday, 1 July 2022 at 01:10:28 UTC, Timon Gehr wrote:
> Go is neither simple nor uniform. The DIP is making D a bit simpler and more uniform.

I guess we are still talking past each other. When I was talking about uniformity I was not talking about language rules. I was talking about code that is in the wild and how it looks. When you look at Go code thats in the wild it all look sameish. Thats the uniformity I talk about and I say it has value. Simplicity also has value. Sharing links that criticize Go`s foreign function interface does nothing to refute my statements especially when the blog you linked even support my statements.
>After all, Go is an easy language to pick up

The code snippets I provided were intended to show visual similarities between function declaration and variable declaration with assignment. Currently lambdas appear in one context and function declarations in another. With this DIP function declarations with lambda pattern will start to appear in places where you can declare functions. In D`s case its practically everywhere. That means function declarations and variable declarations will be intermixed. Now look at this beautiful class.

https://github.com/dlang/dmd/blob/4513d32447ddb1221581dd555b04851db6ec8afd/src/dmd/dmodule.d#L320

Imagine you need to work on it at Friday. Afternoon. While having poor sleep the night before. And the coffee run out.
Try to count how many properties that class has. While counting in your mind try to insert function declarations in all possible places. See how things change.


C# 6.0 has been released in 2015. I dont believe new tutorials were just lazy to upate.

Me personally I dont need things that make easy thing easier. I need things that make difficult things easier.

On 7/1/22 17:43, welkam wrote:
> On Friday, 1 July 2022 at 01:10:28 UTC, Timon Gehr wrote:
>> Go is neither simple nor uniform. The DIP is making D a bit simpler and more uniform.
> 
> I guess we are still talking past each other.

My understanding is that you said burn the DIP with fire (a rather drastic measure) and you are failing to back that up in a coherent way.

> When I was talking about uniformity I was not talking about language rules. I was talking about code that is in the wild and how it looks. When you look at Go code thats in the wild it all look sameish.

There's always more than one way to do things. I lack the patience to go and seek out Go code to point out non-uniformities to you, so I won't try to refute this point, but it's a rather superficial one in any case.

> Thats the uniformity I talk about and I say it has value.

I understand your point, I just think it's very weak and fails to consider the whole picture.

> Simplicity also has value. Sharing links that criticize Go`s foreign function interface does nothing to refute my statements

Well, anyone who actually reads the article (and the previous one that is linked at the start) will easily see how it is in stark contrast to your statements while also criticizing Go's foreign function interface for a while, which in fact does actually relate to the overall point.

> especially when the blog you linked even support my statements.
>> After all, Go is an easy language to pick up
> ...

It's sarcasm. Maybe read the article (or don't, this was mostly meant for readers that are actually interested). It's insightful.

A bit more context to that quote:

> We've reached the fifth stage of grief: acceptance.

> Fine. It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google).

> But surely there's still a place for it.

> After all, Go is an easy language to pick up (because it's so small, right?), and a lot of folks have learned it by now, so it's easy to recruit Go developers, so we can get lots of them on the cheap and just uhhh prototype a few systems?

> And then later when things get hard (as they always do at scale) we'll either rewrite it to something else, or we'll bring in experts, we'll figure something out.

> Except there is no such thing as throwaway code.


It's quoting those things (like you are) because they are the Go marketing gospel, but (in contrast to you) it's very critical of them.

> The code snippets I provided were intended to show visual similarities between function declaration and variable declaration with assignment. 

Well, it's rather visually distinct to me. Anyway, I was under the impression that you like code that looks uniform to you.

> Currently lambdas appear in one context and function declarations in another. With this DIP function declarations with lambda pattern will start to appear in places where you can declare functions. In D`s case its practically everywhere. That means function declarations and variable declarations will be intermixed.

I am fine with that.

> Now look at this beautiful class.
> 
> https://github.com/dlang/dmd/blob/4513d32447ddb1221581dd555b04851db6ec8afd/src/dmd/dmodule.d#L320 
>

You can't really use the DMD code base to make points about idiomatic D code. It's rather old, and does not use many of D's features as it's basically directly translated from the original C++ implementation.

> 
> Imagine you need to work on it at Friday. Afternoon. While having poor sleep the night before. And the coffee run out.

Can't relate. I never drink coffee and I avoid working while too tired, because that leads to better overall productivity.

> Try to count how many properties that class has. While counting in your mind try to insert function declarations in all possible places. See how things change.
> 
> 
> C# 6.0 has been released in 2015. I dont believe new tutorials were just lazy to upate.
> ...

That's fine, neither do I. (And if you read my post you will notice I gave a more nuanced explanation for why it might be the case, though it's also pretty easy to stumble upon tutorials that do include it. Another point: Shorter videos tend to get more watchtime.)

> Me personally I dont need things that make easy thing easier. I need things that make difficult things easier.
Reading code is often quite difficult and the DIP will often make it slightly easier, at almost zero implementation cost. It's a good trade-off. Many things that make difficult things easier are quite a bit more costly.