> Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases > easier to understand, re

> Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases > easier to understand, reason about, more reliable, more maintainable I find DSLs obfuscating, buggy, and unmaintainable. I know we're going to agree to disagree here, as I'm a fan of the Java, Go, C, or even Python side of things, I find most DSLs are a nightmare. Maybe we work on vastly different software. Most DSLs, imho, are usually better off removed. It's part of a class of code smells I like to call: Sound concepts applied too liberally and out of context. It's the same sin as the "Architect Astronauts" of Java Enterprise FizzBuzz Design Pattern overload. Python and monkey patching abuse. JavaScript and framework explosion. C++ had operater overload abuse. Every language seems to go through it's awkward teen years and finds a good balance eventually, so I don't mean to rag on DSLs. The problem is: DSLs usually work well when the problems are well defined, common, and relatively static. SQL comes to mind. BLAS/numpy like programs. If the DSL models business or application ideas, those will grow and shift. If I find myself fixing bugs in the compilers, I need a different language. That's what DSLs end up as: half-designed specs I need to fix.