The Programming Language Doesn't Matter
- Modern Development Environments
- What Is a Good Programming Language?
- Evaluating C++
- The Microsoft Development Environment
- Evaluating Java
- Does .NET Make a Difference?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Although I have worked in marketing and sales support, and although I write about IT architecture and other fancy stuff, I have a secret. Like many ex-programmers, I can't resist the temptation to do some programming now and then.
In the "old days," I used to program on mainframes. I used Unisys MCP machines (I started on a Burroughs B6700), and I programmed in Algol and COBOL. A young grad these days would be appalled by the conditions of programmers then. We used simple text editors, compiles took forever, and object-orientation still hadn't escaped from the ivory tower. You were allowed only limited access to the runtime environment because you were sharing the machine with many other programmers (on a machine the power of a workstation or less). There weren't interactive debuggers, and there were few other tools. But we persevered and wrote database-management systems, operating systems, and compilers. We used Algol or its derivatives for system software and system utilities, and we wrote large online banking systems in COBOL. Others at the same time were doing equally impressive things in Assembler. We looked down on them in much the same way that modern grads look down on us now.
We Algol programmers also looked down on COBOL, even then. To our minds, COBOL had two basic failings: It wasn't block-structured, and it was wordy. The lack of block structure has long been fixed in later versions of the standard, but COBOL is still wordy. COBOL does not have unsafe constructs; there are no pointers, for instance. This means real difficulties writing a program like a compiler, but you don't need these features for batch and online transaction-processing applications. COBOL excels at certain kinds of data manipulation, such as reading and writing properly formatted monetary fields. In many systems, the COBOL compiler (or precompiler) provided database-manipulation commands as an extension to the language. In Unisys A Series, for instance, if you declare a database, all your database record layouts automatically became COBOL 01 record formats without writing another line of code. In many ways, JBDC, ADO, and others are backward steps.
When PCs came out and became cheap enough for me to buy one, of course I wanted to program them, too. I wasn't going to write in Basic (I had some pride), so I bought Borland Pascal. Since then, I have switched from Pascal to C++ and have used later and later versions of the C++ development environment. Today I am using Microsoft Visual C++ Version 6. My interest is in writing modeling programs—in particular, modeling biological systems. I can't say that I have achieved very much; like many who do occasional programming in their spare time, I keep setting off on a hugely ambitious project and leaving it unfinished.
Modern Development Environments
Compared to programming in the old days, modern development environments are fantastic—color-coded editing, intelliSense, interactive debugging, wizards, class libraries, and so on. I also think that Microsoft (and probably its competitors in this field) does an excellent job in trying to keep its developers informed. There are a huge number of books on every possible programming topic. It should be programmer's heaven.
But it isn't.
There are some inherent problems. Writing a program that uses menus and screen formats (using C++ like Visual Basic) is relatively straightforward, but graphics programming isn't. Drawing the graphic isn't the problem, but things such as figuring out which line the mouse is positioned on or moving the text caret can require some gruesome code. Much is often made of the difficulties of writing event-based programs (Windows programs have to handle a stream of messages coming at them from the operating system), but the difficulties are nothing compared to complexities of transaction monitor or database software on which I worked previously. Graphics programming has its complexities, but I can't blame the language or the development environment for that.