I was just explaining this exact thing to somebody a couple days ago - even used ERP as the example. Hear hear, sir

whartung 2 hours ago | parent | next [-]

I dunno.

When it comes to back office business programming, there’s just a lot of code tasked with copying a litany of bits of data from one structure to another.

Whether it’s copying a web form into a database, or converting Their JSON to Your JSON, it’s a lot of detail that does not abstract well. It’s all shapes and sizes and formats, and it almost always has to be enumerated in excruciating detail and, typically, twice.

Sure, there’s logic and whatnot involved, but it, too, is specific to some subdomain of the larger system and it, too, does not abstract well. Not in the large context of the overall system.

Accounts Payable and Accounts Receivable, at 10,000 feet look almost identical. They’re almost literally the same thing with the sign flipped. But in practice, they don’t share code well. You end up with two similar systems, but not similar enough where sharing is actually worthwhile.

At best they can leverage a common API to the GL.

Turns out a lot of languages can manifest a decent level of abstraction. But even then, folks push back.

Consider the love/hate relationship with ORMs. Or the annotation driven markup in Java programs and the underlying “magic” that they enable. Like scribing mystic runes onto things.

Those are both very powerful, yet folks experience that and toss their hands in the air and throw out the baby with the bath water and jump into something “magic free” like Go.

Just because you can use something like CL to “make your own magic”, doesn’t mean it’s a good idea. Doesn’t mean it scales. Doesn’t mean it communicates well to others. AI or no.

It’s not the AIs world yet. We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own. I’ve already seen crass examples of “code only an AI could love”. Completely impenetrable, at least to me. May as well have represented it as a color image and collection of RGB values. Opaque to me, but the AI could “read” it.

There is much more to programming and systems than token density, and AI is still getting cheaper by the day, so less reason to even pre-optimize for it anyway.

	▲	sroerick 2 hours ago \| parent [-]
		There's lots of examples of DSLs being unreasonably useful in industry even prior to LLMs. While I am extremely taken with Lisps and the lisp way of doing DSLs, I would probably go with an OCaml to make a DSL for a company specific ERP. It seems a better way to go about the problem. Lisp, on the other hand, I have found to be extremely good at domains which seem the same but which are tremendously different. For example, a workout app is a surprisingly complex domain. Different exercises have different storage models and functions, as do different training sessions and different programs. Rather than try to build a monoprogram, one training app to rule them all, I find lisp wonderful for making "microprograms". This bears resemblance to Accounts Payable and Accounts Receivable but I don't think Lisp would be a good fit for those. Perhaps a Lean or a Rocq, something with proofs. > We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own. My agents seem to really like Tree Calculus and have bullied me into working on a language which uses it.

▲

tzmudzin 2 hours ago | parent | prev [-]

... and I think you will both find it intellectually stimulating to explore the complexity behind ERP systems that makes a common DSL near impossible across industries, or as businesses change.

DSL presumes agreement on semantics, and that's often the most difficult part.

▲

sroerick 2 hours ago | parent [-]

So why not a DSL for a specific business?

▲

tzmudzin an hour ago | parent [-]

At least two reasons:

- economies of scale no longer work, and you end up doing a custom ERP for your business from scratch.

- your business changes might invalidate your model quickly. You sell through distributors, but open an online shop -- and suddenly your customer is not one of few dozen well-known businesses with a known address and tax number, but user2252 who bought something late at night last night. And you want to understand the needs and behaviors of both.

▲

sroerick 42 minutes ago | parent [-]

Do LLMs change that equation?

	▲	tzmudzin 33 minutes ago \| parent [-]
		We will see, but (first thoughts): - for the economies of scale, you might develop your custom solution 20x faster now, but you're still in competition with the established provides with templates for most of the cases (who btw have the same LLM capability at their disposal) - for the change in business -- you can ask an LLM which changes this induces, and it will give you most typical impacts. And then you're back at square deciding if it's better to roll your custom DSL and the custom system downstream, or just use off-the-shelf stuff that covers 95% of it from day one (well, maybe day two or three)