> On Aug 7, 11:30 pm, Isaac Schlueter <i...@izs.me> wrote:
> > On Sun, Aug 7, 2011 at 06:28, Bruno Jouhier <bjouh...@gmail.com> wrote:
> > > Again, you speak about things without looking at them.

> > > The *non-fibers callback version* of this DOES EXIST.

> > > Streamline.js has nothing to do with fibers. It is a preprocessor that
> > > generates vanilla Javascript with callbacks. If you look at the
> > > transformed file (https://github.com/Sage/streamlinejs/blob/master/
> > > lib/
> > > streams/server/streams.js), you will see that this is a PURE CALLBACK
> > > implementation of this API, which does not have any strings attached
> > > to it: no node C++ extension, not even a JS helper module -- it only
> > > 'requires' modules from node core!

> > So, your claim is that the streamline code is better than the callback
> > version generated by streamline?  That's not terribly impressive.
> > There are already lots of tools that can turn JavaScript into less
> > readable JavaScript.

> In this particular instance, 90% of the source is actually written in
> callback-style and is not transformed at all. This module is not at
> all a typical streamline module. It does not deal with business logic.
> It deals with a low level technical problem:  transforming event-style
> code into callback-style. I'm just using streamline in one or two
> methods because this was handy. I could have as well written all of it
> in callback-style. Maybe I'll do it some day to make it a bit more
> efficient.

> > > I can provide hundreds of code fragments that demonstrate the
> > > difference in usability. I just need a bit of time to format them
> > > properly.

> > Not looking for fragments.  Looking for the effect on a small,
> > finished, well-understood program.  Otherwise, this is all just make
> > believe.

> > Is recursive directory removal too hard to do with fibers or
> > streamline or coroutines?

> Well, this is a technical problem (dealing with retries and all that
> stuff). Typically the kind of thing that I might still write in
> callback-style (or rather let you write for me!).

> I'd rather go with small typical samples of business logic. Because
> then I can explain what I mean by "easy to read and easy to
> maintain" (as you'll see, the maintenance issue takes a very different
> form than in the technical layers). As I said earlier, there is no
> "one size fits all" and I did not pretend that streamline or fibers
> were the right tools for what you are writing (I said the opposite).

> The best format to explain this is probably as a blog post and it is
> going to take me some time to do so (especially as my week-ends are
> currently very loaded with lots of down to earth duties). So please be
> a bit patient.

> Time to quit, if you don't mind.

> Bruno

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en