Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wc in D: 712 Characters Without a Single Branch

dlang.org

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Wc in D: 712 Characters Without a Single Branch

#81

Post by BoiledCabbage »

egdod wrote: post #60
coldtea wrote: post #51

Earlier quoted context omitted.

The aesthetic aspect is insignificant, it's about the semantics -- and thus reasoning about the code and other such properties. So nothing ridiculous about it. It's like Haskell code "of course has" anything C has, as underneath the both run assembly instructions full of gotos and state manipulation, you just "don't explicitly write it".

Branches aren’t hard to reason about though. The only* reason anyone cares about branches is that branch misprediction is expensive.

I think branches are actually harder to reason about, we're just used to doing it since all of us have done it for so long. However I do believe that branches are less straightforward than "linear" code and add to mental complexity on larger projects.

Of course there is no data to back this up, but I think one of the next trends in programming beyond the adoption of functional styles, immutable data, "functional core / imperative shell" will be abstracting away from explicit conditional/branching logic in higher level code.

Obviously people can come up with pedantic/extreme cases where the abstraction does nothing to hide the complexity, or even makes things more complex but im not taking about that. I mean more simple abstractions like what was used in OP, or a filter() abstracting over a while and if combo.

I'm convinced based on personal experience that it makes for cleaner code and will become more widely adopted over the years as people explore it.

Re: Wc in D: 712 Characters Without a Single Branch

#82

Post by monadic2 »

BoiledCabbage wrote: post #81
egdod wrote: post #60

Earlier quoted context omitted.

Branches aren’t hard to reason about though. The only* reason anyone cares about branches is that branch misprediction is expensive.

I think branches are actually harder to reason about, we're just used to doing it since all of us have done it for so long. However I do believe that branches are less straightforward than "linear" code and add to mental complexity on larger projects. Of course there is no data to back this up, but I think one of the next trends in programming beyond the adoption of functional styles, immutable data, "functional core…

Why do you consider a conditional (I have no clue why you call it a “branch”, a semantically meaningless term at the language level) hard to reason about?

Re: Wc in D: 712 Characters Without a Single Branch

#83

Post by forty »

greggyb wrote: post #14

Perhaps I'm just being pedantic or maybe I am misunderstanding. The author claims to be IO bound toward the end. But they are comparing to two versions that are faster. It is my understanding that IO-bound means that the IO subsystem is the thing which limits run time of the program. But the author clearly demonstrates that the IO subsystem of their machine is capable of supporting faster wc binaries. So what am I mi…

I think a good test for IO bound is: will it run faster if disk is faster? If yes, then it's IO bound, if not, it means the bottleneck is somewhere else.

Re: Wc in D: 712 Characters Without a Single Branch

#84

Post by egdod »

BoiledCabbage wrote: post #81
egdod wrote: post #60

Earlier quoted context omitted.

Branches aren’t hard to reason about though. The only* reason anyone cares about branches is that branch misprediction is expensive.

I think branches are actually harder to reason about, we're just used to doing it since all of us have done it for so long. However I do believe that branches are less straightforward than "linear" code and add to mental complexity on larger projects. Of course there is no data to back this up, but I think one of the next trends in programming beyond the adoption of functional styles, immutable data, "functional core…

How is it possible to reason about filter() without thinking it through as effectively a conditional? How is that easier than being explicit about it?

Re: Wc in D: 712 Characters Without a Single Branch

#85

Post by BoiledCabbage »

egdod wrote: post #84
BoiledCabbage wrote: post #81

Earlier quoted context omitted.

I think branches are actually harder to reason about, we're just used to doing it since all of us have done it for so long. However I do believe that branches are less straightforward than "linear" code and add to mental complexity on larger projects. Of course there is no data to back this up, but I think one of the next trends in programming beyond the adoption of functional styles, immutable data, "functional core…

How is it possible to reason about filter() without thinking it through as effectively a conditional? How is that easier than being explicit about it?

Why is separating pure functional code from imperative / side effect causing code easier to reason about? You still have to have the side-effect somewhere.

Why are immutable data structures easier to reason about? They still produce the same results.

None of the above are proven facts, but they are generally agreed upon principles that a number of people have observed. And I happen to believe them as well.

Overall my opinion of why it's easier is that like most optimizations it reduces the number of states/cases you have to think about in the "common path". With a solid abstraction you rarely need to think about the internals, with explicit code you need to check and think through all of the edge cases.

filter() (or map, or ...) is probably the best simple case I can think about. There is more room for bugs in an explicit (ex. for (int = 0; i Another example are parser combinators. There is nothing that parser combinators do that can't be done by hand. But one of the primary way they simplify coding is by hiding away conditional (and looping logic). "?*.." , | and & concepts. Parser combinators also benefit in simplifying things by building an algebra for users to work in with nice closed operations. But again that only became possible by abstracting away the conditional and looping logic and making these nice simple abstractions that can be easily combined.

So my summary is, my view is that abstracting over control flow code does a lot to simplify logic. A lot of logic involving looping has already been abstracted over and included in languages and libraries (in general "functional programming" styles). Now that the low hanging fruit has been incorporated I think next will be the next layer of non-looping conditional logic.

Re: Wc in D: 712 Characters Without a Single Branch

#86

Post by BoiledCabbage »

monadic2 wrote: post #82
BoiledCabbage wrote: post #81

Earlier quoted context omitted.

I think branches are actually harder to reason about, we're just used to doing it since all of us have done it for so long. However I do believe that branches are less straightforward than "linear" code and add to mental complexity on larger projects. Of course there is no data to back this up, but I think one of the next trends in programming beyond the adoption of functional styles, immutable data, "functional core…

Why do you consider a conditional (I have no clue why you call it a “branch”, a semantically meaningless term at the language level) hard to reason about?

Responded here: https://news.ycombinator.com/item?id=22186544

Re: Wc in D: 712 Characters Without a Single Branch

#87

Post by MaxBarraclough »

WalterBright wrote: post #39
VHRanger wrote: post #37

Earlier quoted context omitted.

How will that work with c compatibility?

That's a very good question! When connecting with C code, the C functions being called will need to conform to O/B principles as far as the interface to the function is concerned. It's the same issue as calling unsafe code - the compiler can't check it, the programmer has to. But if you use D as a BetterC compiler, then the D compiler can check the O/B rules in the code. Functions that are O/B checked are marked with…

What's O/B?

Google took me right back to your comment.

Re: Wc in D: 712 Characters Without a Single Branch

#88

Post by biotronic »

MaxBarraclough wrote: post #87
WalterBright wrote: post #39

Earlier quoted context omitted.

That's a very good question! When connecting with C code, the C functions being called will need to conform to O/B principles as far as the interface to the function is concerned. It's the same issue as calling unsafe code - the compiler can't check it, the programmer has to. But if you use D as a BetterC compiler, then the D compiler can check the O/B rules in the code. Functions that are O/B checked are marked with…

What's O/B ? Google took me right back to your comment.

Walter got a bit confused here - what he's describing is the owner/borrow system he's proposed to compete with Rust. This is unrelated to named parameters.

Re: Wc in D: 712 Characters Without a Single Branch

#89

Post by MaxBarraclough »

biotronic wrote: post #88
MaxBarraclough wrote: post #87

Earlier quoted context omitted.

What's O/B ? Google took me right back to your comment.

Walter got a bit confused here - what he's describing is the owner/borrow system he's proposed to compete with Rust. This is unrelated to named parameters.

Got it, thanks.
Post reply on HN