Modern Language Wishlist

Eric Normand's Newsletter
Software design, functional programming, and software engineering practices
Over 5,000 subscribers

I was brainstorming the other day about features that I expect to be easy in modern programming languages (plus libraries).

Some of them are very common, some less common, and some might not exist yet. Some are basic services of the runtime and some are more conveniences for interacting with the modern networked world.

None of them are impossible. I can point to examples of each of them in popular programming languages. But there is no language that has all of them. A lot of progress could be made with fortuitous curation of existing libraries.

  • String manipulationString manipulation should be incredibly convenient. It's so common to parse something out of a string, or build up a new string. It should be so easy it disappears.

    • Regular expressions
    • Splitting
    • Joining
    • Replacing
  • PolymorphismPolymorphism, as I'm describing it here, means the specific type of a value is an implementation detail that I can ignore. I can program to an "interface" and two values that implement the same interface can be treated interchangeably.

  • Basic "container" typesI don't think it's a stretch to say that we know enough, as a science and industry, to know exactly what we need from our containers. +1 for convenient syntax.

    • Linked list
    • Dynamic array
    • Hash map
    • Set
  • Input/outputIt's still a little hard in some languages to read and write files. Especially binary.

  • Web requestsOur computers are approaching 100% time on the Internet. And the web is ubiquitous. You should be able to do web requests with one line.

  • URL ManipulationURL's are very structured strings, but that doesn't mean we should be concatenating the strings ourselves. There needs to be a way to build URL's and break them into their individual components.

  • Garbage CollectionI just don't want to worry about memory management anymore.

  • NamespacesIt is convenient to avoid naming conflicts as your library ecosystem grows.

  • HomoiconicCode can be manipulated as data.

  • Extensible syntaxI find I don't use macros much anymore. I do more with data-driven programming. But it is nice to have when you need it.

  • Math-oriented numeric typesThere are times when I want numbers that are defined by their machine representations, such as C int and double. I'll call this "machine-oriented numbers". There are times when I want a more abstract representation of numbers, that act like they taught me in Math class. I'll call this "math-oriented numbers".

    With math-oriented numbers, the fear of overflowing should not exist and division is division.

    While we're at it, we could add in matrices, vectors, and even equations.

  • UnitsNumeric values should be able to be qualified with a unit. You should be able to convert between units of the same kind.

    • Mass
    • Time
    • Distance
    • Temperature
    • and combinations of the above (speed, acceleration, etc.)
  • TimeTime, dates, and calendars are hard. The language should solve the hard part for us.

  • ErrorA number is rarely 100% accurate. There should be ways to represent the error and have it accumulate when combining different values. +1 for tracing the sources of error.

  • Unification / pattern matchingIt's just for convenience. The important thing is how unification errors are dealt with. Hopefully, there is something better than catching an exception.

  • Before / after functionsThis is sometimes known as aspects. But there is a lot of value being able to add functionality to existing functions without modifying the original code.

  • ParserConvenient way to define parser grammars that generate AST's available in the language.

  • CSV libraryCSV is a very common way to store tabular data, but it's not really a standard. There is enough variability in the format that a library is called for.

  • Good error messagesGood error messages need to help you locate and solve the problem. It's actually really hard to get right. You can see this a lot in newer languages. Languages with helpful errors are typically mature.

  • Immutable valuesValues are values. They shouldn't change.

  • Explicit model of timeIt is very rare to find in programming languages. Time needs to be modeled by the programming language so that we can sanely deal with concurrency. This is one of the bigger mini-revolutions happening in programming at the moment.

  • GraphicsMost languages make it really hard to draw on the screen. This just needs to be easier. Displaying images, shapes, colors, text, video, and associated manipulations: scaling, rotation, translation.

  • SoundSame goes for sound: playing sounds should be easy! Listening to the microphone should be easy!

  • Common file formatsReading common formats should be easy. At the very least, there should be a framework/convention for libraries for common formats to follow.

  • Game inputBy this, I mean getting raw events about key down, key up, mouse movement, etc.

  • GUI

  • First-class functionsHigher-order programming is an obvious win. +1 for lexical closures. +1 if you can store the functions to disk and read them back in!

  • Easy way to store data in flat text filesI don't want to have to write my own serialization routines.

Sean Allen
Sean Allen
Your friendly reminder that if you aren't reading Eric's newsletter, you are missing out…
👍 ❤️
Nicolas Hery
Nicolas Hery
Lots of great content in the latest newsletter! Really glad I subscribed. Thanks, Eric, for your work.
👍 ❤️
Mathieu Gagnon
Mathieu Gagnon
Eric's newsletter is so simply great. Love it!
👍 ❤️