gmane.comp.lang.smalltalk.vwnc

Re: Reducers in Smalltalk

Vincent Lesbros — 2013-05-21T19:56:27

from a previous message, as an old hands at Smalltalk, (or old feet),
I'll wirte it  :

(1 to: 10) inject: 0 into:
   [:sum :n | sum + (n odd
      ifTrue: [ n squared ]
      ifFalse: [ 0 ]) ]

But, I like new way of programming if there is a real change in point
of view. Perhaps the case with Reducers.
And I don't like to change a technique if it is still working efficiently.

I have a concrete case :

I have large arrays of numbers. I want to show different aspects of
theses series of numbers. I may have to show samples taken randomly
into the whole set, because calculations are too long to be done on
each elements.
For example, I can sample 1 of 100 of the elements.
A contrario, I may have to do over and over the same calculations on
portions of this population.

How Reducers may help me ?

Should I implement a system that remember what is already calculated
to improve performance and saturate memory,
or a "lazy" evaluation system, that will develop and calculate only
the value really needed ?



2013/5/

Re: Reducers in Smalltalk

Steven Kelly — 2013-05-21T17:16:55

As this conversation proves, one of the hardest things is to get people to actually try something new. It's more natural to respond with "I don't need it, I can cope with the basic functions I already have", or "I already know another add-on that offers some of the same benefits". Both are true, and I'm guilty on both counts. But in a sense the value of Reducers may be precisely that they offer something familiar to functional programmers, as Helge says. By giving them familiar vocabulary and things they value (e.g. parallelism), we make Smalltalk a little more palatable. And even old hands at Smalltalk may learn something new - after all, most agree that inject:into: always feels a little lacking.
 
I'm really glad to see Steffen's work, and the Xtreams work of Michael and Martin. I'm not using either in anger yet, because I don't have enough pain from the existing base collection and stream support to justify adding a dependency on a non-base component. But I do think my brain benefitted from being stretch

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-21T16:35:30

Hi!

Your're right Helge, Reducers originated from a functional (actually  
LISP-like) language, Clojure. My idea was to find out how the concept  
could work out in ST. It turned out, that it translates directly to  
iterating with (nested) blocks. The function transformers are just  
factories that produce those blocks.

However, I am not sure why


appears so hard to read in contrast to


Is it the uncommon (renameable) selectors? Or the concept of building a  
receipt (i.e, a reducer) for a collection instead of using intermediate  
collections?


Besides the intermediate collection, I am a bit uncertain about the  
benefits of #sum or #allOddElements, too. These methods are quite the  
opposite of the generic high-level concept of #collect:, #select: and so  
on. (Which build upon a functional concept, blocks aka anonymous  
functions.)

Also I am quite surprised by John's stress on optimization. Performance  
was just one of the possible benefits I can imagine. I did never claim  
that it will be signi

Re: Reducers in Smalltalk

Nowak, Helge — 2013-05-21T14:00:41

Dear John,

 

in general I agree.

 

I think the real issue is that Reducers are coming from a mindset
different from Smalltalk: functional programming, which is rooted in
mathematics. From my point of view functional programming looks rather
at the "how to implement functionality" whereas Smalltalk's philosophy
is "what domain to model". As a programmer of non-mathematical software
I have an intuitive notion of what a Collection is (a collection of
things). Yet what is a "Reducible"? Naively: something that can be
reduced, i. e. a value?? If I am a programmer of mathematical software
though, I may have an intuitive notion of what a Reducible is, just like
I have a notion of vectors, matrices etc.. Having said that I think
Reducers (a Do-er: is this OO think at all?) may have their place, yet
not as a general concept.

 

To not be misunderstood: I don't judge anything like implementation
details or claimed benefits of the one or other implementation. And I
don't want to belittle the work Steffen has done.

Re: first MOOC about OOP with Smalltalk and Seaside - voting period ends at Thursday

Johannes Brauer — 2013-05-21T13:41:50

Hi,

there is a chance to adjust our MOOC project: please vote for it until May, 23rd. You can use the following link:
https://moocfellowship.org/submissions/objektorientierte-programmierung-von-web-anwendungen-von-anfang-an

I apologize for this reminder.

Thanks a lot

Johannes

Am 04.05.2013 um 17:29 schrieb Johannes Brauer <brauer< at >nordakademie.de>:



________________________________


Staatlich anerkannte private Fachhochschule
NORDAKADEMIE
Gemeinnützige Aktiengesellschaft
Köllner Chaussee 11
25337 Elmshorn

Vorstand:
Prof. Dr. Georg Plate (Vorsitzender), Dipl.-Ing. Jörg Meier (stellv. Vorstand)

Vorsitzender des Aufsichtsrats:
Dr. h.c. Hans-Heinrich Bruns

Sitz:
Elmshorn, Amtsgericht Pinneberg, HRB 1682

Re: Reducers in Smalltalk

john woods — 2013-05-21T13:02:23

This style is harder to read, especially for more complex conditions and

Actually, I'd like to completely disagree.  It is, in my opinion, much
easier to see what the latter does.  The easiest to read is the most
naive.  Write the following extension methods:

Given Collection>>sum, (((1 to: 10) select: #odd) collect: #squared) sum.

Or you could use Collection>>inject:into: here instead of writing
Collection>>sum.  Or you could go the other way and implement, for instance
Collection>>oddElements etc, and just do (1 to: 10) allOddElements
sumOfSquares.

What I really don't want to see is unnecessary complexity or in the code
because programmers think that it will be faster or more efficient.  For
instance, one of your concerns was the creation of an intermediate block.
But you have offered very little proof that this is even a problem.  Who
knows what the VM will do, especially if it does JIT optimization?  or uses
the GPU?

As a full time performance engineer I spend a lot of time looking at
incomprehensi

Re: Next-DataSetView

giorgio ferraris — 2013-05-21T12:41:54

hi, Marteen

your work on dataset seems quite interesting.

BTW, great drawing on your product screeshot; all done in VW and cairo?
very good work
ciao

giorgio


On Tue, May 21, 2013 at 1:47 PM, Sean Glazier <sglazier456< at >gmail.com> wrote:

_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Re: Next-DataSetView

Sean Glazier — 2013-05-21T11:47:57

I would be interested in it. OD you need additional help with the widget?

Sean


Kind Regards

Sean Glazier

Light yourself on Fire with enthusiasm and people will come for miles to
watch you burn!


On Tue, May 21, 2013 at 10:20 AM, <maarten.mostert< at >stakepoint.com> wrote:

_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Next-DataSetView

2013-05-21T08:20:45

Hi,
I think they told us many moons ago that DataSetView was to complicated to be maintained ..
Now I lately got really upset about all this not coming Grid stuff and abandonnement of DSV so I decided to give it a serious BITE
 
For the moment my subclassed DataSetView adresses two major shortcomings:


1) Fully editable treeView (like editbale as any other column)
2) Be a drag source (including for itself).
 
You can see some preview here: [http://stakepoint.com/news] http://stakepoint.com/news
 
Does this interests anyone ?
 
< at >Maarten,_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-18T10:53:13

Hi Joerg!


Yes, there is - namely by hand. Let's consider the following example:


It can be written the classic way:


Which creates two intermediate collections. Again, we can avoid them:


But now we have to think in terms of #inject:into and craft the behavior of
#select: and #collect: into the block by hand.
This style is harder to read, especially for more complex conditions and  
mappings.


This idea uses specific block combinators (#&, #||, #,) for the different  
types of enumeration messages. Besides implementing the BlockCollection  
class, you extend BlockClosure with those new messages.
Furthermore, you have to modify each implementor for each of the  
enumeration methods #collect:, select: and so on. This approach does not  
seem to be composable or easy to extend. Moreover, it doesn't give you the  
other benefits I've sketched before. (And it does not simplify the example  
above.)

Did you gave reducers already a try?

Kind regards,
Steffen

Re: Reducers in Smalltalk

Joerg Beekmann, DeepCove Labs — 2013-05-17T18:54:10


There is already a way to compose the blocks used by select:/collect: etc. and avoid intermediate collections. For example in the case of 
test1 = [:i| I odd].
test2 := [:i| (i\\3) = 0].
((0 to: 100) select: test1) select: test2 

Does indeed iterate over the collection twice. But:

(0 to: 100) select: [:i| (test1 value: i) and: [test2 value: i]]

Only iterates over it once with the two tests composed.

If you want nicer syntax you could create a BlockCollection class with ways to compose blocks. For example:
aBlockCollection := (test1 & test2) || test3.

Then modify select: to take a block collection so you can write (1 to: 100) select: aBlockCollection.

Extensions to support block collections for collect could also be written say:
aBlockCollection := map1, map2, map3.
Then (1 to: 100) collect: aBlockCollection would give you the result of feeding the output of each block into the next.

Joerg
-----Original Message-----
From: vwnc-bounces< at >cs.uiuc.edu [mailto:vwnc-bounces< at >cs.uiuc.edu] On Behalf Of Steffen

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-17T17:06:03

Dear Micheal,

I'll try to only indicate some answers, since I am not too familiar with  
Xtreams. I only used parts of it, e.g., the neat PEG package. Please keep  
in mind that Xtreams is an extensive library, whereas Reducers is in an  
early stage and neither complete nor optimized. For example, so far the  
only way to write to a collection/drain is to accumulate with  
#reduce:init:,  e.g.,


* Composition
You already mentioned this.

* Performance
Reducer objects do nothing more than transforming a reducing function  
(block, symbol). The reduction with the transformed function is done by  
the underlying source (~terminal). Thus, apart from the one-time  
transformation, there is no overhead.
This property may give a performance edge over the classical enumeration  
operations and Xtreams. First simple tests look promising to accomplish  
this. However, the tests were not extensive and hardly representative.

* Parallelism
Since most operations, e.g map and filter, do not assume any order or  
repres

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Randy Coulman — 2013-05-15T14:07:07

OK, I understand what you're looking for.  I could think of a couple of
interpretations.

You basically have two options:

1. You can make a complete double of the class like this:

classDouble := DoubleAgent of: MyClass class.
classDouble stub: #myMethod return: 42.
result := suspectObject doStuffWithClass: classDouble.

If this is a common use case, then I should think about adding some kind of
convenience protocol to handle it.

2. You can use an in-place double on the original class like this:

classDouble := MyClass classSideDouble.
classDouble stub: #myMethod return: 42.
result := suspectObject doStuffWithClass: classDouble.


I see the tradeoffs between the two as follows:

 * The complete double will not respond to any other messages than those
you stub or mock; the in-place double will retain its original behavior for
any methods that you don't mention.

* The complete double has to be injected into the object under test; the
in-place double does not.

* The complete double will not impact any other

Re: Reducers in Smalltalk

Michael Lucas-Smith — 2013-05-15T13:17:55

Apart from the composition, what advantage does this give me over Xtreams. Xtreams is not just read, it's also capable of write and it backs up to IO with a streaming API. Some kinds of streams are also positionable, which is another bonus.

Cheers,
Michael

On 15/05/2013, at 10:37 PM, Steffen Märcker <merkste< at >web.de> wrote:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-15T12:37:14

I've just pushed a new version that improves the API a little bit:

- added Collection>>reducer to support more smalltalkish style:
   ((1 to: 10) reducer filter: #odd) map: #squared
- composition style:
   squares := (Reducer map: #squared).
   odds := (Reducer filter: #odd).
   squared <> odds from: (1 to: 10)

Regards,
Steffen

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Steffen Märcker — 2013-05-15T09:25:19

Say, we have MyClass that defines myMethod on the class side, e.g.


The code to be tested is given that class in some way and uses it, say


Can I stub myMethod with DoubleAgents? Maybe similar to


Regards, Steffen



Am 14.05.2013, 20:11 Uhr, schrieb Randy Coulman <rcoulman< at >gmail.com>:

Re: indexedType: #illegal

2013-05-14T20:48:27

I find that syntax highlighting helps me a lot with these types of errors (assuming you're coloring different variable types differently). Even if you happen to override a variable with a temp variable, it will be highlighted differently.

"Vincent Lesbros"<lesbros< at >gmail.com> wrote:

Re: Reducers in Smalltalk - template clean blocks

Paul Baumann — 2013-05-14T18:34:08

You mentioned CollectionViews. I use generated blocks in that code. When client code asks GS for information then a clean query block is created to gather that information for each item in the collection being enumerated. The block allows context to be passed as arguments into it so that it remains clean while still being able to resolve anything that is needed. The savings is that the context object need only be created once for all the items being enumerated and that the code being performed each time is as efficient as the compiler can create.


Yeah, that would be slow.


Yes, and you've hinted at the solution that can be used when blocks have little to change. You can use a clean block as a template for creating other clean blocks. You copy the clean block and replace an easily recognized literal with the with a different selector to execute. It avoids having to compile a block every time. This kind of tuning varies by Smalltalk dialect (if that is a concern). I've done things like this a couple times.

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Randy Coulman — 2013-05-14T18:11:14

What do you mean by "mocking a class"?  Can you give me an example?

Thanks,
Randy


On Tue, May 14, 2013 at 10:12 AM, Steffen Märcker <merkste< at >web.de> wrote:

Re: [ANN] DoubleAgents: A Test Double Library for Visualworks

Steffen Märcker — 2013-05-14T17:12:32

Hi Randy,

thanks for the explanation. DoubleAgents appear really interesting to me.  
I think I'll give it a try soon. Maybe for the reducers stuff or while  
reworking the SimpleXO / SimpleXPath tests. The latter uses sMock up to  
now.

Do DAs support mocking a class, too? How would you do that?


Nice.


Mmh, for me sMock works well with only one testing framework loaded. One  
can safely ignore the error message on load. Though, it would be nice to  
load the proper test class automagically, dependent on the loaded  
framework.

Regards, Steffen

Re: Reducers in Smalltalk (errata)

Steffen Märcker — 2013-05-14T17:12:33

Two minor points.

1. Reducer class>>filter:from: should be:

2. You can write short
for

Regards,
Steffen