(no title)
justsomeuser | 3 years ago
Sure SQL has types, but they are checked at runtime, not compile time. Also you cannot define function input and return arguments with types that are checked before you run the program.
> compilers
If you want efficient and/or portable code. They will check your code for type errors before you run them. They give you coding assistance in your editor.
> debuggers
Being able to break a program and see its state and function stack is useful. The quality of the tools for real languages are much better than SQL.
I agree that databases do concurrency better than most languages with their transactions (I mentioned I would use the db for ACID).
> text editors, package managers.
Editor support of real languages is much better than SQL.
Package managers enable code re-use.
> C FFI
Take for example Python. A huge amount of the value comes from re-using C libraries that are wrapped with a nice Python API.
You might be able to do this in SQL, but you'll have to wrap the C library yourself as there is no package manager, and no one else is doing the same thing.
CRConrad|3 years ago
> Editor support of real languages is much better than SQL.
So text editors suck at supporting SQL... How is that SQL’s fault?!? Go complain to the text editor authors.
> Package managers enable code re-use.
Yup. Build one for SQL, then you can re-use SQL code. Just like someone had to build one for every other language. What does this prove about SQL being inferior to other languages? A: Nothing at all.
justsomeuser|3 years ago
My point is that I think it is inferior for general application/business logic programs. For queries that filter large datasets to small result sets, SQL is probably better as it has the built in indexes and query planner (plus ACID).
I am pointing out that the current environment (better text editors and package managers) favours general languages, so they are a better current choice (to use in combination with SQL) over just writing everything, including application logic, in SQL.