Stephen, What you are arguing for (no shared libraries) is bad old days where one had to recompile their programming language to add support for a DBMS, rather than the DBMS support being a separately installable library that one could choose to install or not or upgrade semi-independently or not, or choose to use an alternative or not.
Sure, SQLite is public domain, but why should every language bundle it into their core just because? There are lots of other useful libraries one could make the same argument for. Bundling it can make sense if the language core itself depends on SQLite or practically all of its users would use it, but that's not usually the case. I should also point out that the standard Perl interface for SQLite, the DBD::SQLite module, bundles the SQLite source with it, so installing that Perl library gives you SQLite itself, there are no DLLs or dependence on some system SQLite library, but Perl itself doesn't have this built-in nor should it. In the Perl 4 days you had to recompile Perl to make a version that can talk to a DBMS, eg "Oraperl", but thankfully with Perl 5 (1994 or so) we did away with that. -- Darren Duncan On 2016-01-07 5:47 PM, Stephen Chrzanowski wrote: > I personally wish the reverse. I wish that these interpreted language > engines would incorporate the SQLite code directly into their own existence > to avoid having to write wrappers to begin with, except for those wrappers > where their method name is "DatabaseOpen" and I prefer "OpenDatabase". > > SQLite has been around for years, and "R", PHP, Java, Perl, and all these > other interpreted new and old style languages have never bothered to > incorporate this public domain database engine within itself. It isn't > like the maintainers of these languages don't know it doesn't exist, and if > they didn't, then my god they gotta get out from under that rock. Most web > browsers use SQLite for crying out loud. > > For a few years, I've considered taking the entire amalgamation and porting > it to Pascal (Delphi/FPC) so I have exactly zero reliance on DLLs. No > worries about OBJ files, no worries about dependencies, I just include a > unit and my app is now database aware. I know 386 assembly, and I can > always read up on other specifications if I needed to. My problem is that > gaming gets in the way. > > My 2016 wish list for SQLite is that all developers who write for, or use > directly or indirectly, any database engine out on the market has a safe > and happy 2016 and beyond.
