Programmers think the most valuable language is a programming language. Therefore, an LLM that can generate quality code in that language should also be extremely valuable.
I'd argue that the most valuable language is the natural language of the organization you're writing code for.
That language is vague and ambiguous, and encapsulates many hidden assumptions about how that organization works.
For example, if the organization is a retailer or a wholesaler, you might ask the LLM to generate SQL to return last month's sales and inventory for each site and product category.
The LLM can query the database system tables and guess which tables have sales transactions and inventory transactions. The LLM can look at foreign key definitions to make a good guess how to join these tables with metadata about items, sites, categories and the calendar.
But will the LLM know that inventory is a stock, and sales is a flow? Will it know it should sum the sales transactions but average the inventory balances, or take just the beginning or ending inventory balance?
Many human engineers struggle to translate ambiguous requests in natural language into code which reflects the assumptions and mechanics of the organization.
An LLM that generates consistently useful code needs a world model of how things work, not just how to write code.
Whilst Snowflake is pretty popular the days of elaborately modelled EDWs are long gone.
And so typically I find I am doing queries, transformations etc in some abstraction layer e.g. Spark on a data lake, ORM for web applications etc.
They're more prevalent than ever in my experience. Consider the popularity of dbt.
Don't forget the models other's create for you - often hilariously slow code to present a set of facets that often barely align with your business delivery needs; and don't forget to sync it even more slowly with Fivetran, the DE platform of the future!
This doesn't make any sense, or I'm guessing you've never actually used it. Modeling is something you can do with dbt, not what dbt does (or is, or can be?). I've used it to create data marts and EDW's with hundreds of tables, no differently than I would have created a decade ago with other tools.
The C for loop on the other hand…
SQL was created in 60s. It has not really kept up with the pace of modern programming language ergonomics. It was made for a single person executing a batch job query pulling data from the database.
On the other hand, I kind of agree SQL is good to learn. It's an counter example on how not to design a programming language.
The IBM System R and SEQUEL paper was 1974, while Oracle 2 was the first commercial database which added it in 1979.
Despite all the hate MongoDb deserves, it solved the problem how application developers can easily get data in and out of a database.
1. The order of the phrases, the lack of trailing commas, the fact that an awful organization controls the standards and gatekeeps them to a bizarre extent.