If you were designing a programming language what would your favourite features be?

Good question. There's a set of features I can't easily live with nowadays (like generics you mentioned), but let me focus on one of the most neglected language feature:

ADTs (Algebraic Data Types, aka enum / union on steroids, case classes):

Most languages have records, which store various data together. But few has ADTs, which let case selection on a closed set of named records. For example a Haxe-style enum*:

// plain enum so far
enum NumberSystem {
  Roman;  // I, II, ..
  Arabic;  // 1, 2, ..
}

// ADT-y enum
enum MyNumber {
  Numeral(value: Int, writtenIn: NumberSystem);  // I, II, 3, ..
  Textual(value: Int, rawValue: String);  // "one", "hundred", ...
}

var num1: MyNumber = Numeral(1, Roman);
var num2: MyNumber = Textual(25, "twenty-five");

// silly example, a better one would be a render
// function which gives back the original representation
var v = switch(num1) {
  case Numeral(v, _): return v;
  case Textual(v, _): return v;
};

ADTs can be emulated by subclassing to some extent, but then you need to resort to instanceof hacks, which defeats the purpose. Also no guarantee on completeness on cases checked that way.

It also brings a different mindset compared to subclassing: with subclassing, I tried to massage all differences of the subs into a generic interface. With ADTs, I embrace differences and handle them explicitly.

Typically languages with ML (sml, ocaml, mlton..) or Haskell-lineage (haskell, elm, purescript..) have ADTs. Scala has case classes which can be sealed to get similar effect. C has tagged unions which is similar if we squint, but forces manual rolling of tag-to-part mapping.

Apart from this, on the high level I would love an integrated language experience, where all the tooling and syntax work together in unison, batteries-included, with as much upfront guarantees as possible. Ur/web is an experimental (now in maintenance mode) language that kind of promised this for the syntax at least, but in practice didn't satisfy me. Also far from production. From the old times, Turbo Pascal had a nice experience, but it didn't have SQL integrated or any modern language features either.

They say SmallTalk had a nice closed world you could live in, but I have no experience.

*: I don't like Haxe's Color enum example, as the constructors are not orthogonal (red, blue, green, rgb(r,g,b)). Not that they can always be, but this is a particularly bad first example.

I'd probably include generics and extension methods as native functionality, along with:

Decorators

Functions that take another function or class as input, mutate it, and then return the result, together with concise syntax for invoking this as part of the definition of a function or class. Typical syntax in languages that implement them looks like:

@decorator2
@decorator1
function doSomething():
    return 4

They're a remarkably useful meta-programming tool (for example, you can implement the concept of mixins as decorators), and having a clear syntax similar to what's used in Python 9and recently added to JavaScript) means that they're easier to work with in version-control than just calling the relevant functions as part of the declaration.

Exception type matching as an implicit part of try/catch clauses.

In essence, I despise languages that make you write code that looks like this:

try {
    doSomething()
} catch (error) {
    if (error instanceof SomeErrorType) {
        handleError(error)
    } else {
        throw error
    }
}

I much prefer the Python approach to this type of thing:

try:
    doSomething()
except SomeErrorType as error:
    handleError(error)

No need to re-throw the error if you can't handle it, and no extraneous conditionals to clutter the code.

Object property accessors as a native language feature

Not many OOP languages lack this feature these days, but I feel it's just too important to not mention as something a language should have. Put simply, sometimes you just need to make it opaque to the outside world that some attribute of some object in your API isn't just a value, but gets computed when you read from it or does extra stuff when you write to it.

Native concurrency support

Probably done similar to how Go handles things (native coroutine support, but it automatically spreads things out across multiple threads at runtime, with the number of threads chosen by default based on the numer of thread's of execution on the system it's running on). I would likely add regular multi-process and multi-thread support as well, but as part of the standard library instead of a native language feature.

Coupled with sane messaging primitives as a native language feature, this could trivially replace any need for Promises and async/await type functionality (in the places where having Promises be used even makes sense that is, some things they get used for in JS and the Web API's are just ridiculous, and could just as easily be synchronous if it weren't for the stupid execution model used in JS).

List/Set/Mapping comprehensions

Quick Wikipedia link.

Essentially, a concise syntax to perform some of the same type of things that map, reduce, and filter do, without needing even a lambda/anonymous function to do it.

A native Set type

I don't often need to make use of set theory constructs in programming, but there are just some things where it makes life so much easier. Having a native Set type makes handling those cases much simpler from the programmer's perspective.

As far as the other stuff you mentioned:

• Arrow Functions: The shorthand is nice, but the big reason they exist is the insanity that is this in JavaScript. No sane language should have bindings work like that. Without that, you can just use whatever lambda expression syntax you like (and I feel that there are better syntaxes than an arrow operator that might be confused for comparison).
• Async/await: Covered above. I really just don't like the way it works in JavaScript (it really just says "I'm not dealing with async crap here, whoever called me can deal with it.").
• LINQ: The concept is nice, but isn't something I think needs to be native to the language itself. I would probably do something equivalent in the standard library, but not in the core language.
• Attributes: Trivially covered by decorators.
• Database migrations: Should be part of whatever specific database library you're interacting with. Short of possibly providing native ODBC-type functionality, I would not be including database support as a core language feature (though I'd probably have some form of it in the standard library), and thus would not need schema migration support to be a core language feature.

I kind of asked this before here, wanted to share:

What are your favorite programming language syntax features?

Aivan Monceller ・ Mar 27 ・ 3 min read

#discuss #programming #beginners #software

I like pointers. Anyone who thinks C can be bettered is delusional.