This is funny how language trends get interesting and sometimes a bit emotional too. We all have an opinion on them, and here is mine :-)
The basic idea going around in this thread is a very conservative "C is best because 1) it's universally portable, and/or 2) it's very close to the machine (ie low level)". These two criteria clearly apply to library software (such as SQLite), while for "client" (in a very general sense) software a totally different trend has been going on for a number of years: a trend towards higher level, farther from the machine, languages. This started back in the night of times, but C++ as a "better C than C" is certainly part of that trend. Today that trend is more or less at a stage where languages must manage memory: Objective-C is now garbage collected, as are Ruby, Python and Lua, as has been Java since some earlier time. Lua was the language used to program [most of] Adobe Lightroom, and [a large part of] WoW. MacRuby is looking to become a first class Cocoa citizen. .Net is part of that trend too. Portability has at times been an issue there too. Java tackled it, and to some extent, so have Ruby and Python which have become largely universally portable, at least to machines with a minimum level of resources (excluding a number of "embedded" systems). These trends have thus far not been converging very much. I am convinced though that over time, the trend for higher level languages will also include library software. >From this perspective, I would be of the opinion, to some extent tongue-in-cheek, that C++ is far too low-level a language to warrant a rewrite of SQLite. Jean-Denis On 6/3/09 17:23 , "John Stanton" <jo...@viacognis.com> wrote: > Indeed. Very good reply. >> To Sylvain, once again: speculating on what went into the minds of the >> developers, when they set out to develop SQLite, they chose the best, >> most concise, most portable, most universally compilable, mother of >> almost all languages. Once they developed something that was free, >> fast and cheap, there was no reason to change. Case closed. >> >> If you thing C++ can do a better job at doing what SQLite does on all >> the variety of platforms that it runs on flawlessly, well, the source >> code is available in public domain -- go ahead and create SQLite++ by >> transcribing each function into the language of your choice. >> >> May the better plan win. >> >> > This is something of a digression but is pertinent. Colleagues who > worked with Bjarne Thorstrup (inventer of C++) tell me that Bjarne was > disillusioned with C++ and its wide deployment and would encourage > people not to use it unless there were clear advantages. > > In our own company we came to the same conclusion as Dr Hipp and used > ANSI C for our compilers and database software. C can be anything you > want it to be. For example you can ensure portability by incorporating > your own memory management system and tightly manage your use of > foreign libraries. for quality assurance You have access to highly > optimizing compilers which can produce executables as good as those > written by a skilled Assembler programmer. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
