rzimmerman

Thanks! I was wondering if someone would make that comparison. I saw async-await a little after I started working on this and felt it was good confirmation that this was actually a reasonable idea.

That's actually a side effect of uglify.js's beautify, I believe. I'm going to try to get rid of that in upcoming releases.

Thanks! I had not thought to make the comparison to Haskell and monads. That's pretty interesting.

A lot of people prefer symbols over keywords, and I think that's mainly a readability issue. I personally prefer more keywords with good syntax highlighting, so that's what I went with (and why I almost immediately made a .tmbundle).

Thanks for the comparison, I should probably add promise syntax to the landing page to cover more bases.

I think a useful case would be the trickier stuff where Kal really shines. For example, doing async stuff inside of loops, conditional calls (where some paths need async waits and others don't) and error handling. I also think the Kal syntax might appeal to people who are less experienced with JavaScript and it's more eclectic features.

The only way to re-bootstrap is to download a compiled (JS) release from npm, then use that to compile the .kal source in the git repository. Then you can use your newly compiled version of kal to recompile itself. This is how I create the npm releases.

It's not turtles all the way down, though. If you look way back, the 0.1ish releases of the compiler were written in CoffeeScript. I ported the compiler source over from CoffeeScript file by file as it matured and eventually got rid of the dependency entirely. Technically, you could start with the last release that was written in CoffeeScript and compile up to the current release.

I added syntax highlighting to the github landing page manually for now. Try the .tmbundle if your editor supports it. It's not full featured but it gets the colors going. I'm working on getting it into pygments.

It's admittedly a bit link-baity. The async structures in Kal do compile to callbacks in JS.

Definitely play with the exception handling. Latent bugs aside, asynchronous statements (wait fors) work in any crazy horrible nested combination of ifs, fors (parallel or series), and trys that you can think of. Take a look at the JS output with:

kal -o output.js -f beautify input.kal

to see the sausages being made. The http server demo is a good example (https://github.com/rzimmerman/kal/blob/master/examples/async...)

Thanks. I think the main issue with JS callback syntax is that it quickly becomes unmaintainable. Hopefully this fixes a lot of that by abstracting away the mechanics. I don't think there's something fundamentally wrong with the "relinquish control and wait for I/O" model, so I tried to make that explicit here.

Thanks! I wouldn't call it stable or production ready by any means, just as a disclaimer.

Woops good catch!

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)!

Thanks for the suggestion. The closest to a side by side is here (http://rzimmerman.github.io/kal/#asynchronous-wait), and also the table of operators in the readme (https://github.com/rzimmerman/kal/blob/master/README.md#oper...). Also the examples directory on the github repo.

Apologies if you saw these already. I'll add something like what you suggested, though.

Psh, this solves at least two issues. Don't forget the Boolean "but" operator...

That is really unfortunate...

I chose it because it in Hebrew it roughly means something like easy/simple/BASIC.

edit: More importantly, does that make you more or less likely to use it?

Q and ECMAScript 6 solve the callback issue, but I think people might like the built in async iterators and error handling.

It's not a fork of CoffeeScript (though there are a lot of similarities). I'd initially tried doing that but I really couldn't get things to work the way I wanted. Mostly, it's a pretty major rearchitecture to get coffee to parse a function block that way.

I think syntax highlighting helps a lot in this case, so try out the tmbundle in Sublime or TextMate (https://github.com/rzimmerman/kal.tmbundle) if you can.

This is a project I've been working on in my spare time for a while now and I've finally decided to throw it out there and get some feedback. Do you think the 'wait for' callback syntax is useful? What big features do you think are missing?

For some reason they have the following comment towards the bottom of the homepage:

<!-- MEOW -->

And the relevant XKCD:

http://xkcd.com/787/

I was wondering the same thing. If they're running on a quad core (or EC2 Large) the results could look pretty poor with a single node instance.

It's important to note that the studies show that the short term effects of sleep deprivation can reduce the symptoms of depression. The long term effects are the opposite and being chronically sleep deprived can aggravate and severely worsen someone who is suffering from depression.

The last US "test" was in 2008 to destroy a defunct spy satellite. Spy satellites have very low orbits (around 100km) and an overwhelming majority of the debris from that test reentered the atmosphere and burned up within weeks or months. Previous ASAT tests were done in the 80s and were also all at low altitude where debris burns up within a few months. The Chinese ASAT test was at around 1000km and much of that debris will be there for tens or hundreds of years. It basically undid all the work the international community had done on reducing debris over the past decade (http://www.scientificamerican.com/media/multimedia/0212-spac...).

It is possible, but highly unlikely that the US does ASAT tests in secret. It's unlikely mainly because any unannounced rocket launch looks suspiciously like an ICBM (and is easily detectable), so it is in everyone's best interest to announce launches ahead of time. If the US has done secret ASAT tests, they would continue to do them at lower orbits out of concern for debris.

The US tracks all objects in low Earth orbit that are about 10cm or greater in diameter using a large network of radar stations. The Russians have similar capabilities, though not on the same scale. As a result, they actually can tell where most of the debris came from. However in this article it was not clear if it was just conjecture or actual tracking data from the Chinese ASAT debris that led them to that conclusion.

That is pretty interesting. I guess that's still within spec for USB. The iPhone probably doesn't care as long as it's a few hundred mV above the battery voltage (which would max out at about 4.2V for a lithium ion cell). Also, it looks like the big drop occurs when you go over the 1A rating of the charger.

While it's an interesting measurement, I'm not sure how relevant the current sag is to overall quality. Devices really shouldn't be using the charger in the constant current range. I guess it does reflect the overall workmanship and thought put into the design.

Also, nice job doing those ripple measurements - that was interesting stuff! It's not super surprising that the cheap knockoffs fail miserably there. Probably cheap capacitors that are way too small.