My wish-list for yet another programming language

by Max Galkin

I’ve collected my notes on various language features and tools that I wish were more common in modern “general-purpose” languages. Some of them are already available in some languages, some of them are wild ideas that I’m not sure will ever work… this is more like a brain-stormed list of things that address some of the pain-points of the development process in my experience. Let me know what you think! Which ones would you like to see in your language?

    1. Support the whole range of memory management techniques. Stack, heap, ref counted heap, GC-collected heap objects as “first-class” citizens: simple syntax for declaring, passing and returning each of them.
    2. Design for concurrency.
      1. Data should be immutable by default. Except maybe local stack variables can be mutable by default, since they can’t be shared directly.
      2. Need some more restrictions and verifications around passing mutable data around — it should either be protected by a mutex, or it should somehow guarantee that writers always get exclusive access.
      3. Again, simple syntax for declaring something mutable/immutable, this concept should be “first-class” citizen too.

  1. (?) Use “Maybe” monad and pattern matching instead of NULL, error codes and exceptions.
  2. Support ways to express relationships between concepts without using OOP inheritance. No multiple/virtual inheritance. Maybe multiple interfaces, maybe mixins, maybe some kind of type traits. Inheritance is just one way to categorize things, when a single hierarchy can be built, but some relationships between concepts are “fuzzier” than that…
  3. Ability to restrict the dialect used in a file, a folder, or a module. Dialects prohibit some language features. Support low-level dialects going down to unsafe pointer manipulation, and high-level going up to garbage collected references and functional style. Allow custom dialects to be created and custom rules that can be included into dialects.
  4. Built-in code-generation tools, data-driven text-templates with some awareness of the type system.
  5. (?) Support an interface definition language — for inter-module communication, i.e. all public communication must happens only using public versionable interfaces. Inside modules can use simple structs or whatever.
  6. Polymorphism based on language version / available capabilities, so that libraries can satisfy wider sets of customers — e.g. a module could have several implementations to support several language versions…
  7. Cross-compilation into JavaScript and into C++.
    1. JavaScript is the “assembler of the web”, but who programs in assembler anyway… Chrome Native Client will bring C++ to the web…
    2. Not sure if building your own native code compiler from scratch is viable… maybe frameworks like LLVM can help…
  8. Access to AST during compile time to allow for plugins/extensions. Access to AST as a standalone compiler “service”.
  9. Support for design, documentation and testing workflows.
    1. Support the concept of “requirements” — support links from tests to requirements, support links from code to requirements. Enhanced IDE experience and hints to build systems — they can analyze the impact of the change, which requirements are affected, which tests need to be run…
    2. Support the concept of “executable specification” for the code and for the language itself — specification has to be kept and updated together with the code.
    3. Workflow: requirements (specifying ideal behavior) -> code (approximates requirements, documents “implementation details”) + tests (“de facto requirements”) + extra comments in code and in separate files -> generated documentation (describes how the system actually works, where it deviates from the requirements, or clarifies them, what “knobs” can be turned and to what effect).
    4. Generated documentation understands Markdown and DOT language in comments.
    5. Some way to keep automated tests close to code, or test results shown close to the code they verify, ideally updated real-time as you change the implementation.
  10. Deeper integration with source-control, diff and merge tools. Languages and source versioning systems should be friends.
    1. “Fast-track” changes in comments & whitespace: version control should store meta-info about each change, compilers should assist in detecting “whitespace-only” changes, authors should be able to mark a change in a file as “whitespace only”, and changing comments should be as easy as editing a wiki page.
    2. Authors can mark a change as “test change only”, this could be used by build systems, e.g. not creating a new installer, etc.
    3. (?) On check-in the code should be auto-formatted to canonical formatting, on viewing  in IDE — adjust to user-configurable settings, allow special markup to surround regions of code where manual formatting is essential for readability.
    4. (?) Compiler-assisted diff to resolve changes inside lines and adjacent lines, e.g. modification of two separate elements in a list.
  11. Contracts, assertions, some way to describe the preconditions and postconditions of a method — even if there is no static check for the contracts, they should be there for documentation purposes and test runs: ability to build and run with the contracts enabled and disabled.
  12. Get the standard date-time operations right, and use UTC by default!
    1. Computers should only need local time & time zones when interacting with a human or a legacy API, and the conversion between UTC and local time has to happen at the outer boundary layer of the system.
    2. Default output datetime format should be as specified in ISO 8601.
  13. Unicode is a pain point in many systems.
    1. Maybe string types should support all Unicode kinds, exposing kind as an attribute of a string? I’m not sure what’s the best choice here, but I’d like to see languages that explicitly address this issue supporting both convenient and efficient string operations.
    2. String properties should be redefined in terms of Unicode, where one “real” user-visible character may consist of several “characters” in the representation…
  14. Modularity.
    1. Ability to build a module,  and run tests for a module.
    2. Ability to publish/download a module to a public repository.
    3. Dependency manager for modules.
    4. Some mechanism to break the isolation between modules and “merge” the code to allow for deeper optimizations?
  15. Designate a canonical font and color schema for showing the code in IDEs and blog posts :)