Skip to Content

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.

You must be Logged on to comment or reply to a post.
    • I agree. I have been dirtying my hands on a few beta releases of Microsoft technologies and I am finding them pretty fascinating. However, my thoughts will truly count only when I begin to use them productively and have used them for a sufficiently long time.
  • Having moved from C to ABAP and now on to C# and Silverlight, I have been through some of what you faced as well. I am a big fan of Microsoft technologies now - the flexibility it offers developers is awesome.
    • @Vijay: Yes, the newer Microsoft technologies have really grown by leaps and bounds. Visual Studio 2010, C#, .Net are all great technologies. I can't be more happier that we don't need to bother about MFCs anymore.

      However, I still think the build tools of MS have a lot of catching up to do with ABAP.

  • Sorry, my friend, but you are mixing paradigms. When you are grieving for internal tables you are mixing language abilities with availability (or rather absence) of good standardized(!) libraries in C++. When you are talking about debugging and change management, you are talking about a development process – not about the language.

    I think that it is much more correct to compare ABAP with T-SQL or PL-SQL than with any other language. This pairing also good as it forms correct expectations of output.

    • You are quite right, Mikhail, in saying that I am mixing language elements. However, when one talks about ABAP, he is not talking about just the language, but about an all-in-one package. Maybe it is better to call it R/3 + ABAP versus the rest of the world?

      C++ can be developed using notepad, Visual Studio, Borland tools as IDEs. It can be compiled using microsoft, intel, borland compilers. So on and so forth. With ABAP, you work in a single track. You don't worry about which compiler is running behind the scenes and whether it will output cross-architecture compliant code. With ABAP, developing, debugging and bug-fixing is one seamless process. As I said, I don't need to worry about generating DLLs and binary compatible PDBs and ensuring that the debugger is able to link them both together so that I can debug the code.

      The point that I was getting to is that, as a 'developer', the ease with which I can realize my deliverables using ABAP is unmatched. If C++ doesn't have enough built-in libraries, so be it, all the more reason for me to use ABAP. Similarly, if the build tools of ABAP let me concentrate on coding without diverting my attention to other tasks, then again that is +1 for ABAP.

      I have not used pl/sql or t-sql much, but I felt they was more scripting language types. ABAP might have been a reporting language in the past, but with all the new frameworks and Objects available, it is a vast and powerful language that not many might realize. It is a testament to ABAP that most of the productive ABAP development tools have been built using ABAP itself. That shows how much the language has matured.

      Maybe my perspective might be different if I was from the packaging teams and release management teams since then the tools available at my disposal might be different.

      Again, reiterating what I said before, ABAP is probably the best language to 'develop' SAP applications in. ABAP might not let you create a new Operating System like Windows, but when you want the reliability and scalability of an Enterprise Application like SAPs products, then ABAP is the way to go.

  • Thanks for being brave enought to be sharing your experience.

    I have used both C,C++ and Java and ABAP over last 10 years and it is funny that your first impression of ABAP was bad and frustrating.  I never thought that.  I thought it great to be able to read a DB table without all that messing around in establishing connections. A plain editor - ...why does a good programmer need to rely on sophisicated editor?.  I have written some mad Java just in notepad and still loved it!. 

    A good tradesman never blames the tools !

    However I am glad you have seen the light.

    • Well, my first impression of ABAP was not 'bad' as much as a feeling of 'why is it like this?'. I love learning languages and ABAP was just so much more different than the C++ and Java that I was used to back then. It reminded me of COBOL and BASIC which academically were only high school languages, while C++ and Java were college level languages. It was like stepping back in time. I guess the feeling of moving from C++ to ABAP can be compared to the feeling of someone moving now from Java to say Python/Ruby. You have to completely re-learn the art of programming rather than just adopting a new syntax.

      Ah, I too used to be a notepad-programmer back in my school and college days. It does make one feel geeky typing out stuff on a plain jane notepad and then compiling on the command-line. But how much does that help productivity? Take a largescale application and troubleshooting could well become a nightmare. Suppose you have 30-40 files of 3000 statements each and you had to search for the definition of a method, whose call you are at. F12 in Visual Studio, and F3 in Eclipse will get you there in a flash. The same on notepad will involve using the file manager(explorer) to search inside file text to find instances where the method name is used and then find the actual method definition. Fun - yes, productive - absolutely not.

      And then think about maintaining already existing code. It is a nightmare if you do not have a good IDE.

      A good tradesman never blames the tools. A great tradesman will think about making himself some new and better tools. 😉