I think alcohol and tobacco use are primarily symptoms, not causes, of problems. They, along with depression, anxiety, ADHD, and other addictions, are strongly correlated with ACE (adverse childhood experience) score. As smoking has become taboo, other stimulants became more popular (adult ADD). I'd expect something similar if we restricted alcohol without solving the problems that lead to dependency.
Meditation is a pretty broad term encompassing many different activities/intentions (though they all look pretty similar from the outside). In the studies I’ve read on the adverse effects of meditation, the style has a major influence. Due to historical accidents, vipassana is a common style in the West - I find this mind blowing, since it is probably the most likely to cause adverse effects.
As a long time meditator, my experience with vipassana is that it is the hardcore path, for those willing to risk crashing and burning to get to enlightenment faster. Techniques like mettā, tonglen, or dzogchen seem to be ~5-10x less likely to be associated with a psychotic event - which at that point, seems like it could just be about prior history [1]. It's worth mentioning that Britton, the academic meditation critic in the article is a co-author of this paper.
I don’t understand how someone can say “this is the worst software I use daily” and then you say “you are wrong.” Maybe you use worse software than them? Also, you seem to implicitly default to comparing each piece of software to others in it's class; you’re grading on a curve. The parent comment is saying “of all software, these are the worst”, and you are saying “but other PM/VC/OS software is worse” which is different.
For example, git is the best version control software; it is also a disaster of a UX.
Your appraisal of Docker is also too generous, I honestly can’t tell if it’s sarcasm
Not to nitpick, but wouldn’t Etherium Be the right cryptocurrency? I try to ignore it, but I remember that that’s the “smart contracts” one, so it could make the job contracts in such a way that if they are completed, payment is automatic or something?
Oh can we coin a term like this for drunk driving? You know, when it’s more convenient to drive home drunk than leave your car out? That’s just being taxi-averse
They model a system which they know to be constrained by a closed-form equation called the Hamiltonian. They (cleverly, IMO) force the network’s predictions to be constrained by the Hamiltonian, by choosing the right output and loss function.
I don’t see a way to generalize this to the procedural rule-based systems you describe, unless they too are governed by a fairly simple continuous function Like the Hamiltonian.
I don’t know if it was “dramatic”, but it made me really happy.
I think software engineering is depressingly, suboptimally stable. The space of all possible ways to write programs is so, so large and almost completely unexplored. Lisps, Hindley-Milner type systems, Cox, neural networks with autodifferentiation ... whenever we substantially depart from the local optima around C-like programming, we find cool shit.
However, the vast majority of programming is done to build nearly indistinguishable CRUD SaaS apps. If we could just spend half our time doing real, interesting exploration of programming-space to satisfy our curiosity, maybe we could all agree to build apps with a more boring tech stack. However, that would require a large scale change in incentives that is hard to imagine shy of a Space Race style event.
... or Jonathan Blow was right and C was more or less the global max, and everything else was a mistake. I really hope that isn’t the case.
Part of me wants to ask “but who investigates the Inspector of the LECC?” But I’ve dealt with Elixir and I know that supervision trees rarely need to be very deep in practice
I think this is a good observation. One thing I’ve been thinking about is probabilistically evaluating traditional software. Every un-caught exception, for example, is usually a false negative when evaluating “did the code correctly handle the input?”
Not that ML code is bug-free. But it seems like most traditional software is probabilistically correct, despite not being thought of that way.
First off, I totally agree. Not as easy as it should be to write an async web server in python. FastAPI is probably your best bet. I usually use Sanic. Easy to accidentally block though.
That said, it sounds like you’re serving a large model. No amount of async/await or goroutines can solve this problem. A non-blocking web server is a godsend for I/O-bound tasks, but a large model is just a deep call stack - lots of multiply, nonlinear function like RELu, then add, times a billion. This would still block, even if you had perfect async/await code.
I made some assumptions here, but if I’m right, the answer is “shrink your model” and/or “buy more compute”. Neither of which are easy. But if you’re trying to shrink a model, check out Distiller https://github.com/NervanaSystems/distiller
Edit: the restriction I talk about is for event-loop based servers using something like uvloop or asyncio under the hood. Maybe this restriction doesn’t hold for other concurrency modes.