Thanks for all your comments to my post about switching from Delphi to C#. Although I didn’t intend to stir up that discussion again, I would like to answer some of the questions and suggestions raised/
I appreciate everyone telling me about teaching C# programmers Delphi. I know it's not too hard; I've done it myself :-) But, the number of programmers out there does reflect the popularity of a platform, doesn't it? And some applicants bluntly told me they didn’t want to work in Delphi. They obviously didn’t get the job, but it did make me think a bit.
But, the lack of programmers wasn't the main reason for us to switch at all. Despite somewhat (...) critical sounds about Microsoft (some of which I tend to kind of share) there is a lot of development in the Microsoft world. Way more than in the Delphi world. Some may be good, some may be not so good or terrible, fact is that there is a lot of effort put in the MS platform.
What really did it for me were two things.
(1) We had to wait for Delphi 2009 for Unicode support, which (IMHO of course) is a major misjudgement. I haven't been able to deliver Unicode software, even though there was a bit of pressure out there. I know for a fact that I did lose sales because of that.
(2) About the same time Delphi 2009 (and Prism) came out, I attended the Microsoft PDC. It opened my eyes regarding to the scale of things. One may not like MS being enormous in size, but there are so many exciting things going on out there, that it made me decide to go the other way.
In fact, I particularly went to check out MS Surface. Just one of those things that MS can do and Embarcadero won’t. That’s not to hold against them, and it doesn’t have anything to do with my choice for C# really, but it did tell me that there was a lot more going on than I really wanted to realize.
Just a quick note on quality of tools: I was getting used to Delphi crashing on me several times a day. It was getting to a point that I did take that into account when starting a days work. I am so glad that is over: Visual Studio hasn’t crashed on me once since I started using it. Not a real argument for the choice either, but I’m glad that’s out of the way.
I will always love Delphi and will be programming in it for the next couple of years, I’m sure. But for the next few generations of our software engine, C#/.Net will be the platform of choice.
Now, that still doesn’t solve those designing issues for me :-) Guess I’ll have to do some investigation.
Bye,
Bart
Posts
15 comments:
The main reason for me not to use C# is that unlike Delphi it doesn't generate proper exe files (or does it nowadays?) and requires huge runtime libraries. But if you're not developing mass products then there really isn't any reason not to go with C#.
I dislike C#, because I don't like sharing my work with other software pirates (reverse engineering).
The second point is, it is so slow. The jitter takes so long to start up.
Regarding Surface: You probably missed Delphi Live, where Embarcadero has shown off their VCL Touch support. The funny thing is that most of it even works without Windows 7 ;-)
How do you expect your product (Content Management?) being better, faster, and more productive for users having dot net as frame? By making it surfaced unable?
We have had a bad experience trying to convert one of our Delphi product (CRM Abak) to C#. Too many pitfalls, too costy. Too complex to maintain and set for users (some users even not being able to update de .net framework by themselves).
Copernic (the 'then' famous search tool, 100% Delphi devoted) was a prosper entreprise 'til they move to .NET and forced their skilled Delphi programmers learn C#. They are now mostly anonymous among 1 million other microsoft followers. http://www.copernic.com/en/company/index.html It is very sad (it was the main Delphi employer over here)
In any case, good luck.
One huge disadvantage of C# for a lot of developers is that as soon as you make your software publicly available, all your code becomes completely visible to the public through reflection. If you don't want your competitors knowing how you did something, then all .Net languages are out of the question. I think is the main reason why you don't see a lot of commercial software using .Net. Obfuscators don't really fix this.
While I haven't used Delphi Prism with Surface, I am pretty sure you can use Delphi Prism to develop surface with.
And I speak from experience when I saw the Visual Studio 2008 crashed just as often, if not more than any version of Delphi I have used. Actually visual studio would usually just disappear with no message. I would be programming and then staring at my desktop with no warning.
Unicode may have been a little long coming, but that is water under the bridge. It is here now, so no use crying over spilled milk. You only punish yourself by holding a grudge over that.
The previous place I worked decided to jump ship and port an application from Delphi to C#. It took twice as many developers twice as long to do it as the original Delphi development. This was C# 2.0 with Visual Studio 2008, and we invested in 3rd party components and tools too.
As Olaf pointed out Weaver will have a lot of the cool touch features, without the hardware requirement.
I was at PDC too, and one thing to keep in mind is Delphi is actually part of the Microsoft development ecosystem. Pretty much everything going on there could be developed in either Delphi native or Delphi Prism: Surface, Azure, etc.
I think you just beated one of the main arguments of staying-in-Delphi. C# gives by itself a lot of arguments to stay in Delphi as you can see in the previous comments, thats why a migration from Delphi to C# usually sounds too risky. There are cases where it may be useful, in certain markets, but it is not a good choice generally.
And, IMHO, maybe you will be going back some day, i know a lot of cases already.
Sincerelly, i dont know why MS does not exploits the full potencial of its own platform, and let other products like Delphi to do it. They lost the dev race since its beginnings by quality, not by quantity, thats true. But for sure, i prefer to stay in the quality side. Good luck.
It is big part of why I wish Microsoft had bought CodeGear instead of anyone else.
Yes. Embarcadero is doing some good things, but let's face facts. No one else has the deep pockets MS has.
And really, they care more about the number of people developing for their platform more than anything else in the development world.
In regards to IP protection, there are tools that obfuscate your code.
The truth of the matter is that there are more jobs out there in C#/.NET/Java than there are for Delphi. As much as a developer might or might not like Delphi, not wanting to work for a company that uses Delphi makes sense from his POV, because the more experience he gets with the MS ecosystem, the more job opportunities open up for him in the future. It's really that simple.
I wouldn't worry about what other people think. If you think .Net and/or C# are better for you from a technical or business point of view, then have at it. Very best of luck.
My personal experience is surprisingly close to Jim's, though. I'm using Visual Studio regularly and attending Microsoft conferences and events. Even so, Delphi is by far more productive (and profitable) for me. Visual Studio does has some nice features (ASP.Net!), but it also has its own problems.
I've also never understood why people seem to think this has to be an either/or decision. I like having the flexibility to choose the right tool for a given job.
I personally use VB6, Visual Studio 2005 as well as Delphi.
I like Delphi but loath its dumb, slow loading, and resource hungry IDE (when compared to VS 2005).
As far as code protection is concerned we have developed a fleet of software (for many MNCs and companies that sell what we have have developed) but still none of our software has been reversed engineered till date. We use ReShart for obfuscation of our code.
As for JIT I have to say that one can easily precompile the executable to binary so that JIT will never have to work and slow down loading time.
We use Microsoft Accounting software which is developed in .NET 2005 and believe me it just starts instantly so speed is never a factor to consider.
As for runtime requirements I have to say that this is the most unreasonable argument. Try to develop a large scale software in (say for example) Delphi. You will have to build a large set of DLLs and ship those DLLs with your software and this will surely let loos what is knows as DLL Hell!
If you want to get rid of .NET framework dependency then give MONO a try. There is an option to link all libraries statically to the EXE.
There are a few third party tools available which will statically link all default .NET assemblies to your EXE this will help get rid of most part of .NET runtime but be ready to port a very bulky EXE file.
Lastly there are a lot of areas there for which there are very good and efficient ActiveX available (even today) but to date there are no VCLs available or what is available is just not acceptable by commercial standards. Take for example a Descent Free Form Reporting tool or a good Grid component. I have been using Component Ones activex and .net component set but to date I have not found any VCL that can replace most (if not all) of these components so even today in spite of using Delphi for developing software I have to use those ActiveX. Also one has to consider the cost of ownership when it comes to VCLs. For getting most of the functionality of what is avaialable in ComponentOne's I will have to purchase multiple VCls from a lot of different Vendors. And the sum total of VCLs will be almost 6 times more that what Componet One's component set costs.
Do you know that Microsoft till office 2003 (don't know about 2007) used vsFlex Grid (from C1) as its Access Date View Grid & Spreadsheet backbone/building block. In the same way the property palette in all Visual Studio versions (6 to 2008) is still using FlexGrid from Component One. This fact itself show how powerful & flexible this component is.
I can go on and on but please don't get me wrong I have nothing against Delphi personally.
As for claims of being instantly productive in Delphi I have to say that they are false claims. Look at this from this POV: If you started you career as developer by learning and using Pascal/Delphi then naturally you will be instantly productive in it. In the same way I have started my career as developer by programming VB3 so I am instantly productive in VB. What is the big deal in this?
If you want to convert most of you Delphi code to C# then there is tool available commercially (its name slips my mind at present) which will convert GUI, Classes, Modules, etc. to C# easily and quickly.
[But, the number of programmers out there does reflect the popularity of a platform, doesn't it?]
The popularity is driven by the weight of the company behind it, but doesn't reflect the quality of the product. Oracle is another example.
[And some applicants bluntly told me they didn’t want to work in Delphi.]
We have an old but active project on Visual Basic. Same problem.
[They obviously didn’t get the job, but it did make me think a bit.]
One has to keep up with the latest technologies to get the job, but to solve the problem, use the appropriate tool, not the fashionable one.
[There is a lot of development in the Microsoft world. Check out MS Surface.]
I'm assuming MS Surface is exposed as a set of API routines? If so, no problem.
Perhaps I'm getting old, but over the years I have seen Microsoft throwing stuff at the market and hopes some sticks. Remember the Pen interface? And more recently Tablet PCs? There's lots of "exciting" developments that end in nothing much.
[I was getting used to Delphi crashing on me several times a day.]
Yes, CodeGear has some fixing to do, but in VS2005 with C# we have had forms resource files that get mangled irrepairably. Microsoft's response: "Known Issue".
@Yogi Yang
[...develop a large scale software in Delphi. You will have a large set of DLLs...what is knows as DLL Hell!]
Not in Delphi. You can loading DLLs explicitly. I laughed when told excitedly that in C#/.Net there was no more DLL hell.
[there are very good and efficient ActiveX available (even today) but to date there are no VCLs available or what is available is just not acceptable by commercial standards.]
In my experience, Delphi tends to be used for products with a long life, so it is worth it to develop your own VCLs.
Using 3rd party VCL/ActiveX may be a quick solution for the moment but you become hostage to the whims and fortunes of the vendor.
Interesting discussion. Im a fan of using the best tool for the job and it might be Delphi C# or PHP for that matter. If the TIOBE index is to be believed Delphi/Prism may be on a bit of a comeback as is native code development in general. However one should be aware that Microsoft has to innovate to survive and generate revenue. It may be already to late to shift to the .Net programming system as version 4.0 is already more or less cooked. Late adopters may find that Microsoft is already brewing its next all singing all dancing development environment. Do keep a watching eye on Microsoft Research. There are dozens of projects going on in the software development space. One that might lead to the next new thing is the Singularity Project.
On the other hand does Microsft actually make any money from its developer tools investments.? Could they vulnerable to cutbacks and retrenchment. The last 15 years are littered with hundreds of projects, SDK's, architectural approaches,tools, gizmos and addons and a dizzing array of data acess technologies that have ended up on the digital scrapheap. All that waste may have a judgement day. Who knows. And Visual Studio is increasingly offering so much hand holding and canned guidance that it threatens to become the equivalent of paint by numbers. But sometimes thats exactly the medicine you need to solve a business problem.
I so wish there would be Delphi support in the Surface SDK. ;)
that's the LAMEST excuse i've ever heard. TnT components have been available for FREE for ages... and yet you whine about unicode support in Delphi causing you loss of revenue. perhaps it's your incompetence to stay abreast with the open source world that's really the issue here. no wonder you'll be well-received in the MS camp where they actively evangelize closed-source proprietary stuffs. good luck with the switch, one less lost-case from the boat.
Post a Comment