Board index » delphi » Re: Delphi and the .Net platform

Re: Delphi and the .Net platform


2007-12-18 12:39:50 PM
delphi268
Bruce McGee writes:
Quote
I expect that your opinion disagrees with mine.
Mine doesn't. :)
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 
 

Re: Delphi and the .Net platform

Bruce McGee writes:
Quote
I get confused with how the terms forward and backward compatibility
are used, and I use it badly myself. How do you mean it in this
context?
In this context, forward compatibility means the language/toolset is
designed to optimally leverage .NET. The design choices are made with
less regard for existing code compatibility.
Backward compatibility is pretty much the opposite. Design decisions
are made first and foremost to preserve existing code assets.
IMO, Chrome has been designed to be forward compatible; Delphi for .NET
backward compatible. This isn't limited to the language, but the entire
toolchain, including the IDE, framework libraries, etc.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Delphi and the .Net platform

Brian Moelk writes:
Quote
>From what I can see they didn't really have any choice, because they
>haven't got any to be backward compatible with.

That's not true, they could have made it backward compatible with
Delphi Win32 if they wanted to.
I'm wondering whether having a VS plugin would have made any difference
to that position.
--
Dave Nottage [TeamB]
 

Re: Delphi and the .Net platform

"Bruce McGee" writes:
Quote
I.P. Nichols writes:

>Much of what we have been haggling over is your opinions.

ok.
I'm not going to comment on several of your opinions since I consider them
either wish list items or they are subjective and difficult to substantiate.
Quote
In my opinion, adoption of Linux and the Mac are on the rise.
There is no doubt that Mac sales are rising but with Linux IMO it is too
simplistic to just say adoption of Linux is on the rise without
differentating between desktop and server.
And then things like TiVo and the OLPC muddy the waters. Linux based devices
like TiVo enter the home consumer market in huge quantities but hardy
qualify as a justification for a cross platform Delphi compiler. The OLPC
computer will not be sold to the general public and already has software
especially developed for educational use in less developed countries. And if
you carefully examine it is OS and hardware limitations, it doesn't appear to
offer much if any market possibilities for a Delphi app developer.
Sales of Linux servers are substattial and rising but while Linux
desk/laptop sales are rising, I am not sure if there is that much market
potential for Delphi developers until they achive a tipping point. I really
have doubt that Linux desk/laptops will be widely embraced by the business
and general consumer market.
Speaking of growth and surges...
searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci1260325,00.html
"A recent IDC report showed Linux servers continuing to increase market
share for x86 architecture with a second consecutive quarter of double-digit
growth, but the bigger news could be Microsoft's even bigger surge with
Windows Server 2003"
Quote
In my opinion, I think it would be useful if a cross platform Delphi
compiler and VCL let me target these natively.
While you may find a Delphi cross-compiler useful, the big question is how
large must the Delphi cross-complier market be to justify such a critter.
IMO for the foreseeable future, CodeGears resources are better invested in
Windows than Linux.
Quote
I expect that your opinion disagrees with mine.
No doubt about it...
 

Re: Delphi and the .Net platform

Brian Moelk writes:
Quote
>I was happy to use Borland products while their goals and mine were
>aligned. They moved off to high-ticket ALM tools, so au revoir and
>no hard feelings.

I don't see Borland so monolithic in intent. Certainly upper
management had made the ALM decision, but I think the core Delphi
team wasn't terribly interested in it. That they only did ALM work
to stay alive within the context of the larger Borland.
It was the upper management I was referring to. I am absolutely certain
that the core team were not best pleased at the time.
Quote
If you look at the direction now, almost none of the Delphi work is
ALM related at all. These are the same core people, its just now
they are more empowered to do what they think is best for Delphi.
I would imagine that they are only empowered within certain limits.
Strategic acquisitions etc are probably off-limits.
Quote
>>I don't think that was why they wanted to move Delphi to .NET. I
>>think they viewed .NET as Delphi/VCL 2.0 and misjudged it.
>
>Same difference, really: they thought they would get an updated VCL
>for free, while they moved on to ALM. The main contra-indicator for
>me was that they did not just turn Delphi into VS plug-in. Why
>build their own IDE?

It's not the same because I don't think the Delphi team viewed .NET in
the context of ALM.
Again, I was referring to the overall exec strategy, not the views of
the Delphi team. I think the product would look a bit different now if
Danny, Allen et al had been given free rein.
Quote
IMO, there's no point in turning Delphi into a VS
plug-in; there is a point in turning a Delphi-inspired forward
compatible .NET language like chrome into a VS plug-in. Oh wait, it
is!

>I discount the possibility that anybody at Borland believed the
>".NET will be the OS, and Win32 will be emulated" nonsense - I
>don't think they employ anybody that dumb.

I don't. I never underestimate stupidity, and certainly not my own.
:) I think many people thought some degree of that at the time.
I spent some time a while back reading Dave Jewell's exploits digging
through various pieces of the Win32 API. There was absolutely no chance
that .NET would be the base OS with an emulation layer - not unless
Satan was going to start wearing thermal underwear.
Quote
At
the very least that new API's would only be exposed as .NET ones.
So an interop strategy was obviously required from a long way out ;-)
Quote
>However, all the mindless anti-NET
>rantings about how "MS should convert Office to .NET if it was so
>good" actually hid the deeper truth that Borland should have
>recognised: no way was MS going to abandon their insanely valuable
>C++ code base.

So you think they bought this one but not the former? I think they're
pretty much a package deal, although I think it is more likely Borland
bought the former than the latter.
I think that they (senior management) bought into the ".NET is the only
future", but not to the same extent as the more simple-minded, mainly
because they saw this as a low-risk, low-maintenance VCL replacement
that could satisy requirements while the Delphi product gradually faded
into the background.
If they had learned the MS Office lesson, and appreciated the interop
requirement, I'd have expected some serious research into this to
be done way back, which could be resurrected now and used to supplement
the RoadMap at least. The lack of any public alternative .NET strategy
suggests to me that this did not happen. I hope to be proven wrong by a
RoadMap update in the not-too-distant future.
Quote
>If
>..NET had a future, it would develop an interop strategy. This was
>underlined when Managed C++ was recognised as a sick animal, and
>shot in the head. MS needed a meaningful answer. My reading of
>C++/CLI suggests that they have found one. C++ purists and
>cross-platform fans may hate it, but people with a serious Windows
>codebase must be very pleased.

Agreed 100%.

>I have my doubts about their will to change. I still don't think
>they have felt enough pain.

I agree and have serious doubts as well. However, it is not too late
if they move quickly.
I think that a revised .NET solution will only ever be seen as a
bandage. That ship has sailed, unless they can provide a
seriously-valuable USP.
What they need is something that MS can never provide: cross-platform.
Hit 'em where they aren't.
FWIW, I'd concentrate on providing the best client-server/n-tier
solution possible, from a rich GUI client to a scaleable linux server,
plus anything that can be done to leverage FreePascal + Lazarus. Off
the top of my head - how about distributing their own Linux, with all
the server goodies built in?
My number one priority would be buying/doing a deal with RemObjects.
How much value could Delphi extract from integrating/leveraging the
remoting code, DA + Hydra?
Regards
Ian
 

Re: Delphi and the .Net platform

Quote
>In my opinion, I think it would be useful if a cross platform Delphi
>compiler and VCL let me target these natively.

While you may find a Delphi cross-compiler useful, the big question is
how large must the Delphi cross-complier market be to justify such a
critter. IMO for the foreseeable future, CodeGears resources are better
invested in Windows than Linux.
CodeGear has choosen to follow Microsoft.
A lot of people (including me) are "hoping" that CodeGear will choose another path (the Linux one) because it is the only place where nothing really productive has been done from a RAD POV. And people like me are deeply convinced that CodeGear will loose money in a not-so-far future, because the Microsoft products are better. it is not a guess or whatever, it is a *fact*.
There are so many people working at Microsoft to produce a good development environment that even though Delphi was better than any other RAD a few years ago, this is not true anymore. Delphi RAD is still one of the best, but it is not the best so far anymore.
There's only one place where Delphi could be the best and far from the others ones, it is on the Linux platform.
The Delphi2007 quality product is excellent, and with the updates, is one of the best they've ever done (excluding help stuff).
A few years ago Borland Delphi was the best RAD on the market place. that is why so many people bought it.
But it is not the best product anymore. I am note saying it is bad. I am just saying the other ones have caught up the quality.
And that is a real problem for a small company : if you want to stay alive, you have to be better than the bigger ones. If you just try to stay on their rails you're done.
So a lot of people (including me) are warning CodeGear : your product is excellent, but M$ is excellent too and their product is the best up-to-date product we can find on the "RAD's place" because it is Microsoft ! So why should a new customer bother buying Delphi whereas he could have the same offer from a better up-to-date product (Microsoft VS updates its documentation quicker because... when Microsoft has finished a new thing it can immediately link it with VS) ? The only place where CodeGear could still make a lot of money nowadays is from new growing stuff like Linux (or Mac but I don't know Mac at all).
Did you see what Linus Torvalds predicts (and Gartner agreed) ? In 5 years, 33 % of the mobile phones will be using Linux.
Just imagine if Delphi RAD was already done on Linux
Here's how I see the future for CodeGear : they will produce another excellent 2008 product with Unicode, 64 bits and all other stuff. Microsoft has *already* done that (you can even name your variables with French accents).
I'm not saying the battle is lost : IMHO it is lost on the Windows side.
They better prepare to fight on another place than Windows otherwise the future of CodeGear may not be very bright.
It's my POV and I am already re-writing a lot of Delphi code in C under Linux. Once I am done with it I don't know what I will do with Delphi.
It's a really good product but if Delphi just keep this roadmap there won't be room for it on my desktop.
Sad, really sad, but true.
--
Olivier Pons
olivier.pons.free.fr/
 

Re: Delphi and the .Net platform

On Mon, 17 Dec 2007 16:30:18 -0000, IanH <XXXX@XXXXX.COM>writes:
Quote
I discount the possibility that anybody at Borland believed the ".NET
will be the OS, and Win32 will be emulated" nonsense..
The *idea* of designing a newer, cleaner, more forward-looking API than
the existing, "enhanced" version of the 16-bit Windows API; programming
all new applications to that new interface; and finally switching over the
/implementations/ of those interfaces so the current Win32 API was an
(optional) emulation layer on top of the new, tight codebase... well, that
would have been interesting prospect.
But when I read about all these new APIs - and people getting e{*word*277}d at
the prospect of *7125* new APIs in Vista - I think that they've lost
whatever plot they might have had.
--
Paul Scott
Information Management Systems
Macclesfield, UK.
 

Re: Delphi and the .Net platform

"Olivier Pons" writes:
<big snip>
Quote
Did you see what Linus Torvalds predicts (and Gartner agreed) ? In 5
years, 33 % of the mobile phones will be using Linux.
Just imagine if Delphi RAD was already done on Linux
If Google has their way with Android, it could be a lot higher than 33%.
www.google.com/intl/en/press/pressrel/20071105_mobile_open.html
But I am not sure if a "Delphi RAD was already done on Linux" fits all that
well into the Android world. it is my understanding that they use just the
Linux kernel portion with their own libraries. They did have an emulator and
toolkit for developers available for download a week or so after their Press
Release. Here is an interview with Andy Rubin in which he talks about the
genesis of Android and the toolkit etc.
www.zdnetasia.com/toolkits/0,39047352,62034932-39094246p,00.htm
The Android features and architecture are described here:
code.google.com/android/what-is-android.html
If not with Delphi then with it is JBuilder knowledge and experience, there
should be a place for CodeGear in the Android world. it is ironical that in
a comment to his Dec 4 blog, Steve Trefethen said: "While attending Google
Developer Day (I was the only member of the Delphi team to do so)..." What's
even more ironical, he quotes me in that same comment. <g>
www.stevetrefethen.com/blog/BorlandNowDown50SinceJune28th.aspx
 

Re: Delphi and the .Net platform

Paul Scott writes:
Quote
On Mon, 17 Dec 2007 16:30:18 -0000, IanH <XXXX@XXXXX.COM>writes:

>I discount the possibility that anybody at Borland believed the
>".NET will be the OS, and Win32 will be emulated" nonsense..

The idea of designing a newer, cleaner, more forward-looking API than
the existing, "enhanced" version of the 16-bit Windows API;
programming all new applications to that new interface; and finally
switching over the implementations of those interfaces so the
current Win32 API was an (optional) emulation layer on top of the
new, tight codebase... well, that would have been interesting
prospect.
It took how long to bodge Vista to the state it is now?
How long do you think it would take to create a completely new OS, full
of glorious technical goodies, and then add a full Win32 emulation on
top of it? BTW, don't forget to implement all the private API calls
that MS get to use in their own products. And don't forget to code in
emulation of the ACTUAL performance of the APIs, NOT the designed
performance, otherwise you may end up breaking programs that used Win32
in certain ways.
Let me know when you've finished ;-)
Quote
But when I read about all these new APIs - and people getting e{*word*277}d
at the prospect of 7125 new APIs in Vista - I think that they've
lost whatever plot they might have had.
I haven't got a clue what the new APIs are about - MS has been going
API mad for years. However, giving up on full compatibility with Win32
would be far bigger in terms of losing the plot.
Can you imagine the reaction if MS were seen to produce a new OS that
did not run some old software? The only way it would get any traction
at all is if MS threw Office and a load of other goodies into the
bundle - and I can not see that happening either.
Ian
 

Re: Delphi and the .Net platform

Dave Nottage [TeamB] writes:
Quote
>>From what I can see they didn't really have any choice, because they
>>haven't got any to be backward compatible with.
>That's not true, they could have made it backward compatible with
>Delphi Win32 if they wanted to.
FTR, I should have said "...more backward compatible...", and my comment
is mostly about the language, not necessarily the VCL.
Quote
I'm wondering whether having a VS plugin would have made any difference
to that position.
It's not completely clear to me what you mean here.
Are you suggesting that if CodeGear had a VS plugin for Delphi (or
Delphi for .NET), RemObjects would have chosen a different approach with
Chrome?
IMO, if the language of Delphi for .NET stayed the same and was just
plugged into VS.NET, I think RemObjects would have still built Chrome.
Initially, I believe it was dissatisfaction with the language and not
the IDE that pushed RemObjects to build Chrome, but you will have to ask them.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Delphi and the .Net platform

IanH writes:
Quote
We can argue about what "the best" actually means, and come up with
scoring systems to determine how Delphi + MS tools have compared on a
historical basis, but the bottom line for me is that the killer edge
that I KNEW I had by using Delphi has gone.
And this is part of the point too. Ultimately it comes down to what
developers *believe* is best. They need to have "faith" in their tools.
Once developers lose that belief/faith/trust/confidence, it is extremely
difficult to get it back.
IMO, many Delphi developers do not believe that Delphi for .NET is the
best .NET development tool.
Quote
I have a Delphi codebase. If I have to add new features to my app that
rely on .NET, then I'd prefer to be able to add this as required,
rather than convert the entire codebase to become a .NET app. If I have
to go completely to .NET then I will create a .NET structure in C# and
transition my Delphi code to that as changes are required.
Agreed 100%.
Quote
I see interop a la C++/CLI as the ability to select the best of both,
rather than a compromised halfway house solution. YMMV.
MMDNV.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Delphi and the .Net platform

Quote
And this is part of the point too. Ultimately it comes down to what
developers *believe* is best. They need to have "faith" in their tools.
Once developers lose that belief/faith/trust/confidence, it is extremely
difficult to get it back.
I have more "faith" in Delphi because of Borland/CodeGear's emphasis on
source-compatibility w/ Delphi.NET. I have invested many man-years into
writing Delphi code, and my "faith" in an IDE goes to whomever can help me
preserve that huge investment while moving forward and taking advantage of
new technologies.
--Troy
 

Re: Delphi and the .Net platform

Brian Moelk writes:
Quote
>I think that they (senior management) bought into the ".NET is the
>only future", but not to the same extent as the more simple-minded,
>mainly because they saw this as a low-risk, low-maintenance VCL
>replacement that could satisy requirements while the Delphi product
>gradually faded into the background.

Interesting hypothesis.
I just found that certain decisions/actions made a lot more sense to me
given this interpretation. It may well be wrong, but I will need an
alternative rationale that makes at least some sense before I ditch it.
Quote
>If they had learned the MS Office lesson, and appreciated the
>interop requirement, I'd have expected some serious research
>into this to be done way back, which could be resurrected now and
>used to supplement the RoadMap at least. The lack of any public
>alternative .NET strategy suggests to me that this did not happen.
>I hope to be proven wrong by a RoadMap update in the
>not-too-distant future.

IMO, this is doubtful, but they still have a chance.

>>I agree and have serious doubts as well. However, it is not too
late>>if they move quickly.
>
>I think that a revised .NET solution will only ever be seen as a
>bandage. That ship has sailed, unless they can provide a
>seriously-valuable USP.

If CodeGear ships Delphi/CLI at the end of 2008, I think it would be a
reasonable .NET story for Delphi. As it is scheduled on the current
roadmap, they can leave Highlander as the last Delphi for .NET
release. :)
If they deliver in that timeframe, then ok - they have a chance. Yet I
do not believe they will be sufficiently resourced to achieve this as
well as the other vital developments they are already committed to.
Quote
>What they need is something that MS can never provide:
>cross-platform. Hit 'em where they aren't.

Agreed; but Delphi needs to have some .NET capability.
I think that they will stand by what they have for the forseeable
future, and hope that the bandage prevents too much bleeding ;-)
Certain people are already spinning the line that .NET 2.0 support is
sufficient to take advantage of .NET 3.5. While this may be true in a
technical sense, I doubt that it will sell many licenses to .NET
developers. Expect a steady bleed to VS as a result.
Quote
>FWIW, I'd concentrate on providing the best client-server/n-tier
>solution possible, from a rich GUI client to a scaleable linux
>server, plus anything that can be done to leverage FreePascal +
>Lazarus.

IMO, I wouldn't mess with Lazarus, but I'd leverage FPC. I would go
for OSX Client and Linux Server. I wouldn't even try to bring the
visual elements of the VCL to OSX; I would create a new GUI framework for
OSX that makes the best use of Cocoa.

The server-side stuff built for Linux, I would bring to windows as well.

>Off
>the top of my head - how about distributing their own Linux, with
>all the server goodies built in?

That wouldn't be my priority. The last thing Linux needs is yet
another distro. The place to start is Apache IMO.
I don't want to wander too far into Linux, as it is not an area of
interest for me, but I just thought that it would be far easier to
deliver a server stack of components if you were in full control of it.
I don't know the best technical direction for interweb / cross-platform
development - not my area. What I do know is that running a permanent
second place in .NET development is not a long-term strategy.
Quote
>My number one priority would be buying/doing a deal with RemObjects.

Agreed, but that is unlikely IMO.

>How much value could Delphi extract from integrating/leveraging the
>remoting code, DA + Hydra?

A lot, however I am not a huge DA fan.
Not tried DA personally, as I am pretty much tied in to a fixed database
selection. I'd think that it was a good fit for Delphi, though.
The remoting solution is very impressive - enough for me to base my
next project on it. BTW, thanks for writing RO34 (I Cannot ROmember) -
confirmed that I was understanding things correctly.
Regards
Ian
 

Re: Delphi and the .Net platform

Troy Wolbrink writes:
Quote
I have more "faith" in Delphi because of Borland/CodeGear's emphasis on
source-compatibility w/ Delphi.NET. I have invested many man-years into
writing Delphi code, and my "faith" in an IDE goes to whomever can help me
preserve that huge investment
In choosing a proprietary development tool and applying that criteria,
there is only one path. IOW, this is a self fulfilling prophecy.
Quote
while moving forward and taking advantage of
new technologies.
There's the rub. Is it possible to have a something that maintains
backward compatibility and take full advantage of new technologies?
IMO, Delphi for .NET is not doing a very good job when it comes to
taking advantage of new technologies; and it has issues with backward
compatibility as well (i.e. third party component support).
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Delphi and the .Net platform

Quote
>I have more "faith" in Delphi because of Borland/CodeGear's emphasis on
>source-compatibility w/ Delphi.NET. I have invested many man-years into
>writing Delphi code, and my "faith" in an IDE goes to whomever can help
>me
>preserve that huge investment

In choosing a proprietary development tool and applying that criteria,
there is only one path. IOW, this is a self fulfilling prophecy.
Yes, I can see your point. :) But contrast this with VB6 ->VB.NET. To me
the worst thing you can do with a development platform is to tell all your
loyal developers that the current IDE is coming to an end, and that all
their source (which took many years to write) will have to be rewritten.
Quote
>while moving forward and taking advantage of
>new technologies.

There's the rub. Is it possible to have a something that maintains
backward compatibility and take full advantage of new technologies?
Yes, obviously. (Are you're alluding to the idea of a mixed mode compiler
ala C++.NET?) This would be the ideal.
Quote
IMO, Delphi for .NET is not doing a very good job when it comes to
taking advantage of new technologies; and it has issues with backward
compatibility as well (i.e. third party component support).
For me, Delphi for .NET is doing a good enough job of taking advantage of
new technologies (.NET 2.0 w/ generics and ASP.NET w/ master pages). I
wouldn't mind seeing more improvements here.
For me, Delphi for .NET is doing a very good job of maintaining backward
compatiblity. I really don't want a mixed-mode compiler. I want to make
the *jump* into .NET and leave the Win32 world behind. If for no other
reason, than to simplify my new environment. So if I have to rewrite *some*
of my code (ie. the non-.NET friendly parts) that is fine w/ me as long as
it's a small percentage of the total.
But I can see how improving both the new technology story *and* the backward
compatibility story would be a compelling platform for new developers. I
think of Anders H. mentioning the "It Just Works" switch in C++ for
targeting old code at the .NET runtime. it is clear that Delphi.NET would be
more valuable with more components, and there's a ton of Delphi.Win32
components just sitting there.
--Troy