Re: Captain Jake's Top Ten List of what I'd like to see in thenextversionofDelphi

Randy Magruder wrote:
Not really. I could say the same about ECO. How many Delphi
developers are actively developing for ECO? Should Borland not invest
in ECO then? I see many people talk about how ECO is a cool idea, blah
blah blah, but really how many people are going beyond that and using
it right now?

I must have missed all the Delphi developers talking about how Delphi
for .NET and VCL.NET are cool ideas. ;)

What about the ongoing chronic (and not improving) lack of third
party control support ?

It *is* improving, just slowly, that's all. You should be able to
build a rather professional looking windows app using vcl.net
components from Woll2Woll, TMS Software and DevExpress, among others.

At the expense of being able to choose componentone, infragistics,
janus, syncfusion, purecomponents, in addition to using DevExpress
components....yeah, that makes sense.

Does DevExpress have VCL.NET components?

It sounds more like you are bashing the IDE than VCL.NET as a
technology at this point.

I can't speak for Lukio, but IMO, it's the whole package, which includes
Delphi for .NET. BDS as a whole has to keep a certain base level of
features to remain a viable option in the .NET space at all.

I agree 100% that trying to 'keep up with the endless new technology
churn from Redmond' is not a winning strategy. In my opinion, the more
of a 'copycat' DevCo's tools appear to be, the faster they will
disappear from the market. I believe that the only solution is to
address .NET as a new Windows platform, and not worry so much about
things like Windows Forms. Then build best-of-breed
languages/tools/libraries for .NET that are demonstrably better and
more productive than what Microsoft is offering. I don't think that's
as hard as it sounds.

IMO, it's hard if DevCo doesn't build on top of WinForms since I don't
believe they'll be able to get the 3rd party vendor support for VCL.NET
they had received with VCL. Same goes for C# IMO.

For all of Microsoft's evangelizing, I have yet
to see the clear productivity gains on the windows application
development side. For instance, their FCL is so convoluted with
regard to data access that Microsoft is forced to release "Application
Blocks" that wrap best practices in order to make writing solid apps
more approachable. Why doesn't Microsoft SOLVE THE PROBLEM in the core
FCL instead of writing band-aids to deal with the fact that their best
practices are not easily 'practiced' by just using FCL out of the box?
Why do we need even more class libraries to make FCL a more productive
environment. There is a vulnerability in the complexity that Microsoft
is introducing, under the pretense of making us more productive. DevCo
needs to exploit that vulnerability and create a 'wow' factor that
Microsoft isn't.

There is opportunity for DevCo there, but doing the same thing that they
did with Win32 with the VCL is not, IMO going to work for .NET. It's
just that simple.

Yes, it's true that there will be a majority of people who just
slavishly do things "the Microsoft way". but there is also room for
the mavericks who can code rings around that group because they aren't
afraid to innovate. That's a tall order, but I believe it's doable for
DevCo. The dragon's vulnerability is there, but DevCo has to get close
enough to hit it.

Sure, but VCL for .NET and Delphi for .NET don't provide this at the
moment. The thing they provide is a migration path.

..net, like it or not, is here to stay, at least according to the
analyst reports I've seen. And with Microsoft controlling the
operating system, native code is in danger. Maybe not immedaite short
term danger, but danger nonetheless. If we follow a Windows native
code strategy only, we will deserve the label of 'extinct dinosaur' in
the not too distant future, I believe.

I don't doubt that .NET is here to stay. What I believe is that VCL for
..NET and Delphi for .NET are strategically flawed. I think DevCo has a
tremendous opportunity with .NET, but I think they are at an inflection
point. I see VCL.NET and Delphi for .NET as two big albatrosses holding
them back.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Delphi Product Manager questioned
    ... BDS doesn't lock you into Windows? ... DevCo guys have always popped out with very cool things to have. ... Almost all of the Delphi developers I talk with are quite ...
    (borland.public.delphi.non-technical)
  • Re: Codegear in the news
    ... totally different programming language which shares some similarities ... Microsoft Visual Basic Compiler version 8.0.50727.42 ... developers' pleas for "cross-version compatibility". ... Are Delphi ...
    (borland.public.delphi.non-technical)
  • Re: What this mean for Borland?
    ... In any event, whether or not one believes what they are told by Microsoft, ... programmers seem to have received anything like a long-term commitment so far, ... you can take Delphi code from 1995 and still compile and use ... so "committed to developers" why did they did not mention Chrome at all on ...
    (borland.public.delphi.non-technical)
  • Re: What can .Net do for me?
    ... Most of the promises of .NET are designed for developers and ... Single-exe model (already done by Delphi), ... Microsoft is definitely trying to sell the benefits to ... As for clients, IMO, you take a few approaches. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... new DevCo guys. ... On the other hand I believe that if Delphi is back to its roots ... the only chance for DevCo to rebuild the old Borland ... investing in developers' communities and education of young ...
    (borland.public.delphi.non-technical)