On 15.12.2010 17:37, Andrej Mitrovic wrote:
On 12/15/10, Stephan Soller<stephan.sol...@helionweb.de> wrote:
So, _if_ we can figure out a way to do some nice chaining of such calls
we can get:
[1, 2, 3, 4, 5].filter!((e){ return e> 3; })
.map!((e){ return e*e; });
Or if you don't like delegates and don't mind obvious compile time black
magic:
[1, 2, 3, 4, 5].filter!("a> 3").map!("a * a");
You might use pipe! as an alternative:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
auto result = pipe!( filter!("a>3"), map!("a * a") )(arr);
writeln(result);
}
But I can't seem to do the same with delegates:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
pipe!( filter!( (e){ return e> 3; } ),
map!( (e){ return e*e; } ) )(arr);
}
chain.d(9): Error: expression template filter(Range) is not a valid
template value argument
chain.d(9): Error: expression template map(Range) is not a valid template
value argument
Thanks for testing this out. :)
I noticed compose! and pipe! but these break my "thought flow". It's
hard to describe since I only experienced such a way of writing code in
Ruby. You can more or less write your thoughts down without much
translation or the need to go back and forth in the line. As you think
you can type… I don't need a "thought buffer" so to speak.
Having to think about if I want to call multiple collection operations
or just one right at the start breaks this flow. That the data at hand
is pushed to the end of the line (poor visibility) also don't really
help. I don't know if this is a matter preference but while deciding on
such collection operations I usually think about the data first. Only if
I know how the data is structured I start to apply operations on it.
This code
[1, 2, 3, 4, 5].filter!("a> 3").map!("a * a");
matches the that flow of thoughts. With pipe! I have to jump 2 times
within a buffer of 3 thoughts.
All that may sound very… unprofessional or "not like a real programmer".
However that kind of "mental friction" adds up and you notice that if
it's no longer there. I really agree with Matz (the creator of Ruby)
that the way you formulate your thoughts changes your thought patterns
in turn. Ruby is carefully crafted to keep the resulting thought
patterns close to the natural ones. To experienced programmers this
might be irritating at first since languages like C++, Java and even D
require some mental acrobatics to formulate what you want. It takes some
time to just think strait again if you're used to these acrobatics. Ruby
is a very interesting subject if you're interested in what programmers
think while programming.
Please note that this stuff is IMHO limited to application programming.
That is to solve hight level problems where low level work only adds
friction and is not that important (like with usual Websites). With
systems level programming this is different. When working with low-level
APIs and very machine specific problems the thought patterns are
different than the ones of application programming. The problems are
often not defined by real world needs and therefore the experience from
the real world can not help there.
This is the reason why I think D should not spend to much time with
this. It's not a design goal of D and probably would collide with other
design goals (e.g. efficient compiler implementation). If someone really
wants this kind of programming in D it's not that difficult to do, but
will cost efficiency (e.g. using real functions instead of templates). D
should not mimic Ruby nor is Ruby as bad as some might think. It's one
of the few languages that really accept that programmers are humans and
not machines. D does this too but by far not to the same extend (thats
why I still like D1 more than D2 actually).
Ruby has its applications and D has its applications. The right tool for
the right job only works if the different tools have a distinct purpose
and not try to do everything at the expense of being good at one thing.
Happy programming
Stephan Soller
