OT: Re: secret variables?

[Samuel A. Falvo II]

You know, when I first saw the subject heading for this message, I
_seriously_ thought it read:  [Io] secret vegetables?

Uugh.  It's only monday, and I already need to go back to bed.

--
Samuel A. Falvo II

[Steve Dekorte]

On 2009-07-13, at 2:03 PM, Samuel A. Falvo II wrote:
> You know, when I first saw the subject heading for this message, I
> _seriously_ thought it read:  [Io] secret vegetables?

Heh. The title got me thinking about hidden variables in physics and  
what their parallel would be in programming languages.

http://en.wikipedia.org/wiki/Hidden_variable_theories

[Erik Max Francis]

Steve Dekorte wrote:
> On 2009-07-13, at 2:03 PM, Samuel A. Falvo II wrote:
>  > You know, when I first saw the subject heading for this message, I
>  > _seriously_ thought it read: [Io] secret vegetables?
>
> Heh. The title got me thinking about hidden variables in physics and
> what their parallel would be in programming languages.
>
> http://en.wikipedia.org/wiki/Hidden_variable_theories 
> <http://en.wikipedia.org/wiki/Hidden_variable_theories>

Probably something like people who use programming languages with
programming paradigms (generic, object oriented, actor-based, etc.)
without actually changing the way they write programs.

--
Erik Max Francis && max@... && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   She's your moon, she's your sun / She could even be the one
    -- Nik Kershaw

[bblochl2-2]

> Probably something like people who use programming languages with
> programming paradigms (generic, object oriented, actor-based, etc.)
> without actually changing the way they write programs.
>
You dont need atrributes/variables/named memory/slots in generic, object oriented, actor-based, etc.? You are Superman!!

Reagrds BB

[William Tanksley, Jr]

bblochl2 wrote:
> You dont need atrributes/variables/named memory/slots in generic,
> object oriented, actor-based, etc.? You are Superman!!

Those things are part of object-oriented design. Massive IF and CASE
cascades, on the other hand, are an example of coding as though OO
wasn't there.

> Reagrds BB

-Wm

[bblochl2-2]

--- In iolanguage@..., William Tanksley <wtanksleyjr@...> wrote:
>
> bblochl2 wrote:
> > You dont need atrributes/variables/named memory/slots in generic,
> > object oriented, actor-based, etc.? You dont need IF/ELSE and CASE
> in OOP either? Wow! You are Super-Superman!!

Regards BB

[bblochl2-2]

--- In iolanguage@..., William Tanksley <wtanksleyjr@...> wrote:
>
> bblochl2 wrote:
> > You dont need atrributes/variables/named memory/slots in generic,
> > object oriented, actor-based, etc.? You dont need IF/ELSE and CASE
> in OOP either? Eventually you find iteration/repetition constructs old style? Wow! Phantastic! You are Super-Superman!!

Regards BB

[Samuel A. Falvo II]

On Tue, Jul 14, 2009 at 7:20 AM, bblochl2<bblochl2@...> wrote:
> You dont need atrributes/variables/named memory/slots in generic, object oriented, actor-based, etc.? You are Superman!!

I don't think you fully understood the gist of Erik's comment.  He's
talking about people who write functional-style programs in C,
imperative-style code in Haskell, and glorified Bash shell scripts in
Smalltalk.

What's scary is, yes, these people DO exist.

--
Samuel A. Falvo II

[Steve Dekorte]

On 2009-07-14, at 7:44 AM, William Tanksley wrote:
> Those things are part of object-oriented design. Massive IF and CASE
> cascades, on the other hand, are an example of coding as though OO
> wasn't there.


This reminds me of something I've been thinking of doing with the Io  
API...

I've noticed that the use of multiple arguments is, in all the  
examples I've run across, are a sign of bad OO design. I've been  
considering changing the Io standard protos to use no multi-argument  
methods. For example:

        map atPut(k, v)

would become:

        map slotAt(k) put(v)

Thoughts?

- Steve

[Jesse Ross-2]

> I've noticed that the use of multiple arguments is, in all the
> examples I've run across, are a sign of bad OO design. I've been
> considering changing the Io standard protos to use no multi-argument
> methods. For example:
>
> map atPut(k, v)
>
> would become:
>
> map slotAt(k) put(v)
>
> Thoughts?

I haven't been using Io much lately (so I don't know how much my  
opinion is worth), but this seems like a great idea to me. I've always  
liked Smalltalk/Objective-C style method signatures, as they tend to  
be much easier to read.

J.

[Samuel A. Falvo II]

On Tue, Jul 14, 2009 at 1:33 PM, Steve Dekorte<steve@...> wrote:

> I've noticed that the use of multiple arguments is, in all the
> examples I've run across, are a sign of bad OO design. I've been
> considering changing the Io standard protos to use no multi-argument
> methods. For example:
>
>        map atPut(k, v)
>
> would become:
>
>        map slotAt(k) put(v)
>
> Thoughts?

A little enlightenment from the Forth community might come in handy
here, if I may.

According to generally accepted practice in Forth, no Forth word
should deal with more than three stacked items at a time.  In other
words, any Forth word which accepts four or more arguments should
REALLY be refactored somehow.

The problem is, most people simply don't know how to refactor in
Forth.  Refactoring in Forth IS NOT like refactoring in C++ or Java,
simply because it's not OO, and thus, no concept of "local state"
exists.  Yet, despite this, highly readable programs can be written in
Forth which some might mistake for being OO.

With OO, the basic unit of decomposition is the _class_, which
encapsulates some concept you're trying to simulate (OO is a method of
simulation, after all).  With Forth, the basic unit of decomposition
is the _concept_, which encapsulates some _contextual_ state.  Now you
know why Forth deals with "vocabularies" and "words".  It's focus is
on programmer/computer conversation, not on arithmetic precision.

Case in point, in a GUI project I'm writing right now in Forth, I'm
dealing with objects that have positions and surface areas on the
screen.  How does one deal with these concepts?  You implement a
module (or "vocabulary" as Forth coders call them) that maintains the
relevant state:

VARIABLE 'x
VARIABLE 'y

: AT ( x y -- )
  'y !  'x ! ;

: WHERE ( -- x y )
  'x @ 'y @ ;

: SCOOT ( dX dY -- )
  'y +!  'x +! ;

VARIABLE 'width
VARIABLE 'height

: WIDE ( w -- )
  'width ! ;

: TALL ( h -- )
  'height ! ;

: BIGGER ( dW dH -- )
  'height +!  'width +! ;

and so forth.  Having done this, then, ANY concept in your program may
make use of this, without explicitly having to declare a dependency on
it.  Hence, any and all objects in your program may, at any time,
exist with or without a position or area.

Now you can write routines which relies on this global, contextual state.

: address ( -- addr ) ( computes the memory address for the first
pixel to draw )
  WHERE deviceWidth * + CELLS frameBuffer + ;

: HLINE ( -- ) ( draws a horizontal line on the frame buffer )
  address width BEGIN DUP WHILE OVER plot 1- SWAP CELL+ SWAP REPEAT 2DROP ;

Here's typically how you would use this:

16 32 AT 200 WIDE HLINE
0 5 SCOOT 15 0 BIGGER HLINE

This should draw a horizontal line at (16,32) that is 200 pixels wide,
and another one at (16,37) that is 15 pixels wider.

Notice that this looks a lot like Io's OO code or Smalltalk's keyword
arguments in reverse!  Io has a leg up on Forth, however, in that it
supports _local_ state (namely, the object you're invoking upon).  To
do the same in Forth, you have to constantly switch contexts, like
this:

1 PEN black COLOR  ( set pen 1's color to black )
2 PEN white COLOR  ( set pen 2's color to white )

1 PEN ( draws a black line  )
16 32 AT 200 WIDE HLINE

2 PEN ( draws a white line )
16 33 AT HLINE  ( notice no need to reset the width or height! )

So, where does Forth technique come into play?  Again, despite what
Martin Fowler dubbed the "fluent interface," take notice that no word
has more than 3 operands, and the Forth data stack depth remains
extremely shallow at all times.

I'd say that Io's methods should also rely on signatures with 3 or
fewer arguments.  I think having only one argument per method should
be a goal, but hardly enforced -- there are times when passing
multiple values makes sense (e.g., AT, BIGGER, etc).

I hope this bit of culture sharing doesn't give the wrong impression
(namely, that I'm pimping Forth); merely, I'm hoping that the
take-away from this exposition will give the reader something to think
about when designing future interfaces.

--
Samuel A. Falvo II

[William Tanksley, Jr]

Steve Dekorte wrote:

> This reminds me of something I've been thinking of doing with the Io  
> API...
> I've noticed that the use of multiple arguments is, in all the  
> examples I've run across, are a sign of bad OO design. I've been  
> considering changing the Io standard protos to use no multi-argument  
> methods. For example:
> map atPut(k, v)
> would become:
> map slotAt(k) put(v)
> Thoughts?

I'd love to see what happens with this; maybe a prototype to see what it
looks like? We shouldn't violate the Law of Demeter in doing it, of
course.

There's some dangers:

1. It'll require creating a TON of objects. This might be slow.
2. It'll require creating a ton of object interfaces, which will require
documentation.
3. It'll create a ton of possible interactions, which will require
testing.

I just had a little idea... Let me brainstorm.

Perhaps a different solution would be to reify Smalltalk's keyword
arguments, so that rather than forming a chain of objects, the method
returns a single object which is a clone of KeywordFunction.

So your example would look like this:

   map slot at(k) put(v) call

(There's probably a prettier way to do this than using an explicit
'call' at the end; but one way or the other we have to be able to
indicate that we're done specifying keywords and it's time to either do
something with the function OR produce an error.)

Another, possibly coexisting, possibility would be something like this:

   map slot(at(k) put(v))

Naturally, KeywordFunction should provide some methods that make it easy
to perform common cases of keyword function definitions:

1. Define a single function that takes only one keyword argument.
2. Define a single function that takes any number of KW arguments.
3. Define a series of KW functions.

It should also be possible to add a new KW function into a
KeywordFunction clone (for example, 'map slot' might have the at:put
form shown as an example above, but it would also have the at:get form).

> - Steve

-Wm

[Steve Dekorte]

On 2009-07-14, at 2:09 PM, Samuel A. Falvo II wrote:
> I'd say that Io's methods should also rely on signatures with 3 or
> fewer arguments.  I think having only one argument per method should
> be a goal, but hardly enforced -- there are times when passing
> multiple values makes sense (e.g., AT, BIGGER, etc).

To be clear, I wasn't suggesting non-multiple arguments would be  
forced, just that they would be considered the good programming  
practice.

Also, thanks for the Forth detail - I've been a fan of certain aspects  
of Forth and it was interesting to see a bit more about how it's used  
in practice.

- Steve

[Kevin Edwards-2]

On 7/14/2009 3:33 PM, Steve Dekorte wrote:
> map atPut(k, v)
> would become:
> map slotAt(k) put(v)

William raises a good question -- are you suggesting creating an
intermediate Slot object, or rather a new syntax for building a call
frame with keywords?

The former is more powerful but you would need dynamic optimizations
which would eliminate the creation of an explicit Slot object when
it is not necessary.

Kevin

[Steve Dekorte]

On 2009-07-14, at 3:43 PM, Kevin Edwards wrote:
> William raises a good question -- are you suggesting creating an
> intermediate Slot object, or rather a new syntax for building a call
> frame with keywords?

The former. It may seem like it's a lot of overhead (and that is why I  
originally avoided it) until you consider that every Io method  
activation creates a object for the frame. So in relative terms, it's  
not so bad :-)

I've long been bothered by the fact that method/function activations  
(in whatever language) are ultimately just objects created on the  
stack, whose instance variables are the method/function locals
+arguments. Why should this memory management distinction be given  
such a great syntax and (artificial) semantic distinction?

And for that matter, why do we distinguish methods and objects? I  
think there is a lot to be said for languages that make some attempt  
to unify these things (like Why's "Potion" language) but I don't like  
the semantic inconsistencies involved in activation (list referencing  
a List creates an instance but referencing an instance effectively  
calls it's at() method).

[Chris Double]

On Wed, Jul 15, 2009 at 8:33 AM, Steve Dekorte<steve@...> wrote:
>
> map slotAt(k) put(v)

This would make it quite difficult to create objects that subclass or
extend methods wouldn't it? Instead of cloning Map and implementing
atPut I'd need to clone map's slotAt to return a different slot
object, then override 'put' on that slot object.

I like the Self/Smalltalk style keyword arguments but these are
conceptually one method which doesn't have the 'where do I override'
problem.

Chris.
--
http://www.bluishcoder.co.nz

[simonhaines]

Before getting bogged down in implementation detail, can we just take a step back a moment? I'd like to question Steve's point:

> I've noticed that the use of multiple arguments is, in all the
> examples I've run across, are a sign of bad OO design. I've been
> considering changing the Io standard protos to use no multi-argument
> methods.

Does the mere presence of multiple arguments really determine a bad design?

To me, a bad design results from a semantic discrepancy between (the expression of) the model and the way one thinks about what is being modelled. For example, the problem I have with the expression 'map atPut(k, v)' is that it semantically expands to 'for this map, at key k, put value v'. This indeed combines two operations into one, where two operations more closely model the semantic expression. However, when modelling the general concept of a 'key-value store', I see nothing wrong with the expression 'map add(key, value)', or even 'map put(key, value)', because I see a map as a unified entity, not as a gateway to access a slot via its key and then use that slot to place a value.

So no, I don't see multiple arguments as a wart indicative of bad OO design, and believe that multiple arguments can improve clarity an conciseness in semantic expression.

Am I wrong? Thoughts?


--- In iolanguage@..., Kevin Edwards <edwakev@...> wrote:
>
> The former is more powerful but you would need dynamic optimizations
> which would eliminate the creation of an explicit Slot object when
> it is not necessary.
>

[Kevin Edwards-2]

On 7/14/2009 8:11 PM, simonhaines wrote:

> To me, a bad design results from a semantic discrepancy between
> (the expression of) the model and the way one thinks about what
> is being modelled. For example, the problem I have with the
> expression 'map atPut(k, v)' is that it semantically expands to
> 'for this map, at key k, put value v'. This indeed combines two
> operations into one, where two operations more closely model the
> semantic expression. However, when modelling the general concept
> of a 'key-value store', I see nothing wrong with the expression
> 'map add(key, value)', or even 'map put(key, value)', because I
> see a map as a unified entity, not as a gateway to access a slot
> via its key and then use that slot to place a value.
>
> So no, I don't see multiple arguments as a wart indicative of bad
> OO design, and believe that multiple arguments can improve
> clarity an conciseness in semantic expression.
>
> Am I wrong? Thoughts?

I think you are roughly correct as long as there is no reason to
explicitly model a slot.  But Io utilizes the concept of a slot and
selectively reifying slots could be useful, e.g. for localizing
constraints on get, set, update, delete, activate.

Reducing the arity of functions is not always good or necessary, but
it does increase encapsulation which tends to increase reuse, which
is why it's associated with good OO design.

Kevin

[simonhaines]

Thanks for your thoughts, I agree with this sentiment:

> Reducing the arity of functions is not always good or necessary, but
> it does increase encapsulation which tends to increase reuse, which
> is why it's associated with good OO design.

Yes reducing arity can lead to a more concise expression because it unfolds semantic concepts that have become a 'portmanteau'--thus 'atPut(k,v)' rightly becomes 'at(k) put(v)'.

> [snip] Io utilizes the concept of a slot and
> selectively reifying slots could be useful, e.g. for localizing
> constraints on get, set, update, delete, activate.

While this may be useful, I'm yet to be convinced (but this may be because I don't fully understand the concept of 'reification'). Does this not mean the caller now considers the receiver as 'an object with slots', instead of 'a key-value store'?

[Kevin Edwards-2]

On 7/15/2009 1:42 AM, simonhaines wrote:
>> [snip] Io utilizes the concept of a slot and selectively
>> reifying slots could be useful, e.g. for localizing constraints
>> on get, set, update, delete, activate.
>
> While this may be useful, I'm yet to be convinced (but this may
> be because I don't fully understand the concept of
> 'reification'). Does this not mean the caller now considers the
> receiver as 'an object with slots', instead of 'a key-value
> store'?

By "reification" I just meant creating an explicit slot object.  Io
makes use of the idea of a slot, but there is currently no way to
actually reference and manipulate them.  As a result, slot "methods"
can spill-over into other namespaces.

For example, an object is a simple 'key-value store', and the X and
setX idiom is a spill-over due to not being able to easily override
setSlot (i.e. ":=") per slot.  Thus, there's a semantic
inconsistency where we should use setX(0) if it exists, but
otherwise use X := 0 or X = 0 (i.e. updateSlot) if it doesn't.

I guess the other solution would be to implement generic functions.

Kevin