Why Strings as Classes?

[Robert Fraser]

Nick Sabalausky wrote:
> Taking a slight detour, let me ask you this... Which of the following 
> strategies do you consider to be better:
> 
> //-- A --
> value = 0;
> for(int i=1; i<=10; i++)
> {
>     value += i*2;
> }
> 
> //-- B --
> value = sum(map(1..10, {n * 2}));
> 
> Both strategies compute the sum of the first 10 multiples of 2.
> 
> Strategy A makes the low-level implementation details very clear, but IMO, 
> it comes at the expense of high-level clarity. This is because the code 
> intermixes the high-level "what I want to accomplish?" with the low-level 
> details.
> 
> Strategy B much more closely resembles the high-level desired result, and 
> thus makes the high-level intent more clear. But this comes at the cost of 
> hiding the low-level details behind a layer of abstraction.

Didn't read the rest of the discussion, but I disagree here... Most 
programmers learn iterative languages first, and anyone whose taken 
Computer Science 101 can figure out what's going on in A. B takes a 
second to think about. I'm not into the zen of FP for sure, and that 
probably makes me a worse programmer... but I bet you if you take a 
random candidate for a development position, she'll be more likely to 
figure out (and write) A than B. [That may be projection; I haven't 
seen/done any studies]

The big problem IMO is the number of primitive things you need to 
understand. In A, you need to understand variables, looping and 
arithmetic operations. In B, you need to understand and think about 
closures/scoping, lists, the "map" function, aggregate functions, 
function compositions, and arithmetic operations. What hit me when first 
looking at it "where the **** did n come from?"

I'm not saying the functional style isn't perfect for a lot of things, 
I'm just saying that this not one of them.