The better sales pitch and better political connections persuade the granter of research grants. Better design and better science proves itself by performance and success in the marketplace and bad design and bad science consumes the grant without productivity.
This has strayed from the topic. It should get back to Sqlite. James Gregurich wrote: > I describe reality. > > Someone has to be the arbiter of "better." Generally, that arbiter is > the guy handing out the research grants. > > On May 1, 2009, at 5:33 AM, John Stanton wrote: > >> Science is the Scientific Method - observation, hypothesis and >> skepticism. The antithesis of politics. There are no facts in >> science, >> only observations and any hypothesis is only valid until a better one >> replaces it. >> >> You describe bad, politicized science. >> >> James Gregurich wrote: >>> With all due respect, science itself is a set of >>> "positions" (opinions) which are endorsed by small group of people as >>> official doctrine after appropriate study. Saying "A 'position' is >>> politics, not science" is not a particularly meaningful statement. >>> If >>> you want to argue that point, feel free to send me a private email. >>> >>> My threaded application works pretty darn well. I can process >>> thousands of print industry files on an 8-core system keeping the >>> cores busy without lagging the GUI for other applications. Just >>> because many people create ill conceived programs doesn't mean >>> threaded programs are inherently doomed to be ill-conceived. The >>> development tools and techniques for building concurrent systems are >>> advancing and making concurrency quite feasible. >>> >>> James Gregurich >>> Engineering Manager >>> Markzware >>> >>> On Apr 30, 2009, at 5:01 AM, John Stanton wrote: >>> >>>> A "position" is politics, not science. Warnings about the use of >>>> threads are based on science, and advise you to avoid them if >>>> possible >>>> for your own protection. >>>> >>>> I see ill conceived programs using threads which go to complex >>>> synchronization to achieve the equivalent of single stream execution >>>> but >>>> with much greater overhead. A KISS situation. >>>> >>>> James Gregurich wrote: >>>>> thanks for the info. That should work for me. >>>>> >>>>> Given the industry is going multicore and 16-core macintoshes for >>>>> your >>>>> grand-mother are just a few years away, I recommend you rethink >>>>> your >>>>> position on the use of threading. Apple is heavily pushing >>>>> parallelism >>>>> on its developers. NSOperation is a major part of that effort. >>>>> As I >>>>> understand it, MS is developing their copy of NSOperation for >>>>> VS2010. >>>>> The development landscape is only going to get more threaded as >>>>> time >>>>> goes on. >>>>> >>>>> -James >>>>> >>>>> >>>>> >>>>>> On Apr 29, 2009, at 10:03 PM, James Gregurich wrote: >>>>>> >>>>>> >>>>>>> howdy! >>>>>>> >>>>>>> question: >>>>>>> >>>>>>> for an in-memory db with the threading mode set to serialized, is >>>>>>> >>>>>> the >>>>>> >>>>>>> internal mutex held for an entire transaction so that one thread >>>>>>> >>>>>> won't >>>>>> >>>>>>> access the db while another one is in the middle of a transaction >>>>>>> >>>>>> with >>>>>> >>>>>>> multiple insert statements? >>>>>>> >>>>>> No. But the mutex is recursive. So you can get a copy of it >>>>>> using >>>>>> sqlite3_db_mutex() then lock it yourself using >>>>>> sqlite3_mutex_enter()/ >>>>>> leave(). >>>>>> >>>>>> Also remember: You should not be using threads. Threads will >>>>>> bring >>>>>> only grief and woe. On your own head be it. >>>>>> >>>>>> >>>>>> >>>>>> D. Richard Hipp >>>>>> drh at hwaci.com >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
