little challenge for sven and us

> var http = require('http');
> http.createServer(function (req, res) {
>  res.writeHead(200, {'Content-Type': 'text/plain'});
>  res .end('Hello World\n');
> }).listen(1337, "127.0.0.1");
>
> console.log('Server running at http://127.0.0.1:1337/');
> To run the server, put the code into a file example.js and execute it with the node program:
>
> % node example.js
> Server running at http://127.0.0.1:1337/
>
>
> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>
> var net = require('net');
> var server = net.createServer(function (socket) {
>  socket.write("Echo server\r\n");
>  socket.pipe(socket);
> });
>
> server.listen(1337, "127.0.0.1");
>
>
> we should communicate better :)
>
> Stef

>> var http = require('http');
>> http.createServer(function (req, res) {
>> res.writeHead(200, {'Content-Type': 'text/plain'});
>> res .end('Hello World\n');
>> }).listen(1337, "127.0.0.1");
>>
>> console.log('Server running at http://127.0.0.1:1337/');
>> To run the server, put the code into a file example.js and execute it with the node program:
>>
>> % node example.js
>> Server running at http://127.0.0.1:1337/
>>
>>
>> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>>
>> var net = require('net');
>> var server = net.createServer(function (socket) {
>> socket.write("Echo server\r\n");
>> socket.pipe(socket);
>> });
>>
>> server.listen(1337, "127.0.0.1");
>>
>>
>> we should communicate better :)
>>
>> Stef
>
>

> Hi guys
>
> apparently people get excited by nodeJS and I would like to know the equivalence of
>
> var http = require('http');
> http.createServer(function (req, res) {
>  res.writeHead(200, {'Content-Type': 'text/plain'});
>  res .end('Hello World\n');
> }).listen(1337, "127.0.0.1");
>
> console.log('Server running at http://127.0.0.1:1337/');
> To run the server, put the code into a file example.js and execute it with the node program:
>
> % node example.js
> Server running at http://127.0.0.1:1337/
>
>
> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>
> var net = require('net');
> var server = net.createServer(function (socket) {
>  socket.write("Echo server\r\n");
>  socket.pipe(socket);
> });
>
> server.listen(1337, "127.0.0.1");
>
>
> we should communicate better :)
>
> Stef

>
>>> var http = require('http');
>>> http.createServer(function (req, res) {
>>> res.writeHead(200, {'Content-Type': 'text/plain'});
>>> res .end('Hello World\n');
>>> }).listen(1337, "127.0.0.1");
>>>
>>> console.log('Server running at http://127.0.0.1:1337/');
>>> To run the server, put the code into a file example.js and execute it with the node program:
>>>
>>> % node example.js
>>> Server running at http://127.0.0.1:1337/
>>>
>>>
>>> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>>>
>>> var net = require('net');
>>> var server = net.createServer(function (socket) {
>>> socket.write("Echo server\r\n");
>>> socket.pipe(socket);
>>> });
>>>
>>> server.listen(1337, "127.0.0.1");
>>>
>>>
>>> we should communicate better :)
>>>
>>> Stef
>>
>>
>
>

> 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.
>

>
> 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.

>
>
> 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.
>

>
> The second example is too simple to be useful, but this would be the Zn equivalent:
>
>
> (ZnServer defaultOn: 1337)
> logToTranscript;
> delegate: (ZnValueDelegate with: [ :request |
> ZnResponse ok: (ZnEntity text: 'Hello World!') ]);
> start.
>
> ZnClient get: '<a href="http://localhost:1337'">http://localhost:1337'.
>
> (ZnServer defaultOn: 1337)
> logToTranscript;
> delegate: (ZnValueDelegate with: [ :request |
> ZnResponse ok: (ZnEntity with: request contents) ]);
> start.
>
> ZnClient post: '<a href="http://localhost:1337'">http://localhost:1337' data: (ZnEntity text: 'Echo').
>
> ZnServer stopDefault.
>
>
> Smalltalk is a beautiful language, isn't it ?
>
> Sven
>
> PS: the delegate object has to respond to #handleRequest:. In earlier versions, it was a block, now ZnValueDelegate translates #handleRequest: to #value:. I thought that was clearer. For publicity reasons, maybe I could add a #delegateBlock: convencience accessor.
>
>
> On 30 Jun 2011, at 17:07, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> apparently people get excited by nodeJS and I would like to know the equivalence of
>>
>> var http = require('http');
>> http.createServer(function (req, res) {
>> res.writeHead(200, {'Content-Type': 'text/plain'});
>> res .end('Hello World\n');
>> }).listen(1337, "127.0.0.1");
>>
>> console.log('Server running at http://127.0.0.1:1337/');
>> To run the server, put the code into a file example.js and execute it with the node program:
>>
>> % node example.js
>> Server running at http://127.0.0.1:1337/
>>
>>
>> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>>
>> var net = require('net');
>> var server = net.createServer(function (socket) {
>> socket.write("Echo server\r\n");
>> socket.pipe(socket);
>> });
>>
>> server.listen(1337, "127.0.0.1");
>>
>>
>> we should communicate better :)
>>
>> Stef
>
>

>
>
> 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.
>

> Hi Stef,
>
> I don't think that the buzz around NodeJS comes from these samples of code. Yes, it's very easy to starting a project with NodeJS but the interest from NodeJS is that this server extends the usages of Javascript wich becomes an language useable on many platform, many OS for many usages. With Javascript, programmers can write client code in browsers, widgets for desktop computers, shell scripts with Rhino, mobile applications for Android or IOS, ... and now, programmers can write server code for web applications and web services.
>
> My two cents
>
> Olivier ;-)
> www.auverlot.fr
>> Hi guys
>>
>> apparently people get excited by nodeJS and I would like to know the equivalence of
>>
>> var http = require('http');
>> http.createServer(function (req, res) {
>>   res.writeHead(200, {'Content-Type': 'text/plain'});
>>   res .end('Hello World\n');
>> }).listen(1337, "127.0.0.1");
>>
>> console.log('Server running at
>> http://127.0.0.1:1337/
>> ');
>> To run the server, put the code into a file example.js and execute it with the node program:
>>
>> % node example.js
>> Server running at
>> http://127.0.0.1:1337/
>>
>>
>>
>> Here is an example of a simple TCP server which listens on port 1337 and echoes whatever you send it:
>>
>> var net = require('net');
>> var server = net.createServer(function (socket) {
>>   socket.write("Echo server\r\n");
>>   socket.pipe(socket);
>> });
>>
>> server.listen(1337, "127.0.0.1");
>>
>>
>> we should communicate better :)
>>
>> Stef
>>
>
>

>> Indeed. Actually the recent JS popular libraries coding style reminds
>> me more and more smalltalk.
>> Looks like they are inventing new wheel, going long road from creepy C
>> syntax and C programming style
>> to smalltalk.
>
>
> The problem igor is that they will get there and fast because the world is faster.
> Microsoft is creating a new lab at Zurich for example. And our nice little community
> did not move since at least one decade.
> Sometimes I'm immensely sad to see for example that while julian is working for cincom
> he does not lead an effort to bring Seaside to the next level. Company vision are puzzling me.
>

> On 1 July 2011 07:32, Stéphane Ducasse <[hidden email]> wrote:
>>> Indeed. Actually the recent JS popular libraries coding style reminds
>>> me more and more smalltalk.
>>> Looks like they are inventing new wheel, going long road from creepy C
>>> syntax and C programming style
>>> to smalltalk.
>>
>>
>> The problem igor is that they will get there and fast because the world is faster.
>> Microsoft is creating a new lab at Zurich for example. And our nice little community
>> did not move since at least one decade.
>> Sometimes I'm immensely sad to see for example that while julian is working for cincom
>> he does not lead an effort to bring Seaside to the next level. Company vision are puzzling me.
>>
>
> To get to the next level, first you have to define what is next level.
> For me , i don't see what is the next level for web application
> framework like seaside. Do you?