Smalltalk › Squeak › Squeak - Dev

Pipe syntax and the current methods

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

David Mitchell-10

Re: Pipe syntax and the current methods

For this Smalltalker, I don't start with a functional approach, I
start with an object-oriented approach. Compared to functional, I have
lots of state (class names and instance variables).

To the extent that I program functionally, it is usually inside of a
method (eliminating temps). When I show this style to Java programmers
(or use this style on a Java project), it is not well received. So I
assign to temps and stay away from parens and chains (or pipes). I
believe Joe Winchester calls this debugger friendly coding.

asPipe appeals to me because it doesn't change the syntax of the
language. This Smalltalker takes pride in having a tiny core language
that has remained mostly unchanged. I doubt I would be confused about
asPipe cascades because I would see the receiver is the pipe object.
This also makes it easier to port (as long as your dialect doesn't
already have an asPipe implementation).

I would like to use asPipe in my own code (just did the equivalent of
an asPipe reject:;reject:;select: with parenthesis). If the syntax
changed version were adopted for Squeak, I might use it if I wasn't
concerned about ports to other Smalltalks.

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

>
>
> On Aug 28, 2007, at 12:30 AM, Bert Freudenberg wrote:
>
>
>
>
>
> With the generic pipe object from my change-set in the original thread this
> gets you both - no need to define new methods:
>
>
>
>
> highestNumberedChangeSet
>
> "ChangeSorter highestNumberedChangeSet"
>
> ^self allChangeSetNames asPipe
>
> select:[:aString | aString startsWithDigit];
>
> collect:[:aString | aString initialIntegerOrNil];
>
> ifNotEmpty:[:list | list max]
>
>
> I have to admit that the asPipe idea is really cool and it might do the
> trick.
>
> A minor minor thing: you still need to explain it, and it's better to have 1
> syntax token attached to 1 meaning.
> Is a bit ugly that cascade changes it's meaning: sometimes does X, some
> times does Y.
>
> Still the asPipe is a very very nice hack.
>
> I think the question is different from adding or not syntax to do a trick.
>
> Do Small-talkers want to assert:
>
> "Use functional programming when possible"
>
> or not ?
>
>
> This is question. And I can't answer that.
>
> It's not :
> "Shall we add a new syntax token to do the trick ?"
>
> Fabio FIlasieno
>
> PS. Note that I associate functional programming with a chained application
> of functions (better if pure)
>
>
>
>
>

Fabio Filasieno

Re: Pipe syntax and the current methods

In reply to this post by Bert Freudenberg

But also, newcomers to Smalltalk need to understand that to Smalltalkers, the *language* part is actually not all that important. This is very different from other communities like the ones you list, which are in fact centered around their language. For us Smalltalkers it is the environment that counts most, not the syntax.

Smalltalk guys compare proudly their language with others.

It VERY important the less writable (verbose) but very readable syntax (Code is meant to be read and only incidentally to be executed philosophy)

It's VERY important the homoiconic LISPish small kernel. ("Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." :o)

... the *language* part is actually not all that important.

No it is. And you know it. It's very very important.

On Aug 28, 2007, at 11:50 PM, Bert Freudenberg wrote:

On Aug 28, 2007, at 4:11 , Fabio Filasieno wrote:

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.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)

I see that quote as a need for the pipe, as it will remove many complex parts in a system to replace them for simple parts, `taking` away, as Antoine would say, many ugly parts and replacing them more small and beautiful parts.

On Aug 29, 2007, at 1:56 AM, Igor Stasenko wrote:

Bloat you say? but if implemented differently it can improve
performance and transform collection using single loop. Instead of:
^ (self select: selectBlock) collect: collectBlock
or with pipe syntax:
^ self select: selectBlock | collect: collectBlock

That is not important ! Performance is not important in the beginning ! I want the freedom write slow software that is fast develop, reserving the right to improve speed after measuring. If the code you say is executed one or twice, even if I miss that optimization that is not a problem. And you can always fix it.

In software performance comes later!!!!!! How many times this mistake has been made and remade...

I always try to remember myself that software is 40% design (writing code not *really knowing what you are doing*, 40% writing code to test code, 20% *just code* code ).

Check this out and read a how the pipe is central to each point.

http://www.faqs.org/docs/artu/ch01s06.html

In general is this good or bad software engineering ? This is where - I - come from.

But I guess I'll stop annoying you on this pipe thing, at the time being :o) , as Vassili already did some good stuff for me for free. Thanks Vassili.

But ...

The pipe is crucial to support functional programming better. (It's easy to reason about problems functionally )

The pipe is crucial to take away what CAN be taken away (Antoine de Saint-Exupery)

The pipe is crucial to replace complex parts with simple parts (If I can already do it, why write a new method)

The pipe is crucial get functionality implemented for free. (do method A, do method B, get A | B for free)

The pipe is crucial to attract more people to smalltalk (functional programmers, which by the way are good hackers)

The pipe is crucial to reduce bloat. (select:thenCollect it's hilarious ...)

The pipe is crucial to make developers more responsible ( do I really need this method? Or is just mental masturbation ... )

I'll try to appear smart too with another quote of another italian bloke

"It must be considered that there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order, this lukewarmness arising partly from fear of their adversaries, who have the laws in their favour; and partly from the incredulity of mankind, who do not truly believe in anything new until they have had actual experience of it."

Niccolò Macchiavelli

Fabio Filasieno

Blake-5

Re: Pipe syntax and the current methods

On Wed, 29 Aug 2007 00:49:22 -0700, Fabio Filasieno
<[hidden email]> wrote:

>> ... the *language* part is actually not all that important.
> No it is. And you know it. It's very very important.

But it misses the point. When you talk about most languages, you're JUST
talking about the language. That's all there is. Yeah, these days you also
get a VM for a lot of languages but it's a separate beast.

You can't discuss, e.g., changing C's syntax and still be talking about C.
You can discuss--well, discussions have been had about doing Etoys in
Python. You could do all of Squeak in Python, probably, or another dynamic
language (perhaps with some minor adjustments) and a remarkably large
percentage of the discussion would not change.

I love the Smalltalk syntax and would put it up against any other
language, but it's more important that you can change it if you don't.

Yoshiki Ohshima

Re: Pipe syntax and the current methods

In reply to this post by Fabio Filasieno

Hello,

> Since Pipes makes Smalltalk better at prototyping, Pipes gives me a sharper pencil.

I think I know a part of your frustration. When you are trying make
the idea rendered into the first cut of code, you really don't want to
move the cursor back in the characters you typed and insert some other
stuff just to make it compile and do something.

Another approach to solve this problem is to make the editor
smarter. I could imagine to have a some command-key sequence that
puts open and close parenthesis around the *last* expression. The
definition of the "last" expression may need a clarification but it
almost sounds like "right before the last statement separater ($.)"
would be good. With it, if you type:

aCollection select: [:each | each isSomething]

and then realize that you actually want to continue to write collect:,
then you press a key combination and it enclose the above expression
with $( and $). In this way, you don't have to change the language.

For this kind of stuff, having three different precedence in message
sending is basically two too many. That is why the lisp-mode in Emacs
shines more than any other modes. But for Smalltalk-80 syntax, it
wouldn't be too bad.

-- Yoshiki

Bert Freudenberg

Re: Pipe syntax and the current methods

On Aug 30, 2007, at 1:52 , Yoshiki Ohshima wrote:

> Hello,
>
>> Since Pipes makes Smalltalk better at prototyping, Pipes gives me
>> a sharper pencil.
>
> I think I know a part of your frustration. When you are trying make
> the idea rendered into the first cut of code, you really don't want to
> move the cursor back in the characters you typed and insert some other
> stuff just to make it compile and do something.
>
> Another approach to solve this problem is to make the editor
> smarter. I could imagine to have a some command-key sequence that
> puts open and close parenthesis around the *last* expression. The
> definition of the "last" expression may need a clarification but it
> almost sounds like "right before the last statement separater ($.)"
> would be good. With it, if you type:
>
> aCollection select: [:each | each isSomething]
>
> and then realize that you actually want to continue to write collect:,
> then you press a key combination and it enclose the above expression
> with $( and $).

+1

- Bert -

Igor Stasenko

Re: Pipe syntax and the current methods

In reply to this post by Yoshiki Ohshima

On 30/08/2007, Yoshiki Ohshima <[hidden email]> wrote:

> Hello,
>
> > Since Pipes makes Smalltalk better at prototyping, Pipes gives me a sharper pencil.
>
> I think I know a part of your frustration. When you are trying make
> the idea rendered into the first cut of code, you really don't want to
> move the cursor back in the characters you typed and insert some other
> stuff just to make it compile and do something.
>
> Another approach to solve this problem is to make the editor
> smarter. I could imagine to have a some command-key sequence that
> puts open and close parenthesis around the *last* expression. The
> definition of the "last" expression may need a clarification but it
> almost sounds like "right before the last statement separater ($.)"
> would be good. With it, if you type:
>
> aCollection select: [:each | each isSomething]
>
> and then realize that you actually want to continue to write collect:,
> then you press a key combination and it enclose the above expression
> with $( and $). In this way, you don't have to change the language.
>
> For this kind of stuff, having three different precedence in message
> sending is basically two too many. That is why the lisp-mode in Emacs
> shines more than any other modes. But for Smalltalk-80 syntax, it
> wouldn't be too bad.
>

And then the only thing you need is to implant a chip into your brain
to be able read code with many (...) fast :)

> -- Yoshiki
>
>

--
Best regards,
Igor Stasenko AKA sig.

Yoshiki Ohshima

Re: Pipe syntax and the current methods

Igor,

> > Another approach to solve this problem is to make the editor
> > smarter. I could imagine to have a some command-key sequence that
> > puts open and close parenthesis around the *last* expression. The
> > definition of the "last" expression may need a clarification but it
> > almost sounds like "right before the last statement separater ($.)"
> > would be good. With it, if you type:
> >
> > aCollection select: [:each | each isSomething]
> >
> > and then realize that you actually want to continue to write collect:,
> > then you press a key combination and it enclose the above expression
> > with $( and $). In this way, you don't have to change the language.
> >
> > For this kind of stuff, having three different precedence in message
> > sending is basically two too many. That is why the lisp-mode in Emacs
> > shines more than any other modes. But for Smalltalk-80 syntax, it
> > wouldn't be too bad.
> >
>
> And then the only thing you need is to implant a chip into your brain
> to be able read code with many (...) fast :)

A proper indentation helps, of course.

Prof. Takeuchi, a Lisp guru and known as the inventor of the "tak"
function, is also full of sense of humor. One of his jokes takes a
form of dialog between a Lisp Master and a young apprentice of his:

Apprentice: Master, there are too many parenthesis in this language!
Even my eyes hurt! How could you write a program in it?

Lisp Master: Huh? What parenthesis? ... Ah, I totally forgot about
them.

-- Yoshiki

Rob Withers

Re: Pipe syntax and the current methods

In reply to this post by Randal L. Schwartz

----- Original Message ----
From: Igor Stasenko <[hidden email]>
To: The general-purpose Squeak developers list <[hidden email]>
Sent: Thursday, August 30, 2007 11:15:14 AM
Subject: Re: Pipe syntax and the current methods

> On 30/08/2007, Yoshiki Ohshima <[hidden email]> wrote:

> >   Hello,
> >
> > > Since Pipes makes Smalltalk better at prototyping, Pipes gives me a sharper pencil.
> >
> >   I think I know a part of your frustration.  When you are trying make
> > the idea rendered into the first cut of code, you really don't want to
> > move the cursor back in the characters you typed and insert some other
> > stuff just to make it compile and do something.
> >
> >   Another approach to solve this problem is to make the editor
> > smarter.  I could imagine to have a some command-key sequence that
> > puts open and close parenthesis around the *last* expression.  The
> > definition of the "last" expression may need a clarification but it
> > almost sounds like "right before the last statement separater ($.)"
> > would be good.  With it, if you type:
> >
> >   aCollection select: [:each | each isSomething]
> >
> > and then realize that you actually want to continue to write collect:,
> > then you press a key combination and it enclose the above expression
> > with $( and $).  In this way, you don't have to change the language.
> >
> >   For this kind of stuff, having three different precedence in message
> > sending is basically two too many.  That is why the lisp-mode in Emacs
> > shines more than any other modes.  But for Smalltalk-80 syntax, it
> > wouldn't be too bad.
> >
>
> And then the only thing you need is to implant a chip into your brain
> to be able read code with many (...) fast :)

You already have one of those chips. They call that your nose and it is for smelling nasty, nasty code smells. It doesn't matter if you are using () or |, they both smell when used excessively. Refactor!

Do something crazy like defining a StackFilter, where you can push expressions into a stack and apply it to an underlying collection. It would compute the filtered value whenever the underlying collection changes. Something like this would be a more OO approach, I would think. Think like an object and not a function. :)

cheers,

Rob

Jason Johnson-5

Re: Pipe syntax and the current methods

In reply to this post by Igor Stasenko

On 8/30/07, Igor Stasenko <[hidden email]> wrote:
> On 30/08/2007, Yoshiki Ohshima <[hidden email]> wrote:
>
> And then the only thing you need is to implant a chip into your brain
> to be able read code with many (...) fast :)

It's not so bad. It's just as in Lisp: You don't count parens, you
read based on indentation.