scalar vs array and program control

[Thomas 'PointedEars' Lahn]

Laura Creighton wrote:

> […] "Thomas 'PointedEars' Lahn" writes:
>> Laura Creighton wrote:
>>> […] "Thomas 'PointedEars' Lahn" [writes]:
>>>> Laura Creighton wrote:
>>>>> […]  You really cannot make your code 'more functional' and 'more
>>>>> object-oriented' at the same time -- more in one style implies less
>>>>> in the other.
>>>> How did you get that idea?
>>> Because pure object oriented techniques are best when you have
>>> a fixed set of operations on things, and as your code evolves
>>> you primarily add new things.  Things written in a functional style
>>> work best when you have a fixed set of things, and your code evolves
>>> you add new operations for the existing things.
>> Your logic is flawed.  “*Pure* object oriented” is your raising the bar.
> 
> Yes.  But I could have said, and probably should have said 'pure
> functional style' as well.

That would not have changed anything.  It is the “pure” that makes your 
argument fallacious.  The “pure” falsely implies that you cannot have both 
at the same time, that you can have either function or object-oriented code. 
And ISTM that you are extending on the questionable idea that only “pure” is 
“good” to say that it would be inadvisable to have both at the same time.  
That is circular, for *that* property alone fallacious, logic.

>>First of all, object-oriented programming and functional programming are
>>programming *paradigms*, not merely techniques.  Second, they are _not_
>>mutually exclusive paradigms.  Third, Python supports both because in
>>Python, functions are first-class objects.  (In fact, if I am not
>>mistaken, everything except None is an object in Python.)
> 
> Ah, digression here.  I generalise  between paradigms that generate
> useful techniques, (functional programming and object oriented programming
> both do this) and those that do not (the Marxist paradigm of the
> labour theory of value).

You may not find them useful; several other people do.

> It still may be very useful and instructive to think on the Marxist Labour
> Theory of value, and it may have new utility if we can replace all labour 
> with computer/robotic/IT ... but for now, do not run your economy on this 
> theory, ok, because it does not work.)

Trollish nonsense.  Leave politics outside the door, it has nothing to do 
with this.
 
> Second digression:  that a thing uses objects does not make the thing
> more object oriented.

Yes, it does.  That is the very definition of *object*-*oriented*.
 
> But I suspect that it is only possible in things that are in
> the behavioural middle.

Now you are making up terminology.

> You needed a lambda to make the thing more functional,

I did not; it was merely a better visible shortcut, for a lambda expression 
is obviously a part of functional programming.  I could have defined a 
function instead and used the function identifier, and AISB I could also 
have used a reference to a method of an object.  The functional aspect of it 
was not the “lambda” but that I passed (a reference to) a function (a lambda 
expression is an inline function definition).

That is only possible if functions are first-class objects, meaning that 
they can be rvalues [sic] (“object” is not necessarily to be understood as 
the “object” in OOP, but for several programming languages, including 
Python, the other meaning applies as well; I used the term too loosely in my 
previous followup).

> and to create a class where none was before to make it more object-
> oriented. 

I did not need to, but, again, it was more obvious that way.  I could also 
have used an existing class, and its existing or newly added method.  AISB, 
almost everything in Python is an object; therefore, almost everything in 
Python has a class (try “print((42)).__class__)” in Py3k).  And Python is 
not the only object-oriented programming language for which this is true.  
Other object-oriented programming languages, for example ECMAScript 
implementations (which are my primary research topic), still have primitive 
values as well, but those are implicitly converted into object values when 
OOP patterns are used, and then those objects inherit properties as well.

> But this means that the thing wasn't all that> functional nor object-
> oriented -- most likely procedural -- to start with.

Obviously nonsense.  The procedural programming paradigm is neither the 
antithesis of the functional nor of the object-oriented programming one.

> So, very clever.  But still the general rule in refactoring, is that
> you want to go more oo or more functional, not both at the same time.

Nonsense.  You are projecting your misconceptions and ignorance (of Python, 
and programming paradigms in general) onto others.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.