Why Ruby?

[Stephan Soller]

On 15.12.2010 17:37, Andrej Mitrovic wrote:
> On 12/15/10, Stephan Soller<stephan.soller at 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