ataylor284_

Java has Futures, which are close, and allow similar patterns of code. But they're not woven into the language as pervasively as Promises are into JavaScript. You need to deal with asynchronous-ness explicitly.

There's also, in true Java tradition, a number of competing implementations of Promise based frameworks. The one I've used, Ratpack, defines and uses promises almost identically to JavaScript/Node.js.

I am skeptical as well, and I agree with you in principle. However I'd be interested if a 3rd party managed to reproduce his benchmarks. He credits using various prefetch hints for the performance gains, which sounds somewhat plausible.

> The real NtQueryDirectoryFile API takes 11 parameters

Curiosity got the best of me here: I had to look this up in the docs to see how a linux syscall that takes 3 parameters could possibly take 11 parameters. Spoiler alert: they are used for async callbacks, filtering by name, allowing only partial results, and the ability to progressively scan with repeated calls.

The point is that there was no effort to use meaningful abstractions and a coherent interface at the API level. The art of building a good product is finding the right level of abstraction for your audience, and I don't think 3rd party developers are well served here, although internal Windows performance engineers might be.

This seems to be Microsoft's pattern. Make the APIs super low level and difficult to use, and build tooling on top to make it palatable. If you're doing simple stuff with Visual Studio, no problem, but as soon as you need to go deeper, good luck.

I think it's probably embedded in MS developer culture, leftover from the old days when the ulterior motive was to make Windows "easy to develop for, difficult to port away from".

Ah, WebObjects. In a lot of ways, it was the Ruby on Rails of it's day. It was one of the first integrated, opinionated platforms with all the tools to build web sites backed by a database. Architecturally, it was years ahead of the first Java application server platforms; the persistence model so much better than the first iteration of enterprise Java Beans.

Its major drawback, in the early days at least, was that it was designed as an Objective-C framework. By the time I started using it (around 2000), Java was supported, but it was clearly an afterthought and you dealt with a buggy bridge to ObjC components and Objective-C-isms all over.

Last time I was in the area, I stayed at the Domain Hotel in Sunnyvale. About a 15 minute drive to Google and nice enough. And for touristy things: the Computer History Museum just down the road from the Google campus is definitely worth a visit.

Ah, yes. There was also the imake/IMakefile variant too, mostly for X11 related stuff.

This reminds me of my Gakken GMC-4. It's a 4-bit computer like this, but a physical piece of hardware. It has 7 LEDs, one 7-segment LED, a 20-key keypad and a tone generator. You have to key in the programs manually on the keypad, but you've only got about 100 4-bit words into which to fit your code and data. It's further constrained by the fact you can only directly address 16 of them for data. Even so, it's surprisingly fun and challenging to write little assembly programs for.

Nice. For those wondering what Reed-Solomon codes are all about: they are extra data that allows certain types of corruption to be detected and fixed.

I believe RS codes are used on optical media such as CDs and DVDs which allows perfect playback with a few scratches here and there. They're also used in QR codes, so even if the scan is imperfect, the data can be reconstructed correctly. In the case of QR codes, the standard allows the QR code creator to set the level of error correction, providing a wide range of of data size vs resilience to corruption choices.

I remember one program that had a string print subroutine that took zero args. It just used the return address from the stack to grab the nul-terminated string immediately following the JSR/CALL instruction. It then patched the return address on stack to return just after the nul.

Bad for storing data in .text, but still a neat hack that shaved whole tens of bytes off the program size.