As Delphi (Win32) developers we are used to the comfort of the VCL. And if the VCL isn’t good enough we can get some of the many 3^rd libraries and party components (such as encryption libraries, better grids etc.) that are available on the market. Or we can, at least in theory, write our own. And that’s good; up to a certain point.

What is not so good is that in this way we are locking ourselves into various 3^rd party products (and our own “2^nd party products”) in a number of different ways. For example, when a next version of Delphi comes out, the decision to upgrade becomes a trade-off between the new features of the new version Delphi and the requirement to upgrade our 2^nd and 3^rd party toolset. It is possible that we may get stuck with an older version of Delphi because we are not in a position to upgrade our toolset. For example, a 3^rd party tool supplier may have “moved on”.

But perhaps more importantly, in terms of collaboration this also makes it harder for us to transfer skills from one project to the next, even if we find another Delphi project to work on. Unless we are lone wolf developers who can pretty much do what we like, we are likely to encounter other developers using different toolsets. And if we want to join them on a project there will be an additional learning curve as a result of getting used to their toolset. Keep in mind that the larger and more complex a project becomes the more likely it is that it is heavily dependent on a toolset consisting of various libraries, 3^rd party components, and perhaps frameworks. And because each project typically reinvents its own toolset this can put serious limitations on the reuse of our skills between projects.

The .NET frameworks address a significant part of this problem by pushing an enormous, standardised and ever expanding toolset into the operation system. The Framework Class Libraries in the various versions of the .NET framework (see picture) are like VCLs on steroids. They contain a lot of the functionality that you would otherwise get from 3rd party components and libraries. So by learning to use the .NET framework you will acquire skills that can be transferred much more easily to other (.NET) projects. For example, it is not uncommon to for a company to contract developers for a .NET project regardless of the programming languages with which the developer has experience: as long as one of them is a .NET language.

So the main reason to step into the .NET world (whether or not you want to keep that other foot in the Delphi world as well), is that the skills that you will acquire will provide you with more opportunities for future projects.

As Anders Hejlsberg, the (former) chief architect of both Delphi and C#, puts it:

“If you look at languages today, they live and die by whether they have good framework support, as the frameworks are so big and so huge and so rich that you just cannot afford to ignore them anymore. And that’s why you’re seeing so many languages being built on top of .NET or on top of Java as opposed to being built in their own little worlds.”
(http://www.computerworld.com.au/index.php/id;1149786074;pp;1)

Alex Fekken

Welcome all readers and Delphi Programmers.

Our aim is fairly simple. We want to be an integral part of Migrating Delphi programming knowledge to C#.

We have all invested so much time and energy into Delphi knowledge. In many circumstances our knowledge is needed outside of Delphi and sometimes we feel a little lost.

After many years of programming the transition to another language, either by choice or force of hand, is somewhat uncertain. it is somewhat daunting to think about relearning all of our lessons that we learnt while writing in Delphi.

Over time we built up a gut feeling and estimation process to estimate long to perform a coding task. For consultants, working efficiently is the reason why we can demand a higher hourly rate. If we produce a product to sell off-the-shelf, we have a feeling for how long it will take us to code a product and if it is worthwhile than to be sold. If we are required to quote a fixed price, based on a specification, we would have a good idea of how it would take in Delphi. We also would know from previous solutions the best architecture and potential road blocks.

Now a change language to C#.Net. Everything changes. What will we stumble across that will take us hours, days, if not weeks to solve. What if we make an architecture decision, which has larger implications down the track? All this leads to a very uncertain development environment. The result is most of us retract back to what we know, Delphi.

Sometimes, depending on our work environment, we may not have the luxury of choice. If we are applying for jobs, there are less and less jobs for Delphi developers. Likewise, for businesses who already have an application written in Delphi, they are also considering the future access to a qualified Delphi developer.

Here lies our opportunity. As proficient qualified Delphi developers we can understand how to migrate our knowledge to a more popular development environment. In this case we have chosen C sharp. In future articles we will explain why we have chosen C sharp, and in actual fact, we are a lot closer than what we think.

We want this site to be interactive site, therefore will be encouraged. Please comment freely on any article about mistakes, better ideas, or more advanced ways of solving the problem. We would love to have case studies, sample code and design discussions.

Let us know your thoughts !!!

Please contact us at: theteam@DelphiToCSharp.com

Until next time. Michael

Subscribe to our RSS feed to ensure you never miss an article.