31 comments

[ 5.2 ms ] story [ 96.3 ms ] thread
I love how no one is getting zealotous about this :)
So now to get really deep/meta, you'll want to combine with promisify:

    var isTrue = require('callbaxx').isTrue;
    var promisify = require('promisify');
    var promIsTrue = promisify(isTrue);
    
    promIsTrue(true)
      .then(function (res) {
        console.log(res)
      });
      .catch(function (err) {
        console.log(err)
      });
Hi! That's definitely an interesting experiment, but it's rather antithetical to the project.

In fact, it might even be broken by future versions of the library.

See issue #7 [1] for a look at why this might not be a good idea.

Thanks anyway!

1. https://github.com/scf4/callbaxx/issues/7

@jtokoph, maybe this can be put in the examples for the `callbaxx-promise` library that will be surely be created after.
We must go deeper!

  const promisify = require('bluebird').promisify
  const from = require('rxjs').from
  const isTrue = require('callbaxx').isTrue

  const isTrueAsync = promisify(isTrue)
  const makeIsTrueSource = val => from(isTrueAsync(val))

  const source = makeIsTrueSource(true)

  source.subscribe(console.log, console.error)
A few more abstractions and it will meet enterprise compliance. Probably need to write it as a Class ...
Given some of the JS code I've seen recently, I honestly thought this was a serious library until I saw this:

> Proponents of this new language (known as "sixers")

Typical arrogant sixer :)
It took me until the actual API docs.
The satire might be inspired by a very real lib 'Callbag" from the creator of Cycle.js https://github.com/staltz/callbag-basics
I think they're unrelated. This seems to be a protest repo against JavaScript's churn.
Ohhhh I've been had. That'll teach me to RTFM.
When I think of ES6 I think of this statement:

“Appreciation of beauty is taste and the creation of beauty is art.”

ES6 is lacking in all forms of taste and art is never the product of design by committee.

For me the best part is the examples: https://github.com/scf4/callbaxx/tree/master/examples

Also, someday I think we need to launch an API (REST or Graph) to do some basic operations as API calls. So you don't even need a whole language, just lots of fetchs.

That's a fantastic idea.

What about a babel plugin to transform all code into fetches to a proprietary REST API? By doing all of the work for them, we'd ensure reliability with common operations like + and /, which obviously means we eliminate the need for tests! This would allow devs to move and break things even faster, while we/I collect $10–$20 per 10,000 API calls.

E.g.,

  // Regular code
  console.log(3 + 2);

  // Transpiled code
  console.log(await fetch('http://fetchify.io/add/3/2'));

  // Regular code

  const isFive = (x === 5);

  // Transpiled code
  const isFive = await fetch(`http://fetchify.io/equality/strict/${x}/5`)
    .then(body => body.text());
Some of this is almost too easy to understand though, therefore it's pretty amateurish and we're not doing proper programming. What about something like:

  // Regular code
  const thirty = 5 * 6;

  // Transpiled code
  let $$_tmp1;
  const thirty = (
    $$_tmp1 = await fetch(`http://fetchify.io/multiply/5/6`),
    $$_tmp1 = await $$_tmp1.text(),
    $$_tmp1 = parseInt($$_tmp1, 10), $$_tmp1
  );
Even some seasoned developers aren't aware of this syntax, so it's perfect.
I hate how convincing this is. It makes me rethink my optimism on new libraries...
Writing callbacks is much more fun if you make use of closures and named functions.
I was going to say this must be inspired by bored Haskellers
But what's the point of writing callbacks if you're not going to endlessly nest them?

E.g., I can tell the nested math example[1] is good code because of how deeply indented it becomes.

1. https://github.com/scf4/callbaxx/blob/master/examples/nested...

Ignoring that the code doesn't handle any errors, there's really nothing wrong with nesting, as you can clearly see the code flow and understand what it does. The example (1) would look much better using Promise's as it's a chain of events. But imagine a horizontally scaled distributed system where each math operation run's on a load balanced cluster, you would need code to handle back-pressure, retry when errors occur, etc.

Here's how FizzBuzz might look like:

  function fizzBuzzLogic(nr, multipleOfThree, multipleOfFive) {
    var print = console.log;
    if(multipleOfThree && multipleOfFive) print("nr=" + nr + " FizzBuzz");
    else if(multipleOfThree) print("nr=" + nr + " Fizz");
    else if(multipleOfFive) print("nr=" + nr + " Buzz");
    else print("nr=" + nr);
  }

  function fizzbuzz(cb) {
    var modulo = require("modulo");
    var errors = [];
    var maxErrors = 3;
    var maxConcurrency = 5;
    var inProgress  = 0;
    var fizzBuzzCounter = 1;

    next();
    
    function next() {
      while(cb && inProgress < maxConcurrency && fizzBuzzCounter < 100) run(++fizzBuzzCounter);
    }
    
    function run(nr) {
      console.log("run: nr=" + nr);
      var multipleOfThree = undefined;
      var multipleOfFive = undefined;
      
      moduloTest(3);
      moduloTest(5);
      
      function moduloTest(multipleOf) {
        inProgress++;
        modulo(nr, multipleOf, moduloResult);
        
        function moduloResult(err, moduloNr) {
          inProgress--;
          if(err) {
            errors.push(err);
            if(errors.length >= maxErrors) {
              if(cb) cb(errors.join("\n"));
              cb = null;
            }
            else if(cb) moduloTest(multipleOf);
          }
          else {
            
            if(multipleOf==3) multipleOfThree = (moduloNr==0);
            if(multipleOf==5) multipleOfFive = (moduloNr==0);
            
            if(multipleOfThree != undefined && multipleOfFive != undefined) {
              fizzBuzzLogic(nr, multipleOfThree, multipleOfFive);
              next();
            }
          }
        }
      }
    }
  }
I haven't polished or run the code, it for example doesn't call the cb (which is a common error in callback based code), but you get the idea. As an exercise you could rewrite it using async *function or using Promises, but I believe the benefit of Promises wouldn't be as apparent.