@lemonthymeshortbread · textlog

The best Mcp server I have as Claude Connector is Emacs running on my Homeserver. It has one tool - eval-elisp. Using it Claude can do almost anything. My top 1 pinned chat is “Run agent-start-claude-code using HotterEmacs in dir …” - after that I have a ready to use remote-controlled session running on my homeserver.

This sounds like a really interesting idea. What would you say are its advantages over having the agent use the shell, write shell scripts, etc? Just your personal preference for elisp or something else?

To load a skill I literally type - “load (◊doc 'slack) and browse channel X for today”. The idea is my text stays English but repeating concepts are real reusable elisp functions that stay fully deterministic. (◊doc 'agent) and Claude knows how to talk to open code and pi agents.

ai coding feels like it has reached diminishing returns for me. luna is my default orchestrator, routing work by complexity. in practice, usage lands around 16% luna, 48% sol, 30% astra, and 6% terra. at this point, i care less about each new frontier release. the system already finds a capable model for the job. the frontier is moving beyond my day-to-day work, so i’m happy to settle into predictable models for a while.

I’ve found the same, albeit with Opus — it’s hard to find uses for Fable. I don’t need a model that works for longer or works on harder problems, I need one that consistently produces simple, easy to understand, code; which at this point none of them do.

I've been there since I settled on a combination of GLM, DeepSeek and MiMo for planning, implementation, and verification flows. I'm a lot more interested at this point in having cheaper models that can consistently do the work I need. It's been a while that I hanven't noticed any improvement when I try new frontier models. I only notice they are very expensive.

…

same here, for almost an year. At this point, I could easily live with models that were released 6-12 months ago and continue doing so. also possibly the reason why the current focus has been around agentic workflows or agentic anything, than the model capabilities.

Coding probably yeah, but still they are bad at generating novel information, new ideas and such. They’re also not very good at seeing the bigger picture, they will narrowly perform the task but they’re not taking into account future revisions, which ends up in refactor after refactor in order to move forward.

Genuinely, I’m grateful we have such great choices when it comes to programming languages.

It’s just sad the whole corporate world runs on Java, Python, C++, C#, and JavaScript so I just look in envy at what I could be using

Which do you think is ?

Separation of concerns — Locality is more important. Code that changes together should live together.

Absolutely! I think separating HTML, CSS, and JS into separate files was a mistake. Web components would have succeeded far more if they had gone with the single-file component idea that so many web frameworks are converging on. I think it barely made sense in the Web 1.0 days — certainly not in the era of Web applications.

Microservices. Not really programming, as this is more on the architectural level. Microservices is a valid approach when you need to address massive scale. The thing is, I have seen it applied to things that could realistically serve its audience in a handful of modest servers with a less fashionable approach. It was done under the guise of simplification; each individual microservice was in fact very small. But this at the cost of absolute spaghetti architecture.

…

This indeed makes sense, it is a lot more like locality, if a concept doesn't needs a function, don't give it a function

Clean Code

I had so much pointless discussions about this ... but when you say "Clean Code" , do you mean the book or the general idea that such a thing exists?

The book, but actually ideas, like tiny functions and names. Aposd is much deeper book. Hilarious read

To never use single character variable names. I think a variable name’s length should reflect its scope — a function that’s only a few lines long can use single letters no problem.

I assume this is not original at all at this point - but (extreme) DRY is not a good practice. My experience is that a bit of copying yourself and your colleagues in the code base often make maintenance of the code base easier.

I think DRY should just die. It lacks any of the nuance of why copying code is a bad idea. I prefer thinking about a single source of truth and whether two pieces of code are semantically related rather than just happen to look similar. I also think identifying such similarities is hard without first seeing the repetition in a few instances and it is much better to add another copy than introduce the wrong abstraction; unless it’s really obvious then just wait for more repetitions first.

Many have adopted the term WET (write everything twice)

Getters and setters for everything. Certainly, if you want an object to be doing more than just getting and setting a value right now, get them in there! Planning to add functionality later without breaking code? Stop it! That should break code! If I'm consuming a library and have been using this setter method for 2 years, I don't want it to suddenly introduce brand new validation, caching, or logging behavior!

Are getters and setters on everything even considered a good practice? To me it screams junior developer who hasn’t yet fully understood encapsulation and abstraction — if you’re just exposing getters and setters as the interface then what is the class/module/etc providing beyond what a standard variable does…?

Why do so many tools have JSON config files‽ Commenting why options have been set the way they have is just such a basic thing to want to do… Why do tech people have such an aversion to writing things down⁇

This is like the third time in my life I've seen an interrobang in the wild. And I don't know, but I'd prefer JSON over having configuration as constants in a PHP script like at $DAYJOB sob

Ok, that sounds significantly worse, but like, YAML and TOML exists people…

…

My problem with yaml is the indentation annoyance it leads to, and if you are using the same tool on two different machine like windows and linux, have fun configuring those tabs and spaces all the time. I do like toml and ini for editing, but json is not as bad as yaml for sure

TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments. However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org

That’s really cool. I suppose it would allow people to verify their config file is valid without having to pass it to in the intended program, which might be running in production or infeasible to run locally — very interesting

Exactly! The schema also enables tools to have rich editors to config files without having to know about the config file format upfront. There is an editor for TOML Schema as an example, on the website.

I don't know:  
  They should be using YAML:
    - That's for sure

𐑲𐑥 𐑩𐑕𐑿𐑥𐑦𐑙 ·𐑖𐑱𐑝𐑾𐑯 𐑦𐑟 𐑯𐑪𐑑 𐑕𐑩𐑐𐑹𐑑𐑩𐑛 𐑓 𐑷𐑑𐑴-𐑑𐑮𐑨𐑯𐑟𐑤𐑱𐑖𐑩𐑯. I’m assuming is not supported for auto-translation.

nope, google translate doesn’t support it :( looks beautiful though

Hmm, maybe I’ll sometimes post in Shavian anyway and translate myself. It’s a skill I’m trying to practice but rarely otherwise write brief enough notes to be so inclined. 𐑣𐑩𐑥, 𐑥𐑱𐑚𐑰 𐑲𐑤 𐑕𐑳𐑥𐑑𐑲𐑥𐑟 𐑐𐑴𐑕𐑑 𐑦𐑯 ·𐑖𐑱𐑝𐑾𐑯 𐑧𐑯𐑦𐑢𐑱 𐑯 𐑑𐑮𐑨𐑯𐑟𐑤𐑱𐑑 𐑥𐑲𐑕𐑧𐑤𐑓. 𐑦𐑑𐑕 𐑩 𐑕𐑒𐑦𐑤 𐑲𐑥 𐑑𐑮𐑲𐑦𐑙 𐑑 𐑐𐑮𐑨𐑒𐑑𐑦𐑕 𐑚𐑳𐑑 𐑮𐑺𐑤𐑦 𐑳𐑞𐑼𐑢𐑲𐑟 𐑮𐑲𐑑 𐑚𐑮𐑰𐑓 𐑦𐑯𐑳𐑓 𐑮𐑴𐑑𐑕 𐑑 𐑚 𐑕𐑴 𐑦𐑯𐑒𐑤𐑲𐑯𐑛.

Finally watched Project Hail Mary. Easily one of my top 5 favourite films but it’s still not nearly as good as the book — I feel like the cut some pretty important scenes

It's the first film in a long time that I enjoyed.

…

I loved the book and I’m always fearful when a movie script is developed and a movie produced, so my relief after I saw the movie was immense. I too feel they’ve cut-out some bits, but the main thing that a book almost always takes my breath away with is fueling my imagination. A movie would (possibly) never nail that aspect.

I just watched it as well. It was fun. There were a number of things that I felt weren't explained well and broke my suspension of disbelief; I haven't read the book, but I found myself really curious whether the book takes the time to justify things more. Obviously, the movie has a lot of pressure to rush to the next "big moment".

…

If there’s one thing Andy Weir can’t be critiqued on then it’s not fully justifying all of the science. I think the film on the other hand can be hard to follow for someone who has neither read the book nor has a scientific background. It’s just hard to monologue about gravitational forces and relativistic speeds on screen.

bill gates built microsoft by making computation cheaper faster and harder for government to restrain. now that he's a billionaire no longer dependent on the free market for his own success he's discovered the virtues of taxing the next wave of computation. 1995 gates would have called it a tax on innovation. classic pull-the-ladder-up-behind-you politics.

These were exactly my thoughts reading about how he thinks we should “preserve” some jobs for people; I don’t remember him being an advocate of preserving the jobs of typists, draftsman, typesetters, and other clerks when his company was leading a prior digital revolution…

While learning jj, I realize how Git habituated me into being ok with its unique jargon and prickly command line interface. Unlearning Git is refreshing.

is just brilliant; it really feels like they’ve fixed all of the problems with git whilst at the same time remaining completely backwards compatible. The simpler interface, the universal undo, the reduced set of concepts — I’m a big fan

Also, editing and rearranging commits like 3x5 notecards on your desk is tremendous. It makes using an SCM feel more like editing your work than lumbering forward.

Team vim, team emacs, or team “my editor doesn’t start wars”? One line, no essays. Go!

replied to(deleted account):

I like Helix for how it balances a batteries-included approach but without feeling bloated. However, I find the keybindings to be a watered-down version of Kakoune; I feel like the Helix devs sort of missed the point of noun first.

vim/neovim with vim keys everywhere else -- once you learn it text editing with any thing else feels slow

Team vim, it still works even in the worst internet connection. Saved my ass many times during emergencies.

Team vscode with spacemacs bindings, but I kinda do wanna be team nvim in the future

Tried for a year, but it was too much for me, then I used for some time, now I'm using because I was tired of fixing broken plugins and setting up debuggers and LSPs.

…

! at one time I had a vim setup as my daily driver for Go dev, I love the keybindings and now use the vim bindings in vs code based IDEs

join the communityorbrowse more notes