Community pulse: New ways to enhance Delphi

There is an interminable thread on the public.non-technical battlefield called ‘Delphi for the Mac’. At the time of writing, there are approximative 500 (five hundreds) posts on that. (493 to be more exact). No, I won’t provide a link. Because I think that is better (at least now after 500 posts) to start a concrete discussion in order to enhance our tool of choice.

Don’t get me wrong, I do think that defending a tool is good, but this defense must take the form of enhancing our product, and not denigrating the other one just because it doesn’t fit with “my/our” philosophy.

So, in my humble opinion, we must take and adapt what is good on the other product (XCode / Interface Builder in this case) and avoid what is bad. I know that you are willing to do give feedback on this, the vast majority of you proved it many times, including in the last poll which we made. The results are depicted in our classical pie on the right.

However, our community has a long lasting disease – we transform ourselves in a community of talkers in order to be a team of doers. We had this also with .NET and now it seems that we start to have it with Mac. Sons, the better covering of user’s needs through innovation is the thing which will ensure our survival.

So, in short: …and correct me if I’m wrong. 🙂

We need to have enhance the productivity of our tool. Mac “has” MVC. Ok, other languages “has” MVC. Java “has”, .NET “has”… I think that’s time for Delphi to “has” it. Yeah, I know that there are community projects which implement MVC or similar patterns but I think that for example tiOPF is (unfortunately) far enough from Delphi community core in order to say that Delphi “has” an OO framework. I speak now primarily from the cultural point of view. The death of Bold and ECO left more traumas than we thought. But about the need of having a framework in Delphi (an about other things) we spoke in What means RAD Anyway?.

…hence we will concentrate now on another aspect of Delphi which appears constantly in Delphi vs .NET and Mac debacles. It is its data binding mechanism.

There are some ways to display data on GUI artifacts:

  • Build special objects to hold the data (eg. TDataSet descendants) and special components which consume this data. ‘Nuff said.
  • Interfaces. Good but is on-premise
  • Class Signatures. Better – on-demand.
  • Bindings.
  • Attributes
  • Multi-cast Property Triggers.

Of course, all the above can be used together. Beware: I didn’t say that you should do that, though.

Perhaps the last one (Multi-cast Property Triggers) needs some explanation. If you think Delphi, think it like an event handler which is fired exactly before (or after) a property value is set. If you think database, think at a database trigger (you know, 'Before Update', 'After Update' etc.). Of course, these can be added and removed using a mechanism similar with the multi-cast events. Also, this feature will be a very good thing in implementing Design by Contract. Yeah, I know that DbyC can be achieved also using other methods but I think that one of the things which Delphi must enhance nowadays is its flexibility of expression.

Oh, and a very draft syntax: (all the ‘x’ types are custom types of the actual ones provided as drafts for discussion)

  function AddBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;
  function AddAfterTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;

  function RemoveBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;
  function RemoveBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;

…or perhaps a much more OO approach like:


  myProperty.Before.AddTrigger(aCode); //'Before' being a list with Add, Delete, Items, Count members...
  //same stands for 'After'

I do think that the 2nd approach is far superior and gives much more control on the things. Also, TxTriggerProcedure will have as parameter the well known Sender: TxRTTIProperty.

How do you envisage the data binding mechanisms of the next Delphi?

23 thoughts on “Community pulse: New ways to enhance Delphi

  1. Don’t know why, but lately interfaces got out of fashion. But IMHO they are much more elegant than, for example, property triggers. What damaged interfaces in Delphi is tying them too much to COM in the beginning, and its reference counting.

    • The problems with interfaces are:
      1.) you must plan for them. Impossible when you use a 3rd party framework.
      2.) you must implement everything. For example if you want only a read-only access then you need to implement also the setter only because the interface requires it. Of course, one can implement fake stubs just to satisfy the interface requirements but I don’t know how safe it is in a long run.

      • > Impossible when you use a 3rd party framework.

        ?

        > you must implement everything. For example

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

        • >” Impossible when you use a 3rd party framework.
          ?”

          …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 😉

  2. I think that the Delphi team would do well to continue building enabling technologies into the language. By this, I mean adding features that allow developers to do things that were either impossible, or very very difficult without them.

    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.

    • There is a huge difference in expressibility between c1 := c2 + c3 and c1 := add(c2, c3). Huge! I have tried both forms for an interval math library, and I would go so far as to say that anything beyond trivial math in undoable with function calls. This is the quadratic formula: x = divide(add(-b, sqrt(subtract(sqr(b), mul(mul(4,a), c), mul(2, a)) compared to x = (-b + sqrt(b*b – 4*a*c))/2/a.

  3. In my opinion, the Delphi (or should I say Object Pascal) language is just fine the way it is. As a software developer I’m more concerned about the fact that many third party components are abandoned, bad designed, bloatware, overpriced and / or not tested. Some succeed in combining all of this in one component…

    • Imho, a product will die when its evolution will stop. I see that you’re complaining about different 3rd party components. While, perhaps, we can discuss your point, let me ask you one question: Don’t you think that a product enhancement (in the case at hand a language enhancement) should necessary reflect on the quality of the 2ndary market?

      • For me Delphi is a tool to accomplish a task, developing business software. Looking at my recent projects I noticed the major cause for delays are crappy third party components. I need high quality, robust and tested components to stay on schedule. My customers expect me to deliver a high quality product. Enhancing the language with nice to have ‘cool’ features doesn’t really improve my productivity or the quality of my coding.

          • I’m using one of their components (no alternative) but looking at the code it reminds me of TurboPower. To much of everything. Everything but the kitchen sink.

  4. While making all of these features helps in a lot of areas there is one area that is the most neglected. That is web framework. While we do have intraweb, on the native side, it seems to have become more like Indy. The only other viable alternative at this point is to develop a service in win32 then use prism to create asp pages. I think the native side needs to take a que from the java world and build some full fledged web frameworks that can be plugged into a tomcat or jboss like server.

    • I would agree as for lack of choices/vision for web development in delphi (win32 side)…

      -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.

      • Yes, IntraWeb (or VCL for the Web as is named in the new Delphi versions) is a very good tool – but it needs enhancements. I also hope that they will push it forward, especially because it can be done in parallel (AtoZed is taking care of it) and, more important, because it will be cross-platform (on the server side) in the next Delphi version.

        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.

  5. If Embarcardero has the resources, it would be good if they could come up with a group similar to Microsoft’s “Patterns & Practices” team. These guys provide guidance to the .NET developer community on how best to use MS tools and technology. They also foster community projects to develop frameworks to help developers make the most out of their current technologies such as Silverlight or WPF.

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s