151–160 of 171 posts
(1) this is the first instalment, and it's already close to be a thousand times more useful for product owners and analytics than any airtable you can imagine.
(2) as much as I love being on point on every challenge, we're leaving in "good enough" economics for quite some time, and if this will be close enough that will be good enough for business.
What happens if you feed the model with sql as input?
Next generation of 'software engineers' are going to be brain dead: 'duhhh gpt how 2 do x... duh...'
Earlier quoted context omitted.
SQL is popular because it can be run on a map/reduce backend. So once you have written your code it can run on any number of machines.
a) SQL is not that popular on map/reduce backends. Most people are doing it in code. b) Only basic SQL works on any database and even then there are major differences in how they treat things like nulls, type coercion etc.
Earlier quoted context omitted.
I don't think that the point was that there are no for loops in SQL. I think the point was that almost always using for loops is wrong and super inefficient and there is a much more efficient way to just use joins instead.
I wonder if anyone realizes that selects and joins in every database are implemented literally with for loops written in c. The reason people use a relational database is because it has loops that are faster, safer, and more efficient than anything you can write.
The point is that by getting rid of loops you remove one way of telling the computer "How" to do it. Start here, do it in this order, combine the data this way.
When "How" is a solved problem, it is a waste of your brain to think about that again. "What" is a better use of your brain cycles.
Earlier quoted context omitted.
That’ll often not scale to millions of records. Letting the database optimizer find the optimal execution path instead of doing it procedurally elsewhere might result in “finishes in 5 minutes”, versus “doesn’t fit in a night”.
This isn’t the 90s. Most hardware is way over-specced for the data sizes most people are dealing with. The number of use cases which are too heavy to finish in hours but small enough to fit in a single instance is pretty limited.
Earlier quoted context omitted.
There are preprocessors like PRQL that help with some (far from all) of the pain points of SQL as a language
Hopefully we get over the fact that we still need to transpile something to the ugly SQL and databases themselves start to speak a better language. Despite all the hate MongoDb deserves, it solved the problem how application developers can easily get data in and out of a database.
Earlier quoted context omitted.
I don't think that the point was that there are no for loops in SQL. I think the point was that almost always using for loops is wrong and super inefficient and there is a much more efficient way to just use joins instead.
I wonder if anyone realizes that selects and joins in every database are implemented literally with for loops written in c. The reason people use a relational database is because it has loops that are faster, safer, and more efficient than anything you can write.
Earlier quoted context omitted.
Honestly I would rather write stuff in code thats inefficient than deal with one more stored procedure. Its like a black box
That will be interesting soon when 80% of your code will be ai-generated black boxes…
Earlier quoted context omitted.
Shareware?
Yep. Open source means you can build and modify it. If not, it’s not open source. You know it’s a bad timeline when releasing the equivalent of a binary is considered “open”.
In fact, this very model is such modification (fine tune) of the original base model.