zest progress
I'm continuing to chip away at zest. Some new posts:
I'm really happy with the the notation/representation split. There's still bound to be lots of changes over time, but I think the foundational ideas are pretty solid.
The layering of dialects is more tentative, but if it works out it'll be really nice to have a pure zest bootstrap.
So far I have:
- A design doc with 119 unit tests.
- A (shoddy) tree-walking interpreter for zest-lax that passes all the tests.
- Half of a compiler for zest-kernel. It's currently missing functions/specialization and reflection, but basic statements work fine. The codegen is much better than last years prototype - I'm optimistic about getting usable performance out of this.
unexplanations
Unexplanations: query optimization works because sql is declarative
I have a bunch of these little posts planned dissecting instances of fuzzy thinking that bug me. For each individual post I'm hoping people will find them useful to link to as a concise(ish) rebuttal, rather than having to repeat the same argument in each new discussion. But I also hope that the series as a whole might be useful as a demonstration of how chasing concreteness is useful for constructing better explanations.
generic dilemma
The generic dilemma post is pretty old, but I just recently noticed that one of the first comments (from Barry Kelly) actually seems to describe the solution that go ended up using 13 years later. Obviously there was a lot more to figure out eg how to graft generics on to the existing type system. I just think that it's a nice demonstration of a) how much existing knowledge is already out there if you go digging b) how describing a problem on a high-profile blog is often a really effective way to get the answers to come to you.
bitc retrospective
Retrospective is here. But also interesting is this unfinished paper on the goals and design.
It's definitely interesting reading in this in the context of rust having succeeded at similar goals. Rust solved the problem of making region typing usable, which was a genuinely hard problem. But a lot of the other problems bitc struggled with seem in hindsight avoidable. Notably, rust gave up on separate compilation, kept type-classes and built objects (dyn trait) on top of them, avoided inheritance, required types for top-level declarations etc. Also rust did not aim to make 1:1 rewrites from c++ possible and instead relied on ffi to gradually migrate codebases.
It also seems like bitc was lead astray by (some subset of) the academic pl community. In order to get published their type system was pushed towards full inference and minimum 'hacks', even though they might have been better served by annotations and hacks. A depressing percentage of their old website was justifying why they can't just write their operating system in haskell.
The mailing list discussion also branched into this discussion of why they can't use the jvm for executing database queries - even with AOT compilation it takes way too long just to initialize a java heap. Worth keeping in mind for any programming language that wants to double as a query language...
I don't care about memory safety
Makes a really interesting distinction between memory-safe languages and memory-safe systems. I'll rephrase it in the context of known soundness holes like this:
- If I'm writing code and I want to prevent attackers from exploiting it, a language that is 99.99% sound will massively increase my safety. I'll just avoid the weird soundness hole.
- If I want to run code from somone else without letting them exploit the rest of my system, a language that is 99.99% sound is useless because an attacker will 100% exploit the one weird soundness hole.
I'm sure this article kicked off silly forum fights about rust, but the distinction above is the key part. The author is positioning cheri not as an alternative to memory-safe languages, but as a waay to get fine-grained sharing when interacting with untrusted code. If you're going to do that you really want a high level of verification, which is difficult to do in a complex programming language.
done list
And make no mistake: paying off your imaginary productivity debt completely - in other words, working so hard and so efficiently that you no longer feel like you're falling behind - is literally impossible, not just grueling and unpleasant. In the modern world of work, there's no limit to the number of emails you might receive, the demands your boss might make, the ambitions you might have for your career, etcetera - so there's no reason to believe you'll ever get to the end of them.
What if you worked on the basis that you began each day at zero balance, so that everything you accomplished - every task you got done, every tiny thing you did to address the world's troubles, or the needs of your household - put you ever further into the black? What if - and personally I find this thought almost unthinkable in is radicalism, but still, here goes - what if there's nothing you ever have to do to earn your spot on the planet? What if everything you actually get around to doing, on any given day, is in some important sense surplus to minimum requirements?)
leaving the land of tiny muffins
I made a small step into the land of cogsci academia, was wildly disappointed, and quickly bailed. But I always wonder if I was too judgemental, or just in the wrong place. So it's always validating to hear that other people have similar qualms:
Today, the primary function of our scientific and educational institutions is to take in young people and lower their ambitions. "Oh, you want to change the world? You should join our Young World-Changers Program, where we do leadership seminars and write on whiteboards and discuss how nice it would be to change the world, if only such a thing were possible."
I lived in this world for a long time, a world full of people eating tiny muffins from breakfast buffets and listening to talks, all the while going, "We're doing it, we're doing it!" Success meant getting invited to the cooler conferences, where the muffins are tastier and the speakers are more famous.
not spamming is spammy
In an email from http://suspiciousdevelopments.com/.
Also, this list is changing slightly!
Short version: we're gonna get in touch a few times a year to just to update you on how things are going, maybe share something we haven't shared before.
Why? I'm so glad I presumed you asked. We'll turn this into a good thing, but our hand is being forced in a very stupid way. Like when someone makes you slap yourself, except they're making us slap you, with content.
It turns out that current anti-spam rules severely punish lists that only e-mail very rarely. "Is that," you ask, with the air of someone about to make a great point, "true to the spirit and goals of anti-spam rules?"
It's not! It's really not! But the universe laughs at the dreams of mortals, none more so than the dreams of e-mail regulators.
How severely? Well, MailChimp literally would not let us e-mail you anymore, because we hadn't done so in 12 months. Relatedly: we have left MailChimp.
happiness
This is what I want from a pop science book. There's no grand theme, story or call to action. Just a clear summary of the research to date. The author really carefully carves out exactly what they are and aren't measuring, and also which results are solid and which preliminary or suspect.
The starting point is that part of the job of government is to maximize the happiness of citizens, so psychologists ought to be figuring out what makes people happy. And also what we even mean by 'happy'.
Different kinds of happiness:
- The feeling of joy in the moment when something good happens.
- Whether you feel happy about your life in general.
- Whether you feel fulfilled, or are living a 'good' life.
1 is an emotion whose purpose is to make you continue to pay attention to good things to exploit them fully. But if you paid attention to one good thing forever you'd die, so it makes sense that this feeling fades quickly. It's probably not practical/healthy to try to extend it.
Studying 3 runs the risk of having to define what a 'good' life is, which leans a little authoritarian.
2 is the happy medium. It's easy to measure - just ask people if they're happy with their life. This measurement is a little vulnerable to framing (eg people are much happier with their lives if you ask them right after giving them cake). But if averaged over time it's pretty predictive of various other things. Eg people who reported being happier in the past tend to be healthier and more successful in the future. And various life changes affect the results in sensible ways eg people who live in areas with high noise pollution are on average less happy. So this measurement tentatively seems like a thing worth trying to optimize for.
Can we make people happier? There's a lot of talk about the hedonic treadmill - nice things make you happy at first, but you quickly get used to them and are just as happy as before. Maybe happiness is just a matter of personality and your situation doesn't matter?
Luckily the treadmill doesn't apply to all life changes. Basic needs - food, shelter, safety, company - have permanent affects on happiness. People who are hungry are just less happy on average than people who are not - you don't get used to not having enough food. Noise pollution also has permanent effects. Marriage also might, but the data so far is only from the first few years. Divorce definitely makes people less happy though.
The changes that do show the treadmill effect are all positional goods - wealth, power, beauty etc. They're all about relative status, so once you get more you just start comparing youself to different people.
Personality does seem to matter. Neurotic people, in particular, are less happy. Which might seem circular when neuroticism is defined as the tendency to have negative thoughts, but the fact the tendency exists and is fairly stable throughout life does mean something. But neuroticism is over-represented in succesfull people, especially in creative fields, so maybe the tendency to be dissatisfied with your own work has some upsides too.
Also talks about wanting/craving vs liking/enjoying. Roughly wanting = dopamine system and liking = serotonin system, although the author cautions things probably aren't that simple. They don't always overlap - you can want/crave something but then not like/enjoy it when you get it. Suggests that a common cause of unhappiness is confusing the two. (This seems compatible with this model).
daily rituals
Common themes:
- People working only a few hours per day, but with intensity and without interruption or distraction.
- People hating themselves for not meeting some ever-rising bar.
- People spending a significant portion of every day hanging out with friends. Often more time than they spend working. It sounds nice.
- Drugs. Caffeine and amphetamines to start and alcohol and sleeping pills to stop. As someone who doesn't metabolize caffeine fast enough to survive drinking any coffee at all, I feel cheated.
other books
Ok:
- The shepherds life - I enjoyed this peek into a different culture that is barely hanging on, and it feels like a good way to reflect on problems in my own culture. But after the first few chapters it got really repetitive.
- Static program analysis - this seems like a fine introduction to the subject, but zest can get away with the simple techniques in the first few chapters so I ended up not learning anything immediately useful.
Not recommended:
- Stealing fire - incoherent.
- The zen of climbing - not terrible, but totally subsumed by the rock warriors way.
- Art and fear - I enjoyed the first few chapters but after that it wandered around aimlessly.
- Code is for humans - not very organized or novel.
- Excellent advice for living - a whole book of aphorisms.
- The practice of groundedness and Peak performance - shallow summaries of other books, many of which are similar. The author is an executive coach so summarizing good advice for their clients is not an unreasonable practice. But I'd rather just read the original sources.