Frameworks such ASP.NET MVC, Prism (that is the framework for building apps in WPF /Silverlight, and not Delphi Prism, the object pascal language for .NET) help drive that adaptation and acceptance of the MS technologies quicker because Microsoft makes it more accessible by giving developers the guidance on how best to use it in real world problems. It definitely gives more guidance than just a “fish-facts” demo program.

In the old days, the Delphi JEDI portal (www.delphi-jedi.org) was the first place to look for or the place to start such projects but with the slow erosion of the Delphi community, only a few projects remain active (JCL and JVCL to name the most prominent). But this was in the days when the momentum in Delphi was very strong and the competing developer tools were things like Visual Basic, Visual C++ or Powerbuilder. Borland was at the top of its game and other tools compared Delphi as the standard.

Nowadays, .NET is the standard bearer and Microsoft in their infinite wisdom has ensured the success of their tools by backing them up with complementary technologies such as the guidances and frameworks to actually solve real world application development problems. This in turn has built communities around that technology which then locks in the developers to their tools.

It’s not Embarcadero’s fault that the Delphi community is not as strong as it was as in the old days (that blame goes to the previous owners!). And it is to their credit that they are making Delphi the premiere tool that is once was by making it a more stable tool and giving developers the language features such as RTTI and generics to match other languages on the market. But Embarcadero will not succeed by just creating a better Delphi – that is only the first step in getting back the confidence of the community.

To help build the Delphi community and regain that growth and momentum, it needs to take a page out of Microsoft’s playbook and foster the frameworks and developer guidances for developing in Delphi.

There are many examples on StackOverflow where a developer has looked for an MVC/MVP framework or looked for a Dependency Injection framework for Delphi and not found much available. If you look for the same things in the .NET realm, you will find many projects that are both mature and active.

I don’t expect Embarcadero to build these frameworks but it would be a shot of confidence if they can actively sponsor, host and/or coordinate such development. They must make sure that such community projects take a prominence on their blogs and websites and that there is constant reporting on how these project are proceeding to ensure that such a start does not lose any momentum within the Delphi community.

An example of how successful this approach can be is demonstrated by Nick Hodges blog about reinvigorating the Turbopower projects (http://blogs.embarcadero.com/nickhodges/2009/09/28/39317). Although Nick’s involvement with the Turbopower components was in an “unofficial” capacity on the part of Embarcadero. It was enough to garner renewed activity for supporting these components. Unfortunately, without continuing exposure to the developer community of its progress, the projects may lose that initial interest except for a few determined developers.

Embarcadero needs to take a more paternal approach to fostering the Delphi community. Embarcardero needs to acknowledge that the Delphi community is not as big as it use to be and needs some help to get it back on its feet and give it the direction and support until it is strong enough to move on its own. Embarcadero’s involvement in community projects needs to be “official” and give the projects the backing it needs to bring the bright people together. Keep the community projects in prominance and watch as the momentum grows.

Having an official and greater involvement in Delphi community projects (similar to what Microsoft does with .NET technologies) will help Embarcadero further strengthen the eco-system around Delphi which will in turn attract new developers, bring back old developers and lock-in existing developers to Delphi.

CJ

About Indy, like I said to Jeremy the Indy team is planning new features – see Arvid’s blog here. Also, you can drop a feature request or similar in Embarcadero’s .delphi.internet.winsock forum. Remmy is floating there.

-iweb is great but is closed and is a 3rd party framework (Embarca.. should give more direct support/sponsorship here)
-page support in iweb is going to be dropped in ver. XI ?…
-wsnap/wbroker = obsolete (although basis for iw?…)
-indy is somewhere in a middle of nowhere.. (vision/status/plans)? (although being a great pack) – Embarca… should give some more direct support/sponsorship here as well…

However my guess is first go x-platform and 64bit, then later everything else…
B.

…because the interfaces are implemented at design time, then if the 3rd party (the framework provider) doesn’t provide a certain interface you should live with (or rather without) it. Of course, you can subclass, but as you know, this (also) has disadvantages.

about “If a functionality is not supported”…

Raising an Exception is good, but it will blow at runtime… hmmm…. nasty thing

?

> you must implement everything. For example

If a functionality is not supported, I prefer an explicity raised exception instad of ignoring silently a call.

an example of a non-enabling technology: operator overloading. While its cool to be able to do complex1:=complex1+complex2, its not that much better than doing complex1:=addComplex(complex1,complex2) that you could do since Delphi 1. It may be a neat shortcut, but you *could* do it relatively easily without it. Same with class variables.

However, many new things the team has done, such as: RTTI, Attributes, anonymous methods, generics are really enabling. You cannot easily build a flexible data binding technology without Attributes and RTTI (I know it has been done, but you have to use special types associated with the library you are using). The “problem” only is that these new enabling technologies have come so quickly and so recently I don’t think the community has digested and incorporated the power of these new features into their components, libraries and code examples that are on the web.

I would encourage Embarcadero to keep focusing on these. Multi-cast events, native support for aspect oriented programming, property triggers etc would all allow developers to take things in directions that are impossible to go without them. It may take a while for the community to catch up and appreciate them, but this is what will move us forward.