rjknight

The gambling ads have a conscious effect for me: I think “what a terrible world this portrays, I’m glad I don’t gamble”. For me, being reminded of gambling is just a reminder of the fact that I don’t like gambling. The same is true of some other ads too, they mostly serve to remind me that I define my personality in opposition to these things.

However, I have to presume that the effect is different for at least some other people.

But then you lose the Jackson Pollock joke, which is what makes it compelling and memorable!

It's not that you know the artist first and then say "this art is cool because I like the artist". The art is the means by which you know the artist. The more of their works you encounter, the closer you get to understanding the artist and what they are trying to communicate.

Doesn’t that also create a kind of immunity, though? If what I see is a cacophony of differing views, then I am unlikely to be influenced by any particular sock puppet account.

Whereas a community that tends towards groupthink might have a narrower range of views, but if those views begin to shift in a particular direction then it’s much harder for those who are disadvantaged by that shift to resist, because to do so requires violating the norms of groupthink.

I’m not sure which is better. My own preference is to tolerate a wide range of views in return for robust disagreement being the norm, but I can imagine some (most?) people preferring the opposite.

I wonder if it would be possible to have gone directly to Zed, without going through Atom first (likewise, Plan 9 would never have been the first iteration of a Unix-like OS). "Rewrite it in Rust" makes a lot of sense if you have a working system that you want to rewrite, but maybe there's a reason that "rewrite it in Rust" is a meme and "write it in Rust" isn't. If you just want to move fast, put things up on the screen for people to interact with, and figure out how you want your system to work, dynamic languages with bytecode VMs and GC will get you there faster and will enable more people to contribute. Once the idea has matured, you can replace the inefficient implementation with one that is 10% of the size and 10x the speed. Adding lots of features and then pruning out the ones that turn out to be useless may also be easier than guessing the exact right feature set a priori.

No, we are using this thing called a metaphor. What's being compared is the relationship between the hangman and the ropemaker, and the relationship between the app developer and the OS vendor. There is no comparison between taking screenshots and hanging people.

Surely the answer is "the other side of the Gobi Desert".

I always think of it as the "Perez plateau"[1], but I will grant that this is less catchy.

[1]: https://www.researchgate.net/figure/Phases-of-the-S-Curve-Pe...

I think it depends a lot on the org. In enterprise software development, there's definitely a type of "business analyst" or "domain expert" who is capable of reading code, at least to the extent that the code resembles a flow chart. Clojure's small syntax means that it's fairly easy to write code that is obviously just a flow-chart in text form.

The "domain expert" is the business-person who is, it is suggested, more capable of reading and comprehending the Clojure code than the Haskell code.

Since there is an equivalence between types and propositions, the Clojure program also models a "type", in the sense that the (valid) inputs to the program are obviously constrained by what the program can (successfully) process. One ought, in principle, to be able to transform between the two, and generate (parts of) one from the other.

We do a limited form of this when we do type inference. There are also (more limited) cases where we can generate code from type signatures.

I think op's point is that the Clojure code, which lays the system out as a process with a series of decision points, is closer to the mental model of the domain expert than the Haskell code which models it as a set of types. This seems plausible to me, although it's obviously subjective (not all domain experts are alike!).

The secondary point is that the Clojure system may be more malleable - if you want to add a new state, you just directly add some code to handle that state at the appropriate points in the process. The friction here is indeed lower. But this does give up some safety in cases where you have failed to grasp how the system works; a type system is more likely to complain if your change introduces an inconsistency. The cost of that safety is that you have two representations of how the system works: the types and the logic, and you can't experiment with different logic in a REPL-like environment until you have fully satisfied the type-checker. Obviously a smarter system might allow the type-checker to be overridden in such cases (on a per-REPL-session basis, rather than by further editing the code) but I'm not aware of any systems that actually do this.

One of the neat properties of base58 (and, strictly speaking, of base62 as well) is that it does not contain any characters that require special encoding to be used in either a URL or a filename. Nor does it contain any characters that are considered to be "word-breaking" by most user interfaces, so you can do things like double-click on a base58 string to select the entire string. Base64 has none of the above properties, while being only very slightly more efficient.

"I want an end to corruption, or a chance to participate in it!"

It's weird, but LLMs really do gamify the experience of doing software engineering properly. With a much faster feedback loop, you can see immediate benefits from having better specs, writing more tests, and keeping modules small.

One thing I've noticed about working with LLMs is that it's forcing me to get _better_ at explaining my intent and fully understanding a problem before coding. Ironically, I'm getting less vibey because I'm using LLMs.

The intuition is simple: LLMs are a force multiplier for the coding part, which means that they will produce code faster than I will alone. But that means that they'll also produce _bad_ code faster than I will alone (where by "bad" I mean "code which doesn't really solve the problem, due to some fundamental misunderstanding").

Previously I would often figure a problem out by trying to code a solution, noticing that my approach doesn't work or has unacceptable edge-cases, and then changing track. I find it harder to do this with an LLM, because it's able to produce large volumes of code faster than I'm able to notice subtle problems, and by the time I notice them there's a sufficiently large amount of code that the LLM struggles to fix it.

Instead, now I have to do a lot more "hammock time" thinking. I have to be able to give the LLM an explanation of the system's requirements that is sufficiently detailed and robust that I can be confident that the resulting code will make sense. It's possible that some of my coding skills might atrophy - in a language like Rust with lots of syntactic features, I might start to forget the precise set of incantations necessary to do something. But, corresponding, I have to get better at reasoning about the system at a slightly higher level of abstraction, otherwise I'm unable to supervise the LLM effectively.

I think it depends on whether you think there's low-hanging fruit in making the ML stack more efficient, or not.

LLMs are still somewhat experimental, with various parts of the stack being new-ish, and therefore relatively un-optimised compared to where they could be. Let's say we took 10% of the training compute budget, and spent it on an army of AI coders whose job is to make the training process 12% more efficient. Could they do it? Given the relatively immature state of the stack, it sounds plausible to me (but it would depend a lot on having the right infrastructure and practices to make this work, and those things are also immature).

The bull case would be the assumption that there's some order-of-magnitude speedup available, or possibly multiple such, but that finding it requires a lot of experimentation of the kind that tireless AI engineers might excel at. The bear case is that efficiency gains will be small, hard-earned, or specific to some rapidly-obsoleting architecture. Or, that efficiency gains will look good until the low-hanging fruit is gone, at which point they become weak again.

Some of these seem good to me:

- "everything is an expression" is a nicer solution for conditional assignments and returns than massive ternary expressions

- the pipe operator feels familiar from Elixir and is somewhat similar to Clojure's threading macros.

- being able to use the spread operator in the middle of an array? Sure, I guess.

I want to like the pattern matching proposal, but the syntax looks slightly too minimal.

The other proposals are either neutral or bad, in my opinion. Custom infix operators? Unbraced object literals? I'm not sure that anyone has a problem that these things solve, other than trying to minimize the number of characters in their source code.

Still, I'm glad that this exists, because allowing people to play with these things and learn from them is a good way to figure out which proposals are worth pursuing. I just won't be using it myself.

I would really like to know whether this feature gets any (non-accidental) use. It's certainly an important problem to solve, and I can see the technical merit in the solution proposed. What I'm left wondering is how this solution is most effectively communicated to the people who need to know about it, such that they're able to make use of it correctly in the critical moments when they need to use it. For obvious reasons there are probably no good statistics on this, but I wonder what the user research was like.

Valibot is really nice, particularly for avoiding bundle size bloat. Because Zod uses a "fluent builder" API, all of Zod's functionality is implemented in classes with many methods. Importing something like `z.string` also imports validators to check if the string is a UUID, email address, has a minimum or maximum length, matches a regex, and so on - even if none of those validators are used. Valibot makes these independent functions that are composed using the "pipe" function, which means that only the functions which are actually used need to be included in your JavaScript bundle. Since most apps use only a small percentage of the available validators, the bundle size reduction can be quite significant relative to Zod.

It's also worth bearing in mind that much theology is an attempt to explain what the experience of God is like. The experience of God is not (for Tillich, nor perhaps for very many moderns) about finding a literal place and time in which God-the-being can be directly observed. To seek God and expect to find a being who exists in the same manner as a tree or a building is to set oneself up for failure.

When Tillich says "The courage to be is rooted in the God who appears when God has disappeared in the anxiety of doubt" he is describing the psychological process the seeker undergoes. In his case, he identifies God with the open, reflective cast of mind in which one engages with the unknowable, ineffable, combinatorally-explosive possibilities that are found at the horizons of our understanding. The "state of being grasped by an ultimate concern" is one in which we are trying - and necessarily failing - to see beyond the horizon. And yet, something sustains us in the effort, which is faith in God.

Doubtless this really is a very different kind of faith than other self-described Christians might have, whose faith might be rooted in a different mode of being and engagement with the world. And, to be clear, Tillich's description is very much "what it's like" to have his variety of faith, and not a metaphysical claim about the workings of the universe. A different Christian might hold much stronger claims about God's precise nature and existence, but for Tillich those beliefs were unsustainable.

It worked well for me - I was able to correctly infer a lot of information about the app from a single character, which was about as successful as a naming scheme could hope to be.

This is why I think if we're going to do geoengineering, we ought to do it sooner rather than later. The amount of geoengineering needed to offset the current level of methane release is going to be much less than the amount needed once the ocean warms by another degree.

I don't think this is really true.

If by "emissions" you mean the absolute level of CO2 or other pollutants emitted, then the emissions required to build renewable infrastructure will be much smaller than the total emissions for all other causes. It won't be a "massive increase", given what we've already done.

Or if you mean the annual level of emissions, it's also not clear to me how building renewables causes that level to increase, let alone massively. We already have massive annual emissions, and diverting some industrial production to building renewable energy infrastructure won't cause emissions to go up, since those resources would be diverted away from some other use that would also cause emissions.

I thought the same thing, but then "slack" also implies not working very hard, and that didn't seem to be a problem for them (though maybe the counterfactual is a world in which Slack had even more users with a better name).

Yes, but the A16 was a stopgap release, which only happened because Apple has to release a new iPhone CPU every year. The M-series does not update as frequently, and so it seems reasonable to imagine that the M3 is of the same "generation" as the A17.

If you're interested in the background, and th importance of technology in both the motivation for and the execution of the coup, this (opinionated, polemical) podcast might be good for you: https://the-santiago-boys.com/

I think this misses a bit of what's going on. What Buddhism does when it encounters pre-existing religious traditions is that it relativizes them. Previously, the existence of the gods or mythic figures was considered an absolute truth. Post-Buddhism, the enlightened mind is absolute reality, and everything else is relative - to culture, history, etc.

For instance, a Tibetan Buddhist might visualise a deity, supplicate the deity, "interact" with the deity in various ways, but would still ultimately recognise that the deity is an empty appearance. But, since everything else is an empty appearance too, the question is simply whether engagement with the deity is a skilful practice. Which it might be - perhaps the practice fosters social cohesion, or helps with emotional regulation, or whatever. It can't really be "supernatural nonsense", since to be "supernatural" would require that it is beyond the nature of mind, which is absolute.

Developers get more expensive every year, and compute gets cheaper every year. This is a good trade-off to make!

But this is how all victories work, whether it's a war or a sports competition or market share. You get to be the undisputed champion for a while, until eventually someone else comes along and beats you, or circumstances change so that your victory doesn't matter so much any more. "But Tailwind was only the dominant CSS framework for most of a decade" is not much of a criticism.

Funnily enough, your complaint here is that although it may be simple, it is not necessarily easy, while the talk is an argument that we should prefer simplicity even at the cost of some (temporary) un-ease.