I got better results with Claude Code + PostgreSQL MCP. I let claude understand my drizzle schema first, and i can instruct it to also look at the usage of some entities in the code. Then it is smarter in understanding what the data represents.
> most queries I’ve ever seen are just simple joins
Good for you. Some of us deal with more complex queries, even if it may not seems so from the outside. For example getting hierarchical data based on parent_id, while having non-trivial conditions for the parents and the children or product search queries which need to use trigram functions with some ranking, depending on product availability across stores and user preferences.
I agree knowing SQL is still useful, but more for double checking the queries from LLMs than for trying to build queries yourself.
So, an adjacency list (probably, though there are many alternatives, which are usually better). That’s not complex, that’s a self-join.
> trigram functions
That’s an indexing decision, not a query. It’s also usually a waste: if you’re doing something like looking up a user by email or name, and you don’t want case sensitivity to wreck your plan, then use a case-insensitive collation for that column.
> I agree knowing SQL is still useful, but more for double checking the queries from LLMs
“I agree knowing Python / TypeScript / Golang is still useful, but more for double checking the queries from LLMs.” This sounds utterly absurd, because it is. Why SQL is seen as a nice-to-have instead of its reality - the beating heart of every company - is beyond me.
Your Python / TypeScript etc. argument is a strawman, thats why it sounds absurd.
Your arguments would hold better if an average person was good and very quick at learning and memoizing complex new things. I don't know if you work with people like that, but that's definitely not the norm. Even developers know little SQL unless it's their specific focus.
In the original comment you said:
> I guarantee you, anyone who knows any other language could learn enough SQL to do 99% of what they wanted in a couple of hours. Give it a day of intensive study, and you’d know the rest. It’s just not that complicated.
Well your "guarantee" does not hold up. Where I live, every college level developer went through multiple semesters of database courses and yet I don't see these people proficient in SQL. In couple hours? 99% of what they need? Absurd
It's not a strawman, it's reductio ad absurdum. SQL and Python are both languages that are commonly used. It would be (currently; who knows in a few years) laughable if someone said they didn't need to deeply understand Python to be able to correctly write Python at an employable level, modulo experience levels - I don't expect a Junior to know the vagaries of the language, e.g. that bools are aliased to integers.
> Even developers know little SQL unless it's their specific focus.
Yes, and I believe this to be deeply problematic. We don't generally allow people to use a language they don't understand in production, except for SQL.
> Where I live, every college level developer went through multiple semesters of database courses and yet I don't see these people proficient in SQL.
That's horrifying.
Look, while I would love it if everyone writing SQL knew relational algebra, basic set theory, and the ins and outs of their specific RDBMS implementation, I think the below suffices for the majority of work in web dev:
SELECT: extract the columns that are named, optionally with an alias with AS (or simply a space)
FROM: the [main] table to extract columns from
[INNER] JOIN: an additional table to examine, returning only their intersection
LEFT [OUTER] JOIN: an additional table to examine, returning everything in the LHS table, as well as any matches from the RHS table, with NULLs filling in missing data
RIGHT [OUTER] JOIN: the same as LEFT JOIN, but with the logic swapped
FULL [OUTER] JOIN: an additional table to examine, returning the union of both tables, regardless of matches
ON: an expression to use for joining tables, generally consisting of at least one column from each table to match
WHERE: a predicate (or series of predicates, with boolean operators joining them) to use for filtering the result set
ORDER BY: one or more columns to order the result set by, in either ascending (ASC) or descending (DESC) order
GROUP BY: one or more columns (though strictly speaking, this number must match the number of non-aggregated columns in the SELECT) to group the result set by
LIMIT: a limit for the maximum number of rows returned
You're telling me that given a simple educational schema like Northwind Traders, and the documentation for their RDBMS, that someone who already knows a programming language couldn't use the above to figure it out in a fairly short order?
> someone who already knows a programming language
I'm sure someone who can already code, can write a simple query. But my argument is
1. with AI assistance programmer would be quicker, with less friction, more productive, enabled to make queries beyond his current abilities
2. with AI assistance Non-programmer would be enabled to use SQL at all
3. real world queries are often not trivial (todays developers have simple queries covered by ORM / query building tools)
Regarding real life queries - I look at my last query that I crafted with difficulty and AI help - starts `WITH RECURSIVE`, uses `UNION ALL`, `GROUP_CONCAT`, `COALESCE` (even with SELECT statement inside), multiple CTEs. It would take me hours to get to that. I can have that in minutes with AI help. I don't even mention different dialects, feature support, arrays and JSONs, extensions, etc.
SQL is simple for simple needs, basic joins and some basic aggregates. Even that you won't learn in 2 hours. And that is just scratching the surface of what can be done in SQL and what you need to query.
With LLMs and tools like this you simply say what you need in english, you don't need to understand the normalizations, m:n relation tables, CTEs, functions, JSON access operators, etc.
For reference, I’m a DBRE. IMO, yes, most people can learn basic joins and aggregates in a couple of hours, but that is subjective.
> you don’t need to understand the normalizations
You definitely should. Normalizing isn’t that difficult of a concept, Wikipedia has terrific descriptions of each level.
As to the rest, maybe read docs? This is my primary frustration with LLMs in general: people seem to believe that they’re just as good of developers as someone who has read the source documentation, because a robot told them the answer. If you don’t understand what you’re doing, you cannot possibly understand the implications and trade-offs.
What do you see as an alternative? This is exactly what people need. To give quick instructions and have agent work on tasks across webpages/webapps. You say you "have many thoughts on fixing this". Can you share a better vision?
Yes, it involves "recipes" for different "action types" based on a few things (past behavior, sensible "default" behavior, the context, etc.). For example, when looking at a storefront, the agent might want to give a few options (off the top of my head):
- It knows you're low on milk, so it suggests buying milk
- It can get a list of all deals, maybe even cross-checking with other storefronts
- It knows your sister was looking for a planter, and it found a particularly cheap one, so it suggests texting it to her
- Etc.
- (You can of course still chat with the thing, if you so desire)
These recipes are difficult to come up with and hard to generalize (they also need to be categorized, and likely accurately picked from a [RAG?] database), but imo this is the future if AI agents, not yet another chatbox.
It may be resume-driven, but that's the state of the world. If you fail to keep your team members and attract new ones as the team needs to grow, you are fighting a losing battle.
I didn't see many needless ones, but I've seen many team members not wanting to hear about any change. It's hard enough to push a greatly needed change through management. Maybe there are places where they do it just for fun.
That cost should be taken by our government and the tax payer, as a disincentive to locking people up.
If you can lock someone up and get close to free labor for it, then we're going to start locking a lot of people up. I mean, it's free labor. Which is why we used to give people 20 years for possession of marijuana. What, you think it's just a coincidence we were throwing primarily black Americans away in prison for ludicrous amounts of time where they'll spend their days picking cotton?
That's what happens when imprisoning people is cheap.
If a prisoner costs $50k a year, and "if" he would work a job where he would make $50k a year and if he didn't receive a dime from it, does it look to you like a free labor? He merely makes up for what he costs the system, not taking into consideration the likely damage that he has done that made him end up in prison in the first place. And I don't expect prisoners to have anywhere close to $50k salary jobs.
The problem here is you’re really asking for abuse with this mentality.
Prisoners should cost money, lots and lots of money. Otherwise we might just decide to imprison you and extract your labor. And that is exactly why we used to see 20 years for possession.
What, did you think we were just burning money for kicks?
That's what I tried to refute in my previous comment. So in case I miss something, explain to me how is it economical for someone to enslave you, if it costs him $50k/year and he will almost certainly extract less value from your work (from data i found $20-$25k/year jobs are common for prisoners). That's the exact opposite of free labor. It is very expensive labor. I would agree if the cost was like $10k and you would extract considerably more from the job done. But it is not the case. Maybe in countries where they don't spend much on prisons what you say works. I don't think it does in US or in any other developed country
Government is not a business, nor is it 0-sum. Well-functioning societies with low rates of recidivism invest much more in their prisoners. We should be investing money into prisoners, so that they can re-integrate into society and become successful tax-paying citizens, just like the premise of the blog post we are commenting on. As the co-founder said, the Department of Corrections in Maine takes a cut of the inmate's salary.
Cheap labor is still valuable, I don't know what to tell you. 20k salary net is very cheap. I don't know why you think it's expensive, because it's not. What you're maybe missing is the job needs to be done regardless - it's not like if we stop using prisoners for labor that need for labor just - poof - disappears.
Do you mean that the benefit of cheap labor goes to private companies, but the cost stays with the taxpayers? If so, I see the logic. If we are talking about imprisoning someone, because we get cheaper labor for example inside the prison, than that doesn't make sense. Of course I count that the job needs to be done.
Wasn’t much to it actually.
I was working in a team trying to create hp’s first SAAS offering for workflow management.
I was the “webmaster” specialist at that time, and hearing the news that HP bought palmOS which was based on JavaScript made me really excited.
However, during that time, HP was notorious for replacing its CEO on a yearly basis.
After 1 year working on our project, 30 person team, the CEO was replaced and our project was scrapped.
They gave me 2 months to do nothing (actually played gears of war in the game room), and then moved me to another team where we spent 8 months waiting while the managers argued on what we should be doing . After that I quit.
We always knew that the software side of hp provides barely 10% of the revenue while the rest is printers.
It really wasn’t a surprise they failed with the Palm purchase.
This was an offer to non HP folks as well - if you were an established developer, you could get a free Pre2. I was a recipient of said free device, but I did have several legit apps in the store because honestly WebOS was really fun to write code for! Their developer relations were excellent for a while - it was a really fun community to be part of for a bit. Shout out to Chuq, he was great.
reply