Getting double semi as sequencer harvested.

Bert Freudenberg bert at freudenbergs.de
Mon Sep 3 07:41:20 UTC 2007


On Sep 3, 2007, at 0:19 , Andreas Raab wrote:

> Blake wrote:
>> Claims were made that pipes could reduce code size by a factor of  
>> 10 while increasing clarity. If true, it's certainly worthy. Even  
>> by 2 would be hard to argue with. One thing about traits is that  
>> you can see how the code is cleaner (and even then, there's still  
>> resistance).
>
> Do you have an actual example of how the code is cleaner or are you  
> simply repeating what other people tell you? I've been looking for  
> good examples for traits for a couple of years now but it seems  
> that when things go beyond the toy examples presented in the papers  
> traits create more complexity than they help to address.
>
>> It's reasonable to ask for some evidence.
>
> Indeed. Correcting mistakes is reasonable too, but both usually  
> don't happen.


Supposedly the "pipe syntax" is for helping to deal with to many  
parens, right? So I tried this:

	| n found |
	found := OrderedCollection new.
	'Decompiling all classes...'
		displayProgressAt: Sensor cursorPoint
		from: 0
		to: CompiledMethod instanceCount
		during: [:bar |
			n := 0.
			SystemNavigation default allBehaviorsDo: [:cls |
				cls selectorsDo: [:selector |
					(n := n + 1) \\ 100 = 0
						ifTrue: [bar value: n].
					((cls decompile: selector) decompileString includesSubString:  
'(((')
						ifTrue: [Transcript cr; show: '***' , cls name , ' ' , selector.
							found add: cls name , ' ' , selector]]]].
	SystemNavigation default
		browseMessageList: found asSortedCollection
		name: 'Triple Parens' autoSelect: '((('


In my 3.8-based image this matched 96 of 50000 methods. These are  
mostly bit arithmetic and conditionals, and a few occurrences of  
multiple select:/collect:/do:'s. But honestly, none of them, even the  
latter, would benefit (IMHO) from the pipe operator.

I have the impression that Smalltalk has hit a "sweet spot" - there  
may be a few additions (compile-time expressions anyone?) but  
basically it is very succinct in expressing what the underlying  
system does, namely, sending messages to objects. Other languages  
needed to add a lot more over the years as they started out with a  
rather limited model, but if you start with a general model like  
Smalltalk did (which in turn was the result of many experiments) it  
is not necessary to add that much. Or, if you do it, it wouldn't be  
Smalltalk anymore (and that's in fact what Alan's group now is  
working on, there is a whole lot of experimenting with syntax going  
on using Meta).

- Bert -





More information about the Squeak-dev mailing list