Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible".
But that might not be very efficient at all. The people who write "the system" have to write software that does specific things in specific situations and there will be endless cases which cannot be dealt with efficiently. And the more the interface hides the implementation, the less likely it is that those cases will be obvious.
My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our expectations about the “make it so” API into our architecture.
Getting to a good, explicit, imperative API requires a whole nother step, and often a major refactor. You have to step back and ask “what is really happening now and can I conduct it more directly?”
... but by that time your code works and it hardly seems worth the effort.
But it is worth the effort. The declarative API will just get uglier as you add to it, and provide no real guidance about where future additions should go. Just throw another key in the config. Add another conditional. An imperative one will constrain your future choices about how additions can work, and therefore helps you clarify your domain model as you add to it.
You can have high level imperative APIs... they just need to be explicit.
Many declarative interfaces are the culmination of decades of work on re-inventing the wheel at the imperative level. The relational model and SQL databases are a great example of this - “we’ve solved these problems below this line mostly, please move on and focus up the stack closer to the customer/user”. It became a multi billion dollar industry as it nailed the 80/20 rule for data management.
And for a large class of problems this remains solid, despite a perpetual subset of engineers that think they can do better than the declarative interface and engine and build an alternative. Sometimes it makes sense to be adventurous and drop back to the imperative level - SQL databases fell over in recent years was the scalability of the underlying engine for the largest uses. But a Postgres or MySQL endures as a great declarative abstraction over a very complicated set of issues.
SQL is a great example. But it’s also an example of how difficult it is to make a great declarative API. Look how much effort went into designing and then refining and then adapting SQL to changing needs. It’s been an enormous effort across a huge community.
Same with CSS. Those aren’t things some developer just wrote and they got refined in an application over time. There are entire conferences about the regular redefinition of those interfaces.
My point is that concept doesn’t scale to some large number of abstractions. SQL and CSS are big manifolds that operate on the boundary of your application, and often separate you from an entire other group of developers working to maintain the other side of that contract.
If you try to apply that same setup to every problem, with thousands of declarative manifolds all intersecting within your application, you get chaos. Which is what many modern frameworks try to do. Declarative APIs only work when they are rare and standard and everyone knows them.
That's just an excuse to stop mediocre engineers who would fiddle endlessly with pointless micro optimizations.
You very much need to understand the performance of your code if the product has performance requirements that fail unless you do.
I presume most coding is just crudding small strings from UI to database, where performance issues don't kick in, and hence it would be wastefull to care about them.
I've watched production builds to crawl to a halt and become sluggish as molasses because someone in the dev team was indoctrinated in this creed. (Many reasons, including a cartresian explosion in complexity due to some innocuous LINQ calls).
Who is saying that? I've worked in video games for 18 years and never heard that. In fact, anyone who said that would get puzzled and suspicious looks. We generally use a very C-like variant of C++.
I was responding to a comment about Cairo graphics, which I assume is not much used in games. The kind of graphics I was thinking about is things like Cairo, Windows WPF, the Web.
That said: once upon a long time, OpenGL was supposed to be achieve efficiency by being high level so that the rendering stack could optimise your drawing better than you could. That idea didn't work so well and modern OpenGL seems to take the opposite approach.
and efficiency of computation is the least of my worries. i would like things to just work.
