rjknight

I would not be surprised if we ended up with binaries and Lean proofs.

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 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.