301 karma · joined October 31, 2016
Today, you can use software like Luna or Duet, or native screen sharing to control an iMac from another Mac (or vice versa). I have a 2019 iMac, bought for pennies and upgraded after to max out; way better value than buying the display on its own or a comparable monitor alone. The screen quality is just great.
I use it both as a daily driver and as a "thin client" for all my other machines with the software above.
An indexer crawls the codebase and maps slices of code to concepts, then groups related concepts. You can inspect a concept to see things related to it, or ask about the impact of a change and see second-order changes required - things not so easy to see that are related by basic symbol linking (although it does use symbol linking - it heavily relies on Roslyn, since it's all C# focused).
It also returns confidence scores with everything, which adjust based on a dozen or so factors like whether the user defined the concept or the concept was auto-generated during the code crawl. Low confidence score === fall back to grep.
It was a super fun project and ended up being very useful, as much for people as the LLM. But, I'm not convinced it is materially better than grep in some ways and just haven't had the time to really focus on improving it.
I also don't see how trying to emphasize empathy toward users translates to hubris. But sounds like you've got a bone to pick, so keep picking I guess.
This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
Windows doesn't need or deserve defending. It's atrocious. But this is a silly comment.
But if you don't want to and still want to use an LLM, there are low-bar choices you can make (using a technical writing skill, using ASD-STE100 Simplified Technical English, choosing your audience, proofreading at the end with human eyes to make sure it makes sense and doesn't repeat itself uselessly).
I think it shows either a) low respect or consideration for your audience or yourself, or b) laziness.
Trust yourself to write even if it's bad. At least it's human.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
The software allows for fine-tuned settings, button remapping, etc. It is awful software, to be sure, but it's not necessary to use the mouse.
In awe at whatever inspired this though
Also, full disclosure, because this was written entirely for myself, the code behind it is 100% LLM generated. I set the specs and direction but didn't touch code at all, just let agents churn while I did my day job and tested the results later.
For the recommendations:
- Seed selection is performed by building a mix of seed artists from recent listening, lifetime favorites, old obsessions, and underexplored artists.
- Seed weight combines `log(1 + play count)`, track diversity, number of listening months, and a recency decay
- Candidates are generated at the union of artists reached by "similar artist" edges through Last.fm and MusicBrainz-enriched local data (APIs are used to enrich DB initially, then after that it's all offline)
- Discovery excludes known artists, hidden and recently-reviewed artists
- Discovery requires edges with at least two distinct seeds, or one strong seed edge
- Discovery is scored by similarity (Last.fm + tag), feedback, and rediscovery thresholds. Then score is subtracted for excessive knownness within a genre, obviousness, recommendation fatigue, and shallow prior listening. The thresholds are by default but configurable:
```
0.35 × calibrated Last.fm similarity
+ 0.25 × calibrated tag similarity
+ 0.10 × rediscovery
+ 0.10 × feedback
```
- Serendipity is additional score provided when a candidate connects several seeds that are themselves weakly connected, or are in separate connected components. This is a weak implementation of the Auralist serendipity algorithm, and will be improved on.- Finally, diversity reranking; a greey MMR-style reranker.
```
rerank score = λ × candidate score
− (1 − λ) × similarity to already selected results
```1. A music recommendation tool based on Last.fm scrobble history.
It's graph-based, no ML or "fancy" techniques, but I've had good results with it so far. It builds recommendations based on a listening window or just recent history. It combines several different recommendation algorithms (including an Auralist-inspired "serendipity" score for novel recommendations, meant to simulate the serendipity of being recommended something novel by a friend), scores and ranks candidates, and takes in feedback that inform subsequent recommendations.
Fun project. Found some good new music with it already. :)
2. A code exploration / indexing tool with CLI and MCP interfaces for exploring concepts and impacts of changes in a codebase.
Essentially, an overwrought "find all uses" that doesn't depend on exact symbol or string matching.
I have a codebase of non-trivial size, but thankfully it's fairly well-structured. This tool indexes the code and bundles modules into "concepts" -- these can be auto-discovered or preconfigured. Dependencies, inheritance trees, symbols and symbol usage are all also indexed.
Then you can ask, "what's the impact of extending the domain model of XYZ" or "I want to remove this property" and it shows where to start, where to look next, and fuzzy edges or dependencies that might need deeper exploration. It surfaces non-obvious connections, too, or things a junior dev (or LLM) might miss, like when a model is mapped to an API DTO, or intermediary states, etc.
It's been useful for a new dev exploring the codebase, because you can ask in terms of business concepts instead of needing to know the exact symbol name in the code. And it's been much more token efficient than grep for exploration subagents. But it's limited to dotnet only.
The Dissolve alumni are all (mostly) writing at various publications: https://thedissolve.com/
While David Bordwell sadly passed, his blog is still a great resource (books, too!) and actively updated: https://www.davidbordwell.net/blog/