Live data from Hacker News

Kal – a clean JavaScript alternative without callbacks

rzimmerman.github.io

91–100 of 130 posts

Re: Kal – a clean JavaScript alternative without callbacks

#91
post #89
post #86

Earlier quoted context omitted.

I think you have it wrong, generators would solve the problem. If you have asynchronous code N call layers down, then everything above it would be asynchronous as well. So you would only need to yield the first call. Check how Q.nfcall works.

That's a faulty assertion. A generators working principle is that it can resume into the closure if the "caller" is looping over the generator. Let's assume a simple call stack, A -> B -> C. Now C would be a generator, so B has to loop over C instead of just calling C. But what about A? Well if B is now looping, and if yielding out of a loop is how you cooperatively multitask, then A now has to loop over B. So you ha…

I am not sure if I followed entirely.

But let me give you an example, again with Q.nfcall.

    MultiplyAndSquare = (a, b, cb) ->
        Multiply a, b, (err, product) ->
            Square product, (err, square) ->
                cb null, square #ignore errors for now.
    
    nonCallbackVersion = (a, b) -> Q.nfcall(MultiplyAndSquare, a, b)
    
    result = yield nonCallbackVersion(10, 20)

Re: Kal – a clean JavaScript alternative without callbacks

#92

It's remarkable how similar this code looks to the monadic way of doing it. For this Kal code... task getUserFriends(userName) wait for user from db.users.findOne {name:userName} wait for friends from db.friends.find {userId:user.id} if user.type is 'power user' for parallel friend in friends wait for friendsOfFriend from db.friends.find friend for newFriend in friendsOfFriend friends.push newFriend unless newFriend…

I quit engaging at shoprite and currently I build $35h - $80h...how? i am operating online! My work did not precisely build Pine Tree State happy therefore i made a decision to require an opportunity on one thing new… when four years it absolutely was therefore onerous to quit my day job however currently i could not be happier. Heres what I do, www.jobs34.ℂom

Re: Kal – a clean JavaScript alternative without callbacks

#95
post #81

So instead of encouraging you to actually fix the bad nested callback code, you can dress it over with fancy syntax. Well done on making a whole language though. It's pretty challenging and I hope you do well. Aside: This seems very similar to narrativeJS in concept http://www.neilmix.com/narrativejs/doc/

What do you mean by "actually fix?"

Stop nesting anonymous functions. Un-nest them, name them, and encapsulate the process in a monad.

Re: Kal – a clean JavaScript alternative without callbacks

#96
post #19

Excellent work. Especially useful since it appears to throw exceptions. That means it's a step up from Iced Coffeescript. The syntax is a little verbose and might be shortened to something like C#: `user = await db.users.findOne {name:userName}`. Would be a lot more clear to me.

As far as I can tell from reading the readme, it does NOT support throwing exceptions from within callbacks. Because, of course, there's no way to technically do that in anything that is JavaScript at its core -- at least as far as I'm aware of. Correct me if I'm wrong? It says "This includes error handling via callbacks." -- not error handling via exceptions. Elsewhere it says "Any errors reported by fs.readFile (re…

You can do it using monadic augmentation. Or aspect oriented programming.

In plain english, make a function that takes two functions makeADoThingFunctionThatHandlesErrors(doThing, handleError)

and returns a new version of the function that is internally wrapped in a try catch block with the handleError function getting called from the "catch" block. This is relatively straightforward to accomplish using closures/high order functions. This is one utility function you write once.

Finally you can do this with a whole "monadic" api such as jquery- create a function that loops through all the methods on an object prototype and wraps them in an error handler, returns a new version of the prototype you can inherit from.

Or instead of doing all that, you just use some library with promises (such as Q, or jQuery) that implements all the above, and all you need to do is write a single error handler function, and any error that gets thrown by any function in a promise chain gets caught and sent to that function.

Re: Kal – a clean JavaScript alternative without callbacks

#97
post #7

The title is kinda funny to the russian ear because kal means feces in Russian :)

Well, even worse is the Portuguese name Rui.

I was once told it also sounds like something bad in Russian, so it can be a bit inconvenient introducing anyone with such name in Russian if not aware of this issue.

Re: Kal – a clean JavaScript alternative without callbacks

#98
(Don't mean to divert this thread from Kal, but this is on the topic of "callbacks are bad" etc.)

For some time now, I've been accumulating async patterns I've needed when writing JS code in my monadic IO.js library[1]. The aim of IO.js is to provide higher levels of thinking about sequences of actions without worrying about whether they are async, and with a rich set of error management tools (for ex, exceptions are turned into recoverable conditions in IO.js).

The crux of the "callback hell" problem is, contrary to what many have claimed, is not the nesting that results when the callbacks need to be called in temporal order. That much is straightforward to deal with. The "hell" rears its head when you need to coordinate multiple such sequences that are running concurrently. The composable actions you get from a monadic treatment combined with CSP-style channels, are an expressive framework to build abstractions on (tldr - Haskell's implementation is awesome!).

For illustration, the framework in IO.js is flexible enough to implement a node.js web server that can express PG's "Arc challenge" concisely (though that challenge is practically obsolete). Take a look at [2].

For a simpler example, `IO.trace` is a straight forward way to generate a trace dump to console of a sequence of asynchronous actions. You don't need to "enable trace" for an entire app. You can choose to trace only a particular sequence. This is pretty neat when debugging. Stack traces are useless when dealing with async processes anyway.

[1]: https://github.com/srikumarks/IO.js [2]: https://github.com/srikumarks/IO.js/blob/master/examples/arc...

Re: Kal – a clean JavaScript alternative without callbacks

#99
post #33

Earlier quoted context omitted.

Thanks for the feedback. It seems like a lot of people would prefer a more normal looking assignment. If you get a chance (and use TextMate or Sublime Text), please give syntax highlighting a try ( https://github.com/rzimmerman/kal.tmbundle )!

Unfortunately I don't use those editors — maybe you can write a Vim highlighter next? Might also be worth adding syntax highlighting to the website (even if you have to do it manually for now), if you're set on the current syntax and think highlighting will make that much of a difference.

Have you tried converting it in: http://coloration.ku1ik.com

Re: Kal – a clean JavaScript alternative without callbacks

#100
post #65
post #63

ToffeeScript is very similar but better. https://github.com/jiangmiao/toffee-script

This comment would be much more insightful if you put forth your argument as to why it is better.

Sorry I was in a hurry. It has many more features for a sync that looks like sync and for other things. It has a cleaner syntax. It supports easy access to multiple callback return values. It has all of the other CoffeeScript features. It seems very obvious if you look at ToffeeScript that it is objectively better. I find it difficult to believe that it isn't getting more attention. Probably just because it doesn't have a web site.
Post reply on HN