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.
That's a very 2023 comment but I have a feeling it won't hold up. Yes natural language communication is and has been a very undervalued skill in software development. LLMs have made the skill even more valuable, but in the end your solution is being written in one or more languages with additional features that are absent from natural languages and a programmer still needs to understand what they are building, in all of its complexity, in order to build solutions of real value. I don't see that changing for a little while. In the meantime, programmers will become better natural language communicators.
I have been working in this industry for 30 years now. SQL is one of the most ugliest programming language I have ever working with. Like Perl, it's write once, hope you never need to read, language.
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.
There are certainly valid syntatical criticisms you can have of SQL[1] but on the whole SQL is expressive and rather concise while being solid enough to remain the default expression language of choice for fifty years.
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.
Seriously? I just had a Quick Look at the mongodb docs, but when I see that I’m glad to use SQL. All the brackets and dollar prefixed expressions make mongodb queries hard to read.
dbt is not elaborately modeled at all, it eschews all the up front work of data modeling with ... well basically a lot of code and poorly maintained balls of mud.
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.
As a counterpoint, I’ve also worked in this industry for 25 years, and SQL has had no relevance to my career. I write it very occasionally, and if I didn’t, it wouldn’t make any difference.
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.