I like Claude Code in the terminal. For me it's so good it don't need IDE integration. I'm just using emacs and magit to navigate the code out of band.
I wonder if some people grow to develop an inner monologue, but also immediately start developing an ability to silence it, to the point they don't have to try.
Mine is basically always on, and it can be problematic.
Yeah, totally this. I've had so much fun with AoC, learning nim, elixir at the same time.
I would normally tap out around the same place on the first dynamic programming puzzle which just takes me so long to wrap my head around each time (tips anyone? :)).
I welcome these new changes, and what ever the format are very greatful for all his hard work!
They're not as magical as they seem, you just need some practice. Read over the dynamic programming section in https://cses.fi/book/index.php (pdf link near the top is the free English version), then do a few on https://cses.fi/problemset/ . You'll be able to handle the AoC dynamic programming ones with _no_ problem at all.
Nope, I've really, really tried to like modal editing, because the programmable command chaining is super cool, but even though I became proficient with it I never really enjoyed it.
Starting out emacs i got super fatigued with all the long pinky driven commands for mostly used commands. It felt usable after I added keybindings for commands like switch buffer, close buffer, duplicate line(s), move line(s), find in project, find file in project, indent (wrote my own sane (for me)) indention code). The windows/apple key is great for those things because they are not used by emacs.
On linux I settled on using emacs vanilla key commands for copy/paste/cut but that took a looong time to feel comfortable with and I still mess it up sometimes, also with the ctrl+shift-X version of them in the terminal. On iOS, using the apple key like for the rest of the system is sweet relief.
My sweet spot at the moment is Claude Desktop with mcp servers for editing and aider --watch for quick fixes. Claude Code uses way, way, way too many tokens on the large project i work most on.
> Claude Code uses way, way, way too many tokens on the large project i work most on.
That's a very fair critique, and it makes the pay-as-you-go pricing model (vs. one of their subscription options) a completely unrealistic option for doing anything serious with Claude Code.
Yeah, I too found giving LLMs access to my emails via notmuch [1] is super helpful. Connecting peripheral sources like email and Redmine while coding creates a compounding effect on LLM quality.
Enterprise OAuth2 is a pain though - makes sending/receiving email complicated and setup takes forever [2].
Heh. I'm giving Claude running on AWS Bedrock in a EU datacenter access to read small parts of my email (normally 1-3 email threads in a chat), compose drafts for approval and then send them in a separate step. I can read and approve all tool calls before they are executed.
I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Basic Math Server")
@mcp.tool()
def multiply(a: int, b: int) -> int:
return a * b
mcp.run()
If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it with a way to look up details for individual paths and a custom message that explains the basics. For instance https://github.com/runekaagaard/mcp-redmine
The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.
How exactly those messages get transported is not really relevant for implementing an mcp server, and easy to switch, as long as there is some standard.
You’re ignoring the power of network effects - “shitty but widely adopted” makes “better but just starting adoption harder” to grow. Think about how long it takes to create a new HTTP standard - we’ve had 3 HTTP standards in the past 30 years, the first 19 of which so no major changes. HTTP/2 kind of saw no adoption in practice and HTTP/3 is still a mixed bag. In fact, most of the servers pretend HTTP/1 with layers in front converting the protocols.
Underestimate network effects and ossification at your own peril.
I mean isn't this the point of a lot of, if not most successful software? Abstracting away the complexity making it feel easy, where most users of the software have no clue what kind of technical debt they are adopting?
Just think of something like microsoft word/excel for most of its existence. Seems easy to the end user, but attempting to move away from it was complex, the format had binary objects that were hard to unwind, and interactions that were huge security risks.
yeah, but it doesn’t need to be that way. It can be simple and makes it easier adoptable, why over engineering and reinventing the wheel of at least 2 decades experience and better practices.
