I plugged in 5 books I've recently enjoyed and asked ChatGPT for some recommendations of similar books, and 2 out of 10 of the books it suggested did not exist. I googled the author, the book title, they were complete fakes. They sounded like they'd be good books though! When I told it they didn't exist it was like, "you're right, thank you for catching that!"

I enjoyed reading your notes, thanks for sharing.

On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1].

On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well.

I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing.

[1] https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck

Huge fan of minimizing Kolmogorov complexity [1]. There's a balance, but typically if the same behavior can be described in less code, then the simplicity will yield dividends.

[1] https://en.wikipedia.org/wiki/Kolmogorov_complexity

False. The human brain and eye is built to recognize foreground and background and shift focus and attention based off of blur.

Thousands of years of adaptation has honed the brain and the eye to be optimized for this type of view much moreso then the simple UX you see here on HN.

Not only does the blurred/frosted glass background look better but it should be clearer because that's what we've been designed to do.

I'm not sure why you need midi 2.0 to achieve this? Recording midi on windows is totally trivial, and for this sort of application, only capturing the notes and relevant CCs (e.g. pedals) is all you need.

Looks awesome, does it also record the pedal? Also I am worried that if it just records in MIDI, the output sound may be different from what I was hearing when playing unless I somehow have exactly the same sound banks as my digital piano.

Sorry, as who have already designed yet another JSON alternative. Many things about this format are just wrong (as of the first edition):

- (EDIT: Mistakenly read SHOULD as MUST, ignore this item please) The requirement for the mandatory BOM is unacceptable for most non-Windows users, as BOM is by definition invisible.

- An arbitrary name is equally questionable, even XML doesn't do that. Do you accept tabs for example?

- There is absolutely no way to indicate the data type. The document accidentally mixes the wire format and serialization protocol; never a good sign.

- Do you accept 3,000 or 3,,000 or 30,00 or 3,0,0,0 or ,,,3000 or 3000,,, or 3,e,3 or 0.000,3e7 or ,,,?

- How many digits in each group are recommended for the encoder?

- What on earth is "IEEE 64 bit double precision floating point numbers" in the context of textual format?

- Do you require a specific rounding or not in the decimal-to-binary conversion?

- Is `\u{d800}` accepted or not? (JSON famously has this issue.)

- If you have to escape the base64 padding, maybe you should just drop the padding?

- Graph is generally a bad thing to encode at this level, because many applications do not even expect graphs and that can lead to DoS attacks.

- No clear definition of the data model. The document starts with objects, arrays and scalars (untyped? stringy? I dunno), then only reveals that objects can be typed and shared and specific types of scalars should be written in certain ways much later. Define the data model first and describe possible encodings of that model instead.

- Not allowing anything besides from space and tab is okay, but that doesn't speed processing to be exact.

- While technically a matter of choice, it uses a lot of unmatching angle brackets and that's just... ugly.

- In fact, I don't really see why other grouping characters were unused in the first place.

- No canonical representation.

Maybe you should review tons of other alternatives in this space (I recall at least 2--30 of them, probably much more) before your own design.