Smalltalk › Squeak › Squeak - Dev

First post here ... few days on Squeak ... some questions ....

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

134 messages Options

1234567

Alan L. Lovejoy

Re: pipe

Denis Kudriashov wrote:
> Smalltalk is wonderfull language. We can implement any ideas without
> making changes in language (as Java or C# live).
> I think pipes is very usefull in DSL implementation and usage, simpler
> and fast object inspecting. But long message chaines in domain code
> are bad smell

There haven't been all that many syntax changes to Smalltalk since its
public release as ST80. Off the top of my head, I can list the following:

Assignment operator changed from back-arrow (underscore) to ":=".

Symbol syntax was enhanced so that any String literal can be interpreted
as a Symbol literal (by prepending # in front of the String literal.)

The $_ (underscore) character was added as a valid character in identifiers.

Syntax for scaled decimal literals was added.

Method syntax was changed so that the final statement in a method could
optionally be terminated by a "." (originally, the final statement could
not end with a ".")

I think there might have been some change to the syntax of non-decimal
integer literals, but can't recall the details.

I also seem to recall that there was originally no syntax for ByteArray
literals, and that it was added later. Could be wrong about that, though.

And many dialects have added other syntax, but those additions have not
been widely adopted as either de facto or de jure additions to Smalltalk
syntax.

Can anyone add to the list? Or can anyone provide an authoritative
confirmation or denial of the two items about which I was unsure?

Vassili Bykov-2

Re: pipe

In reply to this post by Ron Teitelbaum

Double semicolon also was my original choice for the change set I sent
yesterday, as the comment in Parser>>pipe attests. The concern that
made me change it to :> was the similarity of ; and ;;. It may sound
good from the logical point of view, in practice I'm afraid it can be
a source of bugs. Anyway, here is the full set that does ;; as well as
:>.

--Vassili

On 8/27/07, Ron Teitelbaum <[hidden email]> wrote:

> +1
>
> ; returns self
> ;; returns result is very clean, easy to remember and teach.
>
> Ron
>
> > -----Original Message-----
> > From: Bert Freudenberg
> >
> > On Aug 26, 2007, at 19:10 , David Mitchell wrote:
> >
> > > I like the :> and the double semi (and I also like Bert's asPipe).
> >
> > Hehe. Thanks. For those who did not look at my change-set: It did not
> > touch the Compiler at all or modify the syntax. It was strictly
> > Smalltalk (with #asPipe returning a proxy object).
> >
> > Personally I find ";;" quite fitting. To me, ":>" looks still
> > selector-like.
> >
> > I'd rather not use "_" as it would make a useful character to allow
> > for in selectors later (for simpler interaction with other languages).
> >
> > - Bert -
> >
> >
>
>
>
>

PipeWithDoubleSemi.1.cs (3K) Download Attachment

Jason Johnson-5

Re: pipe

In reply to this post by Igor Stasenko

On 8/27/07, Igor Stasenko <[hidden email]> wrote:
>
> I'm not pushing idea that cascade stands vs pipe. They both can be
> quite useful, i'm just pointing you out that current implementation of
> sequencing operators do not take in account that result is not used
> and must be dropped. And that stinks.

The issue is you can't always *know* if the result will be used or
not. When you generator byte codes for a method the variable storing
on the method goes *there*. Some callers of the method will use it,
some wont.

> Yes it is. I can't consider pushing value on stack just for being
> popped after method returns as useful operation.
> Its simply waste.

It's flexible. To do anything else is going to require some pretty
big changes/complexity to the current system.

> Not at all. for statements like:
> a someMessage.
> you don't need a result, its dropped.

How exactly is it dropped? #someMessage will have op codes to return
what ever it returns. It has to because it can't know what callers
expect.

> And this can be easily detected. If you look at parse tree, a
> statement which beginning from send node (not return node and not
> assignment node) can be considered as send without need a result,
> because its simply dropped at the end.

It's easily detected in the caller, but then it's too late. Unless
you want to somehow dynamically change called methods byte codes
depending on what the caller expects.

> Unmeasurably?
> Ok, simple example, a bytecode of Collection class>>with:with
>
> 13 <70> self
> 14 <CC> send: new
> 15 <88> dup
> 16 <10> pushTemp: 0
> 17 <E0> send: add:
> 18 <87> pop
> 19 <88> dup
> 20 <11> pushTemp: 1
> 21 <E0> send: add:
> 22 <87> pop
> 23 <D1> send: yourself
> 24 <7C> returnTop
>
> now compare it to (suppose we having sendNoRet bytecode):
>
> 13 <70> self
> 14 <CC> send: new
> 15 <88> dup
> 16 <10> pushTemp: 0
> 17 <E0> sendNoRet: add:
> 19 <88> dup
> 20 <11> pushTemp: 1
> 21 <E0> sendNoRet: add:
> 23 <D1> send: yourself
> 24 <7C> returnTop
>
> for each send in cascade you saving at least two operations: push
> result and corresponding pop. Also, you saving a bytecode size in
> method.
> Are you still thinking that this is 'unmeasureable'?
> Do you want me to write a 'measurer' tool which will parse all current
> methods in squeak and shows a percentage of sends which result is not
> used?

No, I'm not really interested to be honest. This is a small fish in a
big pond full of things that need to be fixed. For me much more may
be gained by switching away from a stack based VM altogether (though
I'm not far in my research on it yet :).

Alan L. Lovejoy

Re: pipe

In reply to this post by Vassili Bykov-2

Vassili Bykov wrote:
> ... The concern that
> made me change it to :> was the similarity of ; and ;;. It may sound
> good from the logical point of view, in practice I'm afraid it can be
> a source of bugs.

That's my concern also.

By the way, I just checked the ANSI syntax, and discovered that the $_
(underscore) character is also legal as the first character in an
identifier (Somehow, I had wrongly developed the notion that it could
not occur in the first position.) So I no longer favor "_|" as the
token for the pipe operator.

Jason Johnson-5

Re: pipe

In reply to this post by Fabio Filasieno

On 8/27/07, Fabio Filasieno <[hidden email]> wrote:
>
> cascade operator. You don't like it, but it still provides
> something that requires temporary variables to duplicate without it.
>
> ahaaaa ..... I didn't get temp thing right.

There we go. :) I need to work on my communication perhaps. :)

> Don't know yet if I like it that way ...
> But now I see the point; and why somebody might prefer it that way.
> I wouldn't be so sure now on cutting the ";" cascade out now.
> I would say - but just now - that there is no pipe vs cascade thing.
>
> Thanks for ringing the bell ....

Thanks for being open to discussing it. :) But I would really suggest
finding some project (something with a Seaside web site would be a
good one) of decent size and implementing it in Smalltalk. There is
really nothing quite like this language and many things look a bit
different, and if you're open to it, extremely elegant when translated
to "the Smalltalk way". I had many concerns about the language myself
when I first came here, but now I find I like the Smalltalk way the
best.

Ramon Leon-5

RE: pipe

In reply to this post by Vassili Bykov-2

> Double semicolon also was my original choice for the change
> set I sent yesterday, as the comment in Parser>>pipe attests.
> The concern that made me change it to :> was the similarity
> of ; and ;;. It may sound good from the logical point of
> view, in practice I'm afraid it can be a source of bugs.
> Anyway, here is the full set that does ;; as well as :>.
>
> --Vassili

BTW, that rocks! You wouldn't happen to know how to patch the refactoring
browser's parser as well would you?

Ramon Leon
http://onsmalltalk.com

Fabio Filasieno

Re: pipe

In reply to this post by Jason Johnson-5

On Aug 27, 2007, at 10:00 PM, Jason Johnson wrote:

On 8/27/07, Fabio Filasieno <[hidden email]> wrote:

cascade operator. You don't like it, but it still provides
something that requires temporary variables to duplicate without it.

ahaaaa ..... I didn't get temp thing right.

There we go. :) I need to work on my communication perhaps. :)

Maybe I'm a bit slow too ;-)

Don't know yet if I like it that way ...
But now I see the point; and why somebody might prefer it that way.
I wouldn't be so sure now on cutting the ";" cascade out now.
I would say - but just now - that there is no pipe vs cascade thing.

Thanks for ringing the bell ....

Thanks for being open to discussing it. :) But I would really suggest
finding some project (something with a Seaside web site would be a

I'm writing an interpreter for a scripting language that I have in mind and I

can't wait to finish it, and get some critics out of you !

good one) of decent size and implementing it in Smalltalk. There is
really nothing quite like this language and many things look a bit
different, and if you're open to it, extremely elegant when translated
to "the Smalltalk way". I had many concerns about the language myself
when I first came here, but now I find I like the Smalltalk way the
best.

Anyway thanks a lot for your patience an the "Re: pipe" thread.

Jason Johnson-5

Re: pipe

In reply to this post by Fabio Filasieno

On 8/27/07, Fabio Filasieno <[hidden email]> wrote:
>
> Long chains smells alright to me.

Give it time. Smalltalk has this amazing property that the code truly
seems to "talk" to you and point out things that just aren't quite
right. Some parts of the code seem to "stick out". You notice them
every time you browse through your code. And every time I have seen
this so far, I found a nice refactoring that made the whole system
less complex.

> Happy to see that it seems that your opinion has changed on point 1 from the
> beginning of the thread, and mine has changed on point 2.

Ah, but that's the thing: I never had anything against a "pipe"
operator. I did feel you overstated the need for it a bit, since as
others have mentioned, this doesn't tend to come up as much in
Smalltalk (though it does come up). I also don't like using a literal
pipe. But having an operator that disambiguates how to resolve
statements without so many parenthesis? Sure, I would entertain it.
I absolutely love it in Haskell.

Alan L. Lovejoy

Re: pipe

Jason Johnson wrote:
> ... But having an operator that disambiguates how to resolve
> statements without so many parenthesis? Sure, I would entertain it.
> I absolutely love it in Haskell.
>
How often would it be used in practice? Would most uses be valid, or
would most have to be considered as suboptimal code?

Would it attract a significant body of functional programmers to Smalltalk?

Those are the deciding questions.

Igor Stasenko

Re: pipe

In reply to this post by Jason Johnson-5

On 27/08/07, Jason Johnson <[hidden email]> wrote:

> On 8/27/07, Igor Stasenko <[hidden email]> wrote:
> >
> > I'm not pushing idea that cascade stands vs pipe. They both can be
> > quite useful, i'm just pointing you out that current implementation of
> > sequencing operators do not take in account that result is not used
> > and must be dropped. And that stinks.
>
> The issue is you can't always *know* if the result will be used or
> not. When you generator byte codes for a method the variable storing
> on the method goes *there*. Some callers of the method will use it,
> some wont.
>

This is not an issue with proper implementation.

> > Yes it is. I can't consider pushing value on stack just for being
> > popped after method returns as useful operation.
> > Its simply waste.
>
> It's flexible. To do anything else is going to require some pretty
> big changes/complexity to the current system.

A complexity of implementation is expedient if it serves to increase
performance and efficiency.

>
> > Not at all. for statements like:
> > a someMessage.
> > you don't need a result, its dropped.
>
> How exactly is it dropped? #someMessage will have op codes to return
> what ever it returns. It has to because it can't know what callers
> expect.
>
> > And this can be easily detected. If you look at parse tree, a
> > statement which beginning from send node (not return node and not
> > assignment node) can be considered as send without need a result,
> > because its simply dropped at the end.
>
> It's easily detected in the caller, but then it's too late. Unless
> you want to somehow dynamically change called methods byte codes
> depending on what the caller expects.
>
> > Unmeasurably?
> > Ok, simple example, a bytecode of Collection class>>with:with
> >
> > 13 <70> self
> > 14 <CC> send: new
> > 15 <88> dup
> > 16 <10> pushTemp: 0
> > 17 <E0> send: add:
> > 18 <87> pop
> > 19 <88> dup
> > 20 <11> pushTemp: 1
> > 21 <E0> send: add:
> > 22 <87> pop
> > 23 <D1> send: yourself
> > 24 <7C> returnTop
> >
> > now compare it to (suppose we having sendNoRet bytecode):
> >
> > 13 <70> self
> > 14 <CC> send: new
> > 15 <88> dup
> > 16 <10> pushTemp: 0
> > 17 <E0> sendNoRet: add:
> > 19 <88> dup
> > 20 <11> pushTemp: 1
> > 21 <E0> sendNoRet: add:
> > 23 <D1> send: yourself
> > 24 <7C> returnTop
> >
> > for each send in cascade you saving at least two operations: push
> > result and corresponding pop. Also, you saving a bytecode size in
> > method.
> > Are you still thinking that this is 'unmeasureable'?
> > Do you want me to write a 'measurer' tool which will parse all current
> > methods in squeak and shows a percentage of sends which result is not
> > used?
>
> No, I'm not really interested to be honest. This is a small fish in a
> big pond full of things that need to be fixed. For me much more may
> be gained by switching away from a stack based VM altogether (though
> I'm not far in my research on it yet :).
>

Yes, maybe you right, it's a small fish, you can say same for any
bytecode in bytecode implemented language. And from what you choose
and how you combine them depends an overall performance of your
language implementation.

--
Best regards,
Igor Stasenko AKA sig.

Jason Johnson-5

Re: pipe

In reply to this post by Jason Johnson-5

On 8/27/07, Alan Lovejoy <[hidden email]> wrote:
>
> How often would it be used in practice? Would most uses be valid, or
> would most have to be considered as suboptimal code?

That's the question. I have no idea. In all the code I have written
so far, the only place it would have come up would have been in the
LazyList implementation I did (probably at most 5 methods of it),
which was inherently functional. But in that case I'm not sure that I
still wouldn't go with the parenthesis.

> Would it attract a significant body of functional programmers to Smalltalk?

I don't know if that would be bad, though I don't know how much of a
worry/hope it would be. It's not only Smalltalk that seems to be
generating interest, but high level languages in general. The Lisp
list seems to be growing, Haskell is growing. Erlang is about to
explode, some think it will be the next Java (in popularity, not with
overly verbose syntax).

Ramon Leon-5

RE: pipe

In reply to this post by Bert Freudenberg

> Just for fun - the tiny attached change-set allows #asPipe to

> get piping behavior for cascades:
>
> Squeak asPipe
> ps: 'aux';
> grep: 'fabio';
> sort
>
> It makes these two expressions equivalent
>
> ((((4 + 2) * 3) + 3) * 2)
>
> 4 asPipe + 2; * 3; + 3; * 2
>
> Now I wouldn't use this in production but for interactive
> exploration it might actually be useful. Similar to
> implementing Symbol>>#value:
> to allow "(1 to: 10) collect: #squared".
>
> Btw, did you know each class can declare its own parser and
> compiler class? Experimenting with the syntax does not
> necessarily have to break other's stuff.
>
> - Bert -

Hey Bert, this is actually a pretty cool hack, being standard syntax, none
of the tools break (refactoring browser, pretty printer). This could be
useful in production with a bit of self optimization.

Just for fun, attached is your class with #doesNotUnderstand: passing the
message to a method that compiles keyword messages into delegation methods
on the fly to avoid the overhead of dnu and #perform for future calls.

Ramon Leon
http://onsmalltalk.com

Pipe.st (1K) Download Attachment

Bert Freudenberg

Re: pipe

In reply to this post by Igor Stasenko

On Aug 27, 2007, at 9:16 , Igor Stasenko wrote:

> I can't consider pushing value on stack just for being
> popped after method returns as useful operation.
> Its simply waste.

It's actually called "encapsulation". The sender must make no
assumptions on what the receiver will do with your message.

If any, it's an optimization problem. An inlining jit compiler could
easily optimize these operations. From a system or language pov it's
way simpler to always assume a return value.

- Bert -

Denis Kudriashov

Re: pipe

In reply to this post by Denis Kudriashov

2007/8/27, Alan Lovejoy <[hidden email]>:

Denis Kudriashov wrote:
> Smalltalk is wonderfull language. We can implement any ideas without
> making changes in language (as Java or C# live).
> I think pipes is very usefull in DSL implementation and usage, simpler
> and fast object inspecting. But long message chaines in domain code
> are bad smell

There haven't been all that many syntax changes to Smalltalk since its
public release as ST80. Off the top of my head, I can list the following:

These changes does not have an influence on language core, language semantics. Its just was some convenient constructions for building special objects. But when we put in Smalltalk new operator we change it semantics. Why we must do it?
Bert implemented it in clean Smalltalk without any language changes. Why it is not enough?

Best regards,
Denis

Fabio Filasieno

Re: pipe

On Aug 28, 2007, at 10:50 AM, Denis Kudriashov wrote:

2007/8/27, Alan Lovejoy <[hidden email]>:
Denis Kudriashov wrote:
> Smalltalk is wonderfull language. We can implement any ideas without
> making changes in language (as Java or C# live).
> I think pipes is very usefull in DSL implementation and usage, simpler
> and fast object inspecting. But long message chaines in domain code
> are bad smell

There haven't been all that many syntax changes to Smalltalk since its
public release as ST80. Off the top of my head, I can list the following:

These changes does not have an influence on language core, language semantics. Its just was some convenient constructions for building special objects. But when we put in Smalltalk new operator we change it semantics. Why we must do it?
Bert implemented it in clean Smalltalk without any language changes. Why it is not enough?

Best regards,
Denis

Well said.

My view is that adding the pipe you asserting that chained functional applications are good and should be used more. Is this what you want ?

The good tricks we have seen are not enough for me because I don't like the cascade to change it's meaning while reading.

on the pipe (which I look at as beautiful hack)

I't like making the question mark become an exclamation mark because there was a special keyword (asPipe).

"!" and "?" are both terminators and I don't like their meaning to be switched while reading.

Then I think that chained applications of functions is good way to reuse methods.

Fabio Filasieno

Re: pipe and system building

In reply to this post by Jason Johnson-5

On Aug 27, 2007, at 10:07 PM, Jason Johnson wrote:

On 8/27/07, Fabio Filasieno <[hidden email]> wrote:

Long chains smells alright to me.

Give it time. Smalltalk has this amazing property that the code truly

seems to "talk" to you and point out things that just aren't quite

right. Some parts of the code seem to "stick out". You notice them

every time you browse through your code. And every time I have seen

this so far, I found a nice refactoring that made the whole system

less complex.

You are missing something... the pipe is very good for prototyping. You are not taking into account how easy is to bind existing functionality.

Just stick together things with glue (pipe) at the beginning. This way you are writing the spec !!!!!!

My experience tells me that this way of working produces results.

The code is done quick - and very readable ! - with lots of chains. Tests are written. Then some cleaning.

It's like doing sketches.

The way you do without the pipe is that you need to guess the right re-factoring without a "code as spec"

in front of you. This is difficult. There is a high risk of developing functions that you don't need. This is on of the main critics OOP.

When I was a bit younger I often made this mistake:

Lets a make a nice apple object. The nice apple must have the `eat` method of course. An apple that cannot be eaten is rally a terrible apple, is it? So let's invest some time in our apple `eat` method. But here is the mistake ...

you are writing code to make pies. You will never eat the apple directly. You have just spent brain and time budget on something useless: the `eat` method on the apple object. I bet this is the main reason for code bloat in OOP and Smalltalk too.

Maybe you can do it. But for me it works better to chain stuff to get the spec out and then clean if required.

The problem of writing complex systems like software is not building them, it's understanding what really needs to be done !!!!

Spec hunting is the problem ! No building the system !

For example.

if I have :

data select: ... | map: ... | collect: ...

I've written quickly a spec. And a very good one as it's WRITTEN down and it's TESTABLE.

Only then I might add

data searchForThis

But How do you know in advance you need that.

With functional programming you:

1) patch the functionally...

data select: ... | map: ... | collect: ...

2) test

... some unit tests

And there you go a system that works.

Now you can't tell me that :

data select: ... | map: ... | collect: ...

this NOT understandable.... it's only a bit verbose... but since it's functional it's CLEAR

3) Now that you know you TRULY need ...

data select: ... | map: ... | collect: ...

you add

data searchForThis

And you've got also tests ready to go !!!!!!

Give it time. Smalltalk has this amazing property that the code truly
seems to "talk" to you

Give it time. Functional programming has this amazing property that you can easily reason about problems, especially when side-effect free.

I want that in Smalltalk.

I can't do it with parenthesis. It disturbs me. I have to break my thoughts.

I need the pipe.

And I'm sure that any functional programmer (from ocaml, erlang , haskell, ... ) would understand what I'm talking about.

It's just that I see this great opportunity for smalltalk that with a little fix people like me would appreciate Smalltalk more.

The messaging system allows me to blend perfectly the mixed bottom-up top-dow approach that I use in system building, but to do the bottom-down properly... I need the pipe.

Fabio Filasieno

Re: pipe and system building

....

(sorry, obvious errors on the previous ....)

It's just that I see this great opportunity for smalltalk that with a little fix people like me would appreciate Smalltalk more.

The messaging system allows me to blend perfectly the mixed bottom-up top-down approach that I use in system building, but to do the bottom-up properly... I need the pipe.

Fabio Filasieno

.\ Software Developer

Alan L. Lovejoy

Re: pipe

In reply to this post by Denis Kudriashov

Denis Kudriashov wrote:

>
> 2007/8/27, Alan Lovejoy <[hidden email]
> <mailto:[hidden email]>>:
>
> There haven't been all that many syntax changes to Smalltalk since its
> public release as ST80. Off the top of my head, I can list the
> following:
>
>
> These changes does not have an influence on language core, language
> semantics. Its just was some convenient constructions for building
> special objects. But when we put in Smalltalk new operator we change
> it semantics. Why we must do it?
> Bert implemented it in clean Smalltalk without any language changes.
> Why it is not enough?
>

There are two issues:

1) Are the proposed "pipes" a good idea at all? Is it good programming
style--or an abusive practice?

2) If pipes are good style, is it better to implement them syntactically
(which is rarely done in Smalltalk,) or using Smalltalk's usual
implementation strategy: sending messages to objects?

There are two arguments in favor of the syntax-based implementation
(which presumes that the answer to point 1 above is that "pipes are good
style"):

1) Performance: The syntax-based implementation would be significantly
faster.

2) Code clarity: The syntax-based implementation could be made visually
much clearer, with much less probability of being wrongly interpreted by
the reader. A reader of the code would be much more likely to miss an
#asPipe message at the beginning of a sequence of message cascades, than
he would be to miss a new, well-chosen pipe operator (e.g, ":>"). The
semantics of a message cascade and a sequence of piped messages is
rather different.

Personally, I'm undecided as to whether pipes are good style, but favor
a syntax-based implementation, if pipes are to be implemented and used
at all (for the reasons above.)

--Alan

Fabio Filasieno

Re: pipe and the social context

In reply to this post by Denis Kudriashov

On Aug 28, 2007, at 1:38 PM, Alan Lovejoy wrote:

Denis Kudriashov wrote:

2007/8/27, Alan Lovejoy <[hidden email] <[hidden email]>>:

There haven't been all that many syntax changes to Smalltalk since its
public release as ST80. Off the top of my head, I can list the
following:

These changes does not have an influence on language core, language semantics. Its just was some convenient constructions for building special objects. But when we put in Smalltalk new operator we change it semantics. Why we must do it?
Bert implemented it in clean Smalltalk without any language changes. Why it is not enough?

There are two issues:

1) Are the proposed "pipes" a good idea at all? Is it good programming style--or an abusive practice?

I remember a sentence of Alan Kay related to education stating that education is about learning powerful ideas and it was said in the context of describing what a metacircular interpreter is. Understanding this powerful ideas is difficult and requires experience.

In my opinion, the homoiconic system written is itself is the powerful idea in Smalltalk. But before trying what it means to work in an homoiconic system, my judgement was "who cares". But then my opinion changed, as soon as I tried squeak.

Same for the pipe. The pipe is one of those powerful ideas. And you will need experience in using it. Look at what the pipe did for Unix. The pipe IS the powerful idea in UNIX around which a whole culture of sharing was built. I'm not talking only of quality software artifacts, but an entire culture of people sharing small pieces of art. Showing how a piece of code written for specific context can be used in another one. This is the job of the artist, to show that there is always a new context.

- one guy would write `ls`

- another guy would write `grep`

- another guy would write `tar`

- another guy would write `gzip`

... etc ...

And everyone has a scriptable archiving system for free, absolutely for free.

Things like:

select:thenCollect:

It very very ugly bloat. It should removed instantly. To a unix user and to functional programmer this is something to be ashamed of. This is REALLY bad as it also appears in general purpose collection libraries !!!

How much other bloat is in Smalltalk ?

I wonder if the absence of the pipe is the cause of all this bloat in OOP ? (paul graham seems to argue that the next 100 year language is not OOP - why ? ... bloat )

The pipe is a lesson of the 70' .

It has produced in 30/40 years the Unix programming environment that not all but many people love.

It has produced a culture of sharing as: one guy writes methodA in an object, another guy writes methodB in another object, and everybody have for free their combination.

If some one prefer some hard numbers in arguments then:

you can calculate the number of combinations of methods that have compatible return value/receiver and consider chains of size from 2 to n ... As soon as you add the pipe you get that amount of functionality for FREE ! for FREE ! no one needs to write them ! it's already there by magic. Just PIPE them !

If we do an economic analysis of adding the new pipe `law`, the result is that the more people write code the more EXTRA functionality everybody would get for FREE, as the number combinations of return value/receiver of methods should grow when code is written. This in theory should push developers to write more code, because the net utility is greater than the work spent writing shared code. This in theory should grow the Smalltalk user base.

This is a naive proof that PIPE = an exponentially more powerful system. Not just a better syntax.

If the pipe is accepted then ...

The next step would be to find (in general purpose libraries) and dump all the methods the can be classified as bloat.

And the first to go is stuff like

select:thenCollect:

It hard to believe that in 2007 there are questions if the pipe is good or not; after 40 years of Unix culture made history all around that concept.

Object's are so easy to write that they can become complex very easily. The future Smalltalk need a way to question the developer.

"Are you sure you need that extra method ? or it's just bloat ?"

This will make the developer THINK. Not just abuse of his freedom to add methods at will.

Encapsulation and the virtual address space of the class gives power, and with power comes responsibility. Let's make OOP programmers more responsible.

Today, to my eyes, many Object Oriented developers are not responsible. They add methods without really needing them:

they do that to satisfy a false sense of beauty in writing a materialization of what the software object SHOULD be instead of writing methods that they really need, since there is no other way to get that functionality out of previous code.

I've tried to argue why is a mistake to not have the pipe with:

- example's

- reference to history

- mini economic analysis

and have exposed why Smalltalk 2008 will have the pipe.

Fabio Filasieno

PS. In my humble opinion of course.

David Mitchell-10

Re: pipe and system building

In reply to this post by Fabio Filasieno

I'm curious,

would Bert's asPipe work for you.

It basically lets you treat cascades as pipes.

Or does it need a syntax change?

On 8/28/07, Fabio Filasieno <[hidden email]> wrote:

>
> ....
>
> (sorry, obvious errors on the previous ....)
>
> It's just that I see this great opportunity for smalltalk that with a little
> fix people like me would appreciate Smalltalk more.
> The messaging system allows me to blend perfectly the mixed bottom-up
> top-down approach that I use in system building, but to do the bottom-up
> properly... I need the pipe.
>
>
>
> Fabio Filasieno
> .\ Software Developer
>
>
>
>
>
>
>
>

1234567