Am 30.06.2011 um 21:03 schrieb Janko Mivšek:
>
>
> S, Norbert Hartl piše:
>>
>> Am 30.06.2011 um 17:53 schrieb Janko Mivšek:
>>
>>> S, Norbert Hartl piše:
>>>
>>>> Am 30.06.2011 um 17:23 schrieb Stéphane Ducasse:
>>>
>>>>>>> apparently people get excited by nodeJS and I would like to know the
>>>>>>> equivalence of
>>>
>>>>>> What does it mean?
>>>
>>>>> in Pharo.. how do you have the same:
>>>
>>>> It depends what is in your head when you wrote this. The code snippet
>>>> doesn't tell that much. Registering a Block for execution on request is
>>>> probably not what makes you excited about. What is exciting about it is
>>>> that javascript is written in a strictly asynchronous manner (event
>>>> driven) and that matches perfectly the implementation with asynchronous
>>>> I/O. Suddenly you can write programs they way you ever wanted it. And
>>>> lucky for us smalltalk itself is event driven so it can go there easily,
>>>> too. Well, easily would mean to have support for asynchronous I/O in the
>>>> vm (file operations) and in the socket plugin at least.
>>>
>>> Because I'm just working on asynchronous no-blocking node.js like
>>> control flow in Aida, I can say that this is really natural to Smalltalk
>>> with its closures, much more than so called callbacks in JavaScript. In
>>> Smalltalk it is more readable and you hardly notice the difference to
>>> the normal Smalltalk code, while in JavaScript those callbacks are a bit
>>> hard to grasp and understand. From non seasoned programmer perspective,
>>> that is.
>>>
>> Can you elaborate on this? I agree that one of the biggest flaws in
>> javascript is that you have to write function() {} to use a closure which
>> prevents its usage in a lot of cases, e.g. in filter functions etc. It is
>> just ugly and nobody likes it. The second point is that you need to preserve
>> this in javascript manually if you wish to use it in closures.
>> Apart from that I can see a single difference between the two. Callbacks are
>> natural to javascript because most usage pattern use it. Closures are
>> natural to smalltalk because it just needs [ ] and it is well used
>> throughout the class library.
>
> Let me show an example by Ryan Dahl, author of node.js. First in
> JavaScript then how it will look in Smalltalk.
>
> Synchronous blocking database call:
>
> var result = db.query("select..");
> // wait
> // use result
>
> Asynchronous non-blocking database call:
>
> db.query("select..", function (result) {// use result });
> // continue
>
> In first case program execution is blocked until database returns
> result. In second case we register a callback function to deal with the
> result. This function will be called later when result arrives, while we
> don't wait but continue with execution.
>
> If you'll do in Smalltalk a blocking call:
>
> result := db query: 'select..'.
> result useIt
>
> A non-blocking call can look something like:
>
> db query: 'select..' thenDo: [:result | result useIt ]
>
> As you see with our closures we can much more naturally and
> understandably write such calls.
>
Ok, I don't think we need to argue that smalltalks syntax has great potential.
But to be honest
> db query: 'select..' thenDo: [:result | result useIt ]
doesn't feel natural to me from a smalltalk point of view. More natural appears
database select: [:each| each....]
So not having to use javascript syntax might be an advantage. It would be great
if you would omit the SQL as well ;)
If we talk about asynchronous programming I'm more concerned about
composability and control of asynchronous operations then to have a nice syntax
for a really simple case.
Norbert
