A Paradigm shift in moving from ABAP development to Microsoft technologies
My first few months learning ABAP were particularly annoying, for a wide variety of reasons. Yes, it was a new language, no, it was unlike anything that any of us had ever worked with. We were a batch of would-be-ABAPers learning this language for the very first time, wondering why was a language ever developed that was so different from C++ and Java. Every single ABAP statement was being met with resistance as to why it was done in such an unintelligible way and not in the simplistic way that C++ and Java did.
Writing statements that ended with a full-stop (.), instead of a semi-colon (;) was something unheard of in the software world that we came from. Add to that the plain jane and blue editors and simplistic IDEs that we had to code in. On the other side we had Visual Studio, Eclipse, Netbeans and other simple editors with color coding, code completion, and so on. Yes, it was annoying, and it was for a reason.
And then, for the next 5 years, I coded my heart out in ABAP. I was fortunate enough to witness a lot of changes in the language, and in the development tools, that made coding in ABAP a pleasure. I took to ABAP like fish takes to water and I enjoyed pushing the capabilities of the language to the maximum. Each time I pushed, I learnt something new, and I learnt something that I could share with the other ABAPers. After working on ABAP for so long, and developing a lot of ABAP tools and products, realization dawned upon me. A numerous number of times have I told this, and I tell this yet again- “There is no better language than ABAP to build SAP products with.”
ABAP is a very interesting language. It is unlike anything that you have ever worked with. It changes your way of thinking as a programmer. You have to live by the rules and limitations of ABAP and once you accept those rules and limitations, you being to realize that the product that you are developing also needs to work within those rules and limitations. So what limitations you felt ABAP had, were no more a limitation for your deliverables. In fact, I began thinking so much in the ABAP way, that during a CodeJam event that I was participating in, which allowed the use of only open languages, i.e. one for which a compiler was freely available, I felt that the solution could be completed in half the time and half the size, had I the chance to use ABAP. Unfortunately that was not to be and I ended up coding a long-winded program in C++, where I could not use internal tables and had to stick to some age-old concept called arrays and vectors.
Well, after over 5 years, I decided to take up an opportunity to develop on Microsoft technologies. Currently, I code in C++ and C#, and use Microsoft tools, frameworks, and methodologies such as Visual Studio, .Net and COM. I still remember, when I coded my first bit in C++ on Visual Studio, the exact reaction running through my mind was – “Ewww… why does this look so primitive?” The tables had turned. ABAP had changed so much and my mind was so used to the ABAP tools that one of the best IDEs out there looked old fashioned and user-unfriendly. And don’t even get me started on the issue of debugging.
Debugging on Visual Studio is nothing short of a nightmare. You first find out which functional area, and hence which DLL, is causing the problem. Then you build the symbols for the DLL and place it along with the newly built DLL, into the location where the product was installed, overwriting the existing ‘buggy’ DLL. If this were not all, the compiler has a tendency to optimize out certain parts of the code due to which many a times, you are not able to check the value in a particular variable that would end up being the most crucial roadblock to your debugging. Oh, and if the program flow has branched off into another DLL, then repeat the symbols(PDB) generation process and start debugging all over again. Then there is the issue of multiple developers working on the same code in their local copies, and then checking-in the code into a branch after resolving differences, and then integrating into another consolidation branch where multiple streams come together, and then crossing your fingers and hoping that everything builds successfully without any compilation errors. Phew, where then is the time for coding?
No such issue in ABAP, no sir. The New ABAP Debugger was a pleasure to work with. Never did it ‘misbehave’ while debugging and you never had to deal with all the intricacies of debugger symbols and compiled code. The versioning and transport system automatically takes care of the issues of integration of code from multiple developers. Everything that is branch and build related is automated and only requires the initial set up from a dedicated team which administers development machines. Developers need least be concerned with these administrative details, and can focus purely on development and troubleshooting.
Well, I notice a marked change in my thoughts about ABAP as time went by and after I have actually started working on non-ABAP technologies, I have begun to appreciate ABAP a whole lot more. ABAP is a way of life in SAP.