What a respectfully and humbly written comparison page. Ditto for their Supabase comparison. I can't rate the objectivity since I know very little about TrailBase but they got my attention now. It brings me such joy to see such a writeup in a world where humility is perceived as weakness. Kudos.
As a person who knows next to nothing about how the brain or the genes that configure it work, I tend to think of this in terms of 80s video games like River Raid. The level data for these games, if stored naively, would fill the computer's available memory many times over. So they just store a pseudorandom number generator seed along with a few other parameters. Coupled with a few rules to make the level playable, it can generate a seemingly impossible number of levels with very little stored data.
Maybe the genes just encode a few crucial rules and the rest just emerge from that.
Oh, and I know even less about how the universe works. But I tend to think of it in the same terms: Emergent phenomena stemming from simple rules à la Game of Life.
Ever since I read about Rodney Brooks and his idea of the Subsumption architecture I've been convinced that something like this is going on in our minds - likely with some other mechanisms too. It just clicks for me - I'm mostly likely completely wrong, but it's a pretty cool idea, and I've used it to create some really interesting simulations.
It's all about context, isn't it? "Humans vs. animals" is an important distinction to make in some contexts and useless in others. Insisting on the fact that humans are also animals if we're talking about, say, "language in humans vs. animals" is unproductive. It just makes discussions harder by forcing everyone to add "_non-human_ animals" to every mention. But if we're talking about, say, cellular biology, it's unproductive to force everyone to write "human and animal cells" instead of just "animal cells".
Similarly, distinguishing between transpilers and compilers might be important in some contexts and useless in others. Transpilers are source-to-source compilers, a subset of compilers. Whether it matters depends on the context.
For six years I worked in a SaaS startup that built an applicant tracking system (a tool to manage recruitment efforts in big/mid-sized companies) tailored for the local market of the country we lived in. My experience tells me that our main value was in forcing them to rethink their recruitment processes, not adapting to their existing ones that were usually all over the place.
As much as I want to believe the opposite to be true as a “power user”, good tools often force you to adopt better practices, not the other way around.
> good tools often force you to adopt better practices
Just wanted to highlight this excellent statement. It's like having a strict type system that enforces certain rules are always met. It provides consistency and predictability.
> rethink their recruitment processes
This context is relevant to the kind of software system that was needed. To improve their processes, it was necessary to impose an explicit top-down order to the existing mess.
Malleable software, on the other hand, feels more suited for personal computing, greenfield projects, or small teams with members working independently as well as collaboratively. Particularly in the early stages of product R&D, strict rules can be a source of friction in the creative process.
Strict better practices and well-designed tools are discovered and developed through open and flexible explorations, as a kind of distillation of knowledge and experience.
I worked for a company that provided a mobile friendly job application form that integrated with major applicant tracking systems (back when they didn’t provide mobile friendly forms).
Our biggest value was getting customers to remove all the extra questions on their applications that had built up over years of management changes that no one had any idea why they were even asking.
Absolutely. When we started growing (I was employee #3, we were about 20 people when I left), we didn't use our own product for our own needs. It wasn't designed for a tiny startup, it would be like building a sand castle with a bulldozer.
But we started as a "boutique" company that implemented everything requested by our then small number of clients (mainly out of desperation, we were self-funded and we didn't have much leeway, we needed those clients). It was as flexible as it gets before the LLM times.
But after a while, you start noticing patterns, an understanding of what works and what doesn't in a given context. Our later customers rarely requested a feature that we didn't already have or we didn't have a better alternative of. It's not like we had a one-size-fits-all solution that we forced on everyone. We offered a few alternative ways of working that fit different contexts (hiring an airline pilot is a very different context than hiring a flight attendant). And in time, this know-how started to become our most important value proposition.
At some point we even started joking about leaving the software business and offering recruitment consulting services instead.
In fewer words: It was already a fairly flexible and customizable tool. But then came a time when a client requested faster horses we could show them our car instead and they recognized the value. (And occasionally, when _they_ requested a car instead of our faster horses, _we_ recognized the value and implemented it).
I write some of my thoughts on this sone years ago. The library described at the end is now fairly out of date but the ideas and suggestions are still good, I think.
reply