Re: pipe

On 8/30/07, Fabio Filasieno <fabio.filasieno <at> gmail.com> wrote:
>
> This is absolutely false.

Everything he said was correct.

And also, instead of calling it the very confusing "pipes" I think we
should call it then "then" operator.  That is, it clearly says "do
this to completion, *then* do this".

> Smalltalk-80 lacks the concept of EASY "pipes" (chained functional
> applications)
> as it is evident from the difference between
>
> (((obj method:param1) method:param2) method:param3)
> and
> obj method:param1 | method:param2 | method:param3.
>
> Smalltalk does't have EASY chained message sends .

To be totally honest here, I have no problem with the first.  And it
certainly isn't a problem in prototyping because the Squeak browser
has things to help you when you need to go back and add parenthesis.

> Smalltalk is  inconsistent too.
>
> obj send1 send2 send3.
>
> A perfect pipe. Is it ? Too bad that you can do only it sometimes not when
> you want.

Re: [ANN] FixedDecimals

nice.

On 8/31/07, Chris Cunningham <cunningham.cb <at> gmail.com> wrote:
> Hi.
>
> I've just release a package FixedDecimal on SqueakSource.
>
> A FixedDecimal is similar to a ScaledDecimal, but different in certain
> select ways.  It's primary purpose was to be able to represent precise
> decimals for such things as representing money - where ScaledDecimals leave
> something to be desired.  For instance, with ScaledDecimals, you get:
> (33.333s withScale:2) + (33.333s withScale:2)   print it yields 66.67s
> but with FixedDecimals, you would get:
> (33.333 asFixedDecimal: 2) + (33.333 asFixedDecimal: 2)    print it yields
> 66.66.
> So, FixedDecimals round the numbers to the exact scale you specify -
> converting a float to a FixedDecimal and back will not necessarily return
> the starting number, unlike ScaledDecimals.
>
> Most simple arithmetic is defined for FixedDecimals, but not all methods
> that probably should be (it's getting late and I'm going away for the
> weekend - thought I'd publish what I have).
>
> Thanks,
> Chris
>
>
>
>

Re: pipe harvesting

On 8/28/07, Fabio Filasieno <fabio.filasieno <at> gmail.com> wrote:
>
> There are quite some Phd powered hackers there, and I personally think that
> Smalltalk could win their love.

I seriously doubt it.  Haskell programming is as much about
programming to the typing system as it is functional programming [1]
(possibly more).  So switching to a dynamically typed system is highly
unlikely.  It's pretty unlikely that many of them would even accept
such a system as viable at all.

Functional programmers typically think they don't need OO as well [2].

So if you truly believe that changing expressions that look like:

(((someObject message: 1) message: 2) message: 3)

to:

someObject message: 1 >>= message: 2 >>= message: 3

is going to overcome all those issues, and bring in all those
PhD's.... well, it calls in your previous claim that your arguments
are logical, etc. :)

[1] http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17#xmonad_part1b_zipper
[1] http://www.paulgraham.com/noop.html

Re: Using the .NET Bridge to access MS Office applications

Re: Pipe syntax and the current methods

On 8/30/07, Igor Stasenko <siguctua <at> gmail.com> wrote:
> On 30/08/2007, Yoshiki Ohshima <yoshiki <at> squeakland.org> 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.

Re: pipe and system building

Ok, this is getting worse then election year in the states.  The sheer
volume of controversial, incorrect and downright nonsensical comments
made in this thread is just out of control.

On 8/28/07, Fabio Filasieno <fabio.filasieno <at> gmail.com> wrote:
>
> There is a high risk of developing
> functions that you don't need. This is on of the main critics OOP.

Oh?  I did a quick google search and I did see a lot of complaints,
though none of them were "developing functions that you don't need".
How do you determine this is one of the main criticisms?  A link
please.

> When I was a bit younger I often made this mistake:
>
> Lets a make a nice apple object. The nice apple must have the `eat` method
> of course. An apple that cannot be eaten is rally a terrible apple, is it?
> So let's invest some time in our apple `eat` method. But here is the mistake
> ...
> you are writing code to make pies. You will never eat the apple directly.
> You have just spent brain and time budget on something useless: the `eat`
> method on the apple object. I bet this is the main reason for code bloat in
> OOP and Smalltalk too.

Is no one else ever going to use your Apple class?  The core classes
in Smalltalk/Squeak are there to be general.  Not for one application.

> Now you can't tell me that  :
> data select: ... | map: ... | collect: ...
> this NOT understandable.... it's only a bit verbose... but since it's
> functional it's CLEAR

Since it's functional style it's clear?  Based on what?  Because *you* know it?

> Give it time. Functional programming has this amazing property that you can
> easily reason about problems, especially when side-effect free.

Given your statements on this list I suspect I am much more well
versed in functional programming then you are.

> I want that in Smalltalk.
> I can't do it with parenthesis. It disturbs me. I have to break my thoughts.
> I need the pipe.

So add it.  If anyone else has your problem they may use it too.

> And I'm sure that any functional programmer (from ocaml, erlang , haskell,
> ... ) would understand what I'm talking about.

I use all those languages and I understand function composition.  But
the problem is you vastly overstate the "pipe" operator.  If it's so
important to functional programming why is it not even present in:
Ocaml [1] (or any ML for that matter), Erlang, Lisp.... actually, come
to think of it the only two places I know of that have such an
operator is certain Unix shells and Haskell.

The fact is it doesn't even play such a large role in Haskell.  The
function composition operator (the period) is much much more
important.

[1] http://caml.inria.fr/mantis/view.php?id=2415

Re: pipe and system building

On 8/29/07, Fabio Filasieno <fabio.filasieno <at> gmail.com> wrote:
>
> From a first look at the collection libraries, it seems to me that there is
> a LOT of bloat. Really really a LOT.
> I bet that Ocaml's collections can do the same things with an order of
> magnitude of less of code.

http://en.wikipedia.org/wiki/Order_of_magnitude

That's quite a bold statement, though at least this time it was
grounded with "I bet".

> and by the way the counter arguments
> were a bit mild or close to non-existent.

....  So "I disagreed with/didn't understand" is the same as "a bit
mild or close to non-existent"?

Re: pipe and system building

On 8/30/07, Fabio Filasieno <fabio.filasieno <at> gmail.com> wrote:
>
> I'll show the most evident thing
>
> add: newObject after: oldObject
>         "Add the argument, newObject, as an element of the receiver. Put it in
>         the sequence just succeeding oldObject. Answer newObject."
>
>         | index |
>         index _ self find: oldObject.
>         self insert: newObject before: index + 1.
>         ^newObject
>
> Why ? Why there is a NEED for this ? to save me 2 lines of code ?
>
> I would dump it.

This is your most obvious example?  And you're not worried about 2
lines of code but you are concerned about 1 character?  This is a
pretty handy and clear operator and allows Smalltalk to read more like
English.

> If the user needs to do that he could write: find then insert. is it ?

And what would this code look like exactly?  Not C++'s awful iterators I hope.

> This is an example of bloat !

Opinion.

> A functional programmer (LISP) don't even have the stack data
> structure. They use a list. As they are very very concerned of bloat.

?????  Surely you must mean Scheme here.  Common Lisp is the most
bloated unorganized pile of odd and inconsistently named functions I
have ever seen.  Powerful, but concerned of bloat?  Obviously not.

> In OrderedCollection I would dump:
> addLast: (make Add be addLast)

They are the same in the places it makes sense.  But it doesn't
always, hence the two separate methods.

> Don't you think that this numbers shout at you `I'm bloat !`
> 50% overhead => the method is not doing anything (declaration and
> return) and inlining would remove this overhead .
> 50% just 2 calls to self...

Small methods *are* Smalltalk.  What exactly of Smalltalk do you
actually like?  The environment?  Are you sure you don't just want
Haskell/Ocaml/whatever in a Smalltalk-like IDE?  Perhaps you should
check out the Lisp+Slime combination.

> In Ocaml there is simply no bloat. Just open their doc. count the
> methods. There are very few.

Which means everytime I want to do certain things I have to write
specialized methods for it.  In Smalltalk most of these have been done
in the image already.  In most any language I know besides Smalltalk I
always have a "utilities" library I build up from all these methods I
would otherwise have to keep redefining.

> LISP is even more terse.

Not sure which Lisp you mean here but:

http://www.ffconsultancy.com/languages/ray_tracer/verbosity.html

The reason Lisps tend to be terse is because of Macros, but I'm kind
of confused how this applies to your point that the libraries should
have few methods.  Common lisp probably has more methods for
collections then Smalltalk, and with odd names.

For example, filtering a collection:  select:/reject: (Smalltalk),
filter (Haskell, Ocaml, Python, etc.), remove-if-not (Common Lisp)

> Then there is the following, which is a bit more subjective.
>
> I don't care of traits.
> I don't care of inheritance, the less the better. It confuses me.

I really don't see what it *is* that you like of Smalltalk besides
perhaps the IDE and the debugger.

Re: pipe

Jason Johnson schrieb:
>
> And also, instead of calling it the very confusing "pipes" I think we
> should call it then "then" operator. That is, it clearly says "do
> this to completion, *then* do this".

I agree.  I would expect a "pipe" to work like a FIFO queue, like
Unix-pipes do.

But    aCollection select: [...] ;;  collect: [...]    
 or     ( aCollection select: [...] ) collect: [...]   
is not a queue; so  "then"-Operator might be a better name .

- Winfried

Re: Using the .NET Bridge to access MS Office applications

Hello,

We used bridge to call functions of com sever dll from squeak. We
succeeded only when calling very  "simple" functions. We failed to get
non ASCII characters, decimals when decimal separator  in windows is
not dot. Bridge can operate in two modes: sockets or direct. Direct
mode IMO have problems with releasing windows resources. We saw
growth of used handles with every call in  Process Explorer from
Sysinternals. We had "hangings" when tried to call SOAP method that in
turn calls .Net method, but solved this problem.

 Vaidotas