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.

20 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

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