Naming conventions and terminologies

[aberba]

So i decided to take a look at iopipe again and I think I remember why I've never tried it.

1) Its uses synonymous terms like sink, chains, source etc which are technically correct by unfamiliar. Chain for instance I believe is more like a pipeline() cus you used that term whilst talking about it.

stream.pipe(transform()).pipe(outputStream)

Or say pipeline(one(), two(), three (), writeln())

The above api name pipeline(), pipe() looks more obvious being familiar with the Nodejs stream api design. Widely used for even less tech-savvy use cases. Its a great reference.

2) use of abbreviations for api names doesn't make code readable without having to read the docs. Its obvious if you're familiar with the focs but doesn't make a great first impression... example openDev, bufd, ...

3) Showing every soffisticated feature its has got also overwhelms first time users. I guess it'll appear normal to people very familiar with that domain but didn't make a good impression on me. Feels being bombarded with too many options all at once. The D docs tend to have this same problem showing every language feature due to the people who write them.

[schveiguy]

Thanks for the feedback.

Regarding the naming -- "chain" is really only used as internal members (though I think I do mention chain in the docs a lot). I was lazy and did not mark most of these private, though they should be. But pipeline could be a good substitute (and makes sense). I can look into changing this because it's an internal name otherwise.

Regarding using a global function to set up the pipeline, I don't think this is as clean or as intuitive. My inspiration is really the unix command line, where you use the | character to pipe things from one tool to the next. The way iopipe works is to have the next segment "wrap" the previous segments. Your suggested usage implies a wrapper type which has all the pipeline members as individual processors (incidentally, a very early version that I got working but hated did things this way).

Regarding abbreviations -- I wanted something easy and fast to type for very commonly used things. Creating a buffered pipe from a stream is a critical building block. bufd instead of buffered to me is a good improvement, and not difficult to remember. In most cases, I did not use abbreviations (e.g. assumeText). We'll have to agree to disagree on this. openDev is deprecated anyway, you should be using std.io.

Regarding the demo, are you referring to the front page code? I will take a look. iopipe is set up to be simple but straightforward components you glue together, and as such, the chains are not going to be always short. But the nice thing is that the code itself is simple and useful, and it's the combination of them that can create some really interesting pipelines.

I can probably alter the demo to show successive changes that will add on more features.

[aberba]

Yeah, updating the demo will be nice.

But still, bufd() is not immediately obvious. Sometimes you have to choose between easy of use and short words which is a non issues these days...and short abbreviations are phasing out in most code based except for real world abbreviared words.

Most Phobos functions are not but you just know what they do immediately you see it. Its said that we read more code that we write. Which is been proven to be true. Also almost every text editor has autocompletion.

I should also say I'm very glad you're working on iopipe. I've been reading some of the threads and impressed with how you continue to push it to be very performant.