New project, "Code to Code"
Madison Kelly
linux-5ZoueyuiTZhBDgjK7y7TUQ at public.gmane.org
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 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.
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. :)
Madi
--
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
More information about the Legacy
mailing list