[Estimated Reading Time: < 1 minutes]

I have elevated this comment from David I in a previous post, to the status of a post in it’s own right, in order that it might elicit the suggestions from readers/commenters that David seeks. I have adjusted the opening wording to make more sense in the context of a post, but give full credit to David I for kicking this off.

I shall be responding myself shortly, but in the meantime, here’s the chance for others to contribute to an interim, ad-hoc “Delphi Survey” of sorts. 🙂

David I thought it would be great to have a post with product feature suggestions for Marco to focus on. He suspected that we might see a few of the following (in no particular order):

  1. Delphi ORM
  2. Additional features for DataSnap: security, load balancing, fail over
  3. Un-dockable form designer for VCL and FMX
  4. Improved code optimization
  5. Native control support for iOS/Android/etc
  6. MVC for Web App Development
  7. Dependency Injection Framework
  8. BiDi: better support in VCL, add support in FMX
  9. Accesssibility support in FMX
  10. IDE options, packages migration when installing new version
  11. Remove Package/Component compiler version dependencies
  12. Parallel / Concurrency support
  13. Garbage Collection

On your marks, get set…. GO!

[With apologies to those who already responses inline to the comment on the previous post – would you mind resubmitting to this one to kick things off ? Again ? :)]

129 thoughts on “Suggestions for Marco … ?”

  1. There is a gap to fill – GUI native applications. Currently I’m not using Delphi because there is no free version. And don’t want to make money from free versions, it could be free for non-commercial projects or something like “Starter for Free”. There are a lot of developers who write programs for free or who are not sure if they will earn any money from experimental software they write – free version would be helpful in this situation. And then, if program sells very well, IDE could be updated. There are a lot of business models you can follow – free for non-commercial use, extra tools in paid version (useful: profiler, memory debugger, version control connector, VCL source codes etc), limited free version (no support for extra compiler steps, no code metrics, 32bit version only).

    Without free version:
    – no one will learn it (for money? pls)
    – free component / tool environment is not being build
    – C# is a strong competitor (when you forget about .NET requirement for a moment)

    Second thing is that native Delphi in any version could support Linux from tomorrow – just using FPC (or other user-provided) compiler for Linux cross-compilation – at least for console projects.

    (former GExperts submitter)

    1. You can do all of that with lazarus.. You can even cross
      Compile Linux apps on windows or cross compile win32 on Linux.

      1. Why are people so desperate to push people to use a competitor rather than encourage them to get hooked on Delphi (and envisage ways that might be achieved) ?

        It really is as if the current Delphi community is positively afraid of new people joining in.

        Just close the doors, batten down the hatches, and keep jacking up the fees to the current members to offset those who do manage eventually to tunnel their way out of the ghetto.

        1. Exactly, if borcadera made it more accessible then
          lazarus would not be as desirable, but as it stands now
          Even the pro version is starting to get out of reach of
          Mere mortals, why should someone fork out a grand and the
          480 per year to get bug fixes when you can do everything
          You need to do for the most part in lazarus? I mean seriously
          Why should we make Embarcadero’s ceo richer than sin?

  2. Give the possibility to make the executable files smaller even if this means considerable manual intervention by the developer.

  3. Give the possibility for local de-referencing. There are many suggestions how the WITH statement can be fixed in the QS, and other languages have solutions that work much better, e.g. VB6 and C# has a variant of the “using” statement.

  4. It’s the daily things. They may not look spectacular on a new-features sheet but that are true productivity drivers: Refactoring, Code Completion, Help, intelligent autoindenting – that kind of thing. Visual Studio with C# does these so much better.

    …oh, and if a great productivity booster is implemented, shout it from the rooftops! There was a modest “why you really should consider moving from D7 to D2007) whitepaper some years back. I think you even needed a login to access it!

  5. Bring back referenced objects with local scope. They behaved as if they were on the stack. This was removed around BP7/D1 and now we only have heap objects which must be remembered to be destroyed manually.

    Local-scoped objects go a long way to reducing the imperative for a GC and were one of the day-by-day timesavers I valued.

Comments are closed.