How I want to write Node: Stream all the things
51–60 of 118 posts
Re: How I want to write Node: Stream all the things
#52Forgive me for being "That Guy" but I really think Javascript is ill-suited for this paradigm! Streams, honestly, are hard to keep straight when the program gets big without a stronger type system. IMHO. Some really sharp people have been working on stream computing software in Haskell for a while - Gabriel's Pipes package is a good example of generalized stream computing with strong equational reasoning as its found…
Node follows the unix way. Everything is a stream. It's just Buffers and JS objects flying around. It's really stupid, and sometimes it's nasty. This isn't helped by Javascript's warts.
But there's an enormous upside to this: following the stupid Unix way means that no matter what you need to do with your data, there's an npm module for it. Just .pipe() your stream in and your code is done. This is amazing. And it's possible only because of how bare-bones and loose the Buffer stream API is.
Strong typing has its place, but it would ruin node's biggest selling point. It's hard to realize this without trying it.
Re: How I want to write Node: Stream all the things
#53Earlier quoted context omitted.
var Promise = require('bluebird'); var fs = Promise.promisifyAll(require('fs')); Promise.spawn(function* () { var data = yield fs.readFileAsync(somefile); }); Documentation: https://github.com/petkaantonov/bluebird/blob/master/API.md My favorite example is doing a diff using an async diff service which provides a function `svc.diff(string1, string2)`. But also imagine that you need to preprocesses the files using the…
- Why BlueBird? What's wrong with Q? - Isn't data a scope down? - https://github.com/petkaantonov/bluebird/blob/master/API.md is API based, not task based. async is API based too, but the API has names like 'waterfall' and 'parallel'. I can click them because I know what they mean. Promises just makes me feel like I'm reading about and endless series of abstractions.
Promises can be used as flow control, but more importantly, it's an object that encapsulates asynchronous mechanics.
I like to see how async can launch an asynchronous operation, then allow listeners to be attached later to capture the result. Now, you may say that if you want to attach listeners to capture result, you'll want to use event emitters. True, but event emitters has its own problem because event emitting and attach listeners are synchronous. What if the event was emitted before any body has a chance to attach listener to it?
Promises does not have these issues.
Re: How I want to write Node: Stream all the things
#54Earlier quoted context omitted.
Whereas with _.map, you always know exactly which implementation you're getting, right? :)
Actually, you do. You've loaded it, and you can lock it down privately to your library or app with _.noConflict(). You can have ten different versions of Underscore loaded on the page, living in peace and harmony, in ten different third-party modules. Not that you should. But that you could.
But to be perfectly fair, you are 100% correct: this is not a technical complaint and perhaps this entire sub-thread is, as has been claimed, "bike-shedding." Since this lib is designed to be loaded via an AMD-style mechanism, users can call it whatever they want, so _ is just as valid an identifier as any other. Except the obvious issue that readers of the code, examples, and any code that follows suit, will end up with this completely pointless ambiguity because _ is ultimately a meaningless name if it evolves to mean simply "some library I loaded." You may as well write sample code like:
var $ = require('http'); $.createServer(...);
I would think people would call that out as ridiculous and confusing.
Re: How I want to write Node: Stream all the things
#55Earlier quoted context omitted.
var Promise = require('bluebird'); var fs = Promise.promisifyAll(require('fs')); Promise.spawn(function* () { var data = yield fs.readFileAsync(somefile); }); Documentation: https://github.com/petkaantonov/bluebird/blob/master/API.md My favorite example is doing a diff using an async diff service which provides a function `svc.diff(string1, string2)`. But also imagine that you need to preprocesses the files using the…
- Why BlueBird? What's wrong with Q? - Isn't data a scope down? - https://github.com/petkaantonov/bluebird/blob/master/API.md is API based, not task based. async is API based too, but the API has names like 'waterfall' and 'parallel'. I can click them because I know what they mean. Promises just makes me feel like I'm reading about and endless series of abstractions.
In short, its API is nearly as extensive as Q's with essentially no overhead—bluebird is hardly more expensive than callbacks, while Q is something like 10x slower than using callbacks.
Re: How I want to write Node: Stream all the things
#56Forgive me for being "That Guy" but I really think Javascript is ill-suited for this paradigm! Streams, honestly, are hard to keep straight when the program gets big without a stronger type system. IMHO. Some really sharp people have been working on stream computing software in Haskell for a while - Gabriel's Pipes package is a good example of generalized stream computing with strong equational reasoning as its found…
Here's the main enlightenment of becoming a node.js guy: Node follows the unix way. Everything is a stream. It's just Buffers and JS objects flying around. It's really stupid, and sometimes it's nasty. This isn't helped by Javascript's warts. But there's an enormous upside to this: following the stupid Unix way means that no matter what you need to do with your data, there's an npm module for it. Just .pipe() your st…
Re: How I want to write Node: Stream all the things
#57- We have object.defineProperty() in ES5 to avoid enumeration.
- You can use user-specified prefixing to avoid future conflicts.
Eg:
{foo: 1, bar: 2}.hlPairs();
rather than: _.pairs({foo: 1, bar: 2});Re: How I want to write Node: Stream all the things
#58Earlier quoted context omitted.
Here's the main enlightenment of becoming a node.js guy: Node follows the unix way. Everything is a stream. It's just Buffers and JS objects flying around. It's really stupid, and sometimes it's nasty. This isn't helped by Javascript's warts. But there's an enormous upside to this: following the stupid Unix way means that no matter what you need to do with your data, there's an npm module for it. Just .pipe() your st…
Yes, and "the unix way" isn't just "everything's a stream", but rather "everything's a text stream." In that regard, node's version of "everything's a stream" is actually a half-step up in abstraction.
Re: How I want to write Node: Stream all the things
#59Earlier quoted context omitted.
Yes, and "the unix way" isn't just "everything's a stream", but rather "everything's a text stream." In that regard, node's version of "everything's a stream" is actually a half-step up in abstraction.
Isn't it more accurately a byte stream (I don't know, which is why I'm asking)?
Re: How I want to write Node: Stream all the things
#60Earlier quoted context omitted.
Here's the main enlightenment of becoming a node.js guy: Node follows the unix way. Everything is a stream. It's just Buffers and JS objects flying around. It's really stupid, and sometimes it's nasty. This isn't helped by Javascript's warts. But there's an enormous upside to this: following the stupid Unix way means that no matter what you need to do with your data, there's an npm module for it. Just .pipe() your st…
Yes, and "the unix way" isn't just "everything's a stream", but rather "everything's a text stream." In that regard, node's version of "everything's a stream" is actually a half-step up in abstraction.