erb2x@babbage.acc.virginia.edu (Erik Bleyl) (02/23/90)
I'm getting ready to develop a new product using a 386 based Compatible PC and have the enviable task of selecting the development system of my choice. What I am curious about is the following: Assuming C is used as the base language which C compiler is better(Turbo or MSC) What development tools exist in the current market to help prototype and assist in the development stages? Does a Hypercard product exist for the PC? Which database packages provide the programmer with the most usefull and effective routines? If I choose to use a windowing product should I pick MS Windows, Desqview, or some generic windowing routines? Please email any response to erb2x@uvacs.Virginia.EDU Any responses would be greatly appreciated. ------------------------------------------------------------------------------- erb2x@uvacs.Virginia.EDU Department of Computer Science, University of Virginia Charlottesville VA 22901
bcw@rti.UUCP (Bruce Wright) (02/24/90)
In article <1257@babbage.acc.virginia.edu>, erb2x@babbage.acc.virginia.edu (Erik Bleyl) writes: > > I'm getting ready to develop a new product using a 386 based Compatible PC and > have the enviable task of selecting the development system of my choice. What > I am curious about is the following: > > Assuming C is used as the base language which C compiler is better(Turbo or > MSC) > > What development tools exist in the current market to help prototype and > assist in the development stages? Does a Hypercard product exist for the PC? > > Which database packages provide the programmer with the most usefull and > effective routines? > > If I choose to use a windowing product should I pick MS Windows, Desqview, or > some generic windowing routines? You don't mention exactly what kind of product you're talking about, but I can't help but get the feeling that you or someone else in your organization has put the cart before the horse. Many of the things you ask about (such as the choice of database, or the choice of MS Windows vs other windowing systems) are things that can't really be answered in the abstract. There are tradeoffs (both technical and marketing) and different circumstances may imply that different environments ought to be used. For example, an inherently text-based application like a VT-100 terminal emulator or a straight text editor (as opposed to a word processing system) doesn't derive anywhere near the technical benefit from MS Windows as does an inherently graphical application (not to imply that the benefit is zero - MS Windows has more going for it than just graphics - but it also has some serious negatives such as using lots of memory and processor time). If you are using a database, are you looking for sheer capacity, speed of retrieval, ease of use, or resistance to hardware and software errors? Do you require a specific data model (relational vs hierarchical vs network, for example), or will any model do as well? I think you get the idea. What you, or someone else in your group, needs to do is to sit down and define more clearly where you are trying to go; then some of these questions may answer themselves, and you will know what questions to ask in order to answer the others. Some of the things you might consider: o Niche: Is this product going to be a complete, turnkey system that doesn't have to work with anything else (with your organization providing all software and maybe all hard- ware) or is it going to be coexisting with other products? What industry or function does it address, and what is the current customary practice in that area? o Marketing: Who within the customer's company will be buying the product? How will you reach them? How will this fit into the rest of your customer's operations? Are they likely to be attracted by things like fancy graphics, or are they going to be more interested in blinding speed (for example)? o Technical: Given the functions that the product must perform for the customer, what functions would be most important to have in the underlying system hardware and software? I don't mean to imply that this is an exhaustive list. It's just a few things I can think of off the top of my head. I don't think anyone can really do justice to your questions in the posting before you have answered many of these questions - perhaps you have, but you can hardly expect to get reasonable answers from other people unless you share something more about what you are looking to get out of the system environment software. If at ALL POSSIBLE, it would be EXTREMELY useful to talk to some potential customers of your product beforehand to find out what they would like. It might make answering a lot of the questions above much easier, and would save you from having to guess how somebody else wants to do things. Much of this even applies if you are developing software for use within your own organization. Good luck - Bruce C. Wright