Some programming language ideas

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.