It's a nice idea, but the run-length example is kind-of-misguided, even though that's how everyone would implement it on first try.<p>A language should push you towards a more robust/faster/simpler solution by making it the simple, elegant thing to do. In K, a run length encoder would be something like:<p><pre><code> {(x@&~m),'(+/m)@&~m:~':x}
</code></pre>
Which looks like line noise, but basically encodes the following operations:<p>x is the input<p>m gets 1 where a position in x is the same as the previous position, 0 where it isn't. (apply ': "each-pair" to ~ "match")<p>Then take the sum of match (+/m) at where (@&) there is no match (~m).<p>Finally, add that to x where there is no match (x@&~m, literally, "x at where no m"), and zip it (,' meaning concat each). And the curly brances make it into a function of x.<p>Now, I understand most people would think that this is unreasonable. However, in K it is easier to produce a vectorized solution than an itertive one - and as an added bonus, the bugs tend to be either of the "wrong spec" or the "off by one" error, eliminating whole classes of potential bugs.<p>And .. the result is usually quick, thanks to vectorizing (and can go on a GPU easily).<p>A language that promotes item-at-a-time processing is missing a lot.