Defense of Lisp macros: The automotive field as a case in point

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.