The days when programmers could get by on skills in a single programming language have passed. Newer products call for a suite of programming skills. At a minimum, programmers should be able to to develop both a presentation layer (Visual Basic, Java), as well as a database layer (M, SQL, etc.) In this environment, what is a prudent MUMPS programmer to do? Greg Kreis shares his experiences in learning Java and Object Oriented programming by helping start a study group. This article reveals the authors reaction after returning to MUMPS programming after working with more mainstream technologies.
What do you do when you have been programming in the same language for many years and realize that you want and need to broaden your software horizons? In my case, I had two hurdles to overcome. I had used a Macintosh heavily since 1984 and programmed almost exclusively in M since 1979. Since neither technology is commonly found in business today, I needed a plan.
I decided to hitch my wagon to Java to see what this object orientation (OO) talk was all about. After all, if you plan to broaden your horizons, why not do it in an emerging market where not everyone is expected to be a seasoned veteran? Besides, my research showed that Java is founded on the principle of code portability, a premise I found so appealing in M.
Searching on the web, I found a local Java User Group in the Atlanta area (AJUG) that was just getting started. Fortune smiled when I met a most amazing person at one of the meetings. Jack Harich is a very bright, creative fellow with tireless patience, and love for sharing ideas and spending time with others. Can't you just imagine a fellow who signs all his email with the upbeat signature, "Happy Jack"? Would that the world had many more like him.
Jack made a career change from custom woodworking to software, for health reasons, and decided to dedicate his time and efforts toward learning object oriented modeling and design using Java. When you see some of Jack's masterpieces in wood you quickly realize he is an extraordinary craftsman, and it shows in his software efforts. Jack and I discussed forming a study group that could meet twice a month to explore Java and OO -- the Java-as-a-Second Language (JSL) study group was born.
We started meeting at my home, but it was a long drive in traffic for everyone, and Jack was lugging his 21" monitor and computer to each meeting. After a couple of weeks, one of the JSL members was able to reserve a room at his employer's offices, but we continued to grow and soon needed more meeting space. We finally found a training center, New Horizons, that was willing to provide a meeting room in the evenings with a big screen projector for no cost.
To keep us on track between meetings, we decided to start a web site: (http://www.mindspring.com/~gkreis/jsl/) and a mailing list. The management at Five Points, a Java consulting firm, graciously provided a server for our mailing list. We learned to patiently explore the contacts of our group's members to secure the required resources for meetings. Never underestimate the number of people that you know, directly or indirectly.
The weekly two and one-half hour JSL meetings are typically lead by Jack Harich, as we explore our OO projects, classes, models, Java, etc. Jack announces the meeting agenda, via the mailing list and web site, several days before the meeting. With typically ten to fifteen in attendance, we have lively discussions exhibiting a range of interests.
We have experimented with different topics and the approach to the meetings to determine group interests and what seems to work well. Hands-on meetings, where members work in small groups around a laptop computer or with pencil and paper, are popular, especially after meetings where new topics have been introduced. When a technique or topic does not appear to be of interest, we move on, requesting member guidance and ideas.
Meeting notes are posted promptly to the JSL web site to allow those who missed the meeting to stay current. This practice also allows everyone to download software, UML models, etc., created in the meeting. Trends of our meetings include:
My JSL experiences show that you must be patient while a core group forms. There are always newcomers, but the core members are the ones who maintain the momentum. While this group is forming, however, the founders must put forth the extra effort to provide meetings that will attract, meeting after meeting.
Until recently, we functioned without a formal membership model and did not charge for meetings. As we have grown and the projects have matured, however, we have found that we may need to offset miscellaneous expenses, such as copy costs, etc. Time will tell if charging a nominal membership fee will be viable.
The JSL has helped at least half a dozen programmers in preparing to pass their Java Certification exam. For example, a Mac User Interface designer came to us with no programming experience, attended regularly, and in short order received his Java Certification and took a job programming in Java. Jack Harich's mentoring efforts with a restaurant worker helped him to get his first programming job in Java. These and other examples show that the support and camaraderie of those who are striving for a common goal is a highly motivational force.
While studying with the JSL, I was also doing a pilot project with Delphi and SQL that involved more Win32 API calls than I ever expected. As a result, I was getting a double dose of OO and finding the similarities and differences between Delphi, Win32 and Java to provide a great learning experience.
For me, the JSL meetings have provided a steady diet of OO topics and Java code. Little by little, I am gaining comfort with this new way of thinking, something I might have felt overwhelming if I tried to study it on my own. Not only am I stimulated by the discussions at the meetings, but I am making valuable connections in the growing local Java community.
At the end of the Delphi project, coming back to M programming after a year's hiatus, I had a few pleasant surprises waiting for me.
1. Renewing my friendship with M arrays made me realize all the more why I had pined for their power and simplicity. In my wanderings, I never found a persistent structure its equal.
2. There is also something to be said for a language that is small enough to fit in your head! One quickly finds the number of APIs and classes in Delphi, Win32 and Java to be mind-numbing.
3. I had forgotten how comforting it is to work with a very familiar language where surprises are few and far between. This is a setting where you can concentrate on what you are trying to say and not how to say it. (This reminded me of a friend who came from Germany to the U.S. at the age of fifteen. Even though he had been speaking English for over thirty years, when asked to lead in a public prayer he could not think of a single English word, his thoughts could only be expressed in German. In times of stress, one has a mother tongue.)
Having quickly settled back into M, like a favorite easy chair, I discovered there were a few lumps that I did not recall.
1. When I started to piece data in global nodes, I realized it was a practice I could not defend. Data should be encapsulated and clearly identifiable in code. Who remembers what is stored in piece 4 of a global node six weeks later, not to mention six months?
2. In typical M systems, interactions with the user, logic and data are too tightly coupled in programs. While I realize this is not specifically a failing of M, the extreme simplicity of dumb terminal dialogs and global accessing leads programmers to create quick fixes and one-of-a-kind solutions. In a perverse way, other languages promote reusability by making data access, for instance, so tedious that there is a quick return on an investment to code reusable components.
3. Standard M is not easily extended through the addition of libraries. In Java you can easily add support for such areas as multimedia, telephony, etc., through the use of a namespaced package. This promotes the development of a healthy market that provides low-cost, high-quality extensions.
4. There is no inherent support in M for the concept of an Interface, as defined in Java. An interface is a way to define an API contract between two programmers. The creator of the interface specification defines the method signatures (method name and parameters) that must be present in an implementation of an interface. This permits a programmer to write their software to use an interface, without knowing the name of the class (routine in M terms) that will provide the implementation. This also makes it possible to substitute different implementations at run-time.
The above list of M negatives can be overcome, or at least managed, through ingenious designs and enforced programming standards, but not until they are recognized as problems requiring a solution.
I am accomplishing my stated goal -- to expand my software horizons. For example, JSL members introduced me to the concept of design patterns, a way to express software using reusable collections of collaborating classes. An example of a commonly used design pattern is an iterator. An iterator provides a way to navigate and access members of a collection, without knowing the source or structure of the collection. (Notice we have not defined anything about the implementation when describing the pattern. While some design patterns are only applicable in an OO setting, many are universal in their applicability.)
Applying the iterator design pattern in M would let you create, destroy and modify a collection of items without knowing if it was stored in a global, a sequential file or even being accessed through TCP/IP sockets on a remote server. We can benefit from recognizing design patterns that work well in M, cataloging them so they can be readily reused and communicating them to others.
As a result of my JSL experiences, my approach to systems and applications development has been challenged. In years gone by, portability was achieved by using M for virtually all aspects of a system. In today's world, open standards, loose coupling, multiple tiers and a framework that avoids implementation entanglements is the name of the game. In this environment, when M has the superior characteristics for a task, it will be my first choice, but no longer just because I know it well.
I have personally benefited from the JSL experience by meeting some fascinating people and making several new friends, while at the same time being intellectually stimulated by the challenges of OO and Java. Breaking out of my procedural thinking has been a struggle, and I still find myself at times approaching Java projects with a procedural mindset.
When I get a chance, I share some of my M passions with my new friends. They have all found the idea of globals intriguing, but I can tell they have the same trouble breaking out of their SQL and relational database mindset that I have in breaking into OO.
Perhaps you noticed that many of the concepts I presented in this article are not new. Encapsulation and reuse, for instance, have been goals in computer applications for decades. Excellent M applications programmers have already implemented these concepts in their own ingenious ways. What was new for me was seeing them in settings outside of M. This helped me to appreciate their utility, stripped of the distractions of the language of expression.
Might you benefit from this kind of study experience? It depends on how quickly you grasp new ideas, how many ingrained habits you have developed, how open you are to change and how much time you are willing to spend. These factors combine to determine how long it will take to transition to objects. Don't expect to do it overnight. It will take years to develop the skills you need to become fully proficient in an OO world, but in my opinion it is a worthwhile endeavor. Go for it.
Greg Kreis is president of Pioneer Data Systems, Inc., a small consulting
and training company. He believes learning is its own reward and applauds
those who make it one of their lifelong endeavors.
Email: gkreis@mindspring.com
http://www.hardhats.org/.