Wednesday, May 10, 2006

Speaking of C'ing #'er

I become more of a toothpick artist, writing the numerous pieces of "glue" (methods) to bind the toothpicks (properties) into something useful (a class); where before I was a wood carver.

I have been teaching myself Microsoft's C# programming language off and on for a little while now using the O'Reilly book, "Programming C#" (4th edition). One of the problems I have with C# (and with Java) is they are radically different when compared to the other programming languages I know (assembler, COBOL, PL/SQL and PHP to name a few) and how you build applications (or "solutions" in the Microsoft world) with those languages.

For example:

COBOL is the most straight-forward language I know. It is also the most verbose, has minimal string handling, index rectangular array handling, and a monolithic memory structure. In the old days, back in the age of the dinosaur (mainframe), development was mostly time consuming (unless you modularized, which most smart people did) but it was simple because you were forced into specific ways of doing things. For transaction processing you used CICS with BMS, pseudo-conversational programming with temporary storage queues and/or communications areas. For batch processing you had JCL (JES or POWER/JCL) defining search paths and inputs and outputs for program executions.

PHP is the most useful language I know. PHP, however, suffers from version differences (4 versus 5, object and function), relies upon hundreds (over a thousand?) functions to accomplish basic tasks and complex tasks, has inconsistencies and "experimental" features in those functions, allows variables that are not strictly "typed", is said to "encourage bad programming techniques" (whatever that means) and has known, exploitable components that require either programming or specific setup to trap or avoid.

Now I'm learning C#. When compared to PHP, the vast and extensive function library has been replaced by the .Net 2.0 framework. The more and more I learn about C#, the more I realize that the language is only a small portion of an executable solution. As a programmer I no longer concern myself with writing code because it's already in the framework, someone has already developed a component or offers a web service for free or nominal (expensive) cost, a legacy component already exists or the code is generated for you by the Visual Studio. I become more of a toothpick artist, writing the numerous pieces of "glue" (methods) to bind the toothpicks (properties) into something useful (a class); where before I was a wood carver.

The biggest difference, however, is the object oriented world versus the linear and/or modular world. When I think of a program I think of it as a "list of instructions to accomplish a task". Even when introducing iterative and decision constructs I can still think of the program as a linear list of tasks (i.e. repeat steps five through eleven while there records available). Even with a stateless program like a CICS transaction there is the concept of a linear list of instructions, just with a different start (entry point). Object oriented programming seems backwards; you write code (or have it generated for you) to interact with objects that accomplish interdependent tasks.

I burnt out yesterday when I got to the chapter on arrays; and all of Microsoft's implementations like Queue and Dictionary. My mind was having a hard time grasping the "indexers". The String and Regular Expression pieces should be a breeze, though.

No comments: