Well, as I remember, the thing about solid is it’s a protocol. So, if you don’t trust one vendor, you can trust another vendor or implementation without losing interoperability. So it goes the opposite direction of consolidation because it allows arbitrary storage services to be used transparently by arbitrary services in a secure fashion.
A degree is too big for the effect, the division of the degree into 60 arcminutes and the arcminute into 60 arcseconds is the standard subdivision of degrees as an angle measurement going back to the Sumerians.
> It's too bad because it's not like the web is incapable of providing a beautiful ux for those products.
I’ve never seen a web app I was happy with being a web app. I understand that a lot of people prefer web-based tools but a lot of us cannot stand them and try to get our work out of the browser as much as possible because we dislike the UX of the browser platform.
It’s just not true that users don’t like making things opt-out. HN Users tend not to like it but I think a lot of users dislike the alternatives: either because they’re undiscoverable (toggle in settings or a menu) or intrusive (various sorts of what’s new overlays). Imo, the question of when to make things opt-in vs. opt-out is fairly subtle and largely depends on the feature and pre-existing trust.
I knew .git can be a normal file because of worktrees. But most of the weird states have to do with the working tree not the repository. Even rebasing isn’t weird as far as the file formats go: it just is replaying commits on top of a new base commit. Since my goal was basically to implement enough of git to serve files from a git repository as a website, the actual task was fairly small.
There aren’t that many weird states a git repository can be in: the on-disk format of the repository is too simple for that. The hard part has to do with the various protocols for transferring objects around.
I wrote a nearly complete implementation of git file format parsers in Common Lisp over like a month of evenings and weekends. I’m sure there are hard parts between where I am and a full git implementation but you can get quite a bit of utility out of a relatively small amount of effort.
Yeah, that was one of the pieces of research I was thinking about. Another is this review of the evidence, such as it is, for static types: https://danluu.com/empirical-pl/
So far, Fred Brook’s “No Silver Bullet” remains undefeated.
Although, from what I can tell, there’s a lot of new evidence that the Dunning–Kruger effect is an artifact of the experimental protocol and not some interesting fact about psychology.
I think just about every developer hack turns out this way: static vs dynamic types; keyboard shortcuts vs mice; etc. But I think it’s also possible to over-interpret these findings: using the tools that make your work enjoyable has important second-order effects even if they aren’t the productivity silver bullet everyone claims they are.
I looked around and it seems like Smalltalk didn't make modifying literals UB, the way Common Lisp does but I'm not an expert. Still, for both languages, most implementations won't stop you if you modify string literals, you just have to deal with the consequences.
Common Lisp and Smalltalk have mutable strings, I think. So it’s not too surprising that ruby does too, since it was pretty heavily influenced by these languages.
My point is that no one is a new user forever and so I think we need to come up with a better solution than UI taking up screen space for things people end up doing via shortcuts. Menus and command palettes are great for this because they are mostly invisible.
The other important thing is learning to fit into the conventions of the platform: for example, Cocoa apps on Mac all inherit a bunch of consistent behaviors.
I sort of disagree with this: once I’ve internalized the gestures, I really appreciate the lack of UI for them. It’s like vim and emacs: the sparse ui creates a steeper learning curve but becomes a feature once you’ve learned the tool
I think it oversimplifies, though and I think it’s shortsighted to underfund the (harder) crafted systems on the basis of this observation because, when you’re limited by scaling, the other research will save you.
The alternate here is that Harry Potter is written with sentences that match the typical patterns of English and so, when you prompt with a part of the text, the LLM can complete it with above-random accuracy
I don’t think it’s true that “consumers don’t care about quality” but rather that their concern for quality doesn’t really manifest itself in those terms. Consumers care about critical tools being available when they need them and businesses often have a hard time situating feature requests in the broader desire for utility and stability (in part because these are things only noticed when things are really bad).
Part of my growth as a developer was connected with realizing that a lot of the issues with quality resulted from miscommunication between “the business” and engineers advocating for quality.
My impression is they’re basically trying to end third party kernel development; macOS has been making it progressively more difficult to use kexts and has been providing alternate toolkits for doing things that used to require drivers.