Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!princeton!udel!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!nuchat!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: Date: 16 Nov 90 18:39:06 GMT References: <27376@megaron.cs.arizona.edu> <-M.6315@xds13.ferranti.com> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 20 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > As to this I have good news! DBMSes and 4GLs are often (anectodal but > frequent evidence) impressively *faster* than any ad-hoc program that > does the same. NOTE: *the same*, not similar but much much simpler. [mainly when manipulating large masses of data] Sure, use the right tool for the job. I once wrote an adventure program in APL as a learning excercise, but I'd be hard pressed to recommend it to anyone for that purpose. It's a killer language for tasks that need a lot of matrix operations, though. But for tasks that don't lend themselves to the database model a DBMS is really really slow... [also, as an aside... you can get the same sort of speed with a killer subroutine library that duplicates the DBMS operations embedded in your mid-level language: I believe Oracle sells such a beast] And even if you're manipulating large amounts of data, you may be better off with a lower throughput but quicker-responding mid-level language. I wouldn't want to manipulate MIDI data in real-time with Oracle, even if you are dealing with large masses of pretty homogenous data. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com