New project, "Code to Code"

Madison Kelly linux-5ZoueyuiTZhBDgjK7y7TUQ at
Wed Dec 17 20:53:46 UTC 2008

Christopher Browne wrote:
> On Wed, Dec 17, 2008 at 2:30 PM, Marc Lanctot <lanctot-yfeSBMgouQgsA/PxXw9srA at> 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.

This would make a wonderful seed article for Lisp to Perl and Lisp to 
Python! If you feel so inclined, could I ask you to add it? If you 
rather, and are willing, I could add it to the wiki on your behalf. The 
main reason I'd ask you is so that you were properly credited. :)

The Toronto Linux Users Group.      Meetings:
TLUG requests: Linux topics, No HTML, wrap text below 80 columns

More information about the Legacy mailing list