From the linked page (https://bitwarden.com/)

I recently witnessed an intoxicated man collapse on the street in front of me, so I was first on scene and had to call our local version of 911 (I live in Australia). Of course I am asked where I am, the address and street, and I had no idea. I was at the bus stop I walk to everyday, surrounded by building with names I couldn't read very well at night, and no street signs near me. I was eventually able to work it out, but that was precious moments we lost that could have made things significantly worse in a different case.

The man was passed out cold (he had hit his head very hard when he fell) and had a very weak pulse and weak breathing, I performed CPR until the ambulance arrived and he started to regain consciousness. The ambulance took a very long time to arrive and then find us, I had to get other bystanders to stand out in the street to wave and shout. When the ambulance left he was fully conscious and able to converse with the officers.

This whole thing of course seemed absurd, as we were all carrying smartphones equipped with HD cameras, GPS, and radios.

In another case, during the Christchurch earthquakes in New Zealand, I was lucky to be involved in a volunteer group which started offering free support services to those on the ground. We ran a text information service where people could text in questions, including asking for the nearest help center based on their location (which they had to provide via text). We would likewise respond over text. We were able to help people find the help they needed, by making it available over text we also were able to reduce the already overloaded cellular services (voice calls are much more expensive than text). We helped dispatch appropriate emergency services to people in need, but it was still very much copying address information as text between various jury rigged systems (written by us during the incident).

I hope we can improve these systems in the coming years, it is especially important to improve them to be redundant to things such as cellular system overload (which is very common during major crisis).

Recently the pain came back worse than ever, this time accompanied with quite serious thumb pains, I certainly do not blame the Kinesis as it is most surely a combination of many factors (poor habits, stress, workload, etc.), but the layout does increase the load on the thumbs so I think that contributed.

For now I have switched back to a cheap Microsoft dome keyboard as it is easier to type with using only my forefinger and middle finger (and easily allows me to avoid using thumbs and pinkies).

Of course this is all just my personal experience, for years the Kinesis was lovely and I may still go back to it, as always YMMV.

I like that way of thinking of it, I see it as just reusing the existing stack frame as a call in a tail call position doesn't need anything from the current stack (returning to this frame adds no extra meaning to it).

Having never implemented them though I feel like my ideas still need some fleshing out, my naive approach seems to be similar to the idea of trampolining.

Really looking forward to reading the linked document, very thorough and looks to be just what I was looking for (it even covers architecture dependent aspects!).

Oddly following that link gives me a 404 ('The requested URL /~dyb/papers/3imp.pdf‎ was not found on this server.', seems there is a trailing character '%E2%80%8E').

I was able to find it on google and open it, yielding the link http://www.cs.indiana.edu/~dyb/papers/3imp.pdf

At the beginning it was very traditional c; symbol and AST manipulation were a PITA (at that point it was a malloc'd arrays of `expressions`). After I had a base language working I started to use the language I had implemented so far to further the implementation, this finally peaked where this weekend I did a large refactor to remove most of my c arrays and instead replace them with scheme pairs and lists.

For example, here [1] I implement define function form in terms of lambda, specifically new_lambda(env, cons(args, cons(body, null))).

In hindsight this seems so obvious, but I have found the whole process extremely interesting, specifically looking at how the implemented languages starts to influence the implementation language.

I really cannot stress enough how enjoyable the process of writing my interpreter has been, I thoroughly recommend it to anyone who is interesting in programming languages.

[1] https://github.com/mkfifo/plot/commit/07272bd69e51979ab71fa0...

I haven't considered if I will go down the compiler route, but either way that resource looks very interesting; especially the coverage on tail call optimisation at the assembly level.

Does anyone have any further resources discussing tail call optimisation? I would like something a bit more in depth.

The other topic I would like to read more on is continuations, as a still newbie-schemer I find the idea of implementing them to be quite daunting.

[1] https://github.com/mkfifo/plot [2] https://mitpress.mit.edu/sicp/

But I still feel like both part 1 and part 2 are far too short; even if read together they provide very little information to digest.

Also I am not sure what he did to push to 150 remotes, and in that case this output would be much more tedious to piece together (and that is assuming he was able to capture all of it).

However I disagree that force pushing is rare, I find it is a (sharp) tool I use most days (more often on private repos or branches).

I do like the idea of github providing some kind of web interface to view the reflog and reset branches to various points within it.

Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.

The issue is that a client may not have fetched for a while before performing the force push, so it may not have all the required refs for performing the rollback.

The server of course still has all the refs, so it shouldn't be too hard to add a command (run client side) to invoke the required server-side rollback.

The old history will possibly be garbage collected eventually, but for quite a while that history is still accessible.

I think the only missing piece is a simple (and obvious) client side 'undo/rollback that force push'.

The issue is that the git client may not have the history pre-force, so it may have insufficient information to do the rollback (at least in the current model), however the server still has all the refs (and they are listed in the reflog).

Without the benefit of hindsight it is impossible to tell with certainty what techs are worthwhile exploring and what should simply be discarded, the idea of discarding is of course based on the false assumption that techs that are later unused never had a use (e.g. we may solve a software problem with current tech that will form the basis for future robotics software).