DConf 2014 Keynote: High Performance Code Using D by Walter Bright

[Don via Digitalmars-d-announce]

On Wednesday, 16 July 2014 at 10:22:41 UTC, bearophile wrote:
> Andrei Alexandrescu:
>> http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
>
> Despite Walter is used to "pipeline programming", so the next 
> step is to also handle failures and off-band messages in a 
> functional way (without exceptions and global error values) 
> with two "parallel pipelines", here named "Railway-Oriented 
> Programming". This is one of the simplest introductions (and he 
> can skip the slides 19-53) that I have found of this topic 
> (that in the Haskell community is explained on the base of 
> monads):
>
> http://www.slideshare.net/ScottWlaschin/railway-oriented-programming
>
> In Bugzilla there are already requests for some 
> Railway-Oriented Programming:
>
> https://issues.dlang.org/show_bug.cgi?id=6840
> https://issues.dlang.org/show_bug.cgi?id=6843
>
> I think no language extensions are needed for such kind of 
> programming, but of course built-in tuple syntax and basic 
> forms of pattern matching in switch 
> (https://d.puremagic.com/issues/show_bug.cgi?id=596 ) improve 
> the syntax and make the code more handy, handy enough to push 
> more D programmers in using it.
>
> For some examples of those things in a system language, this 
> page shows some little examples of functional syntax for Rust:
> http://science.raphael.poss.name/rust-for-functional-programmers.html
>
> Bye,
> bearophile

I think that approach is more convincing for functional languages 
than for D, especially if you are limited to a single return type.

Why not just follow the use Unix stdout/stderr model, and provide 
an OutputRange for errors to be sent to?

I don't really believe that there are two 'railway tracks' in the 
sense that that presentation implies. Once an error has occurred, 
typically not much more pipeline processing happens. As for Unix, 
stdout from one step is tied to stdin, but stderr is output only. 
There may be further processing of the stderr stream (eg, errors 
may be reported to a database), but the steps are completely 
independent from the main stdin-stdout track. I think you get a 
messy design if you try to combine both into a single pipeline.

I think it could be quite interesting to see which algorithms can 
be created with an Error OutputRange model.