|
|
|
|
|
by fifilura
1203 days ago
|
|
> Type systems SQL has types > compilers For what specifically do you need a compiler? > debuggers Some tasks - like the concurrency SQL enables - are just very difficult to debug with debuggers. It would be the same with any other language. What SQL does here though is to allow you to focus on the logic, not the actual concurrency, > text editors, package managers I feel like these two are just for filling up the space. > C FFI Many SQL engines have UDFs |
|
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.