Ask HN: What would be your “perfect” programming language?

Datalog is terminating. Programming languages don't have to allow infinite loops and recursion. There are plenty of ways to ensure recursion is terminating, like structural recursion or only allowing recursing finite data structures.

The germinating thought was remembering the frustration of having to choose between abstraction and performance. Sure, there are languages out there that do address this generally mutually exclusive dual to some degree of success. But there are other duals out there: {semantic-clarity and concision}, and, {effectiveness, and cognitive-load}. And the existing solutions to the first dual generally don't do so well, imho, in the other dimensions.

So my "perfect" programming language would have to:

- allow the programmer (henceforth me) effective abstraction capabilities, in the sense of what the language is used to define and describe, while also allowing for practical high performance implementation.

- have excellent semantic-clarity so the poor me who has to read code more than writing it gets a break. But who wants to read War and Peace to understand how a subsystem works? Not me.

- be effective. Get things done, and have the above two qualities. But I'd rather not have to carry some monsterous mental model in my head. That can hurt. /g

So how do we get there?

We already know a lot about tricks to make abstract code fast. So a ~near possibility that I foresee is either teaming up with, or borrowing the knowledge and tool base of, cognitive sciences to get a handle on things like semantic-clarity and cognitive-load. PLT designers will need to -start measuring things-. At some point we need to start measuring cognitive load of languages as we design them, and to do that we also need a bit of help from AI (D/ML) ("cheating", "not art", "not computer science"? :) so this feedback loop can be hugely sped up.

So first we need to have measures, actual physical measurements of a sample of end users, with existing languages and tools, up to operating and debugging software systems. At this point we'll have numbers to for example compare the cognitive load of Rust vs Go. Stuff like that. We feed that data to our DL model. That model then is expected to furnish what it thinks of your shiny new language. At that point, the PLT designer first defines the characteristic measures (of those duals), and possibly let say start from an existing language, and then have our friend AI go at it.

What will they look like? Hopefully we live long enough to see.

p.s.

fair to say to get this off the ground (measuring and creating the model) requires DARPA level research effort.

- Guarantee 8-bit byte and twos complement

- No undefined behavior. All behavior is defined even if the ramifications of that behavior are not. Use after free? The data in the memory location is written-to or read-from, not omitted by compiler, and programmer is responsible for the second- and third-order effects thereof. Signed integer overflow? You get the assembly ADD instruction for your platform/data width and see what happens.

- Fixed width integers. int8_t == short short int. int16_t == short int. int32_t == int. int64_t == long int. int128_t == long long int.

- char is by default always unsigned.

- byte type similar to unsigned char but requires explicit cast.

- Anonymous functions well-supported.

- A method keyword inside a struct defines a function pointer to an anonymous function with the signature and definition that follows.

- New operator --> such that x-->y(...) is equivalent to y(x, ...) (perhaps with additional error checks)

- Arrays no longer degrade to pointers but to fat pointers with an aligned prefix sds-style. Argument syntax for an array/fat pointer is arg[..]

- char type used alone is deprecated

- string type is an array/fat pointer of type char[..]

- str* functions deprecated; now that unique identifiers can use more than the first six characters, use string* functions instead

- "C" locale defined as using UTF-8 normalized to NFC

- Conforming change: allowable main() signatures include int main(string argv[..])

Elixir is already strongly typed (e.g. I think you can't use a number where a string is needed and doesn't automatically coerce).

I'd also like higher performance numerics in Elixir.