gmane.comp.lang.smalltalk.vwnc

Re: Access modifier missing in ST ??

stephane ducasse — 2013-05-25T18:37:57


 having public methods is the simplest model.
Because if you want to have protected methods then you need to be able to distinguish between 
self sends sent from the class and those that are not from a client. And since in Smalltlak there is no static 
type annotation you cannot simply identify such cases. There are approaches (we are checking one) 
based on the different between self x and anObject x.

Re: Access modifier missing in ST ??

Tom Robinson — 2013-05-25T18:32:57

Hi Mani,

I think it's a feature, rather than a limitation. When you get a 
Smalltalk product or distro, some of the methods are marked private via 
a protocol or some kind of annotation or property. That means that the 
developer or producer of the class thinks that those methods shouldn't 
be called from outside the class.

But you can, if you need to. It means that you need to be careful to 
look at why the method was private and whether you have to do anything 
extra to ensure that you don't break anything. It means flexibility. It 
means that as a Smalltalk developer you can't be condescending to those 
who use your code. "We think we know how you should use this, but you 
might have a use case we haven't thought of" instead "WE KNOW EVERY 
POSSIBLE USE YOU COULD PUT THIS TO AND THIS IS FOR YOUR OWN GOOD".

If someone thinks it's a limitation, he's welcome to. I think it's an 
advantage.

Access modifier missing in ST ??

mani kartha — 2013-05-25T15:16:18

a C# developer today asked me
"is it not a limitation of ST that an object allows all of its implemented
methods to be accessed by any other objects ?"

Can someone tell me if it is intentionally so,if yes what is the advantage
of ST being like that???


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

Re: Reducers in Smalltalk

stephane ducasse — 2013-05-25T12:08:53

On May 25, 2013, at 11:30 AM, Steffen Märcker <merkste< at >web.de> wrote:


;)
just send a presentation proposal like that you will kick you to get a presentation by september :)


yes please continue. We need superPowers and I do not really like blocks into blocks :)


Not really we are too busy but I love this discussion. 


I would love that. 
I could also help to write an article about them in the future (not because I want to steal ideas or need publications but because
I'm slow to understand so this force myself to write nicely). 
So I really suggest to think about a presentation at ESUG so that after we can drink beers and discuss in front of a black board
and this year ESUG will be again in a cool place with good food and energy.

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-25T09:30:00

Thanks for the suggestion Stephane. Actually, I never thought about
presenting at ESUG. Sure, I'd like to contribute a presentation or a paper
but I am afraid it is still too early. And, since Reducers is a spare time
project and the next weeks will be busy, I won't meet the deadline in
June. But maybe I'll be in beautiful Annecy in September nevertheless. =)

Meanwhile, I want to mature Reducers and to keep this discussion open. I'd
be happy about any feedback, ideas and contributions to Reducers.
Stephane, perhaps you want to share your thoughts on improving collection
iterations here, too? Is there an ongoing discussion for Pharo?
If Reducers prove to be useful, a comparative article and a Pharo port
will be logical steps. What do you think?

Just some background:
I read about Clojure's reducers library, since a friend of mine wanted to
use it in his upcoming project. After wrapping my head around Rich
Hickey's blog posts on reducers (links below), I fetched the source and
did the initial port in a train back from Avignon to Leipzig. I turned out
to be really refreshing to figure out how to do this in ST. =)
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html

Kind regards,
Steffen

Am 22.05.2013, 19:20 Uhr, schrieb stephane ducasse
<stephane.ducasse< at >gmail.com>:

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

[ANN] SmalltalkFit

Randy Coulman — 2013-05-24T15:18:26

I have just released the latest version of
SmalltalkFit<[https://github.com/randycoulman/SmalltalkFit](https://github.com/randycoulman/SmalltalkFit>,
an implementation of Ward Cunningham's Framework for Integrated
Tests<[http://fit.c2.com](http://fit.c2.com>
,
Fitnesse <[http://www.fitnesse.org](http://www.fitnesse.org>, and Rick
Mugridge's FitLibrary<[http://fitlibrary.sourceforge.net](http://fitlibrary.sourceforge.net>.


Fit is a tool for writing acceptance tests
(integration tests/examples/executable specifications/whatever you want to
call them). Fitnesse is a wiki wrapper around Fit, and FitLibrary
adds additional ways of writing the tests.

This version of SmalltalkFit includes the equivalent features of Fit Java
1.1, Fitnesse 20121220, and FitLibrary 2.0. It does not (yet) include a
port of Fitnesse Slim.

SmalltalkFit is available in the Cincom Public Store
Repository<[http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository](http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
 A snapshot of the current version is also on
GitHub<[https://github.com/randycoulman/SmalltalkFit](https://github.com/randycoulman/SmalltalkFit>.
The Readme file on GitHub includes high-level documentation if you'd like
more information before diving in.

The full release announcement is on my blog, Courageous
Software<[http://randycoulman.com/blog/2013/05/24/smalltalkfit/](http://randycoulman.com/blog/2013/05/24/smalltalkfit/>.


Thanks,
Randy

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-23T12:24:41

Hi Vincet,

your's is an excellent example for the importance of choosing the right  
algorithm. At the end of this mail you'll find a reducer variant of the  
first naive algorithm.
Let's have a look at a second alternative. It's basic idea is similar to  
your second method. However, it does not rely on array access via indices.  
Thus, it will work with arbitrary reducibles, even infinite sources. (For  
example: r := Random new. [r next] reducer.) The idea is to split the work  
in 4 steps:
1. map to squares
2. map to windows
3. compute window sum
4. drop sums of incomplete windows

First, assume you have an efficient buffer implementation, e.g. a  
RingBuffer class.

*** Sliding Window with RingBuffer class ***
| squared buffer windows tmpSum sum drop |
    "map to squares"
squared := Reducer map: #squared.
    "map to windows of size = windowSize + 1"
buffer := RingBuffer new: (windowSize + 1) withAll: 0.
windows := Reducer map:
    [:each |
    buffer
       removeFirst;
       addLast: each;
       yourself].
    "map to window sum"
tmpSum := 0.
sum := Reducer map: [:window | tmpSum := tmpSum + window last - window  
first].
    "drop sums of incomplete windows"
drop := Reducer drop: windowSize - 1.
    "build recipe for a collection of window sums"
results := drop <> sum <> windows <> squared from: numbers.


Second, to have a WS script that does not depend on a buffer  
implementation, consider the following code. Since it simulates the  
buffer, the code is more verbose.

*** Sliding Window with Simulated RingBuffer ***
| squared bufferSize buffer bufferIndex windows tmpSum sum drop |
squared := Reducer map: #squared.
bufferSize := windowSize + 1.
buffer := Array new: bufferSize withAll: 0.
bufferIndex := 0.
windows := Reducer map:
    [:each |
    bufferIndex := (bufferIndex \\ bufferSize) + 1.
    buffer
       at: bufferIndex put: each;
       yourself].
tmpSum := 0.
sum := Reducer map:
    [:window | | first last |
    last := bufferIndex.
    first := (bufferIndex \\ bufferSize) + 1.
    tmpSum := tmpSum + (buffer at: last) - (buffer at: first)].
drop := Reducer drop: windowSize - 1.
results := drop <> sum <> windows <> squared from: numbers.

*** Aggregate Results ***
results
    reduce:
       [:col :each |
       col
          add: each;
          yourself]
    init: (OrderedCollection new: (numbersSize - windowSize + 1))]


As promised, here is the naive algorithm.

*** Naive Algorithm ***
| windows sum |
windows := (1 to: numbersSize - windowSize + 1) reducer
    map: [:i | i to: i + windowSize - 1].
sum := Reducer map:
    [:window |
    window
       reduce: [:sum :i | sum + (numbers at: i) squared] init: 0].
results := sum from: windows.

Kind regards,
Steffen

Re: Reducers in Smalltalk

stephane ducasse — 2013-05-22T17:20:42

+ 1
I like this discussion. We were thinking (not deeply) how to improve collection iteration to avoid intermediate collections
without the loss of readability.

Steffen did you consider present something at ESUG? Because we could have some nice conversations :)
Or writing something for the workshop? I would love to read something on that and a comparison of Xtreams.

Stef

On May 21, 2013, at 7:16 PM, Steven Kelly <stevek< at >metacase.com> wrote:


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

Re: Reducers in Smalltalk

Vincent Lesbros — 2013-05-22T17:11:23

ok,

It is not so easy to speak english, so I prefer to speak Smalltalk. ,-)*.

Here folows a sample of simple calculations of collection of numbers
with 2 differents methods.
The first one is certainly easier to understand, but is in time NxM,
the second one is in time on N, but... (there is allways a but),
perhaps not so precise.
What do you think of a Reducer implémentation for that precise case ?

| alea numbersSize windowSize numbers method1 method2 temp t1 t2 delta |

numbersSize := 100000.
windowSize := 1000.
alea := Random new.
numbers := (1 to: numbersSize) collect: [:index | alea next ].

"Method 1"

t1 := Time millisecondsToRun: [
method1 := (1 to: numbersSize - windowSize + 1)  collect: [:index |
(0 to: windowSize - 1) inject: 0 into: [:sum :deltaIndex | sum +
(numbers at: index + deltaIndex) squared ] ].
].
"Method2"

t2 := Time millisecondsToRun: [
temp := (1 to: windowSize) inject: 0 into: [:sum :index | sum +
(numbers at: index) squared ].
method2 := Array new: numbersSize - windowSize + 1.
1 to: numbersSize - windowSize do: [:idx |
method2 at: idx put: temp.
temp := temp - ((numbers at: idx) squared)
+ ((numbers at: idx + windowSize) squared) ].
method2 at: numbersSize - windowSize + 1 put: temp.
].

"Delta"

delta := (1 to: numbersSize - windowSize + 1) collect: [:index |
(method1 at: index) - (method2 at: index) ].
^ Array with: method1 -> t1 with: method2 -> t2 with: delta


--
(t1 is about 6000 ms, t2 14 ms, and at end, delta contains numbers in
the order of 1.0d-12
---







2013/5/22 Steffen Märcker <merkste< at >web.de>:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-22T15:37:30

Nice, have fun! =)
I'd be interested in your feedback and suggestions for improvement once  
you have used them.

Regards,
Steffen


Am 22.05.2013, 16:57 Uhr, schrieb Vincent Lesbros <lesbros< at >gmail.com>:

Re: Reducers in Smalltalk

Vincent Lesbros — 2013-05-22T14:57:20

Thank you, Steffen,
I am convinced, I will try them.

2013/5/22 Steffen Märcker <merkste< at >web.de>:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-22T08:18:25

++1

Am 22.05.2013, 09:17 Uhr, schrieb Nowak, Helge <hnowak< at >cincom.com>:

Re: Reducers in Smalltalk

Steffen Märcker — 2013-05-22T08:16:52

Hi Vincent,

I'll try to outline some ideas according to my understanding of your  
problem. This answer is actually quite long and took quite some time;  
sorry for being lengthy.

First, I want to spoil you a bit before diving into the details. We could  
come up with something like


Where
* samples takes the samples
* calculated does the calculation
* validate does some test on the calculated values

Finally, "reduce: #& init: true" simply calculates the logic conjunction  
of the results.


1) Sampling

If it is sufficient to have a fixed distance between your sample, you can  
use:

But maybe you want to take random samples with a certain expected distance:

You can write both filters in a more compositional way to reuse them.

Depending on the representation of the numbers collection this approach  
might be inefficient, since filter: (and select: as well), will enumerate  
the numbers. For example arrays afford direct access via the indices, e.g.

However, reducers make very few assumptions about the reducible (read:  
collection). Namely, it has to implement #reduce:init:. Thus, reducers can  
exploit their strengths if, for example,
- the reducible's type is not previously know
- the reducible's size is unknown/infinite
- the reducible provides only sequential access
   (e.g., generated/streamed elements)
- et cetera

Then you can do things like:

You may find that equidistant/randomized filters are useful enough to make  
them available to all reducibles. If so, you want to implement two  
transformer classes, e.g., TakingEquidistant and TakingRandomized, and  
extend Reducer with convenience methods like
* Reducer>>takeEvery: distance
* Reducer>>takeRandom: probability
Have a look into Taking or TakingWhile for the details. (Maybe the  
convenience methods will be generated automagically in future iterations  
of reducers.)


2) Calculations on Elements aka Mapping
I suppose we split the work on the samples into a calculation and a  
verification step. We can express both as mappings:


3) Caching or Memoizing
This is difficult to answer, since those optimizations heavily depend on  
your calculations and data. As John pointed out earlier, profiling should  
be your guide here.
Said this, reducers allow you to apply your own caching strategies. Just  
an example:

Travis Griggs implemented a small memoizing API for blocks  
(TAG-MemoizedFunctions;  
http://objology.blogspot.de/2012/05/tag-memoizedfunctions.html). You could  
use it to speed up the calculations:

Applying this optimization can be tricky. For example, if the samples are  
randomized, it is likely that the speedup is minimal. Even worse,  
performance may decline due to increased memory consumption.

If you have to perform many similar calculations on the same sample set,  
you might want to aggregate the samples in a collection:

As always, the strategy depends.


4) Wrap Up
With the ideas above, we can complete the introductory example.


Now, the analysis can be applied to multiple times to different sources,  
e.g.,


Since "equidistant" uses indices, "numbers" is required to be indexed. We  
can fix this be defining an indexing step.


Now we can apply the analysis to arbitrary reducibles:



I hope this mail gives a first impression.

Kind regards,
Steffen

Re: Reducers in Smalltalk

Andres Valloud — 2013-05-22T07:28:42

http://books.google.com/books?id=_dce9Jaq7iQC&pg=PA238&lpg=PA238&dq=gauss+learning+new+languages&source=bl&ots=nzpnEIUEDT&sig=VNtIBa-b9zBGfRPBqKdQfecHXbE&hl=en&sa=X&ei=LnOcUaKcLub_igKk9oCgAQ&ved=0CGMQ6AEwBQ#v=onepage&q=gauss%20learning%20new%20languages&f=false

On 5/22/13 0:17 , Nowak, Helge wrote:

Re: Reducers in Smalltalk

Nowak, Helge — 2013-05-22T07:17:03

+1!

-----Ursprüngliche Nachricht-----
Von: vwnc-bounces< at >cs.uiuc.edu [mailto:vwnc-bounces< at >cs.uiuc.edu] Im Auftrag von Andres Valloud
Gesendet: Mittwoch, 22. Mai 2013 09:12
An: Visualworks Mailing List
Betreff: Re: [vwnc] Reducers in Smalltalk

+1... sometimes I don't understand why we focus so much on picking a
winner to the detriment of diversity.  One could also say such a tendency is at play when we compare different computer languages with Smalltalk.  I think we all have picked our favorites a long time ago, what doesn't seem to follow for me is the apparent conclusion that since there must be *a* favorite then everything else is unworthy of attention.  We tend to pay a huge price when we want to interface Smalltalk to that outside "alien" world that doesn't want to conform to our expectations of elegance, uniformity, and simplicity --- and when we would love to share our excitement and passion for what we do.  Maybe we should be a bit more aware of these types of limitations so that we can keep an open mind to different ways of thinking.

FYI, Gauss used to say that he learned a new language every couple years to "keep his mind flexible".

On 5/21/13 10:16 , Steven Kelly wrote:
_______________________________________________
vwnc mailing list
vwnc< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Re: Reducers in Smalltalk

Andres Valloud — 2013-05-22T07:11:50

+1... sometimes I don't understand why we focus so much on picking a 
winner to the detriment of diversity.  One could also say such a 
tendency is at play when we compare different computer languages with 
Smalltalk.  I think we all have picked our favorites a long time ago, 
what doesn't seem to follow for me is the apparent conclusion that since 
there must be *a* favorite then everything else is unworthy of 
attention.  We tend to pay a huge price when we want to interface 
Smalltalk to that outside "alien" world that doesn't want to conform to 
our expectations of elegance, uniformity, and simplicity --- and when we 
would love to share our excitement and passion for what we do.  Maybe we 
should be a bit more aware of these types of limitations so that we can 
keep an open mind to different ways of thinking.

FYI, Gauss used to say that he learned a new language every couple years 
to "keep his mind flexible".

On 5/21/13 10:16 , Steven Kelly wrote:

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/21 Steven Kelly <stevek< at >metacase.com>:

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 stretched in undergraduate days with FP, and more recently with a little greenfield project using Xtreams.
 
All the best,
Steve

________________________________

From: vwnc-bounces< at >cs.uiuc.edu on behalf of Nowak, Helge
Sent: Tue 21/05/2013 17:00
To: john woods
Cc: vwnc< at >cs.uiuc.edu
Subject: Re: [vwnc] Reducers in Smalltalk



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. I just talk about the philosophy behind.

 

Cheers

Helge

 

Von: vwnc-bounces< at >cs.uiuc.edu [mailto:vwnc-bounces< at >cs.uiuc.edu] Im Auftrag von john woods
Gesendet: Dienstag, 21. Mai 2013 15:02
Cc: vwnc< at >cs.uiuc.edu
Betreff: Re: [vwnc] Reducers in Smalltalk

 

 

(((1 to: 10) reducer filter: #odd) map: squared) reduce: #+ init: 0.


It can be written the classic way:

(((1 to: 10) select: #odd) collect: #squared) inject: 0 into: #+.


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

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


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.

 

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 incomprehensible code (often not Smalltalk) which has been 'pre-optimized' by developers, and this pre-optimization is largely (though not solely) responsible for its poor readability.  Even where their efforts work (and you would be *amazed* how often they either have zero or even negative effects on real-world performance), the cost of maintaining such obscurantist code is nearly always vastly more than finding better hardware.  In short, write your application first, then profile it and *then* optimize it - and only those bits which need it.  The observed performance problems will very rarely coincide with the expectation of even some of the most talented developers.

These Reducer things do not look self explanatory and to me that is adverse to the entire spirit of Smalltalk.  My view would be that I would need to see *much* stronger evidence of *very* significant advantages of this approach before I would even consider using such an approach.  

_______________________________________________
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-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 significant or appropriate in all use cases. However,  
avoiding unnecessary work (e.g., intermediate collections) seems not too  
bad an idea.

But what about the other opportunities?

Regards,
Steffen

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. I just talk about the
philosophy behind.

 

Cheers

Helge

 

Von: vwnc-bounces< at >cs.uiuc.edu [mailto:vwnc-bounces< at >cs.uiuc.edu] Im
Auftrag von john woods
Gesendet: Dienstag, 21. Mai 2013 15:02
Cc: vwnc< at >cs.uiuc.edu
Betreff: Re: [vwnc] Reducers in Smalltalk

 

 

(((1 to: 10) reducer filter: #odd) map: squared) reduce:
#+ init: 0.


It can be written the classic way:

(((1 to: 10) select: #odd) collect: #squared) inject: 0 into:
#+.


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

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


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.

 

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
incomprehensible code (often not Smalltalk) which has been
'pre-optimized' by developers, and this pre-optimization is largely
(though not solely) responsible for its poor readability.  Even where
their efforts work (and you would be *amazed* how often they either have
zero or even negative effects on real-world performance), the cost of
maintaining such obscurantist code is nearly always vastly more than
finding better hardware.  In short, write your application first, then
profile it and *then* optimize it - and only those bits which need it.
The observed performance problems will very rarely coincide with the
expectation of even some of the most talented developers.

These Reducer things do not look self explanatory and to me that is
adverse to the entire spirit of Smalltalk.  My view would be that I
would need to see *much* stronger evidence of *very* significant
advantages of this approach before I would even consider using such an
approach.  

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

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