Programming Languages that insulate the developer from the underlying API may not be the best choice.
Following on the heels of my last blog entry from earlier today, about software projects: the reason that the environment where I was made such an important difference is that in the last couple of weeks, I was attempting to write code that did some low-level stuff that I had never written before. Specifically, I was trying to create a server with Visual Basic that used the Winsock API to listen on a socket for data from tool controllers that are located on an assembly line.
I chose this approach because it would seem to be the best way to create a server for a non-PC device. However, I am afraid I did not succeed in writing code that used Winsock. I think it listened for a bit and then would hang up. What frustrated me is the lack of documentation of the Winsock API for VB 6. There were no "complete" code examples that I could find, specifically, of how to use select() or its brethren (like FD_SET(), if it exists in VB) in Winsock2 so that one could serve multiple clients. I needed to create a server that could handle connections to at least 2 controllers.
If this failure served any purpose, it was to show me how much learning programming with VB distorts one's view of programming, especially in terms of how it's "really" done. At one point in my travails with Winsock, I referred to a text on Linux programming to see how sockets is implemented in the Unix/Linux world. Then I found documentation on Winsock, all of which was written in C/C++. This was an eye-opener; seeing how similar the implementation of socket/Winsock is on the two platforms made me see how fundamental the API is on any platform you're writing software for. I also saw why C/C++ developers joke about how VB is a "toy" language, and understood why the insulation from the underlying API is a distinct disadvantage. It would have been far easier to write the server in C or C++.
The truth of the matter in the history of Visual Basic is that before there was COM or ActiveX or OLE, there were application programming interfaces for 16-bit and 32-bit Windows. Developers wrote applications that utilized the Windows APIs, just as C and C++ programmers would call upon these same API functions. The advantage of using API functions is that they are more powerful than many of the intrinsic facilities in Visual Basic. In many cases, API functions were the only way to accomplish many of the things one wanted to do with VB. Facilities for much of the functionality of Windows just didn't exist in the native language. In contrast, for C and C++ developers, this is essentially what you do with everything-- you include libraries of various kinds of functions in your application, and you call upon specific functions as needed.
I came into the IT world at a time when VB 6 was the standard Windows tool for rapid application development. In none of my university classes were the concepts of "API functions" or "application programming interface" stressed. In my classes in C and C++, we certainly used function libraries, but somehow it escaped me, and probably my other fellow students on the VB client server track, that all contemporary programming comes down to writing code that uses API functions whose parameters are not exposed by IntelliSense dropdown lists. In the VB cilent-server classes, utilizing objects, especially COM or OLE objects, was emphasized, and calling API functions wasn't taught at all. I understand now that the instructors might have thought there were better uses of class time.
In Visual Basic, API functions must first be declared before they are used, much as one has to set a reference to an object library before calling the functions that one will use in that library. The difference is, that the parameters in the API declarations had better be exactly what the function is expecting to receive, otherwise you may get errors, possibly fatal ones that bring the Blue Screen of Death to your machine. In this case, there is no IntelliSense to help you out. Programming to the Win32 API in VB can thus seem like working with a black box. What's more, every function in a DLL you want to call must be declared before it can be used. Contrast this to the situation with C/C++, where all you need do is include a library header file in your program, then call the function in your program. Plus, you can usually browse the header file to see exactly what the functions in the library do.
If I were intent upon sticking with VB 6 as my primary programming language, I would invest more time into learning about API functions, especially functions that manipulate Windows user interfaces. The native language facility in VB 6 is inadequate in a lot of situations for giving the UI a polished, professional look, and opens the developer to wrestling with details that are out of his reach. For instance, how to reposition controls on a form so that no matter what resolution the user's monitor is, they will be able to see and access all controls without changing their display settings. If nothing else, give me a way to make the form scrollable if it's going to take up more real estate than what's on the screen! Setting properties in the Visual Studio IDE doesn't seem to work for MDI applications-- the child forms don't inherit this property from the parent, and it doesn't exist in the properties list for the child form! I bet that one of the over 9,000 functions in the Windows API would be able to help me out-- if only I knew which one.
My most recent project experiences make it abundantly clear to me that a new toolset is needed if I want to program anything other than departmental databases and web applications. Along with that is the need to cultivate a new mindset where it comes to programming, that recognizes the underlying API for the platform and helps me to focus on the best way to give the user what they want out of an application. In future blog entries, I hope to outline my explorations of different toolsets for their solutions to the programming challenge.
Comments