New project, "Code to Code"

Wed Dec 17 22:53:16 UTC 2008

On Wed, Dec 17, 2008 at 3:33 PM, Marc Lanctot <lanctot-yfeSBMgouQgsA/PxXw9srA at public.gmane.org> wrote:
> Christopher Browne wrote:
>
>>> 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...
>
> I knew I should not have mentioned LISP. My instinct told me not to and  I
> didn't listen. Bad Marc :)

Actually, I'll poke at that a *little* bit more.

I don't generally consider LISP to be "functional", *certainly* not
Common LISP.  If you look at the HyperSpec, which is more or less the
ANSI spec in a highly-hypertexted form, there are 26 chapters, and
NONE of them talk about "how functional it is."  Lisp was created as a
symbol processing language, and fairly much every interesting
programming paradigm has been attached to it at one point in time or
another.

Good Common LISP code is NOT "filled with crazy recursive functional
constructs" any more than good FORTH is filled with "crazy stack
gyrations" - you may have *little bits* of such, but, as you suggest,
that sort of code is indeed "crazy" and should be kept to small
portions.

Most CL code is fairly imperative.  The rich set of data types and
control structures have the effect that *hopefully* a fair bit of the
code can be much more free of side-effects than the "pointer
gyrations" that C/C++ often force you into, but it's only the sorts of
perverse people that, in the Perl world, would prefer to write their
code in Latin or Klingon, where you'd see "filled with crazy
constructs" of *any* sort.

Scheme (which dates back to the mid-'70s) takes much more the
"functional" tack, but I prefer not to go into that :-)

> I am snipping out your examples but they are good examples. I certainly
> agree that LISP (functional programming in general) allows you to think
> about what you're trying to do and express it in a better way than
> imperative programming typically does. As to whether that is a good or bad
> thing in general, IMO, it depends on your application. I've gotten into this
> argument before and I certainly don't want to again (and I'm not sure it's
> relevant anyway, see below). Suffice to say that I agree with you on the
> surface level about LISP allowing you to represent your intentions better.

I'd tend to call this "applicative" programming, and I suppose it's
*something* of a branch off of functional programming.

The place where it came from, originally, was the notion of
"higher-order functions", typically called "map", where the idea is to
apply some function to each element of a set.

It's a very "Scheme" way to do things to define a function, and then
use map (or mapcar!) to apply that function to each element of a list,
and that looks "sorta functional."

But this idea is sufficiently generally-useful that pretty much any
reasonably modern language supports it in a native fashion, and I
pointed out how to use it in
"not-generally-considered-to-be-functional" languages like Perl and
Python :-).

So while Lisp may be in there at the "genesis", it is decidedly NOT
about "crazy recursive functional constructs."

>>> 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.
>
> I don't see why what you call "numeric for loops" to be bad. In some cases
> you just have to do it. Why would we want to prevent anybody from being able
> to return a sum of a set of numbers? There are perfectly legitimate reasons
> to do this. If your argument is that the /language/ shouldn't allow you do
> do this by using for loops because it's better to think of it as a something
> different, then I think you're saying that you have something against the
> syntax/semantics of the language.

If you're trying to process "all the elements in this list," then
being forced to create a numbering scheme for that list in order to
process those elements certainly DOES seem like a bad thing to me.

Today, I was writing some "billing" code in SQL.

I was pretty happy with...

   insert into billing_results (customer, chargee, type, billing_plan, amount)
      select customer, chargee, type, billing_plan, amount from billing_pricing
        where billing_plan = i_billing_plan_name;

I would have been much less happy with:

   create result set = [query of billing prices where plan = "plan name"];
   count = get_count(result set);
   for i from 1 to count do
       insert into billing_results (....) values (result[i].customer,
result[i].chargee, ...);
   done

I don't care how many records there are; I don't care to do *anything*
about tracking numbers - that's bookkeeping and complexity that gets
forced on the programmer that I'd prefer NEVER to see.

Best line ever heard from a motivational speaker...

  "You're wondering when you could call back to talk to me about this
product you're trying to sell?  Actually,
    NEVER works for me.  Does NEVER work for you?"

There are plenty of cases where having a number counter tied to a loop
is completely useless because there is no reason why I want to know
the number.

Go process all the records - don't trouble me with how many there are.

There are cases where the counter is essential, but I believe them to
be exceptions rather than the rule.

But if you're writing code in FORTRAN (at least, the variations that
any of us would know about!), you have no such option.  A DO loop
requires tracking a counter and using that to identify what data
you're working with.

As Hugh mentioned, language sometimes shapes understanding.  If all
you know is FORTRAN, you may be unable to *imagine* writing code that
lacks counters.

I'm not saying loop counters must NEVER be used - just that there are
plenty of cases where they aren't needed, and that this is one of the
edges where computer languages differ in interesting ways.

Trying to force identicalness between diverse languages seems mighty
counterproductive to me.  It seems very likely to force "lowest common
denominator" usage that may be the *worst* of all worlds.

CORBA had a pretty good example of this; it tried to be language
agnostic, and mapping RPC interfacing between different languages with
mighty different kinds of data structures meant that it was a pretty
hostile thing to work with.  It maps *fairly* well to Java.  The
language mapping for C++ is fairly complex, but doesn't require
"jumping through hoops."  Writing CORBA interfacing for C is *quite*
strange because C isn't natively "object oriented," and the naming
conventions get mighty ugly.
-- 
http://linuxfinances.info/info/linuxdistributions.html
Jay London  - "I was going to buy a book on hair loss, but the pages
kept falling out."
--
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