(no title)
justsomeuser | 3 years ago
Specifically they have: Type systems, compilers, debuggers, text editors, package managers, C FFI etc.
But I agree that having the data and the program in the same process has benefits.
Writing programs in SQL is one way.
Another way is to move your data to your general program with SQLite.
I like using SQL for ACID, and queries as a first filter to get the data into my program where I may do further processing with the general language.
Serow225|3 years ago
malnourish|3 years ago
fifilura|3 years ago
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
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
Non sequitur. SQL is typed; SQL can be edited in any text editor; there are lots of SQL IDEs and, arguably, debuggers and package managers. Sure, the package managers are specific to each RDBMS, but so what? Npm is no use in COBOL either. And sure, the “debuggers”, to the extent they can be said to exist, are radically different from those of “conventional” – of other – programming languages. But again, so what? A Smalltalk debugger is no use to fix the output from Intel’s latest C compiler either, or vice versa.
IOW: There is no such “SQL vs programming languages” dichotomy. SQL is just another programming language, with its own strengths and weaknesses, just like all the rest of them. “The rest” are not distinguished from SQL by somehow magically all having the attributes you claim for them: Some have them, some don't; some have this but not that, some others, the other way around. Someone built all those IDEs and debuggers and package managers for (some / many / most of) those other languages; you can build them for SQL too.
wpietri|3 years ago
The basic notion is you keep your data hot in RAM and manage it directly. You make every change an object (or a command), and write that out serially to a log before you execute it. That gets you the ACID guarantees but with no I/O but linear writes, so it can be extremely fast.
It only makes sense when your data fits conveniently in RAM, but that's a lot of things.
dventimi|3 years ago