Sean Perry said unto the world upon 2005-03-13 02:49:
Brian van den Broek wrote:


1) Namespace issues With procedural (or imperative -- don't know which is the right terms for non-OOP code which employs functions) code, you can have issues caused by namespaces. Just yesterday, someone on the main python list/newsgroup had code something like:


procedural v. OO imperative v. functional

In an imperative language you tell the computer what to do (imperative):
"put 5 in X, use X in function foo, store foo's result in blah". The base component is an imperative statement. If you have not had an English grammar class recently imperative sentences are things like "You, bring me my supper".


In a functional language, the base item is a function.

foo(X(blah())) or for the lispy people (foo (x (blah))).

You could do OO in a functional language. Haskell for instance has a concept of classes, user defined types, polymorphism, etc.

The point is, these are two axes on the programming language chart.

procedural, imperative -> C
OO, functional -> OCaml (close enough anyways)

Thanks for the explanation, Sean.

The reference to grammatical theory here does seem to make sense. But, relying on correspondence between the technical terms in programming/comp. sci. and other fields with similar terminology can get in the way, too.

I've a background in formal logic; it took me some effort to stop being upset that in Pythonic programming parlance get_a_random_element is a "function":

import random
def get_a_random_element(sequence):
    return random.choice(sequence)

(Never mind that you wouldn't really write this; I needed it to genuinely be a function for the example.)

Where I come from, the output of a function is determined by the input to the function.

Anyway, thanks again. Best to all,

Brian vdB

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to