I half get his point--if it's hard to program, then only really good programmers will do it.
But that argument has been made against every advance in software development since the profession began. Patchcord-pluggers made fun of switch-flippers. Switch-flippers made fun of microcoders. Microcoders made fun of assembly-language programmers. Assembly-language programmers made fun of high-level-language programmers. High-level-language programmers made fun of modelers. And everyone makes fun of ruby programmers. But this argument is basically bullshit, because it misses a key truth: software has improved in power, usability, and ubiquity. When only a handful of people could program a computer, then only a handful of useful things were doable with computers. Was that desirable? Or is it better that we have zillions of powerful applications written by all manner of programmers available all over the place? If the masses can program, then you get masses of programs, and you can let market forces weed out the bad ones. Linus' argument basically boils down to real men don't use numerically controlled machine tools. Back when men were men, they built cars by hand, the way god intended cars to be built. The way his grandpappy made cars, dammit, snarls manly Linus as he rocks on his porch, whittlin' and spittin' chaw. ----- Original Message ----- From: "Roger Binns" <rog...@rogerbinns.com> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Sent: Monday, September 21, 2009 10:42 AM Subject: Re: [sqlite] List of active savepoints names > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lukas Gebauer wrote: >> I am not creating and releasing savepoints! > > Yes you are. The SQLite library is not magically doing them on a > whim. > Your code is asking for them. > >>> You can create a custom wrapper for savepoints which may have >>> the stack of calls. >> >> Why I must duplicate code what is inside Sqlite too? > > There is no code inside SQLite that returns the list of savepoints > so there > is nothing to duplicate. There is a data structure of savepoints. > > Adding this code and API seems simple enough and superficially it > is. > However once added it cannot be removed (dynamic linking would > break), has > to be documented and tested, and adds some bloat to SQLite. It > would also > constrain future changes to underlying data structures. For example > if the > public API returns a flat list, it would complicate things if the > internal > data structure would be better off as a tree. > > Although it may not seem like it, one of the most important jobs of > project > maintainers is saying "no". Here is Linus Torvalds on the subject: > > http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html > >> Sqlite have savepoint stack inside (AFAIK). I really not know why >> is >> a problem to list this stack through some API. (But maybe it really >> is a problem, I don't know, but nobody tell this yet...) > > This code will print out the names to stderr. You should be able to > do the > equivalent from your debugger. > > void print_savepoints(sqlite3 *db) > { > int i; > for(i=0;i<db->nSavepoint;i++) > fprintf(stderr, "%s\n", db->pSavepoint[i]->zName); > } > > They are also in a tree like structure so it isn't quite that > simple. > >> Yes, I can create my own wrapper, what can work with my code only, > > It is your code that needs debugging :-) > >> Just because I must duplicate >> lot of code for decide if savepoint is or not is created, > > If you have random code generating random SQL then it is harder, but > that is > a bad design anyway. Generally you'll have a function that when > called > generates savepoints and another for rolling them back. But even > with > random code, the authorizer interface can tell you when savepoint > SQL is > prepared. > >> And now compare it with simple API funtion what just list existing >> savepoint stack inside Sqlite. It is simple, trivial, useful... and >> working right at any case. > > And constrains data structures, requires documentation and testing, > can > never be removed and adds bloat. And in most cases still isn't > useful by > itself - you would still need to add yet another wrapper around that > function depending on what you want to happen (print it indented as > a tree, > convert to utf16 or ascii, combine names separated by commas, stdout > or > stderr, gui dialog etc). > >> This is why I am asking for. Thanks! > > A simple rule of thumb is to look at how useful features would be to > other > SQLite users. Note that you are the only one to have asked for this > feature > and not one other person has agreed with you on its need! The > responses > have generally been along the lines of suggesting you organize your > code so > that you do not need it. But even if it was added as a debugging > aid, do > you expect people to compile up two versions of SQLite - one with > debugging > aids on and another with them off? This feature would impose > decisions like > that on others in addition to the future maintenance costs. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkq3uvIACgkQmOOfHg372QQI/QCcDDg5dthEmqBJj+FZL5NhatN2 > JusAoMSHlyXRJsLHMhCF+S3vQgKFUX7E > =+RxM > -----END PGP SIGNATURE----- > _______________________________________________ > 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
