CodeGear announces that their Next .Net product which is known as Delphi Prism Will be RemObjects's Oxygene.
Oxygene has many nice features that not found in Delphi or C#, and I think it will be a more effective solution for .Net than Delphi .Net previous releases, but it's uses Visual Studio IDE instead of Delphi IDE. which has some cons and pros.
As Delphi Developer or .Net Developer, do you consider to use Delphi Prism for .Net developmenet?
Look at these Links for more info.
I am currently a Delphi w32 developer. Although I think it is very brave to create a language that can be used both on native and .NET, I think there are better optons for .NET programming.
Since Delphi is always catching up on .Net, I don't see any valid reason for using it, besides not being a MS product.
There is already a good language for .Net that has everything in it that delphi has and much more.
As much as I love delphi, using some logic tells me to stay away from it for .Net.
No, Delphi's lack of backward compatibility let to me changing over to C# & VS. Plus, finding developers to collaborate with and good information on in Delphi is hard enough without the compatibility issues.
Plus, the price of the IDE is too high.
If Delphi Prism had existed 5 years ago I would be using it right now (and loving it).
But as Borland being a train wreck, I used C# for .NET development, and now I have kind of grown to like C# more than Delphi.
Perhaps I'll use Delphi Prism to speed up migration of Delphi Win32 code to .NET.
Absolutely, while our main application will continue to live and breathe as a native win32 application, there is the need to connect it to existing .net framework applications. While traditionally we have done this in C#, moving this code over to Prism will not be that much of a problem, and will be very welcome. As a very long time pascal programmer, I tend to think in begin end pairs, not in brackets.
For new development, we will carefully weigh what makes the most sense for our customers. Most likely this will continue to be back end win32 native systems and front ends in either .net or win32 depending on our target audience.
At our company we already have C# developers on board, and they have no interest in switching to an obscure third party language.
Management and auditors are worried about the future of Delphi, right or wrong as they may be, but it is a fact that they are worried and would like to eliminate that perceived risk by moving away from everything that has Delphi in its name. I won't even try to sell Prism for .NET development because it's a religious battle against higher powers.
The only part of Prism that I might use is the DataSnap interop for integrating our massive native Delphi codebase with our new .NET development, but for that I would use C# on the .NET side if at all possible.
Yes, most likely. As a Delphi Win32 developer, Prism gives me a nice gateway into the .NET world, and w/RemObjects Hydra, I can pull the two together into a single app as needed. Will let me leverage the best of both worlds.
No,
I would only think about using:
Delphi Prism has a lot of work to do before I even consider thinking about it.
I think C# is the most sensible option for .Net.
BUT, as a Delphi developer, - I would still consider having it in my toolbox, and in particular, the DataSnap features.
Yes.
As enthusiastic as I was about Delphi for .Net, it still lagged behind the .Net framework. Prism resolves this for the current and future framework versions, including full designer support (except cf, which I don't use). Since I prefer the Pascal language, this gives me the opportunity to use it anywhere I currently use C#.
I don't mind that Prism uses the Visual Studio IDE. This means less time spent duplicating designers that are tied to VS and more time to concentrate on language features.
I'm not happy about the loss of VCL.Net, but I suspect the upside will more than make up for it.
I don't know how much I'll use the Mono support to target Linux and the Mac (and iPhone?), but I certainly like having the option.
Just my thoughts.
Delphi inside Visual Studio? That at least sounds interesting for me as a .net Guy.
For me, the one thing that will matter: Will it keep up? It's now having .net 3.5 Features, but will they manage to keep track with new .net Features, or will they fall again behind several years.
On the other hand:
Pricing will be announced in November when we begin accepting preorders.
If it is as ridiculously priced as recent Delphi Versions, I'll pass.
"Delphi Prism" is not Delphi. It's Oxygene. A very different language (designed to be this way since day one). Just giving it a new name wouldn't help to fill this gap.
Do you want to take the risk? If yes, what you will gain? Since backward compatibility is dead (or will suffer, at best)... Compare the "new" features of "Prism" with future C# 4.0, for example.
So... Sorry, RemObjects. Sorry, Embarcadero. We all love you guys, but C# is and would continue to be the safest harbor in this game.
I'm a Delphi developer, since Delphi 1 (and Turbo Pascal before that).
I have always had an interest in Oxygen, but overall I'd rather just buy it from Remobjects - you can't buy at the US Embarcadero store from Brazil, and it always takes a long time for products to be available here (even though last time what I got was a package shipped from the US...), and it usually is a lot more expensive.
When I tried to buy Delphi 2009, the process involved them e-mailing a proposal (after I ordered) that I had to sign and snail mail to them.
I guess I'll see how the new RAD price will be compared to plain Delphi 2009.
If you want to migrate from Win32 to .NET, in my opinion, the best option is C#. But if you want to recycle your Delphi developer skils and avoid to learn a completly different language, Oxygene seems much more attractive than Delphi for .NET.
I just would consider two other things:
- The component libraries: To check if the component libraries you have, and want to use, for Delphi are available for Visual Studio.
- The visual form designer: After a decade using Delphi for Win32 and 3 years using Visual Studio for Windows Forms, I concluded Delphi has a much better visual form designer than Visual Studio, and it can affect the productivity.
You should analyse both options yourself before to choose. What is better for us, may be worst for you and your team.
This is pretty much DEAD OF VCL.NET :) Shame on you Borland/Codegear. Your product was very good, but price and marketing model was never as smart as microsoft one. They have FREE versions, and Full professional VS2008 comes with MSDN still cheaper than Borland Studio. You killing yourself guys.
Decided to move to C#. Being too kind to you for over a decade, developing components, applications, participating in forums and newsgroups. And at the end - what we get- big middle finger. Thanks borland...
For me, it's all about the language. Sadly, I was FORCED to migrate into C# from Delphi.
I have never come across a more naturally objective language then Object Pascal. I will always see C, C++, C#(Visual Basic) as lacking in comparison.
Doors need to be locked, not people. .Net seems to be like having a roadblock attached to your bumper that lifts when you pay, but you carry the weight regardless, everywhere you go.
Over the years I've built up a nice library of code so that developing new stuff is really fast. Some code was even originally written in Turbo Pascal, and it's still linked into new projects flawlessly.
This is what make me faster than other people. I only have to solve new problems.
Moving to Delphi Prism would force me to start from scratch, because none of that old code will even compile. I would only rewrite stuff with the goal of having the code be used for at least 15 more years, and I think C# would be a safer bet than Delphi Prism.
Therefore, I think I'll be skipping the Prism train for now.
Never Ever! I've switched to Java and C#.NET a few months ago and I'll never return to that "Still alive - and well" attitude by Borland/CodeGear/Embarcadero with no support, examples nor good IDE. I know that Prism is going to ship with VS and you'll get all the goods that come with that but hey - you get Visual C# Express for free! I personally escaped from the "being a Delphi developer" attitude a few months ago (after 10 years!) and I fell great about it!.
Delphi was great because it could produce small, native, blazing fast programs. It was faster to develop in than C, while providing similar fast speeds when running - fast enough to write its own components. Delphi should stick to native, and move to support both ARM processors and 64 bit processors. VCL for OSX would be very interesting, and they could do it cleaner than Kylix.
But Prism. Ugh. I looked at the examples - right there is an example of writing the VB.Net split routine using Prism/Pascal to support the example. In .Net, the last thing in the world you want to do is write library routines in the .Net language. You want to use the .Net library that was written closer to the metal. In VB.Net, you already have split for arrays built-in. The examples provided show the very weakness of the concept.
Any you know what? The cluttered version of pascal when it lives in Prism is just such a noisey pain in the butt - nothing like the clean structure of Delphi, and no clean run time on hand. VB.net is so much cleaner, and really, if you use it as a glue for the program as you should do with Prism, it is easier to read and just as fast. Same goes for C# if you like something that looks similar to C.
In everything .Net - the key is the run time, and learning it. The run times are just better supported, and better understood, by the developers of the VS products.
With classic Delphi - it's the run time. Sure, not everyone likes the TObject tree, but it is more handily constructed to do just about any real world programming task in short order than nearly any other run time library. .Net is clunky, not at your fingertips, but the classic VCL is just a dream to work with. Couple that with the ability to take concepts from advanced computer scientists and translate quickly into Pascal - you have a dream environment for lean, clean and mean code. And you don't need hundreds of megabytes to have run time support for your Delphi app.
But in Prism, you're 99% MS .Net, some untidy glue, a sprinkle of messy syntax, and an envornment that is a "me too" tack-on.
Prsim. What's the point in it? Why not just use C#, VB.Net or whatever. It's definitely NOT Delphi, and it doesn't feel warm and cozy to me as a Delphi.
What did surprise me is that the environment still runs about the same with Prism (it didn't ruin VS 2008). Also, Delphi 2009, while unicode, is at least faster in its IDE on a fast machine than Delphi 2007 (a surprise).
For all the effort of Prism, they could have brought an innovative 64 bit compiler. Then, while porting to Unicode, we could also have ported to 64 bit. Then, Delphi could be a fast, lean and clean 64 bit tool for server processes and large image processing applications as well as complex business rule evaluation engines and perhaps some decision support software. For me, 64 bit Delphi, and possibly direct native OSX support would be real winners, and Prism should be ditched - I cannot find any reason to use it. Right now, it is just a big turd sitting there, an answer that doesn't seem to have a problem.
The quality of Borland's/Codegear's IDE and libraries become worse and worse each year. Bugs, bugs and bugs. Kylix 1,2,3, Delphi 8, Delphi 2005, Delphi 2006 - that was total crap and almost no support, no or very small amount of bugfixes. Delphi 2007, 2009 are slightly better, but I simply tired of this. I'll try Delphi Prism but I am very sceptical about it. I've tried Visual Studio. It is fantastic no single IDE crash for two weeks.
NO,
Ruby may be on Rails, but Delphi now goes off Rails.
Good luck guys, bon voyage, here is where we finally get off!
Why would we possibly want to go through a major conversion effort to go from Delphi Win32 to Delphi Prism on dotNet.
With it now a forgone conclusion that ALL our VCL based components and custom development based on the VCL is obsolete. Embarcadero has outdone even Borland in finally destroying Delphi Pascal.
We will now start collecting a set of components that is roughly equivalent to what we had in Delphi and look for the best Delphi Pascal to C# dotNET conversion facility.
Why would we possibly want to convert from Delphi to Delphi prism without all our VCL based components ever.
At least moving directly to C# dotNet will end all this uncertainty we had to put up with the last few years.
You have lost it guys !
If Delphi is the way you love developing in then you can still develop killer app with it. But their is no future for Delphi for Windows, if in future Delphi put foot in the world of cross platform RAD app world then they may gain momentum, but I don't see any effort being made toward that.. so Delphi Prism or Delphi 2009 they both going down against MS Visual Studio (unless they goes open-source and free).
ABSOLUTELY NOT! It is not Pascal. It is a language mess between Pascal and C created by irresponsible to language standards people. One is the best readable section in the Pascal programs where variables are declared now is... pfuuu
begin
var I := 5; ??????????????? What the hell is that???????
end
I don't see the .NET logic at all. Nowadays even color is an "object", alignment is an object and so on. I don't see why making it all harder to learn is an option. And then.. in all it's wisdom, M$ added linq so even data manipulation could be messed up more than ever. I thought that was why they invented stored procedures in the first place.
ASP.NET looked like something promising but even with .NET you end up coding whole pages by hand. M$ does not have the balls to build an intuitive designer for that. Drag and drop design is treated like something scarry. I'm afraid that Prism will be something like that.
.NET is not ready yet. Look at versions and the time between them. Look at what is missing. Look at the ease of reverse engineering. Think of stupid tools like obfuscation if you want to prevent yourself from giving your code away. And there is the DLL hell we wanted to avoid: every little application is 100 mb of framework, all using it's own assemblies, keeping all .NET versions next to eachother. How about the "there are no version conflicts with assemblies"? How about one party using version 1.0 of an assembly and the other using 1.1? They don't have to be in the GAC, they can be everywhere.
Delphi .NET or Prism should have come with something compatible to the VCL. That is were the strength of Delphi was. Add the TComponent.NET version and let developers re-use their custom made components. I have 10 years of Delphi code that is not portable to .NET. How stupid can one be to think that with alternatives like C# and VB.NET someone will rewrite the whole bunch in Delphi/Prism.NET and not just switch to C# in the first place?
I wonder if anybody just opened their eyes and looked under the hood of the M$ .NET crap in the first place. Maybe then someone can explain why the efford of learning a over complicated framework like .NET and getting along with all the crap and M$ stuff pushed down your throats is worth wile.
No. I don't see the point. It is C# with some pascallized syntax here and there.
For that bit of syntax alone, it is not worth sticking with a non-standard vendor. Delphi has its advantages, but PRISM IMHO inherits none.
As some people have pointed out in their comments, Delphi Prism is waay ahead of C#. I've been using it for well over a year now and I love it.
I was a Delphi programmer from version 1 and as time went by I watched a great product lose its edge over the years until I could stand it no longer and I bit the bullet and jumped to .NET and C#.
However, as soon as I became aware of Chrome/Oxygene/Prism I jumped back to Pascal. I think C# is a great language but if you're looking to the future and will be writing multi-threaded and multi-core apps then Prism is going to give you a big helping hand with that. Take a look at futures and the other async and parallel features to see what I mean. And that is just the tip of the ice-berg as far as features over C# go.
Long time Delphi developer here. I won't be going to Prism.
Simply, if I have a need to develop a standalone win32 application I'll crank up Delphi, use the extensive tools at my disposal, and be done quickly with a high quality product.
Unfortunately, in the current economy my if I have a client request it will include access to the source code. (No one trusts that anyone else will be around long term) I can forget making a bid if the source is Delphi.
I'm also keeping my eyes out for a better job career opportunity. Last I checked there are zero opportunities for Delphi developers in Northern California.
Absolutely! I have been a Pascal guy in one form or another for nearly 25 years (started with Turbo Pascal 3.02a and have a copy of every release since then - am now working on converting to Delphi 2009 and Unicode). I make my living (unfortunately) writing code in C#. If the marketing folks could ever figure out how to convince the world at large that Delphi Prism isn't going away and that it is a good product (from what I have seen, it is) I would convert back in an instant. I am still going to write private projects in Prism and any of my consulting customers that will allow it will also get Prism products. It is my very strong hope that the CodeGear/RemObjects team have a very successful product in Prism so I can go back to writing code that makes sense (there are some pretty weird ideas in C# that are there just to make the old C guys happy)! My one wish above that is for someone, somewhere to write a ReSharper like gadget for Prism. In any event, Yes, I will use Prism for as long as it is available.
Looks like CodeGear is too confused about the way it should go ? The very DNA of Delphi is to produce small and fast native code.
Learning the dot net framework is a far bigger issue that learning c# syntax. If I have lo learn dot net (which I do) then I'll switc to Visual Studio (which I have).
Where's Philippe when he's needed most?
I don't know if I would move from Delphi to Prism or to .NET. When I look at commercial software in the top market none of them is using .NET framework, not even Microsoft Office. My company still write software package and customized software using Delphi and Visual C++ for hi-speed, native Windows application.
Will .NET stayed for more than five years or change to something else that will be for all of us to see. Hope we don't have to throw away our existing code and re-learned new programming language.
Seriously thinking about using it for new code.
Delphi Prism 2010 is nice, the integration with Visual Studio 2008 is slick and fast and the ability to make WPF applications helps to get over some of my .net reservations regarding the occasional perceptible lack of responsiveness for more complicated UI's. Definitely a pro to be able to use the base language and syntax I am most familiar with, even if the library is completely different. Also, can still leverage a good base of programmers with .net experience (in my experience learning the capabilities of the libraries is more work than the syntax of arrays, variable assignments, etc...). It's definitely getting difficult to find local Delphi programmers that are engaged and passionate about it, while similar people with .net experience are all over the place.
On the con side of the equation: I'm still reluctant to drop native code performance and responsiveness, I'm working with a large legacy code base that I am reluctant to rewrite just for the sake of moving to .net and as a corollary to the pro about being able to find people with .net library experience, I don't have as much so there is an added learning curve there for me.
No. Too little, too late.
Please make me 64-bit native Delphi compiler with free grid-tree DB aware component, all multithreaded VCL from start, DirectX, GDI+ or whatever is fast today, terabyte dynamic memory allocation, unicoded from ground up. And yes, do it 5-7 years ago.
I need .Net to develop mobile application, but Delphi Prims doesn't support CF designer, same as old Delphi for .Net
I am trying to avoiding going to .NET period. I write database driven apps where most of the business logic and data logic is all in the database (stored procedures etc.). .NET in general seems to provide no advantages to the developer in this case except in the esoteric sense. Put all your logic in the database all your GUI behavior in the client. Then the switch from one language to another is not as traumatic. Mostly just calls to the database and display. When Delphi 32/64 no longer exists I will be exclusively a database programmer, no more front end. I have been writing in Delphi since Delphi 2 and have never looked back. My success is because of Delphi not Oracle, not SQLServer, not .NET but DELPHI.
Delphi is dead. If you are serious about writing software for .NET, then c# and Visual Studio is the only game in town. Android development is properly done with the Android SDK on Eclipse, and iPhone development is properly done with Cocoa Touch in Objective C. PERIOD. Delphi is now a product without a valid reason for existence.
As a former expert Delphi developer / Former TurboPower Senior Software Engineer and formerly head-over-heels in love with my job because of Delphi, it pains me to say these things, but say them I must.
If Embarcadero, Borland, Inprise, whatever... would just have the common decency to die gracefully, it'd be a much nicer world.
By the way, Floyd Burger isn't my real name. It is a name that a handful of former TurbPower engineers use on forums from time to time.
Yes. As a Windows developer, I need both Win32 and .NET capabilities.
The syntax is a lot different from the usual Delphi but very intuitive for a Delphi or Pascal programmer, makes a lot of sense than VCL.NET. Imagine the VCLs completely integrated to the .NET itself already.
My only longing: a good Delphi prism book or reference to object properties/functions/etc...I'm still trying to guess objects using a C# book/reference.