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

Denis Kudriashov wrote:

...

2007/8/27, Alan Lovejoy <squeak-dev.sourcery@forum-mail.net mailto:squeak-dev.sourcery@forum-mail.net>:

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.