************************************* * * * DB/C Newsletter * * November 2004 * * * ************************************* News and Comments This month's article is an update to an article written nine years ago for this newsletter. It's quite interesting to read the history of DB/C in those old newsletters. You can find them at the 'DB/C Newsletters' link of the DB/C Software Company web site. don.wills@dbcsoftware.com ****************************************************************************** Why Use the DB/C Programming Language (revisited)? The DB/C programming language has well endured the passage of time. DB/C is based on DATABUS, a language created more than 30(!) years ago by Datapoint Corporation, a company that is now long gone. There are a variety of reasons for DB/C's long-term success. Some of these reasons were detailed in an article titled 'Why Use DB/C' that appeared in the October 1995 issue of this newsletter. Many of the reasons discussed in that article are still relevant today. In this article, we'll update that discussion with reasons why DB/C DX is still a good choice. Portability is always the first point of discussion about DB/C DX. Several operating systems of 1995 are now gone - for example VMS and OS/2. Those were important operating systems of that time. Many of the customers who used DB/C on those systems have moved to UNIX and Windows, without rewriting any code. Here is any interesting quote from the 1995 article: "Ten years from now, programs that exist today will be running on hardware and software systems that don't exist today - maybe even from companies that don't exist today." Little did we know that LINUX, which isn't owned by any company, would become a dominant operating system and a major platform for DB/C DX based applications. Portability isn't just about changing operating systems. In the next few years, a major revolution will be taking place in the Windows world. Applications that are written to the Win32 API using Visual Basic, C, C++, and other languages will need to be rewritten in one of the new .NET programming languages. This will be a big conversion, taking many years and lots of development resources at many applications programming shops. With DB/C DX, you won't have to change anything to move to the .NET platform. In some future release (maybe DB/C DX 15), the Windows DB/C DX runtime will use the .NET API instead of the Win32 API. It should be completely transparent to your DB/C DX programs, whether character mode or GUI. The API transition problem isn't just a Win32/.NET issue. One of the most important aspects of DB/C is the fact that it is a domain-specific programming language. Its domain is business applications. For example, the file I/O and print functions of DB/C are tailored specifically for development of business applications. In general purpose languages (Java, C#, etc.), you need to use APIs that are outside of the core language to do many things that are important for business applications. The ability to generate PDF print files directly in a DB/C DX program without using a third party class library is a good example of this. Microsoft has provided a variety of APIs for doing file I/O in their programming languages. ODBC, DAO, ADO and RDO are four incompatible file I/O APIs that Microsoft has championed over the last ten years. During this time, DB/C's ISAM and AIM file I/O has not changed. Relational (SQL) database to object mapping is a related topic. It has been interesting to watch the introduction of various ORM (object to relational mapping) technologies through the years. ORMs have been introduced for both Java and Windows development. JDO is one of the ORMs in the Java world. Basically these technologies attempt to map SQL rows into programming language objects. None of these technologies has been particularly successful, probably because the whole premise is flawed. The SQL SELECT statement is about flattening a structured result (think order header, order detail, item master file). And then the ORM tries to unflatten the data back into a structure of objects. A lot of extra effort is needed to define these conversions. The reason for the digression about ORMs is to note how well the ISAM and AIM models fit the problems found in building business applications. Business applications are built around persistent records that may or may not be well structured. Objects in today's general purpose programming languages are not persistent without going to a lot of work using strange add-ons to the language. The elegant simplicity of READ, WRITE, UPDATE and DELETE is really a big deal. Other reasons for using DB/C mentioned in the 1995 article are still relevant, including these: . intrinsic fixed decimal arithmetic . performance, both development and runtime . ease of understanding a program (words instead of symbols) . intrinsic access to print spoolers and many print output formats And last, but not least, we can't forget Eclipse. This robust IDE is the best cross platform program development environment available today. Developing DB/C DX programs with DDT is truly an enjoyable endeavor. Hopefully you will now have a little more ammunition the next time someone asks you why you use the DB/C programming language. ****************************************************************************** DB/C DX Class Schedule Class: DB/C DX Fundamentals Date: First quarter, 2005 Location: to be determined For information, send email to admin@dbcsoftware.com. ****************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you monthly, just send an email message to 'dbcnews-subscribe@dbcsoftware.com'. The newsletter will be delivered to the email address from which the message was sent.