Both model prompts as functions. BAML is a DSL - write .baml files, generate code, get validated structured outputs.
DSPy is a programming paradigm. I like to look at it like the MVC for the Web. You define Signatures[0]: typed contracts governing the relationship between your models and your app. Signatures model prompts as functions too, without leaving Ruby. Then compose them into modules (Predict, ChainOfThought, ReAct, your own). The framework can automatically optimize prompts based on your metrics.
DSPy.rb brings the DSPy paradigm's tooling (optimizers, evaluation loops) to Ruby. Comes with OpenTelemetry OOTB. It also borrows BAML's schema format for 85% token savings vs JSON Schema in complex signatures. [1]
Everyone is talking about prompt, context, and harness engineering -and I agree they are good ways to frame how to build workflows and agents- this is just programming really.
"Marshall McLuhan once said, 'There is absolutely no inevitability as long as there is a willingness to contemplate what is happening.' The handwaving rhetoric that I’ve called a Borg Complex is resolutely opposed to just such contemplation when it comes to technology and its consequences. We need more thinking, not less, and Borg Complex rhetoric is typically deployed to stop rather than advance discussion. What’s more, Borg Complex rhetoric also amounts to a refusal of responsibility. We cannot, after all, be held responsible for what is inevitable. Naming and identifying Borg Complex rhetoric matters only insofar as it promotes careful thinking and responsible action."
Although Immich does backup from your phone, I don't see it as a viable backup solution. Git-annex, Unison, and Syncthing are much better at keeping files synchronized across devices. Immich will create its own copies of photos and transcode videos for playback on the web. That may be fine if you have enough storage space, but for me it makes the phone backup useless. I suppose you could use a git-annex special remote directory as an Immich external library.
I feel sorry for juniors because they have even less incentive to troubleshoot or learn languages. At the same time, the sheer size of APIs make me relieved that I will never have to remember another command, DSL, or argument list again. Ruby has hundreds of methods, Rails hundreds more, and they constantly change. I'd rather write a prompt saying what I mean than figure out obscure incantations, especially with infrequently used tools like ffmpeg.
> Should I use AI to solve Advent of Code puzzles? No. If you send a friend to the gym on your behalf, would you expect to get stronger? Advent of Code puzzles are designed to be interesting for humans to solve - no consideration is made for whether AI can or cannot solve a puzzle. If you want practice prompting an AI, there are almost certainly better exercises elsewhere designed with that in mind.
I would advocate for Advent of Code in every workplace, but finding interest is rare. No matter how much craft is emphasized, ultimately businesses are concerned with solving problems. Even personally, sometimes I want to solve a problem so I can move on to something more interesting.
The probability space of a 140-nucleotide chain is 10^84. The estimated number of atoms in the universe is 10^80. The hypothesized RNA self-replicator is far simpler than the 238,000 base pair archaeal genome. But how are they formed? Even the most favorable prebiotic lab conditions have only produced short nucleotide chains. Direct chemical synthesis only recently achieved chains over 1700 nucleotides long [1].
To go through all 10^84 possible combinations in a billion years, around 10^67 combinations would have to be "tried" per second. So yeah, it doesn't seem feasible to have one and only correct combination of 140 nucleotides spontaneously appear.
But if the "solution" could be composed of a couple of separate smaller parts, that would be stable and linger for a long time, it would be much easier. 40 nucleotides have 10^24 combinations, so only 10^7 tries per second would be needed... over a billion years. And all of the necessary parts would need to be created and then meet in the same place and somehow combine. So, still not easy, but this case doesn't sound so outrageously improbable.
In the end, maybe it is extremely improbable for life to happen, and only one in 10^n suitable planets develops life, and Earth was just very lucky to experience this peculiar phenomenon.
Agreed, in the sense that software development is an iterative process of trial and error similar to custom car building. But software isn't like a car. It's more like a car factory. It should produce something of value repeatedly.
Isn't the intelligence of every other person alien to ourselves? The article ends with a need to "protect our own engineering brands" but how is that communicated? I found this [https://meta.discourse.org/t/contributing-to-discourse-devel...] which seems woefully inadequate. In practice, conventions are communicated through existing code. Are human contributors capable of grasping an "engineering brand" by working on a few PRs?
> Isn't the intelligence of every other person alien to ourselves?
If we agree that we are all humans and assume that all the other humans are conscious as one is, I think we can extrapolate that there is generic "human intelligence" concept. Even if it's pretty hard do nail it down, and even if there are several definitions of human intelligence out there.
For the other part of the comment, not too familiar with Discourse opensource approach but I guess that those rules are there mainly for employees, but since they develop in the open and public, they make them public as well.
My point was that AI-produced code is not so foreign than no human could produce it, nor do any two humans produce the same style of code. So I'm not sure exactly what the idea of "engineering brand" is meant to protect.
reply