Discussion Thread: DIP 1043--Shortened Method Syntax--Final Review

[Timon Gehr]

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.