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 as Aristotle says “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 Smart Mobile Studio to FL Studio, 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.

Advertisements

44 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

  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. I’m sorry, but this article is filled with the inaccurate myths the few remaining Delphi users keep telling themselves to make themselves feel better as they cling to their sunset technology.

    >Delphi is compiled to native code, so the performance is great.

    One doesn’t follow from the other. A poor compiler can produce poorly performing code. In fact, in SciMark benchmarks, Java *handily* beats Delphi, a fact which drove Delphi users to conniptions. The creator of the last big SciMark roundup even complained that Delphi users kept contacting him accusing him of doing this or that wrong without actually looking at his code or testing their ideas to see if they improved performance.

    Delphi’s compiler is based on an ancient single-pass approach created during the era in which computer memory was measured in kilobytes. It precludes a great deal of possible optimizations. In addition, the 32bit desktop compiler never gained the ability to use modern SIMD instructions. Meanwhile, the newer 64bit compiler never gained the 32bit version’s optimizations! You have to “choose your poison”! The 64bit compiler doesn’t even use bit-shifting for division. For reference, the Tiny-C compiler, which is designed to fit on a floppy disk (with operating system!), only has three optimizations – one of them in bit-shifting. I’ve actually seen JITted Python beat 64bit Delphi in a division-oriented benchmark because of this. The JITter was able to convert the division to bit-shifting and best Delphi.

    It has been pointed out as well in the Delphi Google Plus forum that the new Linux support emits x87 floating point code unless the function is inlined! This results in Linux numeric-heavy code benchmarking at half the speed of the same code compiled for Windows. As mentioned, the 64bit Windows compiler itself is rather poor compared to other compilers, making the Linux code rather poor indeed.

    Renowned Delphi expert David Heffernan recently posted numeric code on Google Plus that demonstrated the 64bit Delphi code performing 2.5x worse than the same algorithm written for and compiled with Visual Studio C++. In fact, Delphi barely performs better than the C# implementation he also posted. Let’s keep in mind that for most people today Visual Studio can be obtained for free.

    So please, don’t tell us “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.

    Again, see above. I’d choose C or C++ every time for this.

    >The compiler is extremely quick

    Again, please tell the whole truth – it’s very quick because it barely optimizes the code.

    > resulting in a fast build-debug loop, and improved developer productivity.

    How many times are you compiling your code that you feel this improves your productivity? Yet your productivity isn’t hampered by lack of memory management, type inference, etc? In modern development code is written, checked into a DVCS and then continuous integration builds it and runs tests on it.

    >Furthermore, deployment couldn’t be simpler as the compiler produces a single executable.

    Deployment is an OS-level problem, not a language-level problem. I could point out that anything that ultimately spits out an MSI file “produces a single executable”.

    >Although the Delphi compiler optimization lags behind C++, its speed is a great trade-off for all but the most
    >demanding needs.

    Is it? Again, I could get a Java .jar file about as quickly but get better performance.

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

    That statement doesn’t make any sense. It’s not a managed environment, period.

    > Object Pascal is far simpler and safer than C++ which further improves developer productivity and code
    >maintainability.

    That’s like saying it’s less verbose than COBOL. Everything is simpler and safer than C++, including D, Rust, Go, Java, C#, etc.

    >It is the perfect balance between C# and C++.

    It doesn’t perform any better than C#, costs 3X to 7X more, and doesn’t have an ecosystem anywhere near as broad as .NET’s. “It’s simpler than C++” is all you can honestly claim. So’s D, and I can download that for free.

    >Portable

    Let me dismiss with this quickly. EVERYTHING is portable today. In fact, unlike Delphi, everything was portable yesterday too. Even MICROSOFT beat Delphi’s (return) to Linux! However, unlike most other languages, I can’t develop Delphi on anything other than Windows. Stack Overflow’s developer surveys suggest that within the next year or so 50% or more of developers will not be developing on Windows! Who wants their development OS dictated by their development tool? Who wants to have to run Windows to develop an OS X app?

    >The VCL has continued to evolve.

    No it has not. Embarcadero doesn’t have the staff to develop two frameworks at once (plus compilers, IDE, database, etc.) Once Firemonkey showed up, VCL progress stalled (which only makes sense since VCL is only a subset of what FMX offers).

    >It is still a premier technology for Windows development.

    How is it a “premier technology” when no one uses it?

    >It too is more of an evolution of the VCL

    No, it started life as a third-party product that was purchased by EMBT (and then discovered to need a lot more work than expected to turn into FMX). It doesn’t share code in common and does many things quite differently.

    >Object Pascal has also evolved, offering many features expected of modern languages such as Generics,
    >Anonymous Functions, Type Helpers, support for AOP, etc.

    Poor generics that can’t work with numbers, huge, bloated anonymous function syntax – and the feature itself should have been passed up in lieu of making our nested functions truly first class an implementing lambdas instead, type helpers that override defaults if you implement them, etc. In each case, these features we essentially all added by Barry Kelly to achieve a specific aim and then never improved upon, probably because Kelly quit. In fact, Kelly said the language had reached the limit of what could be improved without breaking backwards compatibility and the language he’d like to use today would be far different from Delphi (Kelly seemed to have fallen in love with truly modern functional programming concepts).

    Meanwhile, the language lacks type inference, automatic memory management on the desktop, list comprehensions, tuples, generics for first class functions, operator overloading of classes, the removal of forward declarations (needed because of the aforementioned single pass design), a power symbol, a step feature for for loops, a logging module in the system library, string use in case statements, a sane approach to strings (what do we have now – five types? Six?), a much richer set of features for iteration, sane sorting, argument packing/unpacking, multiple assignment, generators (yield keyword), slice notation, design by contract, functional programming concepts (at least filter/map/reduce), lambdas, sets that work with any type and aren’t limited to 256 values (even ISO Pascal doesn’t have this limit), a decimal type, a complex number type, a bigint type, decent JSON support (DWScript creator Eric Grange called the available library the worst JSON implementation he’d seen in any language), HTML parsing in the standard library, unit testing and mocking in the standard library, stack traces, etc., etc., etc. Sorry, but Delphi is far from being a modern language (heck, we still define our variables in sections like COBOL!). I should note that the Oxygene dialect of Pascal has most of the features listed above (and then some) and the “better C++”, D, does as well. Heck, even languages like Ruby have most of these things.

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

    When I showed a web developer the official Delphi REST example code, the reply was “Yuck. I don’t think I could work in a language like that.” When I showed a young programmer what it takes to work with Delphi classes, the reply was “People still subject themselves to that for eight hours a day?” Show the language to someone who’s not a fanboy or a 20 year veteran of Delphi and listen to the responses you get. See how they like the variable definition sections, separating a class’s definition from its implementation, all the try…finall\y… free…. nests, etc., not to mention the begins and ends. It’s an old language that still shows its age. True Pascal successors such as Oxygene and Nim are far, far more ahead in modern features (and significantly cheaper too).

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

    Actually, you can’t create device drivers in Delphi. You can’t (seriously) script a quick text processing task at your terminal, you can’t use it interactively, you can’t embed it in other programs (you can embed DWScript though, which itself is more advanced than Delphi, even working on adding lambdas!). You can’t compile your code on OS X or Linux or BSD or Haiku or the Raspberry Pi. You can’t give a friend a copy of it and you can’t give the code to someone else to freely compile – well, perhaps you could if your code is trivial and can compile with all of the beginner edition’s limitations.

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

    Sigh… now you’re getting into why I originally chose Delphi and why I left. What you call RAD isn’t RAD in 2017 standards. It’s what is now referred to as “point-and-click programming” and if you look around, you’ll notice that the concept never caught on and died out by the end of the 1990s. Today Rapid Application Development is about all the things you criticized earlier – managed environments, memory management, type inference, as well as dynamic typing and open source libraries. Today when we talk about RAD we’re talking about Ruby or Python, not about a language with its roots in the 1960s with defined sections, manual memory management, verbose syntax, etc. Languages like Ruby and Python tend to take 1/5 to 1/6 the lines of code of Delphi programs. LiveCode, which is a language derived from hypercard, has a case study in which the author converted a Delphi application used by his academic institution to LiveCode and it took 1/5 the lines of code! He even popped up on a Delphi MVP’s blog to answer questions about it. THAT’S Rad. Windows and GUI-driven coding are not RAD.

    Let’s say we have this text that represents a sensor’s log:

    “123 – 60 – 10”

    Maybe it represents door opens, door closes, and door ajars. We want to put this data (perhaps it was read in from a file) into three variables to work with it. In a modern RAD language like Python, it’s a trivial line of code.

    So if we have the data:

    sensor_data = “123 – 60 – 10”

    you’d accomplish this with just:

    opens, closes, ajars = [int(num) for num in sensor_data.split(‘-‘]

    No “Program” line (why do we need that now that files aren’t limited to 8.3 characters?). No “Var” section. No defining 3 separate variables. No “begins”. No “ends”. No defining an intermediate string array to hold the results of Delphi’s split function then converting the elements to int vars in three more lines of code. Your mind doesn’t bog down with details for trivial tasks. You’re free to concentrate on the problem you’re trying to solve.

    Python has become the most-used language for CS 101 in colleges today. That means most future developers will be familiar with Python (if not much earlier from the Raspberry Pi). Having written the above in school, you’re never going to convince them that Pascal is about RAD.

    What else represents real RAD today? Open source libraries. One published paper recently found that the number one factor (by a wide margin) that developers use to choose a language is the availability of libraries (especially open source). Delphi’s GetIT has less than 200 libraries, most of which are demos or IoT drivers. Torry.net has been between > 10K and Every day new projects are being started in Delphi.

    Sorry, but this is absolute nonsense. No one uses Delphi anymore. The traditional examples of applications created with Delphi always consist or programs created circa 1999. No one’s using Delphi for new development and no one produces examples that date from 2010+. It’s been said that a language hasn’t achieved success until a multinational company uses it for an infrastructure project. By that measure, Delphi never achieved success in the enterprise. What major company is running its operations on Delphi today? Facebook? Google? Microsoft? Apple? Instagram? Uber? No. Can you name one hot startup using Delphi? No. I checked this weekend and despite living a stone’s throw from New York City and the HQ’s of many national and international companies, there was precisely ONE Delphi job within 100 MILES of my home listed on Dice. That’s actually good since when I checked this time last year there were none within 200 miles. Please, please, please stop lying to people and telling them that Delphi has any significant market presence. It doesn’t. Look at its ranking on Stack Overflow questions; it’s been steadily losing ground since the first year of SO. Look at it on Github; every year the Delphi’s ranking in # of new projects drops (49th last I checked two years ago). There is no evidence in the real world of any meaningful adoption of Delphi either by the enterprise or start-ups (and it’s certainly priced itself out of the hobby market).

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

    This may be the whole and complete reason why you really use Delphi – and it’s a perfectly acceptable answer. If it makes you happy, that’s enough. But please don’t mislead other people into choosing something they won’t be happy with because they think it generates fast code, is quick to program in, is modern and widely used.

    Like

    1. Thanks for your comment, I’m sure I’ve read most of your complaints above in the reddit forums, it’s like you copy and pasted them. People have already replied to you there. I’m curious, why do you assume Delphi developers are not polygots? Why do you assume I have been using Delphi for most of my career? I spoke of the benefits of Delphi and Lazarus, I didn’t criticize anything, but I may now in answering.

      You do understand that a GC is non-deterministic and has performance and power overheads? That’s a problem in many real-time or embedded systems. Even in game development it can be a problem.

      On performance, you and Heffermen miss the big picture: I’ve never seen a WinForms/WPF Desktop Application run as snappy as a VCL Application. WPF has had performance problems for the longest time. FPC emits pretty good code. They’ve written operating systems in Pascal, not just device drivers.

      The desktop scene is a bit of a mess at the moment, it seems everyone is dropping the ball and going web, mobile, cloud or embedded. WPF can’t target Linux or Mac, UWP is not so universal, Mono-WinForms is buggy, and GTK# doesn’t look too good on a Mac. Perhaps Xamarin.Forms will get there, but right now its buggy and the performance is bad. The VCL may just beat Microsoft there with CrossVCL. Delphi FMX is a good option for cross-platform desktop development, it gets better with each release.

      Sure there are other options like Qt/Qml, Java Swing/FX, etc. The JetBrains team have done some awesome work with their IDEs, if I liked Java I’d be using Kotlin and TornadoFX perhaps. I have friends who think WPF is awesome, some love WinForms, yet another likes Qt. In terms of product momentum, I think it’s hard to beat Qt at the moment, every time I look they’ve added significant features. Like Delphi, none of those technologies are perfect, and success depends upon many factors. There is no silver bullet.

      Yup, FMX was purchased (just like Xamarin, and much of Microsoft’s technology) and there are differences because it is cross-platform and vector based, but it is similar enough that I was immediately effective in it – unlike the transition from WinForms to WPF.

      We’ve had the ability to reuse static and dynamic libraries for a longtime. RAD is more than code reuse, and it is predicated upon component-based development (CBD) which, like OOP and FP, is decades old. No one says let’s stop using FP because it had its origins in the 1950s and started appearing in LISP. Multicore programming has made FP even more relevant. FWIW I’m working through this course on Elixir at the moment because I’m considering switching to EJabberd/Elixir for XMPP component/plugin development rather than using C#/Openfire. I’m not averse to embracing newer technologies.

      Back to components, consider adding animations in FMX vs the declarative method in QML or XAML. I’m not saying one is better than the other, I just prefer doing it in FMX. Delphi’s emphasis on components, it’s environment and tooling, visual inheritance, RTTI, reference based object model, single inheritance from TObject, indexers, object method pointers, component ownership practices etc. are very similar to what you see in frameworks found in managed environments – like WinForms. In fact, WinForms and C# feel so familiar to Delphi Developers it’s an easy transition. I did mention Delphi is native.

      Yes, FMX is getting the lion share of the attention, but the VCL is still evolving, it’s still getting new components, updates, styles, bug-fixes and enhancements. It has also evolved to target Win10/WinRT, whilst still being able to target older versions of windows. It’s a premier technology for building Windows Desktop applications because of its capabilities, ease of use, development speed, performance, deployability (XP – Win10), and quality of apps you can build with it. Delphi is productive.

      A nice thing about Delphi, Qt Widgets, and WinForms is you don’t have to be a designer to create nice looking applications. You can style Delphi if you want, and it’s simple to apply third party styles.

      Regarding open-source libraries, the Java world buries .Net, should we all throw away C# now? Not if C# is sufficient for your needs, is more enjoyable for you than Java, and you are productive in it – you can get the job done. As mentioned in the post, we generally like what we are good at, so opinions are often subjective. Yet I believe there are as many, if not more, objective reasons to justify using Delphi for desktop development as there are for any other technology. As you know, Delphi ships with the source code, and the FPC/Lazarus community is open-source.

      Lazarus and FPC are free, and quite capable for many a hobby developer needs. Lazarus has been available on Linux for a long time now, and you can always run the Delphi IDE in a VM. Yes Delphi is expensive, and many Delphi developers complain about that in the Delphi Developer Facebook Group. For a profitable business, however, it is a good return on investment – if the team is productive in it.

      Oxygene is great, Nim also looks nice – but there is more to Delphi and Lazarus than Object Pascal. I’m not sure if you saw it in the post but I did link to a blog detailing some much needed improvements to Object Pascal. I’ve also rather exaggerated my complaints about these things on the Commentary to the Roadmap. In fact, I’ve spammed the good David Millington with such complaints. You assume we’re ignorant of these things, unable or unwilling to embrace new technology. Sure Object Pascal can be verbose, and lacks some constructs to make it more expressive and supportive of other paradigms, but it’s still a great language. They’ve promised improvements, as well as some syntactic sugar, so that’s something to look forward to.

      Are tuples great? Yup! But if they aren’t available in a language, you just have to find another way to communicate semantic meaning, like the C guys do with a function returning a struct. You’d probably want to wrap your example in a function anyways for maintainability (and TDD) purposes, unless it’s a quick script then I would use Ruby, not Delphi for that:

      opens, closes, ajars = sensor_data.split(“-“).map {|s| s.to_i}

      You do realize static type systems are useful in managing large code bases? Not only do they scale better, they enable better tooling for code analysis, etc. You’re confusing horses for courses. Why don’t you send Linus an email suggesting he drop C for kernel development because it doesn’t have tuples nor pattern matching, and you have to have a main method of all things?

      I agree with Brian Kelly, backward compatibility is a limitation – Java’s got the same problem, with type erasure, verbosity, etc. Hence, Kotlin has become the joy of Android developers everywhere. But Delphi is still elegant, easy to read, and capable – and there are things it does well, code which any developer would appreciate looking at, like sets. In fact, whilst verbose in many respects, sometimes Delphi is concise because of things like sets, ordinality, not needing to declare Result, etc. Also, the separation between function and procedure semantically supports the CQRS pattern. There’s a certain elegance to Delphi, and its type system is conducive to writing large maintainable code bases.

      Programming C# in Visual Studio provides background compilation, and with tools like NCrunch and Resharper you get instant feedback on syntax errors, best practices, and broken unit tests. Yet, you still need to build/run/debug frequently when writing native or managed code. A continuous build system won’t help you with that, and you’d be very unpopular checking in code that doesn’t compile. There’s a reason why products like Incredibuild exist.

      Delphi compilation speed is great for a fast build/debug loop, and yes Delphi code runs fast enough for 75% of the use cases. Of course C++ is faster, but the language is far more subtle, has more memory management options, and there is optimization performed by the compiler, so you pay for that with longer build/debug times, increasing complexity and higher development/maintenance costs. If you have to, then you pay for that. For my needs, I don’t, so I prefer Delphi.

      Actually it’s not necessarily either/or, C++ Builder gives you the benefits of the Delphi environment and frameworks, and you can still use a modern C++ compiler. That also means, all those Delphi and standard C/C++ open-source libraries are available to you.

      There are many people using Delphi, there are Startups using Delphi, and there are Enterprises like the ANZ Bank using Delphi. There are new projects being started in Delphi everyday. I also see Delphi jobs available within 15 kms of me – people are still hiring. I didn’t claim it was the most widely used, the most in demand technology. I did say in the balance it is awesome, and I stand by that.

      Delphi is not a hammer, not everything is a nail. For REST services I’ve been using C#/WebAPI, but I’m moving to .Net Core now v2.0 is imminent. For websites, I prefer Rails, for scripting, Ruby. When I need to write a mobile app, I use Flutter, previously Xamarin, but I suspect I’ll be moving to Delphi before long. When I need to write a desktop application I choose Delphi, because overall it’s great for my needs.

      You prefer Python, Nim, LiveCode etc. good for you, I wish you all the best.

      Like

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

  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

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