I feel like performance of code needn't be opposed to ease of writing code, but it virtually always is. Why is that? It feels like that doesn't have to be true

A corollary to this is that very numbskull simplistic code is often the most robust and performant but hard to write because of too much boilerplate.

Why do languages not allow people to write KISS style code more easily when it's more robust and performant?

Why is none of this even remotely on the radar as a design consideration for languages?

I'm not saying that most (all?) programming languages have the wrong design priorities but it sure feels like it

Shame I'm a gamedev which means there's roughly a 0% chance of me ever exploring this by designing my own language (probably one that features code generation as a first class feature)

So I feel like this needs an example. Say I have a function that does a bunch of stuff, then has a switch statement that depending on case returns a value. Say I want to differentiate the cases of that switch statement and I'm using C#...

The way to do this is to use lambda functions to customize parts of a generified version of the original function. Which sounds great! But too often this approach leads to the creation of closures which means a bunch of heap allocation for every call and way more GC pressure...

So on hot code paths you're forced into anti-patterns either way, code duplication or janky code to avoid dispatching closures. When all you want to do is tell the compiler "I wanna run this reusable code pattern here and then customize this little bit there"...

This SHOULDN'T CAUSE OVERHEAD. It causes overhead because C# now has a half assed way to approximate what coders want to do (at the expense of performance) and further interest in fixing the problem evaporated.

You know what does this easily and performantly? CODE GENERATION

This is compounded in C# by the absolutely mystifying decision to remove preprocessor macros. While imperfect and often abused, even this rudimentary version of what is effectively inline code generation would immensely improve this particular, relatively common situation

Reflection is also a good example of this. Too many problems in C# can be "solved" using reflection, except reflection is slow as shit so now you're reduced to writing caching systems and emitting IL at runtime through expression trees to optimize it

Reflection isn't actually a solution at this point but an anti-pattern in and of itself that allows programmers to kindasorta do what needs to be done and so stands in the way of actual progress towards fixing the actual problem

And I say this as someone who LOVES closures and loves reflection

Anyway sorry for doing a big thread most of you probably find inscrutable and boring but I HAVE VERY STRONG FEELINGS, ok???