aardvark179

You should try looking up betting, coffee houses, and the 18th century, or the founding of the London stock exchange. Gambling plays more of a role than you might want to admit.

Pinch zoom is also broken on Safari on iOS.

I don’t mean this to sound harsh, but this post comes across a little like you already assume you deserve to win such a prize and it’s just those fickle judges standing in your way.

I looked at your sample chapter and immediately bounced off a police officer in Maine calling in a murder as a 187 (California penal code).

I think that proposed prize would be pretty “value-free.”

I’m okay with that. I’ve been a huge fan of Ballard and Priest for years, and got into Nina Allan’s work more recently and this book was a brilliant but heartbreaking read.

Having maintained internal forks, and having needed to pull in and rebase upstream changes I do read a lot of commits. Projects that take care with their commits are much easier to work with.

This is also true when creating with security patches and other things that need to be backported to multiple releases.

No, running a command in a terminal buffer doesn’t block the emacs UI, but a long running bit of elisp running in emacs can block the UI.

I think the thing that stops me from running more processes inside emacs is that a large diff parse from magit or similar can block everything, and so I end up keeping a separate terminal around anyway.

Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be.

The lower level bits round the object model etc. all look very solid.

Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.

It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.

Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.

The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.

Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.

JSON ser deser is usually dominated by floats rather than ints, and they are more expensive to handle.

The GoF book came out in 94, and Java in 95.

The point is that having a GC will affect your data structure and algorithm design, so it’s easier to automatically transform JS or TS to Go than to rust because you’re mostly reducing things down to one problem (translation) rather than multiple intertwined problems.