Should programming languages be safe or powerful?
Safety vs Power Tradeoff
- Many argue safety and power are not inherently opposed. High‑level features (e.g., APL‑style array ops) can simultaneously increase expressiveness and eliminate entire bug classes.
- A narrower view sees conflict only when accessing low‑level, hardware‑specific features; here portability vs. safety is the real tension.
- Some participants insist languages should be safe by default, with explicitly marked unsafe regions. Others prioritize raw power and accept that unsafe constructs are sometimes necessary.
Role of Languages vs Programmers
- One camp: unsafe languages can’t be used “safely” in practice; humans are too error‑prone, as evidenced by persistent C bugs even in expert code.
- Opposing camp: safety comes from programmer skill and discipline, not from the language; “guard rails” risk masking bad habits.
- There’s discussion of robustness (graceful handling of bad inputs) vs correctness (meeting specs on valid input); safe languages tend to enforce robustness as a default expectation.
Racket, Macros, and Expressiveness
- The article is seen as mostly an ode to Racket, immutability, and its macro system rather than a deep exploration of the tradeoff.
- Some praise Racket as combining Lisp/Scheme expressiveness with safety, including typed variants and safe macro‑based type systems.
- Others note macros (in Lisp, C++, Rust) can be hard to read and reason about, though still powerful.
Systems Programming: C, Rust, Zig, etc.
- The claim “C is great for drivers” is strongly challenged. Alternatives suggested include Rust, Zig, C++, Nim, depending on platform support.
- Even where C is the only official option, some argue it should be seen as a necessary evil, not “great.”
LLMs, Static Analysis, and Safety
- One view: LLM‑integrated IDEs could turn unsafe languages like C into effectively safe environments by detecting dangerous patterns.
- Skeptics counter that probabilistic tools can’t replace formal methods and that C is “unsafe by design.” AI may help migrate to safer languages or improve analyzers, but doesn’t fix C’s core issues.
Software Engineering Perspective
- Several comments argue that language choice is secondary to proper engineering: clear specs, modeling domains correctly, and rigorous testing.
- Comparisons to civil engineering highlight how immature software practice and standards still are, especially for safety‑critical systems.