New project, "Code to Code"

[Christopher Browne]

On Wed, Dec 17, 2008 at 2:30 PM, Marc Lanctot <lanctot-yfeSBMgouQgsA/PxXw9srA at public.gmane.org> wrote:
> Lennart Sorensen wrote:
>
>> Except you won't be thinking the way the new language should be thought
>> about if you try to find a way to do things as you did in the other
>> language.
>>
>> After all trying to figure out how to do a for loop in another language
>> may be a bad idea if you fundamentally shouldn't be doing counted loops
>> in the other language at all.
>
> Honestly, how many languages differ in the semantics and expected usage of a
> for loop? It's not like someone trying to learn a completely different
> programming paradigm would cross between paradigms (eg. imperative to
> functional programming) .. that's just not what the tool is meant to
> accomplish.
>
> And, even if someone would do something like this, there should be user
> contributed notes attached to each translation.. following my example "Note:
> In LISP a better way to do a for loop is to do <<insert crazy recursive
> functional construct>>".

Actually, let me poke at this one a bit...

We frequently regard "for loops" as being ALL about iterating over a
set of numeric values, basically because of the ways that FORTRAN and
BASIC shaped our thinking.

Thus, people frequently get stuck on this way of thinking because of code like:

      DO 9 J= 1, 10
           DO 9 K= 1, 10
9     L= J + K

and

10  FOR I = 1 to 20
20  PRINT I
30  NEXT I

And if the *REAL* think that you're iterating across is some list of
things, you have to go off and write a correspondence between them.

Frequently, operating on a list would be *way* more natural.

(loop  for (product price) in '(("shoes" 62.50) ("boots" 75.00) ("hats" 35.00)
     do (format t "Product: ~A  Price: ~A~%" product price))

That's the pretty cool example of doing destructuring of a list in a
Lisp loop, drawing the internal elements of a nested list, which is
more than you tend to be able to conveniently do in most languages.
But the same is still commonly true.

In Perl, I wouldn't write:

   for ($i = 1; $i <= $#SOMEARRAY; $i++) {
     my ($element) = $SOMEARRAY[$i];
     # do something with each element in @SOMEARRAY
  }

I'd instead do:
   foreach $element (@SOMEARRAY) {
      # do something with each element
   }

Python has much the same:

 for element in SOMEARRAY:
     foo(element)

> Are you implying that a for loop is a bad habit in any language? :) A
> programmer's style comes from the programmer, not his/her reference tools.

I think that *numeric* for loops indeed are frequently a bad habit.

This is the difference between looking at a computer as a "number
processor" and a "symbol processor."  We often get sucked into
thinking the former, when the latter is a much more accurate way of
looking at things, and is sometimes more convenient, to boot.
-- 
http://linuxfinances.info/info/linuxdistributions.html
Bob Hope  - "I don't feel old. I don't feel anything till noon. That's
when it's time for my nap."
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists