> eval, send, method_missing, define_method , as a non-rubyist how common are these in real-world code?
Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around. I'm not 100% sure, but probably the untyped JSON ingestion example uses those.
Remove that, and you have a very compact and readable language that is less strongly typed than Crystal but less metaprogrammable than official Ruby. So I think it has quite a lot of potential but time will tell.
> Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around
True, but I'd point out that use in frameworks/DSLs etc is the main place you see those things, and most of the code people write in their own projects don't use these.
In my experience (YMMV), eval and send are rare outside of things like, slightly cowboy unit tests (send basically lets you call private methods that you shouldn't be able to call, so it's considered terrible form to use it 'IRL'. Though there is a public_send which is a non-boundary-violating version too).
Also in my opinion, unless you're developing a framework or something, metaprogramming (things like define_method etc) are Considered Harmful 95% of the time (at least in Ruby), as I think only about 5% of Ruby developers even grok it enough to work in a codebase with that going on. So while it might seem clever to a Staff Eng with 15 years of Ruby experience, the less experienced Rubyist who is going to be trying to maintain the application later is going to be in pain the whole time due to not being able to find any of the method definitions that appear to be being called.
I disagree, I use metaprogramming in application code quite regularly, although I tend to limit myself to a single construct (instance_eval) because I find that makes things more manageable.
In my opinion the main draw of Ruby is that it's kind of Lisp-y in the way you can quickly build a metalanguage tailored to your specific problem domain. For problems where I don't need metaprogramming, I'd rather use a language that is statically typed.
The two are not mutually exclusive. On many occasions I've used C# to define domain-specific environments in which snippets of code, typically expressions, are compiled and evaluated at runtime, "extending the language" by evaluating expressions in the scope of domain-specific objects and/or defining extension methods on simple types (e.g., defining "Cabinet" and "Title" properties on the object and a "Matches" extension method on System.String so I can write 'Cabinet.EndsWith("_P") || Title.Matches("pay(roll|check)", IgnoreCase)').
I don't think instance_eval is too nasty. The toughest "good" codebase I've worked in was difficult because it used method_missing magic everywhere, which built tons of methods whose existence you had to just infer, based on configuration stored in a database. So most method calls could not be "command clicked" or whatever to jump to their definition, because none were ever defined.
Ah, I just started with the basic idea. They're super trivial. You want a loop, but the loop can't be infinite so you need to tell the agent to tell you when to stop and to backstop it you add a max_turns. Then to start with just pick a single API, easiest is OpenAI Responses API with OpenAI function calling syntax https://developers.openai.com/api/docs/guides/function-calli...
You will naturally find the need to add more tools. You'll start with read_file (and then one day you'll read large file and blow context and you'll modify this tool), update_file (can just be an explicit sed to start with), and write_file (fopen . write), and shell.
It's not hard, but if you want a quick start go download the source code for pi (it's minimal) and tell an existing agent harness to make a minimal copy you can read. As you build more with the agent you'll suddenly realize it's just normal engineering: you'll want to abstract completions APIs so you'll move that to a separate module, you'll want to support arbitrary runtime tools so you'll reimplement skills, you'll want to support subagents because you don't want to blow your main context, you'll see that prefixes are more useful than using a moving window because of caching, etc.
With a modern Claude Code or Codex harness you can have it walk through from the beginning onwards and you'll encounter all the problems yourself and see why harnesses have what they do. It's super easy to learn by doing because you have the best tool to show you if you're one of those who finds code easier to read that text about code.
At the core, they're really very simple [1]. Run LLM API calls in a loop with some tools.
From there, you can get much fancier with any aspect of it that interests you. Here's one in Bash [2] that is fully extensible at runtime through dynamic discovery of plugins/hooks.
Really, of the tools that one implements, you only need the ability to run a shell command - all of the agents know full well how to use cat to read, and sed to edit.
(The main reason to implement more is that it can make it easier to implement optimizations and safeguards, e.g. limit the file reading tool to return a certain length instead of having the agent cat a MB of data into context, or force it to read a file before overwriting it)
This weekend I installed Hermes on my computer. My M4 Max Studio started spinning its fans as if it wanted to fly, so I went for some cloud hosted models. The thing works as advertised, but token consumption is through the roof. of course ymmv depending on the LLM you choose.
But my main takeaway is that from the security standpoint this is a ticking bomb. Even under Docker, for these things to be useful there is no going around giving it credentials and permissions that are stored in your computer where they can be accessed by the agent. So, for the time being, I see Telegram, my computer, the LLM router (OpenRouter) and the LLM server as potential attack/exfiltration surfaces. Add to that uncontrolled skills/agents from unknown origins. And to top it off, don't forget that the agent itself can malfunction and, say, remove all your email inboxes by mistake.
Fascinating technology but lacking maturity. One can clearly see why OpenAI hired Clawdbot's creator. The company that manages to build an enterprise-ready platform around this wins the game.
Hype, mainly buying Hype before their IPO. The project is open source and the thinking behind it is not difficult, if they truly wanted they could have done it a long time ago or even without the guy. It was a pure hype 'acquisition' of a project that become popular for amateur programmers that got into it through vibe-coding and are unaware of the consequences and security exposure they subject themselves at.
This is the Siri-brained explanation. The Apple AI assistant has been stagnant for 10 years. Therefore assistants as a whole cannot be good.
This is so clearly the next step from Siri to Alexa to {Openclaw like technology}, that is an interface to technology that loads of people find value in everyday, and loads of people complain doesn’t have enough capabilities.
I also expected screenshots there, especially given the word "interface". Turns out, it's not about user interface (UI), it's about programming interface (kinda API). It allows calling window-related functions on Macintosh, X Window System, and Atari. So the resulting windows were looking like a native UI, I assume.
The readers' natural question is 'does this look reasonable on multiple platforms?'. A two-second glance at two or three screenshots goes a long way to answering that.
In hindsight, this sounds more reasonable in 2026 where graphical documentation is taken for granted. In those days I think anyone would have spooled the .ps to their nearest laser printer and begin building something quickly with it just to check the looks.
I remember following a "build your own text windowing system" tutorial printed in a hcontinous paper back then
The document looks to be nicely rendered, likely from Postscript. Maybe generated by roff, since it doesn't look like TeX. Screen cap bitmaps could be converted to EPS and inserted into the Postscript.
If it was a PS document, you would have to spool it to a printer or screen renderer to read it anyway. The X Window System debuted in 1984, so on-screen renders would have been not too hard to find in a CS department in 1989.
Back in the day, in Operating System Design class I dared to suggest the teacher that for some obscure inode related problem the system should ask the user what to do.
His answer was "We are designing an operating system, not a messaging solution".
This was circa 30 years ago of course, and the essence and complexity of what an OS is today is different, but the idea still resonates in my head every time macOS deploys one of these prompts at me.
Somewhere in early MacOS design guidelines I remember it saying that settings/prompts were a design failure that put a burden on users. Something really has been lost on the design team.
I know the landscape is different – more liability , regulation etc. But Lawyers will always overreach on compliance and notice. Even to the point of making the app useless.
They are expecting the product team to be forceful.
A positive example is that I noticed most EVs have a lot of consent prompts and warnings (e.g. a warning to look at the backup camera, and a consent prompt to comply to never using the nav/infotainment while driving) – but Tesla’s do not. I imagine Elon being very demanding that the experience take precedence.
Light from the sun that is reaching us now escaped the surface of the sun 8 minutes ago, yes.
But photons are generated in the core through nuclear reactions, where they take their sweet amount of thousands of years bouncing around until they get out.
I think this is right in a certain sense, but not precisely. From what I understand no visible light photons are created in the core from nuclear fusion, it's mostly a bunch of gamma rays that get almost immediately absorbed. The energy, but not the photons from fusion, gets transfered up through the layers of the sun, through radiation and convection, eventually heating the photosphere. It is then the photosphere, white hot, which ultimately radiates the visible light we see as sunlight.
Thanks for your answer, I understand you're correct. Also, as another counterargument, if a photon is scattered... is it the same photon or a different one? Your perspective on energy instead of particles is better.
reply