104 karma · joined April 21, 2023
Adding numbers like this is not common in real world code. Now let's say instead of adding x, you have too look up X in a cache with an additional "type" param and update a metric of cache hits (or misses). You have to define a free function to keep your fold readable and understandable. In for loop it's much easier to understand.
You will eventually learn about something called "for loop", and it will be nice.
Let's not mention other aspects of security, such as the recent supply chain issue, or the old story of the serde maintainer shipping a binary blob just because...
However, other people around me are fine with apt installs and pip installs from global mirrors in every CI run. So I may be just autistic.
Maybe the emails weren't worth it? I have little to bother if most of my emails go away, especially if I am switching companies every few years anyway.
The classical epics speak of heroism and virtue. Understanding certain human morality which is timeless is very useful.
It's not like education in practical domains like CS or supply chain are highly efficient either. Something which forms your outlook is important. While most of the modern literature is not that influential, kids should read the Iliad, Odyssey and Havamal.
With exceptions you can
1. Set exception breakpoints.
2. Have real stack traces.
3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world.
Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because
1. You are making a network call or OS interactions every 2 lines which can err
2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments.
3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling.
I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.
Leave alone 97%.
> Your agent calls 20 tools. Each returns 500-3,000 tokens wrapped in {"content":[{"type":"text","text":"..."}]}.
This is a problem with your tool design. Most MCPs are fully vibe coded without any thought about tool selection.
> On a 128K context window, that's 30-55% gone. Not on work. On syntax.
Tool output is not "syntax" you donkey clanker.
Again, use the code approach, let the LLM filter out the JSON using tools. This TOON thing is just vibes. Most of the time your tool output should not even be JSON. It should be well formatted markdown. In cases where it's large structured data, your LLM should have tools (code / jq) to dissect it. So TOON is pointless.
Oh dear