Cours the D programming language, tutoriel & guide de travaux pratiques en pdf.

Something Went Wrong

● It’s not for lack of trying
● It’s not because I’m a better programmer now than I was, prefering to write it better now
● I need to look deeper

A Troubling Look

● My abstractions are leaky
● and the dependencies leak out into the rest of the code
● The components are too specific
● they work for type T, but not for type U
● Need to reset back to first principles

What is a Component?

● more than just reusable software
● there are lots of libraries of reusable code, but these aren’t really components
● a component follows a predefined interface
● so components can be swapped, added, and composed, even though they are developed independently
● most libraries roll their own interfaces
● require scaffolding to connect to other libraries
What would a general component interface be?
● read input
● process that input
● write output
Even if a program doesn’t fit that model, it is usually composed of subsystems that do
In Pseudo-Code
source => algorithm => sink
or, composing:
source => algorithm1 => algorithm2 => sink
Where Have We Seen That Before?
The Unix “files and filters” command line model

Files and Filters
● Incredibly successful and powerful
● Found its way into C as the “file interface”
● files are both sources and sinks
● algorithms are the ‘filters’
● pipes connect them
● there are even pseudo-file systems to take advantage
http://linux.die.net/man/5/proc

Not Perfect

● Evolved, rather than was designed
● http://en.wikipedia.org/wiki/Ioctl
● Data is viewed only as a stream of bytes
● awkward for algorithms that need random access, for example
● But it shows what a component is and that components deliver

Looking Back At My Code

void main(string[] args)
{
string pattern = args[1];
while (!feof(stdin))
{
string line = getLine(stdin); if (match(pattern, line))
writeLine(stdout, line);
}
}
Doesn’t look like source => algorithm => sink, it looks like:
Arthur Rackham
Rather Than An Assembly Line
National Archives
I Prefer This
void main(string[] args)
{
string pattern = args[1];
stdin => byLines => match(pattern) => stdout;
}

The Next Design

● C++ OOP
● did not result in better component programming
● C++ iostreams
● started looking like source => algorithm => sink
– by overloading >> operator
● but never went beyond reading/writing files
● Many successful C++ libraries, but they were not components as discussed here And Then Came Alexander

Stepanov

● Revolutionized C++ with iterators and algorithms, the STL (Standard Template Library)
● more than just files
● algorithms
● common interface
● compiled to highly efficient code
Not Quite There
for (i = L.begin(); i != L.end(); ++i)
… do something with *i …
still looks like loops. Then came std::for_each(), std::transform(), but still won’t compose because iterators need to be in pairs.

Back To The Drawing Board

● sources
● streams, containers, generators
● algorithms
● filter, map, reduce, sort
● sinks
● streams, containers

Source Algorithm Sink

————————————–
file sort file
tree filter tree
array map array
socket reduce socket
list max list
iota search
random numbers odd
word count

Summing Up Requirements

● snap together, i.e. composability
● strong encapsulation support
● generate industrial quality efficient code
● natural syntax looking like: source=>algorithm=>sink
● work with types not known in advance
Requirements for an InputRange
● is there data available?
● bool empty;
● read the current input datum
● E front;
● advance to the next datum
● void popFront();