Defense of Lisp macros: The automotive field as a case in point
Advocates of Lisp macros argue that powerful metaprogramming could replace today’s sprawling ecosystem of domain‑specific tools, pointing to automotive software — with its mix of C, Simulink, statechart tools, A2L/XCP, and ad‑hoc scripts — as an example of unnecessary complexity. Others counter that macros are hard to reason about, hurt tooling, and can create opaque DSLs, which is why even modern Lisps like Clojure encourage restraint and why industry gravitates toward “simpler” languages plus code generators and visual environments. The exchange broadens into questions of CS education, the trade‑off between power and maintainability, and why Lisp’s core ideas (like garbage collection and dynamic data structures) have spread widely while S‑expressions and macros remain niche.
Lisp macros: power and pitfalls
- Macros enable DSLs, sophisticated syntactic abstractions, Yacc/Bison‑style code, test frameworks, contracts, and instrumentation without external tools.
- They act as an “escape hatch” when normal abstractions fail, and can enforce invariants that are hard to encode otherwise.
- Downsides: they introduce a meta‑level that complicates reasoning, debugging, and error messages; tooling and IDE support often lag.
- Overuse leads to opaque, ad‑hoc languages inside projects that are hard for new contributors to learn. Several commenters describe a progression: fear → overuse → cautious, minimal use.
Visual and domain-specific tools in automotive/control systems
- Automotive and controls engineers rely heavily on tools like Simulink, Stateflow, Matlab, ladder logic, and statecharts.
- These grew directly out of long‑standing engineering notations (block diagrams, signal‑flow graphs, relay diagrams) rather than from programming culture.
- Visual models are appreciated by non‑programmers and can clarify complex control logic and concurrency, but can become rats’ nests, obscure underlying equations, and hinder testing and refactoring.
- Some see the profusion of specialized tools and standards (e.g., XCP/A2L) as evidence of Greenspun’s rule; others just see necessary domain‑specific complexity.
Language adoption, “Lisp curse,” and s-expressions
- Debate over why Lisp isn’t mainstream: suggested reasons include steep learning curve, too much expressive freedom, intimidating power, off‑putting s‑expression syntax, weak or fragmented tooling, and lack of strong static typing.
- One view: “Lisp already won” because many of its ideas (GC, dynamic data structures, higher‑order functions, REPLs) permeate popular languages, even if s‑expr + macros did not.
- Others argue s‑expressions hinder adoption despite macro benefits; Clojure’s relative success still leaves it niche.
CS education and professional roles
- Ongoing tension: should undergraduate CS focus on theory (type systems, compilers, algorithms) or industry practice (Java/Python, HTTP, testing tools)?
- Some propose bifurcating into math‑style “computer science” and engineering‑style “software engineering,” with different expectations and outcomes.
- Several argue that early exposure to Lisp/ML‑like languages improves conceptual understanding, but this conflicts with employer‑driven language choices.
Metaprogramming approaches and tooling
- Alternatives to macros discussed: external code generators, annotations, partial classes, extension methods, and AOP frameworks.
- Pro‑macro side: everything a preprocessor/codegen tool can do can be done more coherently inside the language.
- Skeptical side: explicit generation is simpler to reason about and easier for IDEs; highly dynamic macro systems can defeat static analysis and sophisticated tooling.
Miscellaneous
- Recommendations surface for classic Lisp macro books and macro‑oriented languages like Racket.
- Some wish Unix command‑line tools shared a common Lisp dialect instead of many inconsistent ad‑hoc scripting languages.