Last Friday I watched a presentation by David I and Andreano Lanusse on the upcoming Tiburon.
I did not get really excited whit any of the features discussed.These additions – VCL enhancements, DataSnap, Generics, Unicode support, ribbon control and etc. – are useful but not earth shattering.

The only featurei in Tiburon that I would consider worth upgrading was Unicode support. In my opinion the Unicode feature was long overdue.

But what about the future? In looking at the Delphi road map I see that Commodore will bring 64 bits to Delphi – cool. But is that all?

Only beyond Commodore I see features that turn my inner geek on. I’m talking about cross compilation and development for PDAs. I favor a future where the OS is irrelevant and I can sell my product to all customers that want to buy it.

But enough about what I think. What would you like to see in the next versions of Delphi?

What do you think is missing on the road map? Please share your opinion with us.

16 Responses to The Delphi road map – are we on the right road?

  • C Johnson says:

    Top feature I want to see : Linq, Second feature: List/arrays as data sources (and of course, extended RTTI to support both). Honestly, without Linq, I see Delphi becoming a less relevant language as time goes by. Why should I keep wasting time writing code for data management, sorting, sifting etc when there is a great tool that already does the trick AND unifies accessing SQL data and local data structures PLUS the benefits of strong data typing at compile time? Linq is a can’t do without feature for the language over the next 5 years – I hope someone at CodeGear gets that soon (or is it a matter of EGO and bitterness over Anders’ defection to MS a decade ago causing an avoidance pattern?).

    IDE extensions : Either give us perl v5 capable regular expressions or allow the ability to plug in third party editors some how. The limited search & replace technology that has really grown from the early 90ies is painfully limited.

    PDA support – I suspect it would get about the same reception as Kylix did. I think that boat has long since sailed. Anyone that needed a PDA solution has long since found one, and with the price of UMPCs failing day by day, PDAs are a dying breed.

    Target any OS? Pick the 4 controls (label, button, check box, edit box) that are most likely to work on most platforms and lockdown the interface so no one can extend it – then you might stand a chance, but I suspect it would be a hell of a hard sell. Anything more would require recreating the JAVA VM and since you already have a product that works on the java vm….

    With Mac OS’ rising popularity, perhaps it would be viable as a specific target (VCL is great for win32, and I would have expected Kylix should have shown the futility of trying to extend it to other platforms, but the VCL.NET foolishness makes me worry that CodeGear would try to make a VCL.Mac – a disasterous mistake in my mind)

    Incidently, I do consider the concept that the IDE would remain a win32 app to be a seriously strange choice. If the win32/win64 rtl/vcl path is identical then it’s just the debugger that would hold it back – take the extra step, make a 64bit version of the IDE. Who knows how much longer win32 is even going to be around?

  • william says:

    I prefer .NET CF & full first class support of C# (got too much bad experience using Delphi .NET with ECO on BDS2006 IDE). ECO for Win32/64 (or at least Bold) would be nice.

  • Jolyon Smith says:

    If you REALLY are “wasting time writing code for data management, sorting, sifting” then you need to revise your skills and practices, not your tools.

    LINQ is a great time saver for those who cannot be bothered to invest in a bit of up front infrastructure and can’t wait to start writing real code and then complain that there is no infrastructure to take care of the tedious parts of the code they are writing.

    At the same time of course, LINQ further removes your code from the data it works with and the runtime environment it is running in.

    That’s great as long as the supposed dynamic targetting of LINQ is working for you, but if (rather: when) you have a situation where performance or behaviour is not as you would have expected – or worse, is not as is required – then you are going to have a much harder time addressing that.

    When you look at some LINQ code, the great thing is you don’t need to know the implementation details. The problem is, you cannot tell what the implementation details will involve.

    And as I’ve said before, quality software is ALL about the implementation details.

    That is what software development is about – converting ideas and specifications into usable, working solutions.

    Let Business Analysts and user work in terms of intent. Software developers HAVE to get closer to the problem than that.

    As for the notion that LINQ is a “can’t do without” feature. What utter poppycock. we’ve done without it for the last 5 years, so the empirical evidence is that LINQ is not a must have at all.

    Furthermore, LINQ hasn’t yet existed for 5 years, so whether it proves to have the legs that some people believe is still far from certain.

    LINQ for SQL is a good case in point where the initial excitement will likely soon wear off.

    It’s great for an existing, stable DB schema. But aiui if your schema is an evolving one then you go from:

    Change DB schema
    Change Code

    to

    Change DB schema
    Re-synch LINQ model to schema
    Change code

    So far from saving you any time – in such a scenario – it actually adds work. Which isn’t even to mention the additional runtime overhead added by conversion to expression trees and the simple addition of extra layers between code and data that is entailed.

  • Well, it will all depend on your needs. We´ve being looking for DataSnap to be improved and Unicode is on great timing.

    Linq, well, not a decisive factor for us. ASP.Net improvements yes, adding support of datasources and datamodules for .Net so we can use them there will be fantastic. I think it is also too soon to start talking, they are about to release a new Delphi, which has a biiiig amount of changes (Unicode itself is huge). I prefer them making sure it works properly, and then surprise us with more.

  • Lars Fosdal says:

    I mostly agree with C Johnson here. LINQ combined with an ECO ORM would be nice. I use TextPad for it’s reg.exp search/replace, but I agree – it would be good to have in the IDE. 64-bit is coming, so I don’t worry too much about that, and if they don’t do the IDE in the first go – maybe they will at a later stage.

    I don’t have a classic PDA, but I do have a Windows Mobile phone. I sat down to try to figure out what kind of applications I would want to write for it, but ended up concluding that most apps that I desired would be better off as web apps, optimized for a small display. My mobile already have all the little applets I need for notes, calendar, contacts and so forth.

    .NET – SilverLight support may come in handy, but the .NET platform is still in a state of flux with new “technologies” appearing frequently. At times, I almost wish that CodeGear would split off .NET from Delphi and start working with the REMobjects guys to offer Object Pascal and VCL in MSVS, but stating that in public might be considered as blasphemy (Ooops!)

    Linux would greatly benefit from having a Tiburylix, but the headaches of supporting a severely fragmented platform like Linux with it’s endless number of distro’s, doesn’t bode well for doing it without losing bundles of cash.

    On the point of cash… Modularizing Delphi and allowing you to “opt out” from stuff you don’t need could be interesting. Selling the “extras” separately could be a way of reducing the entry point cost. The question is if such a modular Delphi would be more costly to develop, debug, maintain and support or if it is doable.

  • JB says:

    Features that will make me consider going off Delphi 7 (upgrade) are:

    1. True VCL (No .Net required) Delphi 64bit
    2. Multi-Target Binaries (By Project Type for instance) – (Windows Native, .Net / Mono, Linux, Symbian, Java, MAC etc.)
    3. Maintain / Re-instate Delphi 7 IDE Style (optional setting), Solid Performance
    4. BDE compatible data components such as PostgresDAC, for instance.
    5. Auto-sorting DBGrids and similarly enhanced components etc.
    6. More Graphics, Music, Image Scanner, Mobile Phone and Text Editing enabled components.
    7. More Components to display more MIME types from blobs – EG .doc, .odf etc.

  • Mauricio Buso says:

    I agree with you in all. I think that Embarcadero/Codegear should focus their efforts in MultiPlatform. I want to distribute my application for all OS. I think that Embarcadero will effort on that, but the Embarcadero´s Promisse is a Delphi for .NET COMPLETE. Finally at all … will support WPF, Silverlight, Compact Framework. But .NET is not everything. I want to deploy my application on Linux, on Mac , Palm , Windows Mobile, Symbian…. things that FreePascal and Lazurus already make. Why a flock of independent developers can do, and a company of over 30 million dollars cannot? This is the reason of the Delphi´s community is losing more and better developers….

  • S Kamradt says:

    Re: 64bit version of IDE. I don’t see the reason to do this. The reason to go from 16 bit to 32 bit were obviously compiler resource driven. I don’t see what would be gained by having a 64bit version of the IDE, unless of course I needed to compile a VERY large program that needed more than the 3gb of memory to compile. I don’t believe that 64bit is always better. But should we be able to target 64bit apps? ABSOLUTELY! I’m far more likely to need to address huge amounts of memory, or need to push data around quickly. Until the world requires you to have a 64bit version of the IDE, I say don’t do it.

  • Sean says:

    I want:
    Multiple targets (IPhone!, Mac, PDAs)
    Garbage collection

  • Simon says:

    Completely agree with JB (August 4th, 2008 at 2:11 am).
    Get rid of the .NET . Codegear should not copmete with Mircosoft on their own ground.

    .NET COMPLETE, WPF, Silverlight, Compact Framework sounds great to some people, but this will cost big efforts to be done and again Microsoft will always be a step forward of Codegear. If somebody wants to code with this technologies lets use Microsoft Visual Studio. Coregear maganers should read “The 22 immutable laws of marketing”. Understand how thay broke them and apply the Law of sacrifice to .NET

    I need VCL. Better and faster VCL. Small executables and rock solid Delphi IDE without .NET

  • Ken Knopfli says:

    The real focus should be on the details that make a programmers daily life easier. D2007 took the first steps. Keep going, CodeGear!

    M$ has long since overtaken the Delphi IDE on this front. I esp. like being able to comment your method parameters so that the comments pop up in a tooltip a great help.

    Regions are also great but need fixing and some usability issues need addressing.

    M$ also showed courage in developing C#, a new language that took the best of Delphi, Java and C/C++ and used the power of modern PCs to help the programmer. No more header files, not even a header section like Delphi needs (and which is such a time consumer as files get larger).

    CodeGear might also consider allowing VAR and TYPE declarations and BEGIN/END blocks (with local type/var scope) in the body of code; C# allows this without a second thought.

    Generics couldn’t have come a moment too soon. C#’s implementation is really good and I now grit my teeth every time I cast objects from collections in Delphi.

  • Ken Knopfli says:

    Just some comments on the Multiplatform idea: Kylix showed how illusiory that is. The promise of writing code once and compiling to the platform of your choice simply doesn’t work beyond fairly trivial programs.

    Basically, you end up with a compiler that supports your familiar Pascal/Delphi syntax, but you still face a really large learning curve to understand the new OS way of working that, to learn a language native to that platform is trivial by comparison.

    Yes, a library can go some way to shield the developer from the platform, but only by introducing inefficiencies, so you will lose the speed and comfort that you have come to know in Delphi.

  • Lars D says:

    There are basically 2 kinds of options:

    1) Extend, support new stuff
    2) Enable our existing stuff to run on current and future market platforms

    64-bit Vista is rushing in right now, with 8GB RAM laptops available in more and more shops. Therefore, 64-bit support is a huge help when marketing products made using Delphi.

    .net compatibility of source code is important in order to keep business logic the same. It’s always the business logic that is most expensive to develop.

    New platforms could be mono. It would be cool to see some official support for it.

    Personally, I would love automatic but deterministic deallocation of objects in Win32/Win64. If “automatic without determinism” is much easier, then that would also be ok – mainly in order to support better crossplatform programming (win32/.net).

  • I’d like to continue to see more improvements on the Win32/64 front, I’m not much into .net but I have one .net CF app – PDA support for Delphi would be good. Continuing the trend of increased stability with each Delphi release would be good.

  • Sanjip says:

    Re: 64-bit, and C Johnson’s parting question:
    Windows Server 2008 R2 (due out possibly as early as mid-2009 — see http://blogs.zdnet.com/Bott/?p=545) will be 64-bit only. Release date for ‘Commodore’ & 64-bit support seems to have been slipping. Can anyone comment on how committed are the plans, and dates, for 64-bit support?

  • brass says:

    How come the Commodore IDE remains 32-bit? Does it mean we can’t debug 64bit apps?

Leave a Reply

Your email address will not be published. Required fields are marked *

Login with Facebook