Re: puts / print as method not keyword?

On Sun, 12 Dec 2004 15:17:48 +0900, Gavin Sinclair
<[e-mail]> wrote:
> On Sunday, December 12, 2004, 9:06:16 AM, zuzu wrote:
>  
> >> string.puts(STDOUT) creates a coupling, the string must call a method of the
> >> given object with itself as the argument. It must know that the object it's
> >> passed responds to #puts.
> 
> > i think to me this seems natural for the pure-OO "everything is an
> > object" nature of ruby (or  smalltalk).  strings know how to display
> > themselves, they just need to know where.  again, i think "naked
> > objects" is the latest way to talk about this, though i often think of
> > self language which was built on smalltalk.
> 
> I'm not normally given to this kind of negative exuberance, but ...
> 
>   ... that is just ABSURD!!!
> 
> Do you seriously think a string should know how to output itself to
> the console, a graphics canvas, a printer, a fax machine, a network
> connection, a sky-writing aeroplane, and every other bloody output
> device!!?!?!?

read my clarification.  it should know how to describe itself /
present itself to output objects, be they a console, a graphics
canvas, a printer, et. al.  this would be the difference between
postscript and the displaypostscript engine.

also, as i think ilmari mentioned, perhaps this is really an issue
more along the lines of .to_s, to be sent to some kind of display
object rather than #puts in the Kernel (which assumes STDOUT).

> In Ruby, everything is already an object.  The output devices
> included.  Let's leave the details of rendering output to them and
> them alone, shall we?

well, yes.  i'm not disputing this.  i'm balley-hoo for "everything is
an object".  but, i have a feeling (perhaps irrational) that
Kernel#puts is a kludge of the VM.  (actually, iirc it is just an
alias to something C++ like with STDOUT << "some string".)

my original point was to favor a postfix (concatenative combinator)
notation for directing outputs at the outset, rather than a prefix
notation of keywords that smells like imperative/procedural
programming.  #display offers a postfix notation for now.

> Claiming that #puts is polluting the OO nature of Ruby (perhaps noone
> has done this, but they compare it to legacy procedural languages) is
> sheer bloody madness.

i wouldn't say polluting...  the thing about OO is that it's
completely orthogonal to the imperative/procedural vs. functional
debate.  ruby very elegantly side-steps this issue with blocks (as
functions), and a list of procedures is a list -- written vertically
instead of horizontally.  (though once things start getting into
accessors and attributors, side-effects get prickly again, i think.)

but what i love about ruby is how most idioms seem to favor the
object-functional route, especially that closures are favored over
loops for iteration (though ruby does support loops such as 'while').

> What do I love about Ruby?
> 
>   def output_something(out=STDOUT)
>     ...
>     out.puts "something"
>     ...
>   end
> 
>   output_something(STDERR)
>   output_something(StringIO.new)
>   output_something(Socket.open)
>   output_something(File.open)
>   output_something(FaxMachine.discover)
>   output_something(SkyWriter.yeah_right)

ok, i'm all for choosing outputs.  but the issue i brought forward is
that the work in this kind of example i think is rare, or at least is
counter to how i want to think about most of my problems.  for me, the
data of "something" is almost never static.  i need to parse emails,
html, system logs, irc logs, on and on and on...  the "something" is
an infinite stream and never hard-coded by me.  where i output it to,
however, is a constraint, and not only finite but probably fewer than
i can count on my fingers.

however, again as ilmari has clarified, the issue of namespace arises.
 we cannot

  object.method.method.method.method

without making object some kind of uber-object which defeats the
purpose of namespace and thus objectification in the firstplace.  i
*think* this is where you feel flummoxed.  what i would like to see is
syntactic sugar for pipelining dataflow across multiple objects which
are compartmentalized rationally (and, eventually, separate processes
as well for sake of concurrency).

  fuel.method.method | oxygen.method | sparkplug.method.method

then the really cute part about lazy-evaluation is this can be shifted
across time...

  fuel.method.method | oxygen.method

(several hours pass)

  oxygen.method | sparkplug.method.method

which, again referencing backus as well as what most functional
programmers tend to have a hard-on about with regards to things like
referential transparency is that we can forget, as designers, about
time.  it doesn't matter *when* things get done, as long as they
eventually do; and we don't even have to specify the correct order for
how things get done, as long as all the pieces are there.  eventually,
this approaches declarative programming, but not in the oft thought of
logic programming sense.  it just means we tell the computer what to
do, not how to do it.  this leads towards code that looks alot more
like issuing command-lines (as end-users still often do in operating
systems).

> Having a pure OO language delivers us great practical benefit.  Let's
> keep it that way, and keep enjoying _practical_ benefits rather than,
> in the name of purity, turn all our objects into politicians who
> endlessly defer responsibility for actually doing anything.

endlessly defer....  well, according to message-passing architecture
(smalltalk, ruby, actors), i believe this means that messages are
passed in the reverse flow of the dataflow.  data flows downstream
while requests for data flow upstream.  data is processed lazily -- it
gets done when it's available; as opposed to eager-evaluation where
team B can only start once team A is completely finished.  frankly, i
much rather see web sites load as the html is parsing rather than
waiting what feels like endless seconds/minutes for the entire dom to
validate.

> Sorry for any harshness.  This kind of discussion just drives me round
> the bend.  And that's not fair, because it's the people with the crazy
> ideas that bring progress.  ("Whaddaya mean, you can add methods to
> existing classes, you nutjob?")

hehe, as long as we're all willing to leave ego behind (no ad hominem
attacks) i'm willing to argue the validity of the issues as much as
necessary (or as my time permits).  hopefully ruby itself won't have
its feelings hurt.

> Cheers,
> Gavin

peace,
-z