▲ | xelxebar 7 hours ago | |||||||
You stole the words from my mouth! One of the issues DSLs give me is that the process of using them invariably obsoletes their utility. That is, the process of writing an implementation seems to be synonymous with the process of learning what DSL your problem really needs. If you can manage to fluidly update your DSL design along the way, it might work, but in my experience the premature assumptions of initial designs end up getting baked in to so much code that it's really painful to migrate. APL, on the other hand, I have found extremely amenable to updates and rewrites. I mean, even just psychologically, it feels way more sensible to rewrite a couple lines of code versus a couple hundred, and in practice, I find the language to be very amenable for quickly exploring a problem domain with code sketches. | ||||||||
▲ | skydhash 3 hours ago | parent | next [-] | |||||||
I was playing with Uiua, a stack and array programming languages. It was amazing to solve the Advent of Code's problems with just a few lines of code. And as GP said. Once you got the right form of array, the handful of functions the standard library was sufficient. | ||||||||
▲ | marcosdumay 2 hours ago | parent | prev [-] | |||||||
> One of the issues DSLs give me is that the process of using them invariably obsoletes their utility. That means your DSL is too specific. It should be targeted at the domain, not at the application. But yes, it's very hard to make them general enough to be robust, but specific enough to be productive. It takes a really deep understanding of the domain, but even this is not enough. | ||||||||
|