Comment Re:No (Score 1) 296
It's the job of a programmer to say what needs to happen. It's the job of the compiler to make it happen with efficient machinecode. There is a long way to go in optimizing compilers, there are a lot of optimizations that could happen, but aren't happening because the compilers are not smart enough yet.
There is still a lot of stupid stuff being done by programmers or their drag-n-drop environment, that would require a full-blown AI system to optimize. I've lost count of the number of times I've opened up some developer's code because the DB wasn't tuned properly and discovered SQL queries pulling 100K + rows and the developer is reading a row, incrementing a counter, closing the cursor, and looping back through 100K+ times with the associated overhead of opening/closing a cursor. Or the SQL export that joins 8 tables without ever doing an explain, thus never knowing that a full table scan is happening on 4 of the 8 tables involved in the join.
Or the developer that insists that he has to have is own private set of tables, to be created at execution time and then destroyed, rather than using a view (yes, depending on the DB, and the hardware, I know views can be incredibly slow. conversely, if you understand where you are working, they can be incredibly fast.)
None of those instances will be caught with today's technology, It just isn't there, yet. Until then, it is the developer's job to write efficient code ( efficient doesn't always mean the fastest, it might mean the lowest resource usage). Why write a program to display the output of a database query, if you can have the SQL engine do all the work for you?