Stop Torturing Your Colleagues with DSLs
The article critiques Domain-Specific Languages (DSLs) for complicating development, suggesting well-designed libraries as more efficient alternatives that offer similar functionality without steep learning curves and maintenance issues.
Read original articleThe article critiques the use of Domain-Specific Languages (DSLs) in programming, arguing that they often complicate rather than simplify development processes. While DSLs may seem appealing as specialized tools, they typically create significant challenges, including steep learning curves, maintenance difficulties, and communication barriers. The author emphasizes that only a few developers, those who created the DSL, can effectively navigate these languages, leaving others stranded with complex and poorly designed systems. Furthermore, the departure of DSL creators can lead to a loss of crucial knowledge, exacerbating the issues for remaining team members. Instead of creating a new DSL, the author suggests that developers should consider using well-designed libraries, which can provide similar functionality without the associated costs of learning and maintenance. Libraries built on general-purpose languages also benefit from broader community support, making them more accessible and efficient. The article concludes with a call for developers to reconsider the necessity of DSLs and to prioritize practical, straightforward solutions that do not burden their colleagues.
- Domain-Specific Languages (DSLs) often complicate development rather than simplify it.
- Only a few developers can effectively use DSLs, leading to knowledge gaps when creators leave.
- Well-designed libraries can provide similar functionality without the steep learning curve of DSLs.
- Libraries benefit from community support, making them more efficient and accessible.
- Developers should critically assess the need for DSLs before creating them.
Related
Defense of Lisp Macros
The article highlights challenges in automotive software development, emphasizing reliance on C, fragmentation from specialized tools, and advocates for powerful languages like Lisp to improve efficiency and integration.
Micro-libraries need to die already
The article critiques micro-libraries for introducing complexity and security risks, advocating for developers to use simple utility functions instead, which can reduce dependency issues and improve code efficiency.
Breaking Changes: A Tooling Problem
Richard Marmorstein discusses the challenges of managing breaking changes in library development, emphasizing the need for better tooling and definitions to support library maintainers and enhance usability for diverse users.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.
The Liberating Experience of Common Lisp
The author critiques modern programming languages for their complexity, praising Common Lisp for its stability, unique developer experience, and creative freedom, making it preferable for software development.
Perhaps the difference is that my DSLs are hosted on Lisp, so inherit that syntax. The nouns and verbs I create extend the standard library transparently. There is nothing to learn but the vocabulary. So perhaps programmers who aren't confident about language design should avoid creating DSLs that aren't hosted on a good general purpose language. Everyone else should write DSLs on top of Lisp the way God and John McCarthy intended.
Which probably requires making them in a language that is prone to extensibility to so you can just reuse existing tooling.
Instead a lot of DSLs happen the way IBM JCL happened - it was explicitly not supposed to be in any way a programming language, was to be fully declarative, but it quickly evolved beyond that creating the monster some of us know.
Related
Defense of Lisp Macros
The article highlights challenges in automotive software development, emphasizing reliance on C, fragmentation from specialized tools, and advocates for powerful languages like Lisp to improve efficiency and integration.
Micro-libraries need to die already
The article critiques micro-libraries for introducing complexity and security risks, advocating for developers to use simple utility functions instead, which can reduce dependency issues and improve code efficiency.
Breaking Changes: A Tooling Problem
Richard Marmorstein discusses the challenges of managing breaking changes in library development, emphasizing the need for better tooling and definitions to support library maintainers and enhance usability for diverse users.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.
The Liberating Experience of Common Lisp
The author critiques modern programming languages for their complexity, praising Common Lisp for its stability, unique developer experience, and creative freedom, making it preferable for software development.