Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: Sybase, embedded SQL, and the library approach Message-ID: Date: 30 Oct 89 19:27:37 GMT References: : <1528@esquire.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 28 In-reply-to: rreid@esquire.UUCP's message of 27 Oct 89 20:11:06 GMT In article <1528@esquire.UUCP> rreid@esquire.UUCP ( r l reid ) writes: Sybase says they feel that the library approach is superior to the embedded approach. My problem is I disagree - I like to have the choice; and the embedded code is for me in most cases easier to write and maintain. Hmmm, does the fact that there is usually little support for embedded languages amongst traditional implementation facilities ever bother you? For instance, I have not found any version of indent(1) or cb(1) that will parse all embedded language constructs correctly. Also, limitations in the embedded language parsers often get in my way (DEC's RDML preprocessor bit me recently when it recognized a comment delimiter within a C string as being an actual comment delimiter which it promptly close for me!). Utilities like Yacc and Lex (even C++ preprocessing) do not handle embedded languages too well (if at all). In short, if you like writing straightforward programs from scratch in a language supported by the embedded language processor, then the embedded approach may be "easier to write and maintain" (personally, I think that is just a question of ones mindset). However, if you plan to stray outside this environment, you may find the embedded approach more of a headache than anything else. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "Nobody here but us chickens..."