Just realized the halting problem is decidable for functional programs 😂
05.03.2026 15:35
👍 0
🔁 0
💬 0
📌 0
Just realized the halting problem is decidable for functional programs 😂
Let's take Rails Contributors (contributors.rubyonrails.org) as another example, an application I wrote in 2008 and have maintained ever since with @rmfranca.bsky.social.
If things degenerate too much, we could well freeze it and leave it as a symbol of a past time.
Before (!?), there was a huge human aspect in all this. Let's take it to the extreme: If you knew someone solved AoC in assembler, or doing some crazy Excel stuff, that was like WOOOW.
Now, AoC in assembler done by a LLM is 1) admiration for the tech 2) total meh for who wrote the prompts.
I also struggle with this, and not only in OSS.
Who I am talking to? Who deserves the credit? Because you can use an agent as a tool to speed you up, still having full agency about what is going on, but a different thing is talking to someone that has not made the effort to understand the problem.
Gasp, got my first smartwatch 😅
LLMs make mistakes.
Well, what about our bloated designs, degraded code bases, need for mentoring, need for code reviews, and busy exception tracking services say about us?
I read in pragprog's newsletter that AI seems to be reducing people's need for books.
I guessed that.
But there is something that does not add up to me. If you don't train, you won't be able to spec, steer, and review.
Is like, a hole in knowledge is forming world-wide, just give it time.
I have had some gigs like that: a CTO wants to do something that is scoped a well-suited for independent work (coordinated with anyone affected). It has to be done and can afford it, but the day to day eats them. You enter, do it, and shake hands.
Alternatively, hire a consultant to focus on the epic till completion, working in a parallel universe out of the day to day 😀.
Awesome episode of Star Talk on AI with Nobel laureate Geoffrey Hinton.
AIs do not hallucinate, they _confabulate_, just like humans do.
They may sense you are testing them and adapt their responses.
A lot of stuff in one hour and a half of conversation.
startalkmedia.com/show/the-ori...
While the analogy might not be exact, this kind of reminds me of astronauts.
When USA wanted to go to the Moon, they wanted the best test pilots.
Chuck Yeager explains in his biography that they had little interest the moment they realized a rocket was not piloted (Chuck declined).
I mean, appreciating what the system is able to do is fun and impressive, you certainly enjoy that aspect of it.
But it is a different angle. I don't know if I would be attracted to this kind of programming if I was a kid today.
Agentic dev is mindblowing, we could not dream this was remotely possible.
But it is less fun.
My OSS is written by hand. Because I program not only as a means to solve a problem, but to enjoy the process.
Just like motorbike touring is about enjoying the ride, no just going from A to B.
mise now supports precompiled Ruby binaries (learned this from @nateberkopec.bsky.social's newsletter).
Right now you have to opt-in in the config file, but it will become default later.
See: mise.jdx.dev/lang/ruby.ht...
@antirez.bsky.social experiments and shares a lot
@thorstenball.com newsletter
The organic neural network inside my cranium has generated Zeitwerk 2.7.5.
This is a maintenance release, performance improvements, uses `Dir.scan` if available (only in Ruby `master` for now), docs, and quite a bit of internal work.
Wonder if mobile app stores are getting an avalanche of AI-generated apps
Are we going to generally see less interest in learning new programming languages? Even less motivation for creating new ones?
That's it!
For require_relative, you'd do it e.g. the way Zeitwerk itself does it: see github.com/fxn/zeitwerk...
I put things in the module body because I am strict about who creates namespaces, but could be at the top.
autoload_relative closes that gap for autoloads. Can elaborate the pattern if you will.
What about client projects wanting to cherry-pick something form the gem to make sure it is available?
No longer a need, because in that scenario everything is available everywhere, as in projects managed by Zeitwerk.
I would go to the extreme of gems being able to opt-out of adding lib to $LOAD_PATH.
You'd say: This is my entry point, no need to add my lib to $LOAD_PATH.
This already happens in Rails apps, autoloaded directories are no longer in $LOAD_PATH, you don't need them there anymore.
For gems without an autoloader, you use require_relative for eager loading, and autoload_relative for lazy loading.
It is a waste of resources to trigger a lookup for something internal you control.
And they also promote nicely organized and predictable code bases.
I think autoload_relative is a big deal, not for Zeitwerk (Zeitwerk already uses absolute paths exclusively), but for Ruby.
My personal hunch is that $LOAD_PATH lookups should be eliminated, and Kernel#require deemphasized.
Let me elaborate.
Just landed in Ruby master:
Dir.scan: List directories with entry types using half the syscalls (mod :unknown), by @byroot.bsky.social: github.com/ruby/ruby/co...
autoload_relative: Like require_relative, but for autoloads, by @ioquatix.bsky.social: github.com/ruby/ruby/pu...
Selfie with the stadium of FC Barcelona during construction works in the background.
The new Camp Nou is slowly taking shape.
FC Barcelona is already playing there, with partial capacity. Construction work is ongoing in the upper tiers and surroundings.
The stadium goes deeper than it appears, the pitch is below ground level.
Boxes do not form a tree either, it is all flat.
When thinking about the new **experimental** Ruby::Box, you cannot have a fork mental model.
A box is a blank slate that inherits nothing from who created it.
You start from scratch, no gems loaded (conceptually), no monkey patches in place, etc.
Cool one.
I have always said: Your monolith is not such, you already have a SOA.
You did no write Redis, Sidekiq, or the error tracker, but SOA is about splits, responsibilities, communicarion, etc. If the service was developed in-house or not does not matter.
www.iankduncan.com/engineering/...
