Ruby Was Ready from the Start
obie.medium.com
obie.medium.com
Is he saying that Ruby is better for LLM programming? That’s hard to imagine because strong typing has to be a big help for automated programming tools and Ruby is behind all the other modern languages on typing.
However doing actual manual coding starts to feel weird as well
I have a feeling the job's about to get a whole lot shittier.
The thing that made our crowd apart in the work society is now vanishing, that’s sad.
I wonder how future movies will depict programmers: depressed faces getting angrier and angrier chatting with a CLI coding agent! This will not inspire future generations!
What I can't stand even though I tried quite a bit is talking to the damn clanker at length to describe step-wise what I believe needs to be done, and keep waiting, reviewing, telling it what's wrong, waiting, reviewing, I don't think I'm at a stage where I have the mental capacity to be running dozens of clankers at once doing all their changes on their own, and just reviewing later. It's absolutely exhausting and joyless, I've tried, and at the moment it's not for me.
And just up and changing companies is also not a realistic option for many, before people start bleating that tired, privileged trope.
I asked Claude to help me out with an issue I was having with a small renderer I was working on, it fixed the issue but also added a memory leak, the leak was easy enough to fix because I fully understood what was going on but if you’re vibe coding and don’t have the skills to debug yourself you’re going to have a bad time.
In the end I don’t like using LLMs for coding but they are good at solving isolated problems when I get stuck. I prefer it when they review my code instead of writing it for me.
They can generate stuff, but generally I spend so long fixing it manually that it makes the time savings zero or negative.
Only thing I have found useful is the PR review bot. That thing is genuinely incredible at spotting tiny mistakes in massive PRs that make your eyes glaze over.
https://tech.lgbt/@graeme/115608630019342209
We marry the user guide or reference manual to the unit tests into a single live markdown file. Intent and verification in a single package.
The a
The live markdown provides a substrate that causes the tests to run when the user guide or reference document is read. We use these reference documents in place of specs in our development, they're the same information in different form (input vs output in the whole affair when treated typically) so why not just use them that way? And marrying the unit test to them provides instant verification.
During the development process, any agent (or human) accessing the spec will also receive the current state of development free (relatively... the tests need to run) of charge.
Afterwards, the tests remain, ideally green, but as an indicator anytime anyone (agentic or human) needs a refresher on whatever that feature might have been. Tucked away down at the bottom of the page somewhere, the tests stay active so that we have an on going drift/regression detector embedded in the document that describes its function. When the entire platform is based on Turing complete markdown, it helps to keep things flowing in the right direction.
There's a larger write up (and the odd shitpost) here https://www.graemefawcett.ca/blog/little-things/ if you're interested
This I think proves the power of what Obie is saying. We do RSpec now and it's glorious
https://tech.lgbt/@graeme/115622344011576598
That shows how we can create a single node on the graph with a pair of {{include:statements}} and a bit of ${interpolation:based-pointer.math} and poke and peek tools in an MCP proxy turns a markdown file into an Rspec test runner, just by reading the file. And that same {{include:}} lets me drop that pattern anywhere I want all over the graph, which is pretty neat.
Obie's definitely on to something with this. There's a rather lot of negative emotion surrounding the changes to our profession. There's a certain lack of joy bleeding through many of the comments. Computing doesn't have to be that way, didn't used to be anyways. If you're smart about your verification process, if you're smart about optimizing the framing of your intent, this isn't a scary world we're all crashing headlong into. Remember what they're for - they're generative not thinking - and they'll serve you well.
Or not
They can be little gooses sometimes ;)
> Most of all, it promised a much bigger paycheck!
Tell us about this part, son, so far you’ve been only spewing same Agile/Xtreme shite we’ve been hearing for decades.
"Agile/XP" is a big bag of many ideas. Some of them aren't related, but they all get stuffed in that bag.
Personally, I enjoy pair programming, which is the literal experience of dealing with an (agentic) AI for the purpose of programming.
Tests (regression tests, unit tests, integration tests, ...) make development easier in that they tell you right away when you took a wrong step. You don't have to test manually anymore, so that saves you time and concentration, and you can test a lot more often.
Those are the good bits of "Agile/XP".
You mean "not statically typed". Which also applies to Javascript, PHP, Python, ... so if that critique doesn't stick to those, it's not a critique you can level at Ruby.
But it does have extremely powerful metaprogramming capabilities which are regularly abused by those not wise enough to know that just because you could do something doesn't mean that you should.
I regularly code in a variety of languages from C / C++ through Python and Ruby through to Haskell. They all have their advantages and disadvantages. All of them are capable of abuse by the sufficiently determined. And unit tests are helpful in all of them.
I’ve worked on rails apps for the last 9 years and I’d guess 80% of the bugs that show up on production would have been flagged by typescript.
Which is what the Ruby test-heavy culture is all about. I prefer types for this very reason; the compiler/checker is a complete suite of testing I don't have to write.