Delphi and the .Net platform
Olivier Pons
A lot of people are unhappy with that.
The story is :
- Delphi for Win32 relies on the Microsoft Windows Libraries.
- Delphi for .Net relies on the Microsoft Libraries.
The situation is the same, *exactly* the same.
Why are people unhappy with Delphi going .Net ?
They may be unhappy with Delphi not going Linux or not going somewhere else,
but the fact is that Delphi has always been relying on Microsoft Libraries.
Am I wrong ?
--
Olivier Pons
http://olivier.pons.free.fr/
Bernhard Geyer
> Why are people unhappy with Delphi going .Net ?
- The quality of the .NET Port (D8 unusable, D2005 instable, D2006 only
with updates good to use)
- The missing support of WinForms (in D2007) and WPF and much other
Features in the IDE (Without GUI-Support you can use notepad, C# and the
comandline-compiler)
Iv
I'm not care about *big experiment" named Net :)
Maybe the question is: Who/What is bad - the car or driver?
"Olivier Pons" <olivier.dot.pons...@ignore.this.fr> wrote in
message news:474d2ce2$1...@newsgroups.borland.com...
A Nielsen
> Delphi is relying more and more on the .Net platform.
> A lot of people are unhappy with that.
>
> The story is :
> - Delphi for Win32 relies on the Microsoft Windows Libraries.
> - Delphi for .Net relies on the Microsoft Libraries.
>
> The situation is the same, *exactly* the same.
No, it's not. Win32 is a native platform similar to other native
platforms for Linux and Mac. .NET is Microsoft proprietary virtual
platform.
> Why are people unhappy with Delphi going .Net ?
Windows API is a fairly open platform, thoroughly tested and used for
more than twenty years. There are good emulation layers for other
systems, like Wine, which has also been there for enough time to make it
mature.
.NET is a single provider, work in progress project, not good for the
same range of applications as native API.
> They may be unhappy with Delphi not going Linux or not going somewhere
> else, but the fact is that Delphi has always been relying on Microsoft
> Libraries.
> Am I wrong ?
Yes you are. Microsoft cannot supress Windows API because there are
thousands of applications running on it. Also it's very similar to other
systems, like Xlib or Macs' GUI. Every step that Delphi takes to
coupling more tightly with .NET and other Microsoft-only technologies is
a step away from the possibility of Delphi becoming a cross-platform tool.
Every other independent tool goes torwards cross-platform, including
other CodeGear supported languages like Java, Ruby and PHP.
Which language do you think that a young programmer will choose? There
are a lot of free tools out there. Delphi can't compete being a shadow
of Microsoft's offers.
Actual CodeGear strategy is keeping existing customers that have no
other choice than stay with Delphi, because we have applications to
maintain. They sell incremental updates, long expected like unicode or
win64. We still hope that Borland finally will sell CodeGear and new
developments appear. But CodeGear is a year old and still there are no
signs of a sell.
I'm afraid that while Borland owns CodeGear, no cross-platform strategy
is possible.
Eric Grange
Not really...
.Net is a *huge* set of libraries ('assembly' + 'Microsoft.Net'
directories weight in at about 800 MB here, that's comparable to the
size of OS... and I only have 1.1 and 2.0 installed, no 3.0 or WPF!).
Yet, those 800MB don't do anything that the regular WinAPI can't do, and
there are *still* many things you can't do in .Net without resorting to
P/Invoke wrappers.
That's a huge layer of added fat, dependencies... and bugs (how many
tens of thousandths of extra bugs do those 800MB add to the mix?).
Eric
Li Yang
> Every step that Delphi takes to
> coupling more tightly with .NET and other Microsoft-only technologies is
> a step away from the possibility of Delphi becoming a cross-platform tool.
There might be some misunderstanding. By making MSIL/CIL an
internaltional standard, Microsoft allows others to create clones. Mono
is an open source CIL implementation which supports both Windows and
*NIX (UNIX, Linux, and Mac OS X).
I think it is a pity that because of VCL compatibility, Delphi cannot be
freely extend to .NET purely like RemObjects Chrome. Delphi for .NET now
means Object Pascal + VCL for .NET. This implies that only if VCL for
.NET is Mono compliant, we can say Delphi for .NET applications can run
on most OS platforms.
If you know Chrome, you can see that Pascal compiler binds to CIL
directly. It makes use of WinForms, WebForms, and WPF directly. Thus, no
VCL for .NET is required. As a result, RemObjects can easily claim
Chrome as a cross platform language/toolset.
Delphi for .NET can go that far but since VCL is heavily used in the
past, CodeGear cannot give it up completely.
If you mean that Delphi should not bind to .NET that much, I would like
to say I expect it to bind more to .NET like Chrome. Every user has
his/her special requirements which CodeGear can hardly satisfy.
A Nielsen
> A Nielsen wrote:
>> Every step that Delphi takes to coupling more tightly with .NET and
>> other Microsoft-only technologies is a step away from the possibility
>> of Delphi becoming a cross-platform tool.
>
> There might be some misunderstanding. By making MSIL/CIL an
> internaltional standard, Microsoft allows others to create clones. Mono
> is an open source CIL implementation which supports both Windows and
> *NIX (UNIX, Linux, and Mac OS X).
So we should trust Delphi cross-platform strategy to... Mono?
> If you mean that Delphi should not bind to .NET that much, I would like
> to say I expect it to bind more to .NET like Chrome. Every user has
> his/her special requirements which CodeGear can hardly satisfy.
Cross-platform isn't "special" requirement, but a very common one. Java
climbed to #1 with this banner. Delphi 8 OTOH...
David Wilcockson
> I'm afraid that while Borland owns CodeGear, no cross-platform strategy
> is possible.
>
And yet they've talked about it at CodeRage, and there is some mention of it
on the roadmap:
http://dn.codegear.com/article/36620
"Cross-compilation to other operating systems"
Olivier Pons
This is a CodeGear problem, not the principle of going 32bits => .Net
Bernhard Geyer
The question was: Why are people unhappy with Delphi going .Net, not
generally 32Bit -> Net. I know enough Companies that go Win32 (VS/C++)
-> .NET and are happy with that.
Olivier Pons
It just feels like people don't like CodeGear going .Net, not only because
of CodeGear bugs you've written, but mainly because of the .Net platform
itself, which is Microsoft.
A Nielsen
The roadmap assigns features to releases. The final section is for
features that haven't been assigned to a release. So in fact it says
that it isn't scheduled yet.
BTW, the last release that appears in the roadmap is winter 2008. Won't
Borland sell CodeGear in a year?
Brian Moelk
> So we should trust Delphi cross-platform strategy to... Mono?
At this point in time, it's the most practical. It's far better to
trust Mono than Microsoft for cross platform development.
>> If you mean that Delphi should not bind to .NET that much, I would
>> like to say I expect it to bind more to .NET like Chrome. Every user
>> has his/her special requirements which CodeGear can hardly satisfy.
>
> Cross-platform isn't "special" requirement, but a very common one. Java
> climbed to #1 with this banner. Delphi 8 OTOH...
I don't believe that's what Li Yang was talking about. I happen to
agree with Li on this point, but it's more complicated than that.
Delphi's goal of maximizing backward compatibility was a strength and
weakness. In hindsight, I believe it's mostly been a weakness.
The other issue is IDE integration. Chrome benefits a lot by hooking
into VS.NET, as almost all the designers simply work with Chrome.
Delphi for .NET has its own IDE and thus all the designers need to be
reimplemented.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Brian Moelk
> And yet they've talked about it at CodeRage, and there is some mention of it
> on the roadmap:
>
> http://dn.codegear.com/article/36620
>
> "Cross-compilation to other operating systems"
That's a far cry from a "strategy" in my mind. Listing a vague line
item on a road map and discussing it a bit isn't a strategy.
Delphi had a cross platform strategy, it was implemented in Kylix. That
turned out to be not-so-hot for various reasons. They need a new
plan/vision/strategy and I don't think they really have one at this time.
Olivier Pons
> The quality of the implementation is everything.
>
> The core issue is that Delphi for .NET is simply not the best tool for
> developing .NET applications.
>
Thus the problem is about CodeGear's buggy implementation, not about the
CodeGear's direction ?
Brian Moelk
> Delphi is relying more and more on the .Net platform.
> A lot of people are unhappy with that.
>
> The story is :
> - Delphi for Win32 relies on the Microsoft Windows Libraries.
> - Delphi for .Net relies on the Microsoft Libraries.
>
> The situation is the same, *exactly* the same.
> Why are people unhappy with Delphi going .Net ?
The quality of the implementation is everything.
The core issue is that Delphi for .NET is simply not the best tool for
developing .NET applications.
--
Brian Moelk
> Thus the problem is about CodeGear's buggy implementation, not about the
> CodeGear's direction ?
It's more complex than that, but ultimately I do think it boils down to
exactly that.
If Delphi for .NET was clearly and demonstratively superior to the
alternatives, no one would care so much. For example, it's not like COM
didn't suck, it's just that Delphi did COM much better than MS did.
But competing in the .NET space is very different from the Win32 space.
First, the scope is much broader. Second, MS has devoted far more
resources into their own tools development. Third, MS development tools
are better than they've ever been. Fourth, .NET is focused on competing
with Java; its sweetspot is server side development, Delphi's isn't.
I don't blame MS for this; Borland's the one that has chosen to play on
MS' turf and CodeGear continues playing. And it's not so much that they
choose to play, it's how they choose to play that matters.
CodeGear has to be smarter than they have been about how they want to
support .NET. They are smarter now than they were before, but I still
don't think they've learned enough. :)
Rudy Velthuis [TeamB]
> Bernhard Geyer a écrit :
> >>This is a CodeGear problem, not the principle of going 32bits =>
> .Net
> >
> >The question was: Why are people unhappy with Delphi going .Net, not
> generally 32Bit -> Net. I know enough Companies that go Win32
> (VS/C++) -> .NET and are happy with that.
>
> It just feels like people don't like CodeGear going .Net, not only
> because of CodeGear bugs you've written
But are those bugs actually the result of Delphi hosting and using .NET?
I am not so sure about that, although I agree the impression exists
that this is the case (probably because the bugs and .NET support were
both introduced at the same time, with the Galileo IDE).
--
Rudy Velthuis [TeamB]
"The worst crimes were dared by a few, willed by more and
tolerated by all." -- Tacitus
James Smith
> developing .NET applications.
And silly for CodeGear to try to make such a product. Delphi is the best
tool for w32 development - a legacy platform and static market. If CodeGear
is to develop a tool for the future, it's got to be something that addresses
the internet as its own platform. Maybe the Rails stuff or JBuilder is the
future, but for a native solution (pick a os target), seems to me that
focusing on stuff like proof of correctness in code, workable concurrency,
session management, and security should have priority over interface
widgets. ExtJS and YUI are close to getting all that interface stuff
hammered.
I'm much more interested in a good cross-platform pascal json serializer and
coroutine or fiber implementation over new widgets and .net support right
now.
James
Brian Moelk
> And silly for CodeGear to try to make such a product.
Yes and no. If they can create something special or unique and make
money...why not? The problem is that I believe Delphi for .NET is 0 for
3 by those standards.
> Delphi is the best
> tool for w32 development - a legacy platform and static market. If CodeGear
> is to develop a tool for the future, it's got to be something that addresses
> the internet as its own platform.
Agreed.
> Maybe the Rails stuff or JBuilder is the
> future,
But they aren't markets with high enough switching costs to make any
significant money. The problem for CodeGear is that they are open
platforms with a lot of competition, good for us though. :)
> but for a native solution (pick a os target),
Just one? I say pick two: Windows and OSX. If you want server side
development, then drop OSX and pick up Linux.
> seems to me that
> focusing on stuff like proof of correctness in code, workable concurrency,
> session management, and security should have priority over interface
> widgets. ExtJS and YUI are close to getting all that interface stuff
> hammered.
Agreed, but you're talking about something completely counter culture to
the Delphi user base. IOW, it's not going to be *Delphi* that makes
this happen. CodeGear needs an entirely new product for that purpose.
> I'm much more interested in a good cross-platform pascal json
> serializer and coroutine or fiber implementation over new widgets and
> .net support right now.
No need for pascal...I'm watching CouchDB closely. :)
I suspect that ExtJS and CouchDB will be good enough for many kinds of
document based applications.
John Moshakis
> Fourth, .NET is
> focused on competing with Java; its sweetspot is server side
> development, Delphi's isn't.
I can't say I agree with that and what about if I do dotnet with Delphi?
Cheers,
John
--
Brian Moelk
>> Fourth, .NET is
>> focused on competing with Java; its sweetspot is server side
>> development, Delphi's isn't.
>
> I can't say I agree with that and what about if I do dotnet with Delphi?
IMO, you're not using Delphi for what Delphi is uniquely the best at
doing. Like it or not, Delphi's sweet spot has always been GUI
applications. It's growth driven in times of Client/Server
architectures that required rich GUI's connecting to database servers.
I'm not saying that Delphi isn't capable of server side applications,
web applications or non-database front ends or .NET development. What
I'm saying is that those things aren't Delphi's sweet spot; those things
aren't what captures the developer's imagination when they first see Delphi.
Andre Kaufmann
>> The situation is the same, *exactly* the same.
>
> Not really...
>
> .Net is a *huge* set of libraries ('assembly' + 'Microsoft.Net'
> directories weight in at about 800 MB here, that's comparable to the
> size of OS... and I only have 1.1 and 2.0 installed, no 3.0 or WPF!).
> Yet, those 800MB don't do anything that the regular WinAPI can't do, and
.NET 2.0 has a download size of 20 MB, .NET 3.0 56 MB.
Silverlight has a donwload size of 4 MB.
> there are *still* many things you can't do in .Net without resorting to
> P/Invoke wrappers.
And there are things you can't do (easily) in Win32 API.
> That's a huge layer of added fat, dependencies... and bugs (how many
> tens of thousandths of extra bugs do those 800MB add to the mix?).
>
> Eric
Andre
Robert Giesecke
> Eric Grange wrote:
>>> The situation is the same, *exactly* the same.
>>
>> Not really...
>>
>> .Net is a *huge* set of libraries ('assembly' + 'Microsoft.Net'
>> directories weight in at about 800 MB here, that's comparable to the
>> size of OS... and I only have 1.1 and 2.0 installed, no 3.0 or WPF!).
>> Yet, those 800MB don't do anything that the regular WinAPI can't do, and
>
> .NET 2.0 has a download size of 20 MB, .NET 3.0 56 MB.
> Silverlight has a donwload size of 4 MB.
>
He meant the real size on the target system, after ngen'ing it. And He could be right with 800MB, at
least half a gig...
>
>> there are *still* many things you can't do in .Net without resorting
>> to P/Invoke wrappers.
>
> And there are things you can't do (easily) in Win32 API.
>
Yep, I don't agree on the rest of his statement. .Net is quite different from what and how you did it
before, and fortunately so! :-)
Robert Giesecke
>
> So what's is Delphi missing in those other areas that means it doesn't
> hit the sweet spot ?
>
Tools and library support. But eventually all boils down to missing Reflection and maybe meta data
like Attributes.
There're no standard interfaces for containers, heck, there's not even a set of standard containers
worth mentioning...
Add more interfaces and containers to the RTL, add Reflection-like introspection capabilities and meta
data. Then, there might be the tools and libraries that you see in the .Net world. (xsd.exe, wsdl.exe,
sgen.exe, svcutil.exe, nHibernate, LINQ, ASMX, Remoting, app.config/web.config, ...)
John Moshakis
So what's is Delphi missing in those other areas that means it doesn't
hit the sweet spot ?
--
John Moshakis
Ok I see. I should of been more explicit, when I said Delphi I meant
win32 and dotnet. In which I can probably leverage most of what you
mentioned.
Cheers,
John
--
Donald Shimoda
> I am not so sure about that, although I agree the impression exists
> that this is the case (probably because the bugs and .NET support were
> both introduced at the same time, with the Galileo IDE).
>
I find Refactor and together the main source or ide bugs. Disabling that
everything start working as expected.
Actually almost everything. :P
You loose refactor wich is a great thing, IMHO.
--
Donald Shimoda
Robert Giesecke
>
> Ok I see. I should of been more explicit, when I said Delphi I meant
> win32 and dotnet. In which I can probably leverage most of what you
> mentioned.
>
Ah well, my point against D.Net is, that it just doesn't feel right, let alone give you the ease other
languages like C# or Chrome come with.
Unit/Namespace/Filenames in D.Net are easiest to be described as PITA, compared to *any* other serious
.Net language.
Then there is the issue of D.Net *forcing* you to have you assemblies cluttered with stuff that you
didn#t use and probably didn't even want to use. But those things will not only make them look awkward
to other .Net devs, they make your assemblies violate the .Net API guidelines.
Oh, and this added stuff renders assemblies compiled by one version of the D.Net compiler completely
incompatible to any other version of D.Net.
I could go on forever with more stuff, let's just settle it with something along: I can't see why one
would choose D.Net as the language of choice for new .Net dev, except for migrating old code.
But even then, I'd rather write everything new in another language and port the old code one class at
a time...
Delphi has a unique opportunity to leverage .Net as it happens to have a native and a .Net compiler:
Mixed mode!
going mixed mode would mean that you can use your native code natively and .Net code managed and have
the compiler to build the glue code.
Either that or dumping the D.net compiler completely and go for something similar as Chrome.
I can't see much sense in the way it is done since D8...
Brian Moelk
> So what's is Delphi missing in those other areas that means it doesn't
> hit the sweet spot ?
Off the top of my head:
1) Cross platform deployment
2) Broad Third party support - think about Oracle writing a dbx driver
3) Corporate acceptance - have to be able to sell into "big IT"
4) and the technical things Robert mentioned...
It's not that Delphi is necessarily technically capable, it's just that
it's not its sweet spot.
Mat Ballard
> Why are people unhappy with Delphi going .Net ?
Let me count the ways ...
1. Speed
2. Memory
3. bugginess
4. the tight integration of the Delphi IDE help functions with ... Visual Basic
Help ???
5. While the zealots claim it is a "platform", it's just a wrapper for Win32.
About 20x less efficient than the VCL at that. It's a much better wrapper than
MFC, so those VC++ programmers are happy, but it's not significantly better than
the VCL for us Delphi programmers.
6. Lack of true 64-bit support.
7. It dooms Delphi to be a poor second cousin to M$ products, who for some
reason seem to be able to keep up with the frequent release of new versions,
while Delphi cannot.
8. M$'s updates have a habit of nuking the Delphi IDE about 6-12 months after
its release. D1 to D7 run happily on every version of Windows (with the
exception of D1 on Win64). D8 runs on no version, and D2005 is not much better.
Sorry, when I spend a kilobuck or so on a dev tool, I want it to continue
working for a few years.
9. What does it let me do that I cannot do with D7 ? Answer: buggerall. Or to
put it another way, it has a lot of nice *features*, but little or no added
*capability*.
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] escribió:
>
> > I am not so sure about that, although I agree the impression exists
> > that this is the case (probably because the bugs and .NET support
> > were both introduced at the same time, with the Galileo IDE).
> >
>
> I find Refactor and together the main source or ide bugs. Disabling
> that everything start working as expected.
Refactoring? I doubt it, since, AFAIK, that only runs if you start it,
and doesn't have to be disabled (and, FWIW, I don't know if refactoring
is a .NET process). I guess that the background compiler is the main
source of the IDE problems. And the compiler is a Win32 process.
--
Rudy Velthuis [TeamB]
"Dying is a very dull, dreary affair. And my advice to you is to
have nothing whatever to do with it." -- W. Somerset Maugham.
Paul Klink
> developing .NET applications.
But it is the best tool if you want to use the same code base across both Win32 (thick GUI clients) and ASP.NET (Web
Applications).
Paul
Rudy Velthuis [TeamB]
> John Moshakis wrote:
> >
> > Ok I see. I should of been more explicit, when I said Delphi I meant
> > win32 and dotnet. In which I can probably leverage most of what you
> > mentioned.
> >
>
> Ah well, my point against D.Net is, that it just doesn't feel right,
> let alone give you the ease other languages like C# or Chrome come
> with. Unit/Namespace/Filenames in D.Net are easiest to be described
> as PITA
Huh? One of the things I always liked about Delphi is that unit name
and file name coincide, unlike in C++ or C#. Makes finding and
including things a lot easier. And you can still have different files
attribute to a namespace, in Delphi for .NET. That is IMO the best of
both worlds.
Isn't there also a strong coupling between file name and class name (or
whatever they call it there), in Java?
FWIW, what I totally don't like about .NET is that namespaces can be
spread out over different assemblies (actually, Delphi for .NET can do
that too), so you don't readily know which assembly to reference when
you want to include a namespace. You'll have to guess.
--
Rudy Velthuis [TeamB]
Customer: "I'm running Windows '95."
Tech: "Yes."
Customer: "My computer isn't working now."
Tech: "Yes, you said that."
Robert Giesecke
> Robert Giesecke wrote:
>
>> John Moshakis wrote:
>>> Ok I see. I should of been more explicit, when I said Delphi I meant
>>> win32 and dotnet. In which I can probably leverage most of what you
>>> mentioned.
>>>
>> Ah well, my point against D.Net is, that it just doesn't feel right,
>> let alone give you the ease other languages like C# or Chrome come
>> with. Unit/Namespace/Filenames in D.Net are easiest to be described
>> as PITA
>
> Huh? One of the things I always liked about Delphi is that unit name
> and file name coincide, unlike in C++ or C#. Makes finding and
> including things a lot easier. And you can still have different files
> attribute to a namespace, in Delphi for .NET. That is IMO the best of
> both worlds.
>
Ah yes, right... "Rudy.ProjectNameSpace.Unitname.pas" looks just so much nicer and easier to spot than
just Unitname.pas in your project's folder...
> Isn't there also a strong coupling between file name and class name (or
> whatever they call it there), in Java?
>
Only the class name, which is how I write in .Net: Usually one type per file and the file is called
like the type.
> FWIW, what I totally don't like about .NET is that namespaces can be
> spread out over different assemblies (actually, Delphi for .NET can do
> that too), so you don't readily know which assembly to reference when
> you want to include a namespace. You'll have to guess.
>
I like that actually. Inside a solution, I often have some assemblies that will put their stuff in the
same namespace(s).
But they aren't always used by the same consuming assemblies. (Hence the separation)
In D.Net things get even more complicated, when you consume code written in D.Net, because now you had
to use *units*, not just namespaces... *shakes head*
Robert Giesecke
> Robert Giesecke wrote:
>
>> Ah yes, right... "Rudy.ProjectNameSpace.Unitname.pas" looks just so
>> much nicer and easier to spot than just Unitname.pas in your
>> project's folder...
>
No, it isn't and you tried again to quote-out the part that doesn't look to good for your POV, right? ;-)
There are real issues with D.Net, and those do not exist in other .Net languages.
So, D.Net is not an equally good choice for .Net development. I guess that choice would be made mostly
for migration or code reuse, not for new development.
Rudy Velthuis [TeamB]
> Ah yes, right... "Rudy.ProjectNameSpace.Unitname.pas" looks just so
> much nicer and easier to spot than just Unitname.pas in your
> project's folder...
Is that your sole objection: "it doesn't look nice"? What about project
default namespaces?
--
Rudy Velthuis [TeamB]
"I have spoken many a word, therefore, it is fact."
-- Eric the Verbose
Rudy Velthuis [TeamB]
> > Is that your sole objection
>
> No, it isn't and you tried again to quote-out the part that doesn't
> look to good for your POV, right?
Not on purpose.
;-) There are real issues with
> D.Net, and those do not exist in other .Net languages.
Sure, but I was specifically asking about the namespace part. Is that
your sole objection to Delphi's way of specifying namespaces?
--
Rudy Velthuis [TeamB]
"[War] might be avoidable were more emphasis placed on the
training to social interest, less on the attainment of
egotistical grandeur." -- Lydia Sicher
Rudy Velthuis [TeamB]
> > Isn't there also a strong coupling between file name and class name
> > (or whatever they call it there), in Java?
>
> Only the class name
And in what way is that much different to having a unit name that
coincides with the file name?
--
Rudy Velthuis [TeamB]
"The only way to combat criminals is by not voting for them."
-- Dayton Allen
Robert Giesecke
> Robert Giesecke wrote:
>
>>> Is that your sole objection
>> No, it isn't and you tried again to quote-out the part that doesn't
>> look to good for your POV, right?
>
> Not on purpose.
>
> ;-) There are real issues with
>> D.Net, and those do not exist in other .Net languages.
>
> Sure, but I was specifically asking about the namespace part. Is that
> your sole objection to Delphi's way of specifying namespaces?
There's more...
You cannot make one file per type: You have to have forward declares like in classic Delphi for
mutually used types.
From D.Net to D.Net, there are no namespaces, only full unit names. Had this one in a prev post though.
All this would be *perfectly* acceptable in a mixed-mode scenario. (all this delphi32-lookalike would
actually really make sense in mixed-mode!)
But not when someone tries to sells it to you as a first-class .Net language, which it just ain't...
Rudy Velthuis [TeamB]
> But not when someone tries to sells it to you as a
> first-class .Net language, which it just ain't...
IMO, it is. You can participate in any namespace, and use any
namespace.
The fact that the internal organisation is different (units) from C# or
VB.NET, and compatible with Delphi for Win32 instead, doesn't change
that. Nothing says that a first-class .NET language can't have its own
internal organisation, or must be a C# clone with a different syntax.
I don't quite like the total lack of such an organisation of C# source
files (IOW, there is nothing that links a C# source file to any form of
organisation, be it an assembly or a namespace) that take part in a
namespace. It is what I disliked about C++ as well.
--
Rudy Velthuis [TeamB]
"I'll moider da bum."
-- Heavyweight boxer Tony Galento, when asked what he thought of
William Shakespeare
Robert Giesecke
> Robert Giesecke wrote:
>
>> But not when someone tries to sells it to you as a
>> first-class .Net language, which it just ain't...
>
> IMO, it is. You can participate in any namespace, and use any
> namespace.
>
Reference an assembly in RAD2007, that was compiled in D2005.
Now, reference any verifiable assembly in C#/Chrome, no matter what compiler compiled it (referenced
runtime max. the one you compile against).
Or, reference a D.Net assembly w/o having the .d*il files...
> The fact that the internal organisation is different (units) from C# or
> VB.NET, and compatible with Delphi for Win32 instead, doesn't change
> that. Nothing says that a first-class .NET language can't have its own
> internal organisation, or must be a C# clone with a different syntax.
>
Heck no! Wouldn't make sense to make your own compiler if it wasn't any different.
But, after I compiled it, it shouldn't ... well look like D.net compiled assemblies look like.
Would be perfectly OK, if it was optional. But it is not optional.
I can compile an assembly 1.1 in C#/Chrome (no matter which version) and reference it no matter which
version. I cannot load multiple D.Net assemblies, compiled with different compilers.
This is like native Delphi, you *need* the source. how could that be called first-class .Net language?
(Maybe I got the meaning of this "first-class" in the context of .Net languages wrong...)
Let's remember the original question: "Why are people unhappy with Delphi going .Net ?"
I gave some reasons. You can try to twist them as you like, they are not gonna go away, except by
canceling before google could grap it... ;-)
>
> I don't quite like the total lack of such an organisation of C# source
> files (IOW, there is nothing that links a C# source file to any form of
> organisation, be it an assembly or a namespace) that take part in a
> namespace. It is what I disliked about C++ as well.
>
Well, one can see this lack of restriction as a plus. ;-)
Rudy Velthuis [TeamB]
> Reference an assembly in RAD2007, that was compiled in D2005.
> Now, reference any verifiable assembly in C#/Chrome, no matter what
> compiler compiled it (referenced runtime max. the one you compile
> against). Or, reference a D.Net assembly w/o having the .d*il
> files...
So? Reference them from C#, VB.NET etc. and all works well. Delphi will
look for the specific internal unit info, like it always does.
I agree that dcpil files should go. AFAIK, CodeGear agree too.
--
Rudy Velthuis [TeamB]
"When I am dead, I hope it may be said: 'His sins were scarlet
but his books were read." -- Hillaire Belloc.
Brian Moelk
IMO, this is a bit of an edge case as often times SOA/webservice
integration and even interop techniques can solve this problem if it
actually exists in the first place.
But yes, if one has an existing Delphi codebase and needs to port that
code to .NET, Delphi for .NET is the best tool for that job. But if one
is starting a new project and ASP.NET is the web development framework
of choice and there is a GUI part, IMO, it's better to do the whole
thing in .NET using WinForms for the GUI.
There are some concerns in using Delphi for .NET to bring existing code
forward for ASP.NET. Depending on what that code uses, trust
priviledges might need to be altered for deployment:
from: http://blogs.teamb.com/craigstuntz/dtpostname/vclfordotnetvswinforms
"If you choose to reference rather than link the VCL for .NET
assemblies, administrators may need to grant these assemblies full trust
privileges when your app will be run under restricted security settings,
such as in a browser or on a network share. The VCL for .NET adds to the
size of your deployment, but it’s small in comparison to the .NET
framework itself."
Craig was discussing VCL.NET vs. WinForms, however a lot of Delphi code
brings in SysUtils, Windows and dependencies on the VCL. All these
things could add up to more difficulty with ASP.NET deployment.
Eric Grange
> Silverlight has a donwload size of 4 MB.
Download size matters only for downloading (*shocker*), for execution
and running stuff, it's the size on the harddisk and in-memory that matters.
All the download size indicates is the quality of the compression, and
the relative amount of stuff generated/patched/bloated *after* the
installation.
Eric
A Nielsen
> A Nielsen wrote:
>> So we should trust Delphi cross-platform strategy to... Mono?
>
> At this point in time, it's the most practical. It's far better to
> trust Mono than Microsoft for cross platform development.
Well, I guess it's far better to lose a limb or two than to die. But I'd
be happy to have more options.
I don't find so strange to have a cross platform strategy of its own.
>>> If you mean that Delphi should not bind to .NET that much, I would
>>> like to say I expect it to bind more to .NET like Chrome. Every user
>>> has his/her special requirements which CodeGear can hardly satisfy.
>> Cross-platform isn't "special" requirement, but a very common one. Java
>> climbed to #1 with this banner. Delphi 8 OTOH...
>
> I don't believe that's what Li Yang was talking about. I happen to
> agree with Li on this point, but it's more complicated than that.
I think it's very simple. Either you go Microsoft all the way or you
have something valuable that makes a difference.
Iv
.NET, it is my opinion, is for lazy, unskilled "programmers" or "office"
people.. Where is reason you to use extra layers to do simple call to
Win32??? .Net is only "method" MS to escape VB gaps and bad attempting to
add missing Delphi functionality to VB :) . Maybe all of you know for one
very old joke: "Why VB is the MS favorite product? - Because Bill Gates
understands only Basic"....
Iv
"Eric Grange" <egra...@SPAMglscene.org> wrote in message
news:474e...@newsgroups.borland.com...
Abdullah Kauchali
"Andre Kaufmann"
> And there are things you can't do (easily) in Win32 API.
Hi Andre,
Can you cite some examples? (Genuine question - no funnies)
Michael Anonymous
<snip>
>> The situation is the same, *exactly* the same.
>
>
> The core issue is that Delphi for .NET is simply not the best tool for
> developing .NET applications.
>
Another core issue is that WORKING on a Delphi for .NET
takes away time from other activities like working on a Delphi Win64.
Michael Anonymous
<snip>
>
> Delphi has a unique opportunity to leverage .Net as it happens to have a
> native and a .Net compiler: Mixed mode!
That would have been very smart and it would have saved a lot of time. :-)
I.P. Nichols
Why do we need anything, we could just live in trees and eat grubs.
> .NET, it is my opinion, is for lazy, unskilled "programmers" or "office"
> people.. Where is reason you to use extra layers to do simple call to
> Win32???
I've heard C/C++ programmers say similar things about Delphi programmers and
their VCL boy toy. :>)
marc hoffman
> For what you need .NET?
>
> .NET, it is my opinion, is for lazy, unskilled "programmers" or "office"
> people..
exactly. real men write their apps in machine code.
--
marc hoffman
RemObjects Software
The Infrastructure Company
http://www.remobjects.com
Rudy Velthuis [TeamB]
> Another core issue is that WORKING on a Delphi for .NET
> takes away time from other activities like working on a Delphi Win64.
Not necessarily a negative thing. The fact that there are two products
now means the codebase must be streamlined and that certain spots
causing "cross-platform" problems (between Win32 and .NET) must be
identified and changed anyway. This very likely eases the transition to
Win64 as well, since the problematic spots for such a port (e.g. code
assuming something about the size of a pointer, or a char, or assuming
a specific Win32 feature, etc.) will already be identified and updated.
--
Rudy Velthuis [TeamB]
"Invading Iraq after 9/11 was like invading Mexico after Pearl
Harbor." -- Richard Clarke
Chris Morgan
>> that everything start working as expected.
>
> Refactoring? I doubt it, since, AFAIK, that only runs if you start it,
Disabling Together makes the IDE much more responsive,
but you lose a lot of the refactoring functionality.
> and doesn't have to be disabled (and, FWIW, I don't know if refactoring
> is a .NET process). I guess that the background compiler is the main
> source of the IDE problems. And the compiler is a Win32 process.
The Refactoring uses .NET, and is the reason we have to install
the J# runtime, I believe.
Cheers,
Chris
Craig Stuntz [TeamB]
> (and, FWIW, I don't know if refactoring
> is a .NET process).
It is, both the Together and non-Together refactorings. Refactoring
uses CodeDOM.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it's good: http://tinyurl.com/7hgfr
Brian Moelk
> Well, I guess it's far better to lose a limb or two than to die. But I'd
> be happy to have more options.
As we all would ideally, but I'm speaking from a very practical
perspective here given the reality of CodeGear's situation with Delphi.
> I don't find so strange to have a cross platform strategy of its own.
I agree, I'd love to see that.
> I think it's very simple. Either you go Microsoft all the way or you
> have something valuable that makes a difference.
It might be for you, but my world isn't black/white and in this case
.NET has many shades of grey.
Robert Giesecke
- DataBinding (object-based),
- Dynamic code generation (runtime and language agnostic through CodeDOM),
- meta data and introspection of that meta data at runtime,
- multicast delegates (assignable by static and instance methods),
- closures (thx to GC),
- language agnostic, shared OO libraries,
- self describing libraries, as opposed to DLLs & separate headers
- ... I could go on and on ...
Andre Kaufmann
> For what you need .NET?
>
> .NET, it is my opinion, is for lazy, unskilled "programmers" or "office"
> people.. Where is reason you to use extra layers to do simple call to
> Win32??? .Net is only "method" MS to escape VB gaps and bad attempting to
> add missing Delphi functionality to VB :) . Maybe all of you know for one
The difference between a skilled programmer and a unskilled one is that
the skilled one chooses the technology which fits best to solve a problem.
.NET is a platform for multiple languages. Try to access a Dll in Delphi
from another language or from a website. Well it its possible for sure.
But I'm really tired of wrapping all my objects in flat functions or COM
interfaces in a DLL library.
If you write only single executables or stay in a single language you
may be right, asking "why .NET."
> [...]
>
Andre
Andre Kaufmann
Hi,
additionally to the ones Robert already mentioned:
- Running directly in the browser on the client side. You have
to choose either JavaScript, Java, Silverlight, Flash
- Evaluating formulas entered in an edit box, compiling them
to code directly and running them
- Compiling XSL
- Passing objects through dll boundaries.
Or even better a list / array of objects
- Directly accessing new libraries, written in another language
- Simply create a new language, which can be compiled to IL code
- Same executable running on 32 and 64 Bit
or on multiple platforms (PDA etc.)
- Running in secure environments
..... to be continued ;-)
Andre
Iv
project that is Delphi/ASP - VBScript.. All objects (COM/ISAPI/DLL,
Services), except several web pages are written with Delphi 6. The project
every day serve service to approximately 3 millions people, fletch
information from 20-30 terabits DB with more that 3 900 000 000 records
each, and serve intranet/internet/local service and work really without
exceptions and incident support from few years... The project is related to
financial transactions, not for picture entertainments. The same project is
replacement of one .NET project that was crashed few times in day..
So... For what you need .NET?
"Andre Kaufmann" <akinet@_spam_remove_t-online.de> wrote in message
news:474f...@newsgroups.borland.com...
Andre Kaufmann
> No, I'm not stay only with "only one" language, but I participate in one gov
> project that is Delphi/ASP - VBScript.. All objects (COM/ISAPI/DLL,
You are staying in COM. Besides all the trouble with central
registration and dll hell, which can only be prevented by using side by
side installation and manifest files, it's a pain to work with COM,
compared to a .NET library. Delphi handles and wraps COM quite well, but
COM has technical restrictions, because it's basis are interfaces.
Passing objects, deriving from objects, exporting and using event
handlers is easier in .NET IMHO.
> Services), except several web pages are written with Delphi 6. The project
> every day serve service to approximately 3 millions people, fletch
> information from 20-30 terabits DB with more that 3 900 000 000 records
> each, and serve intranet/internet/local service and work really without
Sounds to be a big system. Then you perhaps already started to port your
applications to 64 bit ?
> exceptions and incident support from few years... The project is related to
> financial transactions, not for picture entertainments. The same project is
> replacement of one .NET project that was crashed few times in day..
Hm, a skilled programmer should be able to handle a platform (.NET)
written for unskilled programmers ?
> So... For what you need .NET?
Well I don't need it to survive. And to develop applications I don't
really need it too. But........
Why do you use Delphi ? A skilled programmer uses assembly, modifies a
Linux kernel combines all together to a single application combined with
a kernel and ships a whole PC optimized for the application additionally
you may also integrate a database directly in the kernel.
Such discussions lead to nothing. You could also ask: Why do we need a
new Delphi IDE, additions to the language ? Delphi6 is quite good
enough. Why do we need other languages than Delphi ?
I'm not happy with everything with .NET. But I like how different
languages can interact seamlessly.
Andre
Abdullah Kauchali
"Robert Giesecke"
> - DataBinding (object-based),
> - Dynamic code generation (runtime and language agnostic through CodeDOM),
> - meta data and introspection of that meta data at runtime,
> - multicast delegates (assignable by static and instance methods),
> - closures (thx to GC),
> - language agnostic, shared OO libraries,
> - self describing libraries, as opposed to DLLs & separate headers
> - ... I could go on and on ...
Hi Robert,
Ok, maybe I'm not understanding this ... but aren't these features of the
.NET framework and the CLI itself (ie. nothing to do with the Windows API)?
I could cite those features from Java too.
I meant to ask: what is it one can do with .NET on Windows that one couldn't
do (or do easily) with the Windows native API? Is there something on
Windows that is exposed exclusively with .NET? (I know that the WPF is only
exposed by a .NET API - besides that.)
Abdullah Kauchali
"Abdullah Kauchali"
> .NET framework and the CLI
Abdullah Kauchali
"Andre Kaufmann" <
> - Passing objects through dll boundaries.
> Or even better a list / array of objects
Good points, thanks!
Craig
> people.. Where is reason you to use extra layers to do simple call to
> Win32??? .Net is only "method" MS to escape VB gaps and bad attempting to
> add missing Delphi functionality to VB :) . Maybe all of you know for one
> very old joke: "Why VB is the MS favorite product? - Because Bill Gates
> understands only Basic"....
Thats exactly why I only use assembler for all my development. It may
take me a year to do the simple hello world web app but at least I
know it's saving me 1ms in that tight loop.
Craig.
Del Murray
have to "write" a program. ..
I like writing programs, I dont like figuring out how a "tool" works, then
"why" it doesnt work, then "what" I'm going to do to get around the problem
until M$, who I cant talk to, get's it solved.
I swear, if Clipper had built a decent mouse interface, I could run rings
with it around the short falls of .Net
Del Murray
that brought us .Net and the 640K memory limit in DOS and the "fake" Window
3.0 and ASP which was another "runtime" back to an ISAPI .. layer upon layer
of "we will do it for you" that keeps going back to a DLL that attempts to
do programming stuff for you.
If you want to write web apps ... Webbroker gets you as close to the web as
you need to go without without writing assembler and if there are any bug,
you have the source code and you get to fix it and get on with it, dont
look for a work around.
I dont see how we can have confidence in the same company that brought us
the technology that had "restrictions" that the next version of their stuff
tries to solve.
Real men write real code that doesn't encode to a fake runtime. Next thing
you know there will be layer upon layer of sql statmemts .. they already
started with trying to run VB inside SQL Server... 6 generations of a DB
manager before we finally get a Date type field that doesn't defy "select x
where date between startdate and enddate" without having to jerk it around
to overcome the "time" part of the field. If they had any sense they never
would have put the two togther.. its like making your addrss part of your
name for Gods sake. If you move, you have to change your name !!!
Sorry .. I'm venting ..
Del Murray
I agree. I still do all my stuff almost exclusively in D5 Enterprise. I can
get data from anywhere, show it to anyone, let SQL server store and manage
it, ship it anywhere in any fomat and report on it with Crystal Reports on a
desktop or over the web to one client or 600. It will count, add, sum,
divide, concatenate, parse, list, sort, copy , fold , spindle, encrypt,
mutilate and otherwise do what ever I tell it to do ... to as much data as
one can store .. in very short order.
Dot Net adds what ???? more machine cycles required to accomplish the same
thing .. they way they want to accomplish it ???? No Thanks !
I think XBox 3000 is running .Net :-)
Jolyon Smith
> Dot Net adds what ????
Sex appeal.
.net is the blonde girl/himbo* of your dreams that looks like she'll do
anything, promises she'll do everything, but ultimately is just a huge
drain on your resources.
(*delete as applicable)
:)
--
JS
TWorld.Create.Free;
WillR
> Yes, and those technical restrictions were introduced by the same company
> that brought us .Net and the 640K memory limit in DOS
The again maybe it was Intel and IBM -- IBM did put ROMS in the top 384K
and later used it as "window" memory... ems boards, memory mapped I/O
and the like.
I do recall that the 8088/86 only went beyond 1MB due to some trickery
-- perhaps it was taking advantage of a design flaw/hole -- don't recall
exactly anymore.
Microsoft did flub the FAT table design -- several times. But that's a
hard drive issue more than anything. It's not like we need drives bigger
than 5MB anyway.
Anyway -- the two digit year was a great advance over the previous
implementation -- and people like you still b.... about that!
> and the "fake" Window
> 3.0
Cmon now they stole stuff from GEM and PARC fair and square...
> and ASP which was another "runtime" back to an ISAPI .. layer upon layer
> of "we will do it for you" that keeps going back to a DLL that attempts to
> do programming stuff for you.
Now I never knew that before...
> If you want to write web apps ... Webbroker gets you as close to the web as
> you need to go without without writing assembler and if there are any bug,
> you have the source code and you get to fix it and get on with it, dont
> look for a work around.
>
> I dont see how we can have confidence in the same company that brought us
> the technology that had "restrictions" that the next version of their stuff
> tries to solve.
Some of these were more hardware issues -- driven by bean counters than
anything... :-)
One of my favorite gripes actually.
> Real men write real code that doesn't encode to a fake runtime.
I wonder what real women programmers do. lol
You mean like java byte code, pascal PCODE, BASIC intermediate byte code
or.... any of those silly interpreted languages.
> Next thing
> you know there will be layer upon layer of sql statmemts .. they already
> started with trying to run VB inside SQL Server... 6 generations of a DB
> manager before we finally get a Date type field that doesn't defy "select x
> where date between startdate and enddate" without having to jerk it around
> to overcome the "time" part of the field. If they had any sense they never
> would have put the two togther.. its like making your addrss part of your
> name for Gods sake. If you move, you have to change your name !!!
Dates!!! -- like I said -- the two digit year...
> Sorry .. I'm venting ..
Great vent actually...
--
Will R
PMC Consulting
IanH
> Michael Anonymous wrote:
>
> > Another core issue is that WORKING on a Delphi for .NET
> > takes away time from other activities like working on a Delphi
> > Win64.
>
> Not necessarily a negative thing. The fact that there are two products
> now means the codebase must be streamlined and that certain spots
> causing "cross-platform" problems (between Win32 and .NET) must be
> identified and changed anyway. This very likely eases the transition
> to Win64 as well, since the problematic spots for such a port (e.g.
> code assuming something about the size of a pointer, or a char, or
> assuming a specific Win32 feature, etc.) will already be identified
> and updated.
It could also mean that compromises have to be made, with the Win32
product bending to accomodate the .NET stuff (and vice versa), with the
result being less than optimal - for BOTH products.
IanH
> Olivier Pons wrote:
>
> > Why are people unhappy with Delphi going .Net ?
>
> Let me count the ways ...
>
> 1. Speed
> 2. Memory
> 3. bugginess
> 4. the tight integration of the Delphi IDE help functions with ...
> Visual Basic Help ??? 5. While the zealots claim it is a "platform",
> it's just a wrapper for Win32. About 20x less efficient than the VCL
> at that. It's a much better wrapper than MFC, so those VC++
> programmers are happy, but it's not significantly better than the VCL
> for us Delphi programmers. 6. Lack of true 64-bit support. 7. It
> dooms Delphi to be a poor second cousin to M$ products, who for some
> reason seem to be able to keep up with the frequent release of new
> versions, while Delphi cannot. 8. M$'s updates have a habit of
> nuking the Delphi IDE about 6-12 months after its release. D1 to D7
> run happily on every version of Windows (with the exception of D1 on
> Win64). D8 runs on no version, and D2005 is not much better. Sorry,
> when I spend a kilobuck or so on a dev tool, I want it to continue
> working for a few years. 9. What does it let me do that I cannot do
> with D7 ? Answer: buggerall. Or to put it another way, it has a lot
> of nice features, but little or no added capability.
I might disagree with the order, but I can't fault the list ;-)
Ian
Eric Grange
> product bending to accomodate the .NET stuff (and vice versa), with the
> result being less than optimal - for BOTH products.
Jack of all trades, master of none.
Eric
Rudy Velthuis [TeamB]
Could be. Did you have some examples in mind?
--
Rudy Velthuis [TeamB]
"Genius may have its limitations, but stupidity is not thus
handicapped." -- Elbert Hubbard
I.P. Nichols
>> product bending to accomodate the .NET stuff (and vice versa), with the
>> result being less than optimal - for BOTH products.
Please explain how you would optimize BOTH products keeping in mind that one
totally depends on the other?
> Jack of all trades, master of none.
Life is a compromise!
A Nielsen
> A Nielsen wrote:
>> I think it's very simple. Either you go Microsoft all the way or you
>> have something valuable that makes a difference.
>
> It might be for you, but my world isn't black/white and in this case
> .NET has many shades of grey.
Don't misunderstand me. I didn't mean to only use Microsoft tools or
not. I meant that you need to have some advantage if you want to compete
with Microsoft. If you only want to make a plugin for VS is a different
matter.
Brian Moelk
> Don't misunderstand me. I didn't mean to only use Microsoft tools or
> not. I meant that you need to have some advantage if you want to compete
> with Microsoft.
Certainly, but what I meant was that CodeGear needs to find a way to do
that in .NET and it doesn't mean choosing between extremes of "Microsoft
all the way" or nothing .NET.
> If you only want to make a plugin for VS is a different
> matter.
Not sure where this is coming from, Chrome is one thing, Delphi for .NET
quite another. But just as Chrome supports Mono, Delphi for .NET can as
well.
Mono isn't Microsoft, but it is .NET. It might not be 100% "MS Windows
.NET", but it is .NET. This has nothing to do with Microsoft Tools
(i.e. VS.NET) and everything to do with Delphi's shortest path to *some*
cross platform capability.
IOW, there's a whole range of things a company can do to provide value
above and beyond what Microsoft is doing for .NET.
David Erbas-White
No, it's a cabaret, old chum...
David Erbas-White
Steve Thackery
> same thing .. they way they want to accomplish it ???? No Thanks !
Well, .NET is supposed to improve developer productivity, and in particular
to make it easier to target your application at a Web server as well as the
Windows desktop with almost identical code.
It is supposed to reduce the considerable risk of bugs in memory management
by offloading some of it to the run-time.
It also allows people to use different languages in the same project and the
same development environment.
I think it does all of those things quite well. Whether any of them are
important to you is, of course, your call.
Just to repeat something you said:
> Dot Net adds what ???? more machine cycles required to accomplish the
> same thing .. they way they want to accomplish it ???? No Thanks !
Exactly the same argument can be said for rejecting high level languages in
favour of assembler. Everything you can do in Delphi you can do in
assembler, and in most cases for fewer machine cycles.
Bearing in mind that these days machine cycles are the least of your
problems, and issues like time-to-market are more challenging than ever, can
you now see the flaw in your argument?
SteveT
Craig Stuntz [TeamB]
> > Dot Net adds what ???? more machine cycles required to accomplish
> > the same thing .. they way they want to accomplish it ???? No
> > Thanks !
>
> Exactly the same argument can be said for rejecting high level
> languages in favour of assembler.
It's also demonstrably true for Ruby, Haskell, and probably anything
which runs in Windows.
Nathaniel L. Walker
> that in .NET and it doesn't mean choosing between extremes of "Microsoft
> all the way" or nothing .NET.
/Agreed, but what is there to do in .NET that Microsoft hasn't already done?
> Not sure where this is coming from, Chrome is one thing, Delphi for .NET
> quite another. But just as Chrome supports Mono, Delphi for .NET can as
> well.
>
> Mono isn't Microsoft, but it is .NET. It might not be 100% "MS Windows
> .NET", but it is .NET. This has nothing to do with Microsoft Tools
> (i.e. VS.NET) and everything to do with Delphi's shortest path to *some*
> cross platform capability.
>
> IOW, there's a whole range of things a company can do to provide value
> above and beyond what Microsoft is doing for .NET.
Mono is a joke in the eyes of many, compared to Microsoft's .NET.
Or maybe this has to do with that cross platform humbug. Seriously, no one
at CodeGear really cares about that. Best thing to do is use Delphi for
Win32, and if you are doing primarily .NET development move on to where the
grass is greener and use alternative/better tools. .NET + C++/CLI is doing
me justice. VS2008 is the best IDE I've ever used to date. Quick like
lightning.
IanH
> IanH wrote:
>
> > Rudy Velthuis [TeamB] wrote:
> >
> > > Michael Anonymous wrote:
> > >
> > > > Another core issue is that WORKING on a Delphi for .NET
> > > > takes away time from other activities like working on a Delphi
> > > > Win64.
> > >
> > > Not necessarily a negative thing. The fact that there are two
> > > products now means the codebase must be streamlined and that
> > > certain spots causing "cross-platform" problems (between Win32 and
> > > .NET) must be identified and changed anyway. This very likely
> > > eases the transition to Win64 as well, since the problematic
> > > spots for such a port (e.g. code assuming something about the
> > > size of a pointer, or a char, or assuming a specific Win32
> > > feature, etc.) will already be identified and updated.
> >
> > It could also mean that compromises have to be made, with the Win32
> > product bending to accomodate the .NET stuff (and vice versa), with
> > the result being less than optimal - for BOTH products.
>
> Could be. Did you have some examples in mind?
Not specific ones - that's why I said 'could'. My concern is that
Delphi accumulates excess weight needed to maintain the level of
compatibility between Delphi for Win32 and Delphi.Net, with the result
as Eric said: Jack of all trades, master of none.
Brian Moelk
> /Agreed, but what is there to do in .NET that Microsoft hasn't already
> done?
That's what CodeGear needs to figure out. I have my ideas, but it's
CodeGear's product.
I think a cross platform .NET or a mixed mode compiler would be
appealing to a certain niche.
> Mono is a joke in the eyes of many, compared to Microsoft's .NET.
And a viable alternative in the eyes of some. CodeGear will never have
a mainstream .NET product; the best they can hope for is a profitable niche.
> Or maybe this has to do with that cross platform humbug. Seriously, no
> one at CodeGear really cares about that.
That's the problem. I think they just give lip service to it and aren't
really committed to doing it.
> Best thing to do is use Delphi
> for Win32, and if you are doing primarily .NET development move on to
> where the grass is greener and use alternative/better tools.
Agreed.
> .NET +
> C++/CLI is doing me justice. VS2008 is the best IDE I've ever used to
> date. Quick like lightning.
Would a Delphi mixed mode compiler be appealing to you?
Andre Kaufmann
> Yes, and those technical restrictions were introduced by the same company
> that brought us .Net and the 640K memory limit in DOS and the "fake" Window
Don`t you blame the software vendor for hardware restrictions ? A20 Gate
for example still exists on modern PC's, same as real mode.
And why had DRDOS the same restrictions for example ?
> [...]
What benefits do I have using Webbroker / Websnap over IntraWeb or
ASP.NET using web services as underlying communication technology.
And how do I run code on the client side of the browser ?
>
> I dont see how we can have confidence in the same company that brought us
> the technology that had "restrictions" that the next version of their stuff
> tries to solve.
Then you effictively shouldn't have confidence in Windows technology at
all and develop for Linux or Mac ?
> Real men write real code that doesn't encode to a fake runtime.
Real men write do only optimize, where necessary and even assembly code
is needed sometimes.
>
>
> Sorry .. I'm venting ..
If you need to, no problem.
Craig Stuntz [TeamB]
> Real men write real code that doesn't encode to a fake runtime.
Be sure to tell Steve Yegge that he shouldn't have ported Rails to
JavaScript since it would threaten his masculinity.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
Brian Moelk
>> Real men write real code that doesn't encode to a fake runtime.
>
> Be sure to tell Steve Yegge that he shouldn't have ported Rails to
> JavaScript since it would threaten his masculinity.
...and Ruby itself is interpreted. Oh no, I'm a virtual man now. :)
Andre Kaufmann
> [...]
> So... For what you need .NET?
Additionally have a look at the thread named
"C++ Library needed in Delphi App".
Then you have one of the many answers.
Andre
Paul Klink
> Paul Klink wrote:
>>> The core issue is that Delphi for .NET is simply not the best tool for
>>> developing .NET applications.
>> But it is the best tool if you want to use the same code base across
>> both Win32 (thick GUI clients) and ASP.NET (Web Applications).
>
> IMO, this is a bit of an edge case as often times SOA/webservice
> integration and even interop techniques can solve this problem if it
> actually exists in the first place.
It certainly is a business requirement where I work (to have a thick GUI client for one market segment and a web version
of our application for other market segments).
>
> But yes, if one has an existing Delphi codebase and needs to port that
> code to .NET, Delphi for .NET is the best tool for that job. But if one
> is starting a new project and ASP.NET is the web development framework
> of choice and there is a GUI part, IMO, it's better to do the whole
> thing in .NET using WinForms for the GUI.
Problem is that a Win32 GUI client will have better performance than a .NET one. This can be quite an important factor
in a competitive environment.
>
> There are some concerns in using Delphi for .NET to bring existing code
> forward for ASP.NET. Depending on what that code uses, trust
> priviledges might need to be altered for deployment:
We have successfully modified our code so it can be used for both a Win32 application and a ASP.NET web application.
The major issues we had to address were:
1) Separating the visual from the non-visual code (and minimising the code in the visual units)
2) Modifying the approach to using threads so it works in both environments.
The beauty of this approach is that when we add a new feature to either the web or client GUI application, it does not
require that much work to add it to the other one.
Paul
Marco van de Voort
> Delphi is relying more and more on the .Net platform.
> A lot of people are unhappy with that.
>
> The story is :
> - Delphi for Win32 relies on the Microsoft Windows Libraries.
which are available on all windows versions and always installed. The core
is pretty much version independant (except for unicode and real original
win95).
> - Delphi for .Net relies on the Microsoft Libraries.
Are not always installed, and in multiple versions.
To be honest, I don't care that much for Delphi (as a user), as long as the
result is stable and not to sluggish.
For the generated apps, the situation is different. One of the reasons why I
use Delphi is that I want to be able avoid the deployment problems that come
with runtimes. For some projects that doesn't matter, for some it does.
Brian Moelk
> So what's is Delphi missing in those other areas that means it doesn't
> hit the sweet spot ?
It appears that Jim Douglass sees a sweet spot for Delphi as well:
http://www.sda-asia.com/sda/interview/psecom,id,110,srn,3,nodeid,1,_language,Singapore.html
"In the past couple of years, we have been increasingly trying to
address a broader set of developer problems with these tools. By
continuing to broaden the focus, we have begun to stray from their core
competency. Delphi and C++ Builder are the best tools on the planet for
developing GUI rich desktop and client/server applications. We are very
focused on ensuring that we maintain their best in breed status in this
fertile niche rather than trying to expand beyond their sweet spot. We
have other tools in our portfolio to address challenges outside of the
desktop and client/server domain."
Hmm, what were those things they tried to do to broaden the focus?
John Moshakis
I saw that and I think he is wrong :)
Going back to the original message I responded to, you said
"Fourth, .NET is focused on competing
with Java; its sweetspot is server side development"
Java's sweetspot may be server but I'm not sure thats the case with
dotnet. Microsoft seem to be moving ahead on all fronts, desktop, web
and mobile using dotnet.
I think it would be a mistake to not target the dotnet platform at
least on Windows.
Delphi and C++Builder target Windows development, from where I sit most
of the api's developed by Microsoft for writing business related
applications are in dotnet.
wwf, wcf, ado.net, linq, wpf etc
I would like to think that Jim was thinking of CodeGears adventures
with linux, csharp and winforms but I'm not so sure.
Cheers,
John
Brian Moelk
> I saw that and I think he is wrong :)
I wonder what the rest of the Delphi team thinks.
> Going back to the original message I responded to, you said
>
> "Fourth, .NET is focused on competing
> with Java; its sweetspot is server side development"
>
> Java's sweetspot may be server but I'm not sure thats the case with
> dotnet. Microsoft seem to be moving ahead on all fronts, desktop, web
> and mobile using dotnet.
I agree, but the target for .NET is clearly Java. As I'm sure you know,
Java is also moving forward on all fronts: desktop, mobile, etc.
> I think it would be a mistake to not target the dotnet platform at
> least on Windows.
Agreed.
> Delphi and C++Builder target Windows development, from where I sit most
> of the api's developed by Microsoft for writing business related
> applications are in dotnet.
>
> wwf, wcf, ado.net, linq, wpf etc
Mixed mode compiler would be a better fit for Delphi.
At this point, there is no reason to choose anything other than what
VS.NET offers for .NET development for the latest/greatest and third
party integration.
> I would like to think that Jim was thinking of CodeGears adventures
> with linux, csharp and winforms but I'm not so sure.
Maybe we should email him. :)
John Moshakis
>
> At this point, there is no reason to choose anything other than what
> VS.NET offers for .NET development for the latest/greatest and third
> party integration.
Its a shame that most people seem to think this, because in my opinion
you only have to look at Steve Shaughnessy's blog for example for
reasons why Delphi is such a powerful platform on which to develop
applications that leverage the windows platform.
>
> > I would like to think that Jim was thinking of CodeGears adventures
> > with linux, csharp and winforms but I'm not so sure.
>
> Maybe we should email him. :)
Yes I was thinking of that
Cheers,
John
Brian Moelk
> Its a shame that most people seem to think this, because in my opinion
> you only have to look at Steve Shaughnessy's blog for example for
> reasons why Delphi is such a powerful platform on which to develop
> applications that leverage the windows platform.
Care to provide any specifics?
ISTM, that the notion of a "super platform" is only super if it can
actually leverage all the .NET goodies properly. There is simply no way
for Delphi to keep pace with .NET development, they *just* added 2.0
support. IOW, it's a nice thought in theory, but IMO, in practice
Delphi for .NET is not the optimal solution for .NET development.
>> Maybe we should email him. :)
>
> Yes I was thinking of that
Would you like to email him, or should I?
I.P. Nichols
> Brian Moelk wrote:
>>
>> At this point, there is no reason to choose anything other than what
>> VS.NET offers for .NET development for the latest/greatest and third
>> party integration.
>
> Its a shame that most people seem to think this, because in my opinion
> you only have to look at Steve Shaughnessy's blog for example for
> reasons why Delphi is such a powerful platform on which to develop
> applications that leverage the windows platform.
Could you be more specific and point out which of his blog posts you are
referring to that make such a compelling story for Delphi for Net as a
powerful competitor to VS-2008?
John Moshakis
> John Moshakis wrote:
> > Its a shame that most people seem to think this, because in my
> > opinion you only have to look at Steve Shaughnessy's blog for
> > example for reasons why Delphi is such a powerful platform on which
> > to develop applications that leverage the windows platform.
>
> Care to provide any specifics?
>
I think this one is probably my favourite
http://blogs.codegear.com/steveshaughnessy/2007/02/16/31865
although the dbexpress metadata one is a close second.
From what I can see in the newsgroups and the fact that ms are still
actively pursuing vb6 developers and wooing c++ developers alot of
people want to develop in unmanaged code. I imagine alot of people want
to do both and others want to whats best for the situation. I would
also think there is another group that doesn't want to be totally tied
into the Microsoft stack.
Steve's posts shows that Delphi can much handle all of those in an
elegant fashion.
>
> ISTM, that the notion of a "super platform" is only super if it can
> actually leverage all the .NET goodies properly. There is simply no
> way for Delphi to keep pace with .NET development, they just added 2.0
> support. IOW, it's a nice thought in theory, but IMO, in practice
> Delphi for .NET is not the optimal solution for .NET development.
>
I'm of the opinion that the Borland management of the business was
hindering progress. You only have to look at the stuff they have
developed since the split. For example the Rails IDE, php, Blackfish
and so on.
It's not going to be possible to leverage all of the platform because
of sheer size, so its best to pick your battles. Like for example just
vcl.net for desktop development rather than that and winforms .
I was reading this post today
http://weblogs.asp.net/rhoward/archive/2007/12/07/microsoft-access-or-sq
l-server-express.aspx
Talking about sql server express and how its not suitable for "massive
shared hosting"
CodeGear has Blackfish which I would think is ideal for this kind of
scenario. I think they should be pushing it more.
>
> >> Maybe we should email him. :)
> >
> > Yes I was thinking of that
>
> Would you like to email him, or should I?
Its probably best if more than one person emails him.
Bruce McGee
> ISTM, that the notion of a "super platform" is only super if it can
> actually leverage all the .NET goodies properly. There is simply no
> way for Delphi to keep pace with .NET development, they just added 2.0
> support. IOW, it's a nice thought in theory, but IMO, in practice
> Delphi for .NET is not the optimal solution for .NET development.
True, Microsoft will always take advantage of the latest .Net features
first, and I have to admit that language features like LINQ look
interesting. I haven't started using it full time, but VS2008 looks
really good, too.
And I have thought that ASP.Net is one of the crown jewels of the .Net
platform since I first saw it demonstrated years ago.
Then again, .Net isn't always the optimal platform for my development.
I use and like C# and Visual Studio, but they still aren't my first
choice for any project, and they won't be until Microsoft catches up to
CodeGear (and Borland before that) on some of the things that are most
important to me.
--
Regards,
Bruce McGee
Glooscap Software
I.P. Nichols
>
> I use and like C# and Visual Studio, but they still aren't my first
> choice for any project, and they won't be until Microsoft catches up to
> CodeGear (and Borland before that) on some of the things that are most
> important to me.
And in the .NET domain those things are...
Brian Moelk
> I think this one is probably my favourite
>
> http://blogs.codegear.com/steveshaughnessy/2007/02/16/31865
Right. I read that post. Honestly, I don't see anything *specific*
there that makes me want to choose Delphi for .NET development.
"Delphi on the other hand is more of a proper managed app when executing
under .net and a proper native app when executing under the native win32
platform. For example, Delphi will use .net memory management when
executing on the .net platform and Delphi will use the existing highly
optimized native memory management when executing on the win32 platform.
To me this an important feature that makes Delphi a “super platform”."
Sorry, to me, this isn't an important feature. What is important is to
have the *best* solution for native and/or the *best* solution for .NET.
It's very simple really.
A super platform must be *super* on all the platforms it targets.
Especially if we're talking about .NET and Windows, since in most
people's minds .NET is viewed as a Windows-only technology. If CodeGear
were to embrace Mono whole-heartedly, as a *real* target of their "super
platform" we would have a bit more to talk about.
"Microsoft with enormous R&D resources could not achieve this kind of
cross platform support for VB. Delphi just turns out to be better
suited as a super platform."
This assumes that MS wanted VB.NET to be backward compatible with VB
classic. They intentionally, by design, broke language compatibility.
Whether or not that decision is a mistake is for another discussion.
> although the dbexpress metadata one is a close second.
FTR, I think CodeGear needs more people like Steve, however you're
talking about one specific area that Steve had to spend a lot of
time/effort to clean up and fix.
The fact that Delphi's dual pronged compilation works well for Steve
doesn't mean that application developers have the same requirements and
needs. In fact, I would argue that they don't. I'm a firm believer in
eating your own dogfood, but as Chris Benson discusses in:
http://chrisbensen.blogspot.com/2007/11/upgrading-delphi.html
They do use Delphi differently than we use it. And remember that Delphi
is a Win32 application with .NET hosted in it. This isn't exactly
eating their own dog food when it comes to what Steve describes as a
"super platform".
I suppose eating their own dogfood in this way was why they developed
unmanaged exports and other interop things like that; it's a shame they
didn't go whole hog and build a mixed-mode compiler. Most Delphi
developers have Win32 applications they aren't going to compile straight
through to .NET...just like CodeGear with Delphi.
> From what I can see in the newsgroups and the fact that ms are still
> actively pursuing vb6 developers and wooing c++ developers alot of
> people want to develop in unmanaged code. I imagine alot of people want
> to do both and others want to whats best for the situation. I would
> also think there is another group that doesn't want to be totally tied
> into the Microsoft stack.
Sure, but I think this has much more to do with the hindsight Steve
mentions:
"I think when the .net framework first came out, many people thought it
would replace most interest in developing native applications. This
thinking proved to be wrong."
Essentially, MS has large customer base that remains useful (in some
way) to service and keep on Windows.
> Steve's posts shows that Delphi can much handle all of those in an
> elegant fashion.
IMO, it's not sufficiently detailed to demonstrate that. All Steve
talks about is high level stuff and how Delphi is distinctive. The
problem IMO, is that Delphi isn't so elegant on .NET.
> I'm of the opinion that the Borland management of the business was
> hindering progress.
I would agree to some degree, however some of that culture is still in
CodeGear, and without the infusion of a separate company it perpetuates
that stuff more.
It certainly could be worse, but that would depend on who acquires CodeGear.
> You only have to look at the stuff they have
> developed since the split. For example the Rails IDE, php, Blackfish
> and so on.
The new products are welcome, however they haven't been proven and these
things have little to do with Delphi and the future direction CodeGear
wants to take Delphi.
If we look at the roadmap, there's some things being addressed
adequately IMO, and other things not so much.
> It's not going to be possible to leverage all of the platform because
> of sheer size, so its best to pick your battles. Like for example just
> vcl.net for desktop development rather than that and winforms .
I agree, but that's the problem. There is no assurance that CodeGear
will pick the things I need from .NET going forward. Say for example,
I'm really interested in the new MVC framework using SubSonic. Do I
believe that CodeGear is going to embrace that? Or do I think they'll
stick with ASP.NET "classic"?
> I was reading this post today
>
> http://weblogs.asp.net/rhoward/archive/2007/12/07/microsoft-access-or-sq
> l-server-express.aspx
>
> Talking about sql server express and how its not suitable for "massive
> shared hosting"
The blog is about developing a specific CMS that is looking to minimize
hosting costs for their users.
I'm sorry, but *real* SQL Server hosting isn't that expensive. You can
get it for $10/per month.
> CodeGear has Blackfish which I would think is ideal for this kind of
> scenario. I think they should be pushing it more.
It's not going to happen.
First, the licensing terms of BlackFish are unknown and will likely be
more complex than the virtuall free alternatives like Access or SQLite.
Second, it's likely that BlackFish licensing will turn out to be more
expensive than SQLServer for ISPs anyway.
Third, ISPs will do what their customers want and I really doubt that
BlackFish is going to be what a sufficient number of customers want.
Besides, for .NET there is only one standard vendor: Microsoft.
But if it's cheap enough to deploy, hosting companies don't have to do
anything to support it since it's just .NET. Customers that want
BlackFish can use it, so we'll see how successful BlackFish becomes.
IMO, it's not going to be very successful unless there is really good
licensing terms.
> Its probably best if more than one person emails him.
I sent mine.
Brian Moelk
> Then again, .Net isn't always the optimal platform for my development.
I agree 100%. But for those things that .NET is optimal, VS.NET is my
choice.
> I use and like C# and Visual Studio, but they still aren't my first
> choice for any project, and they won't be until Microsoft catches up to
> CodeGear (and Borland before that) on some of the things that are most
> important to me.
I think I.P. asks the relevant question here.