Inprise
یک شنبه 18 بهمن 1383, 19:21 عصر
Allen Bauer از مردان اصلی و تصمیم ساز بورلند ؛ طی دو نوشته جالب تو وبلاگش ؛ نکات مهمی در مورد تصمیمات بورلند و روند های آتی نوشته که مطالعه اش خالی از لطف نیست :
<span dir=ltr>OK.. I've have a few days to digest, mull over, and otherwise consume Julian's post regarding the reasons Delphi should be migrated into Visual Studio.آ All in all it was a well reasoned article and on the surface it looks like a “no-brainer.”آ However, I'm going to toss the proverbial “spanner” into the works.
First of all, does anybody really think that Borland hasn't ever looked into what it would look like for Delphi to be hosted in the Visual Studio IDE?آ I mean, we're in business to make money.آ And as much of it as we think we can.آ It only makes sense to explore every avenue of opportunity, no matter what you're emotional ties are to a particular way of doing things.آ Of course I cannot comment on anything specific regarding any kinds of future plans regarding Delphi and Visual Studio.آ I will however outline a few things in order to dispell several myths surrounding the notion that moving to VS somehow magicallyآ gives us a huge boost.
First, lets outline some rules of engagement.آ First of all, I'm not talking about a “Delphi language plug-in.”آ On the surface that seems like a very simple andآ “no-brainer” kind ofآ thing to do.آ However, I'm not interested in having Delphi be simply another “also-ran” in the sea of Visual Studio plugins and third-party languages.آ Delphi has an identity all its own,آ both in its market and its overall look and feel.آ Delphi would have to retain a lot of this identity.آ This raises the bar to a level beyond simply installingآ Delphi into an existing VS installation.آ Yes, Microsoft does offer a program that allows third-parties to deliver and install the core VS bits in addition to that vendor's specific enhancements.آ The problem is that it still has the Microsoft identity plastered all over it in such a way that Delphi would still be relegated to “also-ran” status.
OK, so we've outlined some of the up-front intangible costs associated with moving Delphi into VS.آ Now lets looks at some of the real costs.آ Let's define what Visual Studio really is.آ Basically, VS is simply a shell that provides some core services,آ such as a text editor, menu and window/docking management, some core-debugger services, and some core project management services.آ Other things like the compilers, expression evaluators, syntax highlighting, Intellisense, etc.. are all items that are pushed out to the “language plug-in”آ These are things Borland would have to provide.آ What about the designers, like the WinForm, آ ASP.NETآ and let's throw in the CF designers?آ So far it is unclear whether or not these items are actually part of the core VS redist bits.آ Especially the CF designer bits.آ آ You know that it won't include any kind of support for VCL (Win32 or .NET), so that is something only Borland can provide.آ Then there is the notion of the smart device emulators (for running and debugging CF applications without the need for a physical device).آ These don't come with the core VS redist bits.
So far, you might be saying, “So? Just require that the user purchase VS to get all those extra bits.”آ Hmm... good idea... not! How can we, with a straight face, tell our customers, you, that you need to toss a chunk of cash at MS and at Borland?آ No, you want to buy one product, install it, and be good to go.آ So then we're stuck with selling into VS shops, which has it's own brand of issues... well you get the picture.
So let's do a little math and check the score:
Visual Studio Core
Editor
Debugger (Win32/.NET/CF)
Menus/Windows/docking
Project Manager
Galileo Core (present Delphi IDE core)
Editor
Debugger(Win32/.NET).
Menus/Windows/docking
Project Manager
I'm sure that's not quite an exhaustive list, but you get the idea here.آ There are probably several things that the Galileo core provides that the VS core does not, and vice versa.آ Now let's look at what Borland must supply:
Visual Studio Core
Delphi Compilers (.NET & Win32)
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...).
ASP.NET Designer
WinForm designer.
Expression evaluator (for debugging).
VCL design-time package management
VCL/Win32 Designer
VCL/.NET Designer
CodeDOM
ECO
Modelling
Refactoring engine and code for specific refactorings
Galileo Core
Delphi Compilers (.NET & Win32)
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...).
ASP.NET Designer
WinForm Designer
Expression evaluator (for debugging).
VCL design-time package management
VCL/Win32 Designer
VCL/.NET Designer
CodeDOM
ECO
Modelling
Refactoring engine and code for specific refactorings
Hm... That's interesting.آ I'm not seeing the advantage here.آ The VS core and the Galileo core are essentially done.آ They're sunk costs.آ What the above list doesn't depict is the team cost involved in just moving what we have today onto VS.آ Thatآ would be a very large task to just get to where we are today.آ That doesn't include any new features.آ Sure, there would be some increase in feature-set simply from the move to VS, but what those features would be I can't sayآ because I don't know.آ Yes, we'd be freed from the task of maintaining the IDE core, but to put that into perspective, in the Delphi 2005 product release, I imagine that there was only about 1-2 man-months of real core IDE work.آ There was some core work to add some features, but quite honestly these were features that would not have come fromآ some VS core either.
Now comes the argument, “what about all those third-party VS add-ons you can now leverage?”آ Sounds great, in theory, however in practice I'm much more skeptical.آ I know how development works and I know developers.آ I can see that the following scenario would become all too common:آ I install some whiz-bang VS add-on and point it at some Delphi source file.آ I tell the add-in to “do it's thing”... Now I watch in horror as I see C# or VB code injected into my Delphi source code module!آ Then there's this one, I try and pointآ some hot new add-in at the VCL form designer, and all it can do is sit there twiddling it's thumbs.
How about, “what happens if MS slips the next release of VS?“آ Well that's a good question.آ Borland has a fiduciary responsibility to its stockholders to be profitable.آ Much of that ability to make a profit is being in control of one's own destiny.آ If we cannot meet revenue targets, we let down not only ourselves and our customers, but also our stockholders.آ So now we're relegated into always delivering on the previous rev of VS.آ Not a very attractive prospect in today's market.آ Of courseآ we may end upآ wrestling withآ a very similarآ issue with the recentآ unsubstantiated rumorآ that MS has slipped the delivery of .NET 2.0 into late summer or early fall of 2005!
Here's another one I've heard, “Oh that Allen guy is the Galileo IDE architect.آ He's just protecting his code and his job.”آ No.آ I'd like to think that I'm not that shallow or egocentric.آ Sure I have an ego, and it can be bruised, but I'm also very pragmatic.آ As soon as I see the benefit toآ Delphi, the product, and to Borland the company, you bet I'd be on board.
Finally, and I hesitate to even mention this because it tends to bring out the worst in folks, there is the notion of whether or not our existing Delphi customers would accept a Delphi release built on VS?آ What would they be willing to pay?آ What if they already have VS, do they pay the same price?آ These are not questions I'm prepared to answer or even profess to to answer.آ I know what my gut tells me.آ I'm a developer, so I'd like to think I know developers and have a little insight into what makes them tick.آ We share much of the same passions and ideas.آ I don't know, maybe the Delphi folks will surprise me.
Oh.. BTW, Julian used to work for Microsoft in the Visual Studio group... but, he, as am I, are certainly not biased in any way ;-)..</span>
و در ادامه :
<span dir=ltr>One item in my previous post that I specifically didn't address is the notion of using Eclipse instead of VS. Again, this is something we'd be remiss to ignore. However, the primary ding against Eclipse is its reliance on a JVM. Were it not for the fact that we are trying to support the .NET platform, this might be a reasonable path to persue. I just don't see how we could create a reasonable tool that hosted not only the JVM, but also the CLR in the same process! Yes, Eclipse would be much less encumbering from a business perspective than VS, but I have to think about the developer experience. I, as a developer, would find it very hard to swallow if I had an IDE that fired up both the JVM and CLR in process.
Much of the same issues surrounding what does Eclipse give us and what we'd still have to build. In fact you can substitute Eclipse for VS in much of this post. Of course some of it doesn't apply, but you can get and idea of the scope of things involved.
Finally there is the shear fact that there is nearly 12 years invested in a lot of the current Delphi/Galileo IDE codebase. It's not perfect. It has some rough edges. However, I will point out that it was also the first IDE framework ever released by Borland that supports multiple languages out of the box. I owe a lot of this to the dedication and talent that we have and have had on the Delphi team. Now we've announced our intention of folding C++Builder into the Galileo IDE, which has only been made possible due to the work we'd been doing over the past 2-3 years.</span>
موفق باشید
<span dir=ltr>OK.. I've have a few days to digest, mull over, and otherwise consume Julian's post regarding the reasons Delphi should be migrated into Visual Studio.آ All in all it was a well reasoned article and on the surface it looks like a “no-brainer.”آ However, I'm going to toss the proverbial “spanner” into the works.
First of all, does anybody really think that Borland hasn't ever looked into what it would look like for Delphi to be hosted in the Visual Studio IDE?آ I mean, we're in business to make money.آ And as much of it as we think we can.آ It only makes sense to explore every avenue of opportunity, no matter what you're emotional ties are to a particular way of doing things.آ Of course I cannot comment on anything specific regarding any kinds of future plans regarding Delphi and Visual Studio.آ I will however outline a few things in order to dispell several myths surrounding the notion that moving to VS somehow magicallyآ gives us a huge boost.
First, lets outline some rules of engagement.آ First of all, I'm not talking about a “Delphi language plug-in.”آ On the surface that seems like a very simple andآ “no-brainer” kind ofآ thing to do.آ However, I'm not interested in having Delphi be simply another “also-ran” in the sea of Visual Studio plugins and third-party languages.آ Delphi has an identity all its own,آ both in its market and its overall look and feel.آ Delphi would have to retain a lot of this identity.آ This raises the bar to a level beyond simply installingآ Delphi into an existing VS installation.آ Yes, Microsoft does offer a program that allows third-parties to deliver and install the core VS bits in addition to that vendor's specific enhancements.آ The problem is that it still has the Microsoft identity plastered all over it in such a way that Delphi would still be relegated to “also-ran” status.
OK, so we've outlined some of the up-front intangible costs associated with moving Delphi into VS.آ Now lets looks at some of the real costs.آ Let's define what Visual Studio really is.آ Basically, VS is simply a shell that provides some core services,آ such as a text editor, menu and window/docking management, some core-debugger services, and some core project management services.آ Other things like the compilers, expression evaluators, syntax highlighting, Intellisense, etc.. are all items that are pushed out to the “language plug-in”آ These are things Borland would have to provide.آ What about the designers, like the WinForm, آ ASP.NETآ and let's throw in the CF designers?آ So far it is unclear whether or not these items are actually part of the core VS redist bits.آ Especially the CF designer bits.آ آ You know that it won't include any kind of support for VCL (Win32 or .NET), so that is something only Borland can provide.آ Then there is the notion of the smart device emulators (for running and debugging CF applications without the need for a physical device).آ These don't come with the core VS redist bits.
So far, you might be saying, “So? Just require that the user purchase VS to get all those extra bits.”آ Hmm... good idea... not! How can we, with a straight face, tell our customers, you, that you need to toss a chunk of cash at MS and at Borland?آ No, you want to buy one product, install it, and be good to go.آ So then we're stuck with selling into VS shops, which has it's own brand of issues... well you get the picture.
So let's do a little math and check the score:
Visual Studio Core
Editor
Debugger (Win32/.NET/CF)
Menus/Windows/docking
Project Manager
Galileo Core (present Delphi IDE core)
Editor
Debugger(Win32/.NET).
Menus/Windows/docking
Project Manager
I'm sure that's not quite an exhaustive list, but you get the idea here.آ There are probably several things that the Galileo core provides that the VS core does not, and vice versa.آ Now let's look at what Borland must supply:
Visual Studio Core
Delphi Compilers (.NET & Win32)
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...).
ASP.NET Designer
WinForm designer.
Expression evaluator (for debugging).
VCL design-time package management
VCL/Win32 Designer
VCL/.NET Designer
CodeDOM
ECO
Modelling
Refactoring engine and code for specific refactorings
Galileo Core
Delphi Compilers (.NET & Win32)
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...).
ASP.NET Designer
WinForm Designer
Expression evaluator (for debugging).
VCL design-time package management
VCL/Win32 Designer
VCL/.NET Designer
CodeDOM
ECO
Modelling
Refactoring engine and code for specific refactorings
Hm... That's interesting.آ I'm not seeing the advantage here.آ The VS core and the Galileo core are essentially done.آ They're sunk costs.آ What the above list doesn't depict is the team cost involved in just moving what we have today onto VS.آ Thatآ would be a very large task to just get to where we are today.آ That doesn't include any new features.آ Sure, there would be some increase in feature-set simply from the move to VS, but what those features would be I can't sayآ because I don't know.آ Yes, we'd be freed from the task of maintaining the IDE core, but to put that into perspective, in the Delphi 2005 product release, I imagine that there was only about 1-2 man-months of real core IDE work.آ There was some core work to add some features, but quite honestly these were features that would not have come fromآ some VS core either.
Now comes the argument, “what about all those third-party VS add-ons you can now leverage?”آ Sounds great, in theory, however in practice I'm much more skeptical.آ I know how development works and I know developers.آ I can see that the following scenario would become all too common:آ I install some whiz-bang VS add-on and point it at some Delphi source file.آ I tell the add-in to “do it's thing”... Now I watch in horror as I see C# or VB code injected into my Delphi source code module!آ Then there's this one, I try and pointآ some hot new add-in at the VCL form designer, and all it can do is sit there twiddling it's thumbs.
How about, “what happens if MS slips the next release of VS?“آ Well that's a good question.آ Borland has a fiduciary responsibility to its stockholders to be profitable.آ Much of that ability to make a profit is being in control of one's own destiny.آ If we cannot meet revenue targets, we let down not only ourselves and our customers, but also our stockholders.آ So now we're relegated into always delivering on the previous rev of VS.آ Not a very attractive prospect in today's market.آ Of courseآ we may end upآ wrestling withآ a very similarآ issue with the recentآ unsubstantiated rumorآ that MS has slipped the delivery of .NET 2.0 into late summer or early fall of 2005!
Here's another one I've heard, “Oh that Allen guy is the Galileo IDE architect.آ He's just protecting his code and his job.”آ No.آ I'd like to think that I'm not that shallow or egocentric.آ Sure I have an ego, and it can be bruised, but I'm also very pragmatic.آ As soon as I see the benefit toآ Delphi, the product, and to Borland the company, you bet I'd be on board.
Finally, and I hesitate to even mention this because it tends to bring out the worst in folks, there is the notion of whether or not our existing Delphi customers would accept a Delphi release built on VS?آ What would they be willing to pay?آ What if they already have VS, do they pay the same price?آ These are not questions I'm prepared to answer or even profess to to answer.آ I know what my gut tells me.آ I'm a developer, so I'd like to think I know developers and have a little insight into what makes them tick.آ We share much of the same passions and ideas.آ I don't know, maybe the Delphi folks will surprise me.
Oh.. BTW, Julian used to work for Microsoft in the Visual Studio group... but, he, as am I, are certainly not biased in any way ;-)..</span>
و در ادامه :
<span dir=ltr>One item in my previous post that I specifically didn't address is the notion of using Eclipse instead of VS. Again, this is something we'd be remiss to ignore. However, the primary ding against Eclipse is its reliance on a JVM. Were it not for the fact that we are trying to support the .NET platform, this might be a reasonable path to persue. I just don't see how we could create a reasonable tool that hosted not only the JVM, but also the CLR in the same process! Yes, Eclipse would be much less encumbering from a business perspective than VS, but I have to think about the developer experience. I, as a developer, would find it very hard to swallow if I had an IDE that fired up both the JVM and CLR in process.
Much of the same issues surrounding what does Eclipse give us and what we'd still have to build. In fact you can substitute Eclipse for VS in much of this post. Of course some of it doesn't apply, but you can get and idea of the scope of things involved.
Finally there is the shear fact that there is nearly 12 years invested in a lot of the current Delphi/Galileo IDE codebase. It's not perfect. It has some rough edges. However, I will point out that it was also the first IDE framework ever released by Borland that supports multiple languages out of the box. I owe a lot of this to the dedication and talent that we have and have had on the Delphi team. Now we've announced our intention of folding C++Builder into the Galileo IDE, which has only been made possible due to the work we'd been doing over the past 2-3 years.</span>
موفق باشید