Why I Choose Delphi

Many of my friends are surprised that I choose to use Delphi as my primary desktop technology, especially for Greenfield projects.

They worry that Delphi is obsolete, only used on legacy systems. I’m reminded of this rather amusing comment on a forum:

“My colleague told me to abandon Delphi, it’s obsolete, Silverlight is the future.”

I appreciate their concern, but I choose to use Delphi because it is the best technology for my needs. We all have different preferences/requirements and to paraphrase Aristotle “we like what we are good at.” But for me, Delphi is awesome. I’ll try to explain.

Native

Delphi is compiled to native code, so the performance is great. Without the overhead and inconsistencies introduced by a Virtual Machine (garbage collection, etc.) Delphi is an excellent candidate for real-time and embedded systems. The compiler is extremely quick, resulting in a fast build-debug loop, and improved developer productivity. Furthermore, deployment couldn’t be simpler as the compiler produces a single executable.

Balanced

kam

Although the Delphi compiler optimization lags behind C++, its speed is a great trade-off for all but the most demanding needs. The Delphi environment is as close to a managed environment as you can get whilst still remaining native. Object Pascal is far simpler and safer than C++ which further improves developer productivity and code maintainability. It is the perfect balance between C# and C++. The guys over at KaM Remake made the same observation, their post is well worth the read. As much as I like C++, I find I’m much more productive in Object Pascal.

Portable

Delphi can target Windows (7-10, server 2012/2016) using either the traditional VCL framework, or the more recent FMX. You can even deploy into the Windows Store. Using FMX you can target Windows, MacOS, iOS, and Android from the same code base. Thanks to FMXLinux, you can also target Linux. If you need to target more platforms, you can use Lazurus and FreePascal. You can literally target anything with Object Pascal:

“Free Pascal is a 32, 64 and 16 bit professional Pascal compiler. It can target many processor architectures: Intel x86 (including 8086), AMD64/x86-64, PowerPC, PowerPC64, SPARC, ARM, AArch64, MIPS and the JVM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/iPhoneSimulator/Darwin, DOS (16 and 32 bit), Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, Nintendo Wii, Android, AIX and AROS. Additionally, support for the Motorola 68k architecture is available in the development versions.”

Evolving

The VCL has continued to evolve. It is still a premier technology for Windows development. FMX is Delphi’s modern cross-platform vector-based graphics framework. It too is more of an evolution of the VCL to address modern cross-platform development.

“There is an evolution of technology, not constant revolution.”

Object Pascal has also evolved, offering many features expected of modern languages such as Generics, Anonymous Functions, Type Helpers, support for AOP, etc. There’s more work to be done, especially in terms of reducing verbosity, but the language is in pretty good shape and improvements are on the official Roadmap.

Versatile

You can build anything with Pascal, from compilers to operating systems, from business applications to games. Whatever you can do in C++, you can do in Object Pascal.

Component Based

Whilst I appreciate XAML and QML, I’ve always preferred component based frameworks over declarative. I find them much quicker to develop in, and much simpler to use. Component based frameworks make RAD possible, and RAD is the fastest way to build software. FMX brings RAD to the world of cross-platform development.

Awesome Software Created in Delphi

From FL Studio and Ear Master to Age of Wonders, Delphi is being used to develop great software everywhere. Every day new projects are being started in Delphi.

Delphi Rocks!

Finally, I really enjoy programming in Delphi. Sure it has it quirks, is a bit verbose, shows its age, etc. but there is something fundamentally elegant about this technology, it is always a pleasure to code in. I feel happy when I’m using Delphi. If a tool makes me happy, does the job, that’s win-win.

57 thoughts on “Why I Choose Delphi

  1. Subtitle of the article: Why you work alone.
    Because I’m guessing no companies of any size can find Delphi people to work with you. I would rather have a vestigial Silverlight scar and some background in .NET, than be limited in where I can work and who I can work with. How much can someone make writing Delphi? It’s a lot less than many other programmers.

    Like

      1. That is exactly what I mean. 110/hr is backwater in the land of consultants who code (in anything). I mean, it’s more than offshore labour, but hardly a prime rate.

        Like

      2. @CSVelocity:
        I got most of my knowledge from looking at Code Rage videos as well as simply trying to make the FM framework do what I wanted it to do. It is a bit like trying to learn to drive on the wrong side of the road, but you start to get used to it.

        Liked by 1 person

      3. Recently, one of the large scandinavian logistic and freight company purchased Delphi Rio for new development 😉
        So I guess it is not that bad, and they found Delphi programmers, also as far as I know, this is easy language and dotnet guys can also handle it.

        Liked by 1 person

    1. I have worked with several large insurance companies, a nationally known pizza chain, a large trucking company, I was interviewed for a position at one of the largest advertising companies in the country, and all of them wrote their front line tools in Delphi.

      One insurance company tried to move off of Delphi while I was working there. They asked me to research the reporting program of their front runner for replacing their Delphi application… it was a Delphi only reporting solution! This means that the best they could find was also written in Delphi.

      My normal on site rate is $125.00 per hour working in Delphi

      Like

  2. I have used Delphi originally but switched to Borland C++ with VCL soon. Somehow Object Pascal did not look as expressive as C++. That was long time ago before Borland sold it. Current pricing of the 64 bit package is way outside of my budget especially when full Visual Studio for amatours like me is free. C# with Window Froms is not that far off from VCL. The speed of C# isn;t that bad either.

    Liked by 1 person

  3. Something that might be missing is ‘glue’ between Delphi and the back-end of web-projects. Yes, there are IntraWeb and a number of platforms that try to marry IDE’s visual design with something that spews out HTML, but this almost always doesn’t quite work and takes you too far away of the real work that has to be done for a web-back-end. There’s also DataSnap that fully limits to shuttling data from here to there, and SmartMobileStudio that compiles to JavaScript, but those are different environments altogether. So I’m hoping with http://yoy.be/xxm/ to offer a decent binding for Delphi with a dynamic website’s back-end, using Delphi’s compiler speed to offer the change-F5-test development cycle like web-scripting-languages, but also have it deliver a binary DLL that’s ready to go on a live server (with IIS or Apache) and can do anything you’d expect of any other service written in Delphi (like DB access or other networking).

    Liked by 1 person

  4. “The Delphi environment is as close to a managed environment as you can get whilst still remaining native.”

    What does this mean? Is it about IR, or GC, or simply a claim about how high-level you think it is? I can think of many environments that seem closer to me to a managed environment than Delphi — for example, Haskell.

    “I’ve always preferred component based frameworks over declarative. I find them much quicker to develop in, and much simpler to use. Component based frameworks make RAD possible, and RAD is the fastest way to build software.”

    You should elaborate on this, if your aim is to reach people who aren’t Delphi users. “RAD” is a generic term that can refer to a dozen different techniques. “Component based” is also an overloaded term. I suspect that you have some specific meaning in mind here, but I don’t know what it is.

    As for productivity, there have been studies that compare speed of development in different languages — why use these attributes of the language as proxies for productivity, when we can (and do) measure actual productivity? You’re making this argument backwards: you’re asking me to believe that some X “is the fastest way to build software”, and then saying that Delphi has X. In actual measures of actual programmer productivity, it’s squarely a mid-level language. Find me a study that shows when Delphi is more productive. Don’t just throw acronyms at me.

    “Using FMX you can target Windows, MacOS, iOS, and Android from the same code base.”

    Unfortunately, applications using it look like garbage. The fonts are wrong, the spacing is wrong, the graphics are wrong. It seems to try to emulate the native platform, and doesn’t do a very good job. I wouldn’t consider using FMX to write an application where the user experience mattered.

    Like

    1. Spoken like someone who has never made serious use of FMX.

      If you try to use the graphics in FMX in the fastest way possible (IE least amount of work) then you can wind up with bad looking graphics especially while trying to use bitmaps on a list view. You have to understand the challenges of doing cross platform development before you can make the best use of it. I am using EPS graphics (vector based graphics) in my Delphi app. I use the EPS base to draw the graphics a good deal larger than what is required and use super-sampling (handled by Delphi) to place the end result. This means that it is handling not only adapting my graphic to the exact number of pixels on whatever device I am running on, but it is also handling anti-aliasing and the result is beautiful!

      It is also easy to change a compiler setting and have it run on Windows for testing, or my Samsung Galaxy S6 for deployment. It even lets me debug the app in Windows while it is running on Android 🙂

      Liked by 2 people

      1. Hi Brian, thanks for your comment. I’ve built a simple chess game in FMX and that worked out great (for desktop only – Mac/Windows), but I want to get into mobile. I’m currently using Flutter, previously Xamarin. I’d prefer to use Delphi for all desktop/mobile development. Where did you pick up your knowledge of FMX? If you can recommend a blog, book, video or resource I would be very grateful.

        Like

  5. My first full-time programming job used Borland Delphi 2, and though I have experience in C, C++, Java and various SQL flavors, it has been my favorite language. The initial advantages were database connectivity and optimized compiled code, and with use I appreciated its compilation simplicity and speed (unlike C++. rarely does it matter in which order which units reference others, and even then, it’s easy to adjust), data type checking, ease of debugging and many other virtues. Thanks to Embarcadero for enlarging on this superb development system!

    Liked by 1 person

  6. Could you elaborate on what you mean by a component-based framework (as opposed to a declarative one or some other kind)? I’d be really interested in more detail about how you are thinking about this.

    Liked by 1 person

  7. Automatic memory management is not a good thing, it is a problem! I have done both .NET and Java, both having automatic memory management. In both cases the garbage collector makes your code look TERRIBLE! There is no control over when the memory management will kick in. It always kicks in at the worst possible time, and there is nothing that the programmer can do about it.

    Liked by 1 person

    1. There are some things you can do to mitigate the problem, but you are right, ultimately it’s up to the GC. You wouldn’t want to be in a fighter jet locking onto a target when the GC kicks in lol. Most critical (esp. safety) systems I’ve worked on required C++ (such as train signaling software). In C# apart from needing to implement IDisposable, and possibly a finalizer, and wrapping it up in a Using statement, there’s not too much impact on the coding style (IMO), and it’s nice not having to track ownership of an object. The alternative is smart pointers and RAII. I’m hoping we get record destructors in the next Delphi update, that would make writing smart-pointers etc. a breeze. For the new ARC compilers that’s not a problem, but for VCL Apps it would be useful. I love how you can create classes on the stack in C++. Record destructors would effectively give us the same semantics and memory management option, albeit indirectly. It would also make a lot of utility code simple, such as using a record to log method entry/exit. Fingers crossed, c’mon Embarcadero – oh, and a brand new non-reference counted interface please 🙂 The current interfaces are awesome for COM programming, but not for general abstraction needs.

      Like

    1. FPC and Lazarus are nice, but personally I prefer Delphi. Each to his own I guess. Hopefully they’ll listen to the community and do something about the price, esp. for hobbyists, indies, and startups. A monthly subscription model would also be a good idea. Anyways, best of luck with Lazarus.

      Like

      1. @CSVELOCITY I agree. I tried using FPC and Lazarus and was not very impressed. The professional toolset of Delphi is still far superior.

        Liked by 1 person

    2. @CSVelocity: I heard Idera just acquired Sencha, another company with expensive products as well. I don’t think they will lower the price of their products, it’s more possible that they will keep or even increase the price. But, let’s hope for the best for us all.

      @Brian Thomson: I can say the same thing about Delphi. I’ve tried Delphi Starter and was not very impressed. No mobile, no web, no Linux, no 64-bit, etc… so many limitations that makes it pretty much unusable for my needs. I have to spend a few thousands of dollars to get a usable dev tool. On the other side, FPC and LazIDE offers me more complete and powerful toolset, for free. However, beauty is in the eye of the beholder, so to say. YMMV.

      Liked by 1 person

      1. I fear you may be right about the price staying the same – despite it being the number one complaint in the forums and user groups.

        Qt is not cheap, but it has much more sensible pricing – LGPL + Commercial license. There’s a special commercial price for Startups/Indies earning under 200k per year. You can also pay monthly or annually.

        Delphi Starter Edition is useful to get started, but like you say, no mobile, no database, no refactoring tools, navigation shortcuts don’t work etc. You need at least Professional + Addons to start getting the productivity benefits of using Delphi. I hope they sort out the pricing soon.

        Like

      2. @MR BEE
        Seriously?!? Delphi Starter?!?
        Delphi starter is for kids to play with to try their hand at the language. Of course if you want to do serious work you will need to have the serious toolset. That is just common sense!

        The IDE in lazarus is from the 90s, the pseudo VCL controls are incredibly outdated as well.

        Like

    3. @Brian Thomson: Yes, that’s one of the point in my blog article. Delphi Starter is just a sneak peek or a teaser. It’s not a real dev tool for creating real and professional apps. But Delphi people keep using it to answer the Delphi is expensive argument.

      About Lazarus and LCL, please… if you know nothing about the internal, don’t spread FUD. LCL isn’t a “pseudo” VCL. On the surface, LCL does look like VCL, but the internal is very different. LCL architecture is able to handle many UI managers on different platforms natively and seamlessly, by design right from the very beginning. Something that Delphi’s VCL is unable to handle at all. Hence, the FMX which, I think, is *not* a native solution.

      Like

      1. My point was not that the LCL is somehow the same as the old VCL, it just looks that old. It looks… out of date.

        Firemonkey uses DirectX when running on Windows and OpenGL when running on other devices. This means that it is incorporating the use of native video card drivers drivers that are called from native code. As a bonus, it looks far better than VCL or LCL. There are some things that you need to learn in regards to getting good results from the graphics in Firemonkey. This is why you see people comment that Firemonkey is not capable of presenting good graphics. It is. You simply have to understand the tool you are working with and use supersampling when needed.

        Like

    4. @Brian Thomson: Well, I don’t think LCL is out-of-date. As long as I can do programming with it effectively and efficiently and productively, I don’t see it as a problem. Even Delphi is still using and selling VCL as well. Today there are still many people creating new and modern apps using C/C++, something older than Delphi, just fine.

      Native in programming, as far as I understand, is not just a matter of creating native code. But also about respecting and using native and first party libraries dan frameworks. That means, in Windows using Windows API, in Mac using Cocoa, in iOS using UIKit, etc. FireMonkey doesn’t do that. An iOS button should be using UIKit’s button, not a custom drawn OpenGL button. So, its UI is not really native, but emulated.

      > You simply have to understand the tool you are working with and use supersampling when needed.

      Exactly! That’s what I also see from your argument about Free Pascal and Lazarus IDE. You don’t really understand them well enough, but you keep telling us (and yourself) that they’re bad.

      I mean, take a look at this: https://imgur.com/a/kJR2N (Lazarus v.1.6.4)
      How much different is that with the latest Delphi?

      Like

      1. LCL is not out of date if you want to write all of your own controls. The base LCL controls, just like the base VCL controls, still look like 1990s UI elements. C++ is a language, not a set of UI elements.

        In Delphi you are able to call to native code directly from Delphi. It is easier using the Java calling interface (which means not native), but there is a native layer that can be used as well. If you program your code well the code will have individual units the represent the underlying code for each OS in such a way that it is abstracted for general use, and that code will only be compiled in when compiling for that OS. I have done this with Android and seen examples on IOS.

        As far as using native controls, FireMonkey is all over that! It takes the base abstracted type and allows you to decide if you want to have the compiler automatically convert it to native types when you compile for the various platforms.

        My only gripe on using Lazarus for the one project I used it for was a problem with the drivers trying to display JPEG images, but it still showed a glaring hole in the usability of the tool for the intended target. Being able to handle simple images and display them on the screen, and count on the results, is a very basic level of capability I felt I needed to be able to count on, and Lazarus did not deliver.

        Looking at your link, I do like the newly updated IDE on Lazarus. At least they finally got away from the Delphi 5 look!

        Like

    5. @Brian Thomson: I have no problem displaying any images on my form on any GUI frameworks on any operating systems using Lazarus. And it’s as simple as drag-and-drop and put the image on. As you said, it’s a basic capability. I don’t know what your problem is.

      With Lazarus and FPC, you may as well call native code whenever you like, on any supported platforms. You can even put inline raw assembler codes if you really need to. In embedded programming, it’s quite matter. Have you ever made IoT apps using Delphi? Like, on Raspberry Pi or something. I have done it, since the Raspberry Pi 1. I can even have Lazarus running right on the Raspberry Pi. It’s not important actually, but it’s really fun! 🙂

      About FireMonkey… last time I tried, it doesn’t support native widgetset. All the UI controls are custom drawn using openGL. At least on my Mac, I found that FMX app is still using openGL custom drawn controls with Mac-look theme. Yes, the code is native, but the UI is not. I don’t know if recent Delphi version is able to use native controls.

      Comparing Delphi vs Lazarus will be a never ending discussion. Look… you may use and praise Delphi or any dev tools whatever you like, I have no problem with that. Delphi is actually a good product. The only problem with Delphi is its price. If someone could afford to purchase it, good for him/her, congratulations! If s/he couldn’t, then simply use the FPC and Lazarus combo, which in some cases is better than Delphi, especially for education. And the problem with Delphi people is they keep saying that FPC and Lazarus is really so bad. It’s a FUD, please stop it! The consequences of it, most people become hesitate to try FPC/Laz. And if these people don’t have enough money to purchase Delphi, they will pirate it. Something that I’m really against over. Piracy is bad for everyone… for Delphi, for FPC/Laz, and especially for us as professional programmers.

      Both FPC/Laz and Delphi are good, but both are not perfect either. So, can we simply respect each other, please? After all, we’re using a same language, object Pascal. That’s what really matter.

      Like

      1. @MR BEE yup both are good, and Object Pascal is awesome.

        I do think, however, that custom drawing is better than using native controls.

        FMX got some flack for that at the start, but that’s what QT does anyways.

        Google chose to do the same thing with their new framework Flutter. They looked at everything on the market, considered lessons learnt from 10 years of Android development, and chose to draw directly using OpenGL/Vulkan.

        Flutter looks really good on iOS and Android, and the performance is great.

        Like

    6. @CSVELOCITY:

      > I do think, however, that custom drawing is better than using native controls.

      This is clearly debatable. Most OS authors wouldn’t agree with you, I suppose. There are some reasons why every OSes provides native UI widgetset for the apps running on top of them. Performance is just one among other reasons, such as native look-n-feel, user experience, standardization, integration, etc.

      Of course there are some cases where custom drawn control is better. The most obvious example is game apps. Why game apps have have such privilege? Because usually game has its own “world” which also has its own look-n-feel, user experience, etc. That’s where openGL should be used.

      But regular apps live on the “world” of the OS. They should respect the world they live upon and the people who are living on that world. A proper custom drawn UI widgetset should respect that as well. Besides, why do we need to reinvent the wheel? The OS has provided us ready-to-use UI widgetset which is already optimized, integrated, and well tested.

      That’s why I prefer RemObject’s Oxygene or Lazarus’ LCL approach regarding this thing. Both are cross platform dev tools that respect each platform. And that’s also why I don’t prefer Java’s Swing, QT, FireMonkey, Flutter, or any custom drawn UI libraries/frameworks out there.

      I think a truly cross platform tool should use an LCL-like approach that’s able to provide a single common abstraction for every supported platform. However, such approach should still provide leverage to access native widgetset directly. Something that lacks from current LCL implementation.

      But that’s me. YOMV. 🙂

      Like

      1. @MR BEE

        Hah! Most authors would disagree with my opinion of using Delphi/Lazarus in 2017 too 🙂

        The problem with using Native Controls in cross-platform development is that you end up with something like Xamarin.Forms (slow, buggy, always trying to catch up) or having to do the UI twice (Xamarin Native, RubyMotion, Oxygene etc.).

        With Flutter, Google put the abstraction in at lower layers, and are able to render Widgets faithful to the look and behavior of the native controls. Performance is very good.

        The Google team needed an iOS version of their Android App used internally on their most important product/service. They decided to build a new App in Flutter from scratch that would run on Android and iOS. They built it faster than the original Android App, and it works flawlessly on iOS too. Hamilton is another example of their success.

        In building Flutter they looked at Qt, JavaScript frameworks, Android, iOS, Xamarin, etc. They took the best from what was out there. They deliberately chose not to use native controls.

        Flutter is really something else – you run your app, see an issue on screen 5, update the code, hot deploy in milliseconds, and continue from where you were on screen 5 (no need to navigate from screen 1 to 5). The best thing is, all state is preserved during the run/edit/hot deploy cycle.

        FMX is in good company with their choice to do custom rendering. Right now, I use Delphi for desktop development, and Flutter for mobile. When I get better at FMX, I’ll most likely be using Delphi for everything client/device side.

        (IMO) Unless you want to pay the price and build the App native for each platform, the argument for using native controls is a thing of the past for cross-platform development 🙂

        Like

    7. > The problem with using Native Controls in cross-platform development is that you end up with something like Xamarin.Forms (slow, buggy, always trying to catch up) or having to do the UI twice (Xamarin Native, RubyMotion, Oxygene etc.).

      WHAT? It’s the other way around. No… it’s not the problem of the native control. It’s clearly the problem of Xamarin. Xamarin.Forms abstraction fails. Your logic is upside down and trying to put one’s fault onto the other. How can a native control trying to catch up? It’s THE native control. Native control is the Mac’s Cocoa, iOS’ Cocoa touch, Windows’ GDI+, etc… the UI API that’s provided by the OS.

      > With Flutter, Google put the abstraction in at lower layers, and are able to render Widgets faithful to the look and behavior of the native controls. Performance is very good.

      That’s exactly the same reason and promise of the creator of Swing, qt, Xamarin, etc.

      The performance won’t be any better than the native controls, it’d be equal at max. But it has to keep catching up with the true native look and feel. If tomorrow Apple change Mac’s look and feel, say the window’s buttons move to its center, or the buttons become circle, or change the window behavior, or add new UI control, etc. Flutter will need to catch up, ASAP. It’s always the consequence of custom drawn control.

      > In building Flutter they looked at Qt, JavaScript frameworks, Android, iOS, Xamarin, etc. They took the best from what was out there. They deliberately chose not to use native controls.

      It’s their right, but as long as they draw the controls by itself, it’s not native control. Be it’s so extremely good, it’s still not native control. And the consequenses of being non-native control are always embedded to it.

      Well… actually I’m not really anti native control. If it’s really that good and the author promises to keep it synced with the true native look and feel of each platform, I might consider to use it too. I don’t prefer non-native control because I haven’t found any non-native controls that really as good as native control and that I can trust and rely upon. Also always remember that each time you choose non-native control, you put another point-of-break into your development cycle.

      > (IMO) Unless you want to pay the price and build the App native for each platform, the argument for using native controls is a thing of the past for cross-platform development 🙂

      A true cross platform dev tool is the holy grail of sofware development. Everybody says they sure would find it, but nobody really able to find it. Today it becomes a hype, again.

      I do cross platform development too. Long before Delphi is able to. I do web, android, ios, linux, etc. UI is only a small part of software development. And it’s not the most difficult and challanging either. I share most of the logic and business code of my apps across platforms (most of them in Pascal, of course), but I do the UI of each platform natively. All my software development tools are free and open source, so the price isn’t really a problem to me. At least not as much as if I use Delphi. 😊

      Like

      1. @MR BEE

        > Your logic is upside down

        I think you may be misunderstanding me.

        As you know, using Swift/ObjC for iOS, and Java/Kotlin for Android, is not developing with a cross-platform framework. That’s straight up native platform development.

        As iOS or Android evolves, any cross-platform framework that targets them has to keep up with those changes. Those frameworks which are coupled tightly to native controls will need to be constantly up to date. Those frameworks which render their own controls will be less impacted by the changes, and even have the advantage of being able to render modern looking controls on older phones.

        Xamarin.Forms is a cross-platform framework that renders to native controls. You write the UI once, adding customization only when needed. The goal is 95% code reuse. It’s hard to build a cross-platform framework that abstracts multiple native platforms (i.e. iOS and Android), uses native controls, keeps the bugs to a minimum, has good performance and keeps up with the underlying platforms as they change. Microsoft are focusing on quality and performance issues now. It should get better.

        Xamarin.Native and RubyMotion are also cross-platform frameworks that wrap/expose individual native platforms (i.e. Xamarin.Droid and Xamarin.iOS). You can share business/infrastructure layers etc. but you have to write your UI for each platform (i.e. iOS and Android). The goal is 70%+ code reuse. Like Xamarin.Forms, these frameworks use the native controls of the platforms they wrap.

        Just to be clear, Xamarin and RubyMotion use native controls, they are not like Qt.

        Qt, FMX, and Flutter render custom controls, and try to abstract the underlying platform and services. The goal is 95-100% code reuse. I believe this is the best way, and Flutter is proving it (IMO). I also believe this is a more versatile approach too, being more readily adaptable to other devices and form factors, as demonstrated by FMX4Linux and Qt.

        Actually, the Flutter team found in their research that many of the best apps were bespoke, using a lot of custom controls, and this was a growing trend.

        > I might consider to use it too

        Have a look at Flutter, there are videos on YouTube, it’s very impressive:

        > but I do the UI of each platform natively.

        That’s a lot of work.

        > price isn’t really a problem to me

        But it’s costing you time.

        I want leverage, if Delphi improves my productivity, it’s worth the investment. Every Delphi developer complains about the price, and we are aware of options like Lazarus, and most of us are polygots, so there’s a reason why we are willing to pay the price: leverage.

        > All my software development tools are free and open source

        Nothing wrong with investing in a commercial product if it makes you productive.

        Flutter is also free and open source.

        Anyways, there’s no silver bullet, each to his own.

        Wish you all the best 🙂

        Like

    8. > I think you may be misunderstanding me.

      Probably. English isn’t my native language and my English isn’t really good either. I apologize if I misunderstood your argument.

      > As you know, using Swift/ObjC for iOS, and Java/Kotlin for Android, is not developing with a cross-platform framework. That’s straight up native platform development.

      Yes.

      > As iOS or Android evolves, any cross-platform framework that targets them has to keep up with those changes. Those frameworks which are coupled tightly to native controls will need to be constantly up to date.

      Yes. It’s the main problem of using such approach. Even when you’re using the native controls directly, you still need to keep updating your apps.

      > Those frameworks which render their own controls will be less impacted by the changes, and even have the advantage of being able to render modern looking controls on older phones.

      Of course it will be impacted as well. As I said, if iOS tomorrow change its button to circular shape, all native apps will get the circular shape right away automatically without doing nothing. But the custom drawn buttons will still be rendered the old way because the rendering engine hasn’t yet updated.

      > Xamarin.Forms is a cross-platform framework that renders to native controls.

      I know. The problem isn’t with the native controls, but the Xamarin’s abstraction that unnecessarily bad and problematic.

      > Just to be clear, Xamarin and RubyMotion use native controls, they are not like Qt.

      I knew this since the beginning.

      So, there are 3 approaches:
      1. Xamarin.Forms-like which is an abstraction over native controls into a single uniform interface for all platforms. It’s like Lazarus’ LCL approach.
      2. Xamarin.Native-like which is a wrapper or a bridge to native controls on each platform so you must know how to interact with the UI manager on every single platform. It’s like RO’s Oxygene approach.
      3. Flutter-like which is another whole interface custom layer, ignoring the native controls altogether and build its own complete controls entirely. It’s like Delphi’s FireMonkey approach.

      Personally, I think the ideal approach is the number 1, the LCL approach. Unfortunately, we don’t live in an ideal world. Making such a great and perfect abstraction for all platforms using this approach is highly difficult and complex. That’s why I don’t like people understating LCL as mere “VCL-like”, because it’s not.

      The more viable and easier approach is the number 2, the Oxygene approach. Yes, we will write more codes because we need to differentiate our code for every platform our app support. But in return, our app will be easier to write because it’s directly using the built-in presentation tool of the platform. There’s no hidden magic codes in our part.

      I personally don’t think the third approach is really good in practice. I’ve learn a lot. It’s like wasting resources and energies of the already available UI library of each platform. There’s already an API to draw a button for you, yet you ignore it and you draw a button yourself. It’s not utilizing the platform effectively and efficiently. It’s like creating an OS inside an OS. It’s like we’re back to the DOS-era where we do everything by ourselves.

      Cross platform app isn’t just about the standard UI controls, but also about using the provided SDKs and frameworks of each platform. For example, by using Flutter in iOS, how are we going to use Metal? how about HealthKit? SiriKit? HomeKit? iCloud? etc. Does Flutter also provide its own version of each of those SDKs for iOS and Android? What if –for whatever reasons– Flutter is then abandoned just like any other Google’s project before this?

      This approach is always one –or two– step behind because it’s a follower, not a leader. And as I’ve said, we add another point-of-break in our development process. I will consider such approach if it’s really proven, widely adopted, reliable, and trustable. In this stage, Flutter is still far from that. Personally, I don’t trust Google on other platform, but that’s another thing to discuss at another time.

      > That’s a lot of work.

      At first, yes. We don’t make every app from the scratch every time. As you make many apps along the way, you’ll have some templates and patterns for most of the app you’ll build. In the end, it’s more of like copy-paste from one project to the another.

      > But it’s costing you time.

      Not really.

      > I want leverage, if Delphi improves my productivity, it’s worth the investment.

      Everybody wants leverage. You invest time, other people invest other things.

      > Nothing wrong with investing in a commercial product if it makes you productive.

      Of course. But I don’t think it’s a good decision for me to purchase a very expensive commercial product while there are many equal or better alternatives which cost me almost nothing. But I knew that although it costs me zero money, it could cost me something else, like time.

      > Anyways, there’s no silver bullet, each to his own.

      Absolutely agree.

      > Wish you all the best 🙂

      Wish you too. 😊

      Liked by 1 person

  8. Free software is great, and I use it a lot, but if it doesn’t save me time, then it’s only “free” if my time has no value. Especially where my livlihood is concerned.

    My annual RAD Studio Enterprise subscription more than pays for itself. Fast prototyping and proofs of concept, hassle free deployment, almost trivial forward compatibility when moving to new versions of the compiler (which I do a lot), very readable and therefore maintainable code, compile times so quick that TDD doesn’t get in the way of development and generally faster time to market.

    Multiply that by multiple projects, both rehabilitating existing software and new development, for different companies over the course of years.

    ymmv

    p.s.
    Someone might suggest (at great length) that MVPs get a free license, so their opinions are somehow invalid or compromised. Since I was a Delphi user long before I was an MVP and am responsible for more than one license, that argument is pretty baseless and more than a little petty.

    Liked by 1 person

    1. I agree with you Bruce, that’s why I prefer Delphi. If you are profitable and Delphi makes you productive, purchasing Delphi is a very good investment.

      I think they need to do something for the Indie/Startup in their pricing however.

      The Starter Edition is too limited, it’s not a solution in this case. Special pricing is. Once the person/company is off the ground and making money, then they can pay premium prices.

      Like

      1. Agreed. Delphi is not inexpensive, and I’d love to see Embarcadero lower the barrier to entry.

        Academic and Starter licenses are a start, but they could do more for professional users.

        Liked by 1 person

  9. I am using Delphi for 15 years and it is incredible tool (for Windows apps)! I started with Delphi 7 (amazing version, I used it for years) then little decay (XE…) and now it again rocks!

    What I like on Delphi: OpenTools API + possibility to extend/modify the IDE to match your needs (I created several experts, http://www.rad-installer.com is probably the most famous :).
    It is amazing how IDE can be extended, also there are tons of components, 3rd party packages and other stuff ready to use which boost your productivity.

    The most hated on Delphi: price + subscription model. The price is high for hobby developer and even for small companies.
    What makes me angry are the patches which are not available for users without subscription – this is big showstopper (especially when big issue appears like the Creators update bug).

    The future of Delphi is bright to me, now I want to start with Linux (Raspberry Pi) – which is another great new feature.

    Liked by 1 person

  10. If cross platform is the only difference, then comparing LCL with CLX might be more appropriate, but I’m curious about capabilities since most of the comparisons I see here lack details.

    Like

  11. I was a highly respected Delphi developer for over 15 yrs. I got out of it due to the lack of jobs. I found that more shops were going .Net (both C# and VB.Net) for desktop and PHP for Web. So I learned all of them. I keep getting questions as to why I don’t do Java but I really have no inclination.

    The main reason Delphi failed was MARKETING. Borland neglected to market the tool correctly and it’s adoption suffered. They claimed it was the VB killer but never marketed it as such.

    Liked by 1 person

  12. I have worked a lot with delphi, from version 5 to lazarus. You are right, compile loop has always bloomed me but, I hate it, i hate begin end and begin end and begin end over again, too much words that make your sources fat.

    Like

  13. As a long time Delphi developer that has had the horror of using VS as well, I can tell you that Delphi for any Desktop application is hugely faster to develop with. Prior to Delphi I was a C++ fanboy, but the crap syntax and .h hell and super slow multi-pass compiling I am happy to be rid of.
    BTW super fast Delphi compiling makes debugging also super fast!!! Period!!! Hand down super time saver!!!!!

    Liked by 1 person

    1. Hi Steven, completely agree. Speed and simplicity. Delphi 10.3.2 has just been released, the IDE/Compiler has never been faster. This is the best release in ages, feels like Delphi 7 days. Delphi is back! 🙂

      Like

Leave a Reply to Flavius Fernandes Cancel 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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s