Domain-Specific Languages
One of my take-aways from "Software Design for Flexibility" is that in the debate between implementing a domain-specific language or a library, a DSL is the correct choice.
Software Design for Flexibility
Given that, I've found some cool DSLs lately (sorry if this post turns into a bookmark collection). I've been a fan of the logic programming paradigm for some time, so I tried to search for languages like that. But for some categories it didn't really work out.
Logic Programming Paradigm
*Interactive Fiction*: Dialog. This was new to me.
*Multi-core programming*: (Flat) GHC. Given that every computer I own now has at least 8 cores, this could be considered stretching the definition of domain-specific and in fact be the new general case.
*Web programming*: You can generate quite a lot from the BCHS opendradtool tool. Part of this is a C implementation that is easily wrapped for use in FGHC (above). You could also probably wrap the generated client code from Tau Prolog, which is a transpiler to JavaScript, but I haven't tried it yet.
openradtool, generates client & server code for database Web apps
Miscellaneous Paradigms
*Document processing*: This is an update to a previous gemlog entry of mine. Use plain lowdown as long as you can, maybe even generating gemtext. Then if you're thinking of making money from documents rather than the associated product/service, switch to the Djot input format (possibly with ypp, PlantUML or pikchr) and output Typst. For stuff that isn't in the input tools like bibliographies, just write Typst fragments in the Djot.
Previous document processing recommendations
Lowdown, a lightweight markdown processor (which can generate gemtext)
Pandoc, a comprehensive document processor
ypp, successor to Panda markdown preprocessor
PlantUML, for software design diagrams
Typst, a likely LaTeX successor
*Maths*: For exploratory programming, J. If you get to the point where you need to run for weeks on a cluster (I never did), rewrite in Chapel. Neither are logic programming languages, but still the best I found.
Conclusion
It seems that a purely general-purpose language like Ada/C++/Rust is rarely the correct choice. This echoes an old work experience of mine, where we implemented a private branch telephone exchange (PBX) on top of an interpreter for a subset of C. Would have been much easier to just use Erlang for that project.
Source