Some programming language ideas

Original Article ↗ Hacker News Discussion ↗

Programmers reflect on a grab bag of “missing features” they’d like to see in mainstream languages, from capability-based security and semi-dynamic compilation to built‑in relational data handling and persistent “value databases.” Many point out that partial versions of these ideas already exist in systems like capability OSes, Julia, Starlark, Smalltalk images, PL/SQL, and effect systems, but often only as libraries or niche languages rather than first‑class, integrated features. The overall sentiment is that language design has largely plateaued around C/Java/Python-style models, and that deeper integration of security, persistence, modularity, and relational thinking could unlock more robust and maintainable software.

Capabilities & Access Control

  • Many commenters clarify “capabilities” as unforgeable handles that both designate and authorize access to a resource; authority is in the reference, not in an external ACL.
  • OS analogies: Unix file descriptors, Mach ports, OpenBSD pledge/unveil; some argue these are partial capability systems but not “pure”.
  • At language level, examples include Java/.NET security, Kernel’s first‑class environments, and capability subsets for filesystem or network.
  • Strong interest in using capabilities to constrain libraries (e.g., packages like “leftpad” only ever get string‑manipulation authority).
  • Skepticism: pure capability systems (no ambient permissions) are seen as hard to use; revocation and dynamic nature make them difficult to express in static type systems.

Semi‑Dynamic & Staged Execution

  • Several languages are cited as “semi‑dynamic”: Julia (JIT per type signature), rpython, Starlark (mutation only during an initialization phase), CLOS with explicit “dynamic then compile” points, Crystal’s heavy compile‑time evaluation.
  • Idea: allow a highly dynamic setup phase, after which code is frozen and optimized; some note this is close to what modern JITs and staging systems already do.

Relational Programming & Integrated Data

  • Strong interest in a “truly relational” language where in‑memory data and queries are relational by default (PRQL, Datomic, relational + array systems like Tablam, Haskell libraries).
  • Prolog/Datalog are mentioned as prior art; debate whether logic languages are a good relational model in practice.
  • Some argue SQL’s success is due to its table‑centric, non‑purely‑relational design and business adoption, despite technical shortcomings.

Value Databases & Image‑Based Systems

  • Image/persistent‑store ideas appear via Smalltalk, MUMPS, TADS, QuickJS storage, and Lisp systems.
  • Pros: seamless persistence, easy tooling like time‑travel debugging and “what if” queries.
  • Cons: accumulating cruft, corruption risks, mismatch with text‑based source control. Various systems mitigate this with semantic change tracking and versioning tools.

Modular Monoliths & Dependency Injection

  • Desire for languages that enforce modularity inside a monolith as strongly as microservices do across the network.
  • Ideas: capability‑secure module systems, dynamic scoping or implicit variables for DI, language‑integrated effect systems for IO and side‑effects.
  • Some argue many of these concerns can be addressed by libraries and frameworks (e.g., DI, logging, transactional boundaries), not necessarily new languages.

Loops, Control Flow & Misc Design Ideas

  • Multiple proposals for richer loop forms (e.g., “prepare–check–process” loops, begin/process/end blocks, loop phasers) with examples from Ada, Common Lisp, Raku, and others.
  • Other recurring wishes: better cross‑language interoperability, standard multidimensional arrays and vector types, integrated GPU/CPU compilation, “big objects” with strong boundaries, and non‑Turing‑complete or constrained languages for safer embedded scripting.