Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 26 October 2023 at 03:39:19 UTC, Walter Bright wrote: I've heard from an expert insider source that Scala macros destroyed the language. The worst stuff I've ever heard about Scala, apart from compile-speed anecdotes, is "Scala Collections: Why Not?" https://www.youtube.com/watch?v=uiJycy6dFSQ . It's really hard to imagine a macro problem more off-putting than this video. ```scala scala> List(1, 2, 3).toSet() res0: Boolean = false scala> List(1, 2, 3) contains "your mom" res2: Boolean = false ```
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/28/2023 1:54 PM, bachmeier wrote: I wonder if Walter has an opinion on this. In a .c file: It looks like the author is self-taught with little exposure to other programmers.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:
It's been a long, long while since I published anything on the
blog. I do intend to get pick it up again down the road, but
Walter recently surprised me with plans of his own. He's taken
the topic of his DConf '23 talk and derived a blog post from it:
https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/
I guess he got impatient with the pace at which I'm getting the
talk videos uploaded :-)
And for anyone who'd like to engage in any Reddit discussion
that comes up:
https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
I wonder if Walter has an opinion on this. In a .c file:
```
void *(STDVEC_DATAPTR)(SEXP x) {
if (ALTREP(x))
error("cannot get STDVEC_DATAPTR from ALTREP object");
if (! isVector(x) && TYPEOF(x) != WEAKREFSXP)
error("STDVEC_DATAPTR can only be applied to a vector, not a
'%s'",
type2char(TYPEOF(x)));
CHKZLN(x);
return STDVEC_DATAPTR(x);
}
```
`CHKZLN(x)` only does some checks. It doesn't have any side
effects. After scratching my head for a bit, I used grep to
locate this in a .h file:
```
#define STDVEC_DATAPTR(x) ((void *) (((SEXPREC_ALIGN *) (x)) + 1))
```
And of course, there were no comments to explain what is going
on. Very self-evident.
Re: From the D Blog: Crafting Self-Evident Code in D
On Saturday, 7 October 2023 at 12:37:37 UTC, sighoya wrote:
I disagree however in all binary types should be just boolean.
I prefer machineState=State.On or State.Off than
isMachineOn=true or false.
This was finished possible:
```d
import std;
enum State : bool
{
Off, On
}
void main()
{
State machineState;
"The machine ".write;
if(machineState == State.On) {
"may be ".write;
}
machineState = State.On;
if(machineState == State.On) {
"definitely ".write;
}
"runnning!".writeln;
// BONUS: TriState
int engineHP = -500;
"The engine ".write;
final switch(engineHP.sgn)
{
case TriState.Off: "was off!".writeln; break;
case TriState.Start: "was start!".writeln; break;
case TriState.On: "running!".writeln; break;
}
}
enum TriState
{
Off = -1, Start, On
}
```
SDB79
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/26/2023 2:30 AM, John Colvin wrote: Good talk. Many very clever people would achieve more if they tried to understand why a v. experienced developer would care to spend so much time talking about what might appear to be such basic points. The key challenge: If this stuff was so obvious & everyone did it or it didn't matter so much that they didn't, why would Walter care about it so much? Like user interfaces in an airplane cockpit, it all looks obvious. But, as I was told by the lead engineer for the 757 cockpit, every aspect of it was paid for with somebody's blood.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ Good talk. Many very clever people would achieve more if they tried to understand why a v. experienced developer would care to spend so much time talking about what might appear to be such basic points. The key challenge: If this stuff was so obvious & everyone did it or it didn't matter so much that they didn't, why would Walter care about it so much?
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 26 October 2023 at 03:15:00 UTC, Walter Bright wrote: On 10/4/2023 12:50 PM, claptrap wrote: Yes he can do what he likes, nobody has the right to demand anything from him. But his position and experience and knowledge is such that him doing a talk on coding guidelines is disappointing. Considering how few people follow the coding guidelines I presented, it's worthwhile. It isn't the usual guidelines I see, either. Fwiw, I thought it was a good talk, because this is the kind of thing many people ignore because they think it's "trivial". But what I have learned over 25 years of coding is that less is always more. The best code is code that can be understood. Don't try to be cleaver. It's almost always a bad idea.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/3/2023 8:10 AM, matheus wrote: I understand the advantages of the UFCS, I was just pointing out that the example given in that post are NOT equivalent, if it was deliberated or not I don't know, but I think it was just a small mistake, otherwise the author woundn't say they are equivalent. It was a mistake made by me.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/18/2023 11:51 AM, Max Samukha wrote: On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote: $0. true It's one reason why donations to the DLF go a long way. We try hard to squeeze the most out of every dollar.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/8/2023 6:21 AM, sighoya wrote: I have another thing to add. You argued about reasons not to use macros but these reasons don't apply to AST Macros, they won't allow constructing new languages like in Lisp or in Neat. Typed AST Macros would only accept parseable D source code with correct typing while untyped AST Macros would relax typing issues but syntax is still valid D. It's still inventing one's own undocumented, incomprehensible language. > Scala I've heard from an expert insider source that Scala macros destroyed the language. Macros are like selling your soul to the devil. At first it's a honeymoon, which may last for a decade or more, but eventually you discover you're in a trap you cannot escape. Seeing the life cycle of macros over and over is one advantage to me having been programming for well over 40 years.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/7/2023 5:37 AM, sighoya wrote: Thanks, I think we need more of this as D has become a large language already. There were some points I even never considered before. I'm glad it's a win for you! I disagree however in all binary types should be just boolean. I prefer machineState=State.On or State.Off than isMachineOn=true or false. Give it time. You'll come around! I've gone done many paths over the years on this stuff, to arrive at what I presented. I may evolve further in the future.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/5/2023 10:21 AM, angel wrote: I don't mind if it does not compile without the `ref`, but it should be on the table - WYSIWYG. It's a good point. Consider the refactoring angle. If I wished to switch from a struct to a class, and vice versa, and can just change the definition. If `ref` was needed everywhere, I'd have to refactor a lot of code. This is also why D uses `.` instead of `->`. Easier to refactor.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/5/2023 6:30 AM, claptrap wrote: While I agree with the overall gist I didn't find his examples very interesting or convincing. They were pretty much all made up to illustrate, outdated, or disingenuous (the first one with the intentionally obfuscated code). I know they look trivial, but I trivialized them to get them to fit on a slide. There are few more worthless slides than ones with 50 lines of code on them. Nobody can understand 50 lines of code in a minute, let alone hear the presenter talking about it. It would have been far better if he had actual real code examples he'd cleaned up. With many of them I included a link to a pull request that cleaned up a real example in DMD. (The real examples, of course, tend to be a bit more complicated.) I'm sorry you didn't find it worthwhile.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/4/2023 5:53 PM, claptrap wrote:
I have never once said he cant talk about whatever he wants to, I've explicitly
said the opposite. All I said is that by virtue of who he is has more
interesting things to talk about than whether "enum { yes, no }" is a good idea
or not.
When I stop seeing that kind of thing in the dlang code base ... :-)
Arguments about the things I talked about show up again and again in the n.g.
They are not commonly accepted.
Lastly, it seems obvious. But that's the point! It's very hard to write
self-evident code, and it looks trivial after the fact.
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/4/2023 12:50 PM, claptrap wrote: Yes he can do what he likes, nobody has the right to demand anything from him. But his position and experience and knowledge is such that him doing a talk on coding guidelines is disappointing. Considering how few people follow the coding guidelines I presented, it's worthwhile. It isn't the usual guidelines I see, either.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote: $0. true
Re: From the D Blog: Crafting Self-Evident Code in D
On Sunday, 8 October 2023 at 13:21:12 UTC, sighoya wrote: On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: [...] I have another thing to add. You argued about reasons not to use macros but these reasons don't apply to AST Macros, they won't allow constructing new languages like in Lisp or in Neat. Typed AST Macros would only accept parseable D source code with correct typing while untyped AST Macros would relax typing issues but syntax is still valid D. A good reference to compare are Scala Macros: https://docs.scala-lang.org/scala3/guides/macros/macros.html Also Swift Macros: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: [...] I have another thing to add. You argued about reasons not to use macros but these reasons don't apply to AST Macros, they won't allow constructing new languages like in Lisp or in Neat. Typed AST Macros would only accept parseable D source code with correct typing while untyped AST Macros would relax typing issues but syntax is still valid D.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ Thanks, I think we need more of this as D has become a large language already. There were some points I even never considered before. I disagree however in all binary types should be just boolean. I prefer machineState=State.On or State.Off than isMachineOn=true or false.
Re: From the D Blog: Crafting Self-Evident Code in D
I think if `class` is a reference type, it should've been
explicit:
```sh
class C {
...
}
auto obj = new C();
void func(ref C obj)
{
...
}
```
I don't mind if it does not compile without the `ref`, but it
should be on the table - WYSIWYG.
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 5 October 2023 at 08:46:50 UTC, Dom DiSc wrote:
On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote:
[...] he is has more interesting things to talk about than
whether "enum { yes, no }" is a good idea or not.
His point here was not that having an enum with values for yes
and no is a bad idea. The bad idea is assigning yes the value 0.
That's a much more subtle point, as here nowhere 0 is written.
His point was that both are bad, but one in worse.
And lets be honest, the problem is implicit casting of enums to
int, and then to bool. Or the conflation of enums and manifest
constants. If he wants to argue for self evident code then maybe
that kind of thing needs looking at. Even the UFCS chain example
is bad. Is...
a.b.c()
actually... "c(b(a))"
or is it member function b() on object 'a' that returns an object
with member function c().
It's not self evident is it? So yes UFCS makes the "pipeline"
easier to read, but it actually makes the code more ambiguous if
you dont know what each of the things is. So you need more
context to understand it.
That's what make this kind of mistakes so easy and I think it's
well worth to explain it to less experienced programmers.
If he was doing a talk to a bunch of inexperienced programmers
then yes that stuff might be interesting, but he wasnt. You need
to understand who your audience is, otherwise you risk wasting
your and everyone elses time.
It's not easy to make simple looking code. That has nothing to
do with (coding-)style, it is all about not defining things a
different way than it is usually done, so nobody mix it up.
Sometimes it's very hard to find the correct order of things -
often even experiments are necessary to determine what
"usually" means.
What he says is: Invest your time to find out what "usually"
means, and that is not trivial, even if it sounds like it is.
It requires a lot of experience to come to this conclusion.
Investing time to make things look easy and obvious is well
worth it, despite you're likely not payed (or in your case:
honored) for it.
While I agree with the overall gist I didn't find his examples
very interesting or convincing. They were pretty much all made up
to illustrate, outdated, or disingenuous (the first one with the
intentionally obfuscated code).
It would have been far better if he had actual real code examples
he'd cleaned up.
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote:
[...] he is has more interesting things to talk about than
whether "enum { yes, no }" is a good idea or not.
His point here was not that having an enum with values for yes
and no is a bad idea. The bad idea is assigning yes the value 0.
That's a much more subtle point, as here nowhere 0 is written.
That's what make this kind of mistakes so easy and I think it's
well worth to explain it to less experienced programmers.
It's not easy to make simple looking code. That has nothing to do
with (coding-)style, it is all about not defining things a
different way than it is usually done, so nobody mix it up.
Sometimes it's very hard to find the correct order of things -
often even experiments are necessary to determine what "usually"
means.
What he says is: Invest your time to find out what "usually"
means, and that is not trivial, even if it sounds like it is. It
requires a lot of experience to come to this conclusion.
Investing time to make things look easy and obvious is well worth
it, despite you're likely not payed (or in your case: honored)
for it.
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 21:03:14 UTC, bachmeier wrote:
On Wednesday, 4 October 2023 at 19:50:55 UTC, claptrap wrote:
On Wednesday, 4 October 2023 at 12:50:16 UTC, bachmeier wrote:
On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote:
I personally found this talk very disappointing. Walter is
the head honcho and he's giving talks on coding guidelines?
Its like visiting the F1 engineering workshop and getting a
talk on health and safety.
Tell us the engine, about what you're working on, some
gnarly problem you've solved, or something cool.
Walter's a contributor to this open source project like
anyone else. He's going to give talks on whatever strikes his
interest at the time. If he was a CEO with a 7-figure salary
like Mitchell Baker, things would be different.
Hes not like everyone else he's...
"Walter bright creator of the D Programming Language"
That means he's contributed a lot in the past, so he has more
freedom, not less, in choosing what to talk about.
I have never once said he cant talk about whatever he wants to,
I've explicitly said the opposite. All I said is that by virtue
of who he is has more interesting things to talk about than
whether "enum { yes, no }" is a good idea or not.
Your post is an example of a contribution tax. Those that do
the most work on a project are held to a higher standard than
everyone else, and they are the ones most open to criticism,
including public criticism. It's one reason productive
contributors leave open source projects, and why many people
turn down leadership positions.
Maybe we should hold people to lower standards the higher up they
get and see how that works out?
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 19:50:55 UTC, claptrap wrote: On Wednesday, 4 October 2023 at 12:50:16 UTC, bachmeier wrote: On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote: I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool. Walter's a contributor to this open source project like anyone else. He's going to give talks on whatever strikes his interest at the time. If he was a CEO with a 7-figure salary like Mitchell Baker, things would be different. Hes not like everyone else he's... "Walter bright creator of the D Programming Language" That means he's contributed a lot in the past, so he has more freedom, not less, in choosing what to talk about. Your post is an example of a contribution tax. Those that do the most work on a project are held to a higher standard than everyone else, and they are the ones most open to criticism, including public criticism. It's one reason productive contributors leave open source projects, and why many people turn down leadership positions.
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 12:50:16 UTC, bachmeier wrote: On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote: I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool. Walter's a contributor to this open source project like anyone else. He's going to give talks on whatever strikes his interest at the time. If he was a CEO with a 7-figure salary like Mitchell Baker, things would be different. Hes not like everyone else he's... "Walter bright creator of the D Programming Language" Yes he can do what he likes, nobody has the right to demand anything from him. But his position and experience and knowledge is such that him doing a talk on coding guidelines is disappointing.
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote: I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool. Walter's a contributor to this open source project like anyone else. He's going to give talks on whatever strikes his interest at the time. If he was a CEO with a 7-figure salary like Mitchell Baker, things would be different.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 13:39:33 UTC, user1234 wrote: A message specifically dedicated for you, Mike. According to me there is a problem in the blog. Author and publication date should be put on top of an entry (currently the information are only at the bottom). Yes, I agree. That's the way it was before I switched from our custom theme to one of the default ones. When I get around to revamping the blog, I'll put them back on top.
Re: From the D Blog: Crafting Self-Evident Code in D
On 04/10/2023 8:03 AM, Walter Bright wrote: On 10/3/2023 12:36 AM, Max Samukha wrote: 'No hire' for language designers who design sum types to be implicitly enumerated and convertible to integers and booleans? There's a reason my salary from the D Foundation is $0. As long as its the tag value implicitly converting, I would suggest that is fine and is how I'd do it. There is the special case of None being reserved for 0 that you have to be aware of (if it isn't in set, you are always > 0).
Re: From the D Blog: Crafting Self-Evident Code in D
On 10/3/2023 12:36 AM, Max Samukha wrote: 'No hire' for language designers who design sum types to be implicitly enumerated and convertible to integers and booleans? There's a reason my salary from the D Foundation is $0.
Re: From the D Blog: Crafting Self-Evident Code in D
HN front page, too! https://news.ycombinator.com/news
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 12:01:56 UTC, Martyn wrote: Agreed. Even though I do like UFCS, I find the above confusing to follow despite being more pleasing to the eye. I had to break it down and, as Matheus already pointed out, looked incorrect. I normally avoid writing code like a.b.c.d.e.f because it obscures the intermediate steps. I define variables that hold the results of one or a small number of steps so I can track what the code is doing.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 13:39:33 UTC, user1234 wrote: On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ A message specifically dedicated for you, Mike. According to me there is a problem in the blog. Author and publication date should be put on top of an entry (currently the information are only at the bottom). I agree, in fact I was about to say the same thing for awhile now but I always forget. =] Matheus.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 13:33:29 UTC, Dom DiSc wrote: On Tuesday, 3 October 2023 at 10:39:19 UTC, matheus wrote: I the first example "e" is receiving two arguments. While in the latter "d" is being receiving whatever "c" returns and "3". That's the point. In UFCS it is immediately obvious which function receives the 3, while with all the parenthesis it takes some time and concentration to find out, and getting it wrong is quiet easy. I understand the advantages of the UFCS, I was just pointing out that the example given in that post are NOT equivalent, if it was deliberated or not I don't know, but I think it was just a small mistake, otherwise the author woundn't say they are equivalent. Matheus.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ A message specifically dedicated for you, Mike. According to me there is a problem in the blog. Author and publication date should be put on top of an entry (currently the information are only at the bottom).
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 10:39:19 UTC, matheus wrote: I the first example "e" is receiving two arguments. While in the latter "d" is being receiving whatever "c" returns and "3". That's the point. In UFCS it is immediately obvious which function receives the 3, while with all the parenthesis it takes some time and concentration to find out, and getting it wrong is quiet easy.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 03:17:44 UTC, zjh wrote: Nice! [chinese version](https://fqbqrr.blog.csdn.net/article/details/133522267).
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 10:39:19 UTC, matheus wrote:
Nice article but I think that I found a bug:
g(f(e(d(c(b(a))),3)));
a.b.c.d(3).e.f.g;
"That’s the equivalent, but execution flows clearly
left-to-right. Is this an extreme example, or the norm?"
Well I don't think they're equivalent:
g(f(e(d(c(b(a))),3)));
I the first example "e" is receiving two arguments. While in
the latter "d" is being receiving whatever "c" returns and "3".
Matheus.
Agreed. Even though I do like UFCS, I find the above confusing to
follow despite being more pleasing to the eye. I had to break it
down and, as Matheus already pointed out, looked incorrect.
This appears to be the correct code.
```d
int a() { return 1; }
int b(int i) { return i+1; }
int c(int i) { return i+2; }
int d(int i) { return i+3; }
int e(int a, int b) { return a+b; }
int f(int i) { return i+4; }
int g(int i) { return i+5; }
void main()
{
import std.stdio : writeln;
auto r = g(f(e(d(c(b(a))),3)));
auto r2 = a.b.c.d.e(3).f.g;
writeln(r);// 19
writeln(r2); // 19
}
```
Re: From the D Blog: Crafting Self-Evident Code in D
On 03.10.23 09:36, Max Samukha via Digitalmars-d-announce wrote: 'No hire' for language designers who design sum types to be implicitly enumerated and convertible to integers and booleans? import std.typecons; void main() => assert(Yes.mate_hiringRedFlag);
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ Nice article but I think that I found a bug: g(f(e(d(c(b(a))),3))); a.b.c.d(3).e.f.g; "That’s the equivalent, but execution flows clearly left-to-right. Is this an extreme example, or the norm?" Well I don't think they're equivalent: g(f(e(d(c(b(a))),3))); I the first example "e" is receiving two arguments. While in the latter "d" is being receiving whatever "c" returns and "3". Matheus.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
'enum { Yes, No }; is just an automatic “no hire” decision'
'No hire' for language designers who design sum types to be
implicitly enumerated and convertible to integers and booleans?
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. Nice!
From the D Blog: Crafting Self-Evident Code in D
It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
