Bill Meyer

My limited experience with SVG in Delphi is very recent. I was in need of some icons, and after a bit of rooting around, I found that the TcxImageList from DevExpress supports SVG. I used Affinity Designer to create a few suitable images, and used them with no difficulty. I did discover the lack of text support, but resolved that in the one icon I made which had characters in it by converting them to curves. An added benefit to me was that Affinity Designer has a collection of simple shapes ready for use, and most of what I needed I was able to base on those shapes. Being able to use SVG was a huge benefit. I would have passed altogether if I had to color images pixel by pixel.

I suspect it is because that was the first model anyone created, and others simply grabbed it, following Design Pattern #1: Copy and Paste. At some point it became a matter of intertia.

One of the best things I have seen online in a long time.

In contractor role, I would, as well. But if my manager determines we're not to do that, then I'd be stuck.

And even without the inline variables, it is pretty minor compared to the pain which comes with with.

Again, with no knowledge of content, it is impossible to speculate. If one row per record, you are talking about roughly 60 pages, and though we always want things to be fast, 15 seconds for 60 pages doesn't sound terrible. You need to do some profiling. Also isolate the timing of the report production from any data preparation. Lacking any detailed knowledge of your code, we can offer no specifics.

That code is not much help in understanding the speed issue. What is the data source for your report? Is it the actual report generation which takes time, or the data preparation? In other words, what is happening in PrepareReport? And what do you mean by "extremely slow?" How many pages are produced, and in what time period? I work routinely in ReportBuilder, and these are the issues I would look at. One more: If you produce in your report a line saying page x of y, I would guess that FastReport will generate the report twice. Certainly that is how ReportBuilder does it. Apart from these issues, I found a few years ago that there can be huge performance differences among the different in-memory datasets, so I wonder whether that may be a factor for you.

A year ago, I was able to reduce the total unit dependency cycles in a large app by 25%. The build time reduced by a factor of 8, even though the cycle count is still embarrassingly high.

Mac who???

Too true. Agreed on generics. Toiling in legacy code, I am so far from attributes I can't even imagine using them. Code efficiency certainly needs attention. ARM64, meh. Linux... been trying to make it a thing for myself for a quarter century. But in my area of work, it;s just not a factor. Yes! Reliability of IDE and debuggers are bedrock. Background compilation would be nice, but not essential if compiler speed is high. I'd wish for better tools for dealing with legacy issues. MMX identifies unit dependency cycles, but in a large app, the challenge is then to discover in which units they are actually created, and which modules are merely caught in the chain. I would rant, but need the energy more for finding patience with IDE and debugger problems. 😉

We are in the same trenches.

All teams have turnover. New team members are typically ignorant of product intricacies. They may be expert developers -- or unseasoned but well educated recent graduates -- but in either case, they may easily overlook details which create issues. This is simple reality, and applies not only to Delphi, but to any specialized and complex product.

All true, but legacy code tends to contain massive routines and an unpleasant degree of coupling. Testability requires unit isolation, and -- ahem -- comprehensible routines. Gentle and iterative refactoring is the only viable approach I see to dealing with some of the code monsters which live in legacy apps. And rewriting is rarely an option, since it would often be necessary to refactor to achieve enough comprehensibility that you could write a design spec.

Sometimes, you can only creep toward unit testing. There is a tremendous amount of legacy code out there.

Efforts are encouraging; positive results are better.

As to the titular question of the thread, I consider "cash cow" to be prejudicial to the discussion. Embarcadero is a company, not a charity, and Delphi is a commercial product, not an open source free tool. I rather suspect that all of us here labor for a pay check -- does that make us evil? At any event, the term cash cow is normally applied to a product, not to customers.

And how are people not already using Delphi being led to the site? Yes, it is good that the site has been improved, but it is likely preaching to the choir. The other items you mention have, I think, been mostly promoted on the site. So again....

Marketing? Doing a lot? Examples?

And that is probably at the heart of the complaints. To refer again to Brooks: There is still no silver bullet.

The problem of "special support for every single control" will not be easily remedied. I doubt it will be addressed at all.

Ah, but the "dumping" is inevitably triggered by a thoughtless coder. I have never seen Delphi insert an event handler without human action. 😉

You can write bad code in any language. It's a poor workman who blames his tools. Delphi is not perfect, and certainly we battle defects in the IDE, but failure to design is a plan for failure in any language.

I mean that not all patterns fit all languages. XAML is not a feature of Delphi. Examples have been written of MVC and MVP in Delphi. A book has been written about MVVM in Delphi, though it is not clear that what it describes is actually MVVM -- an objection raised by Stefan Glienke, to whom I defer. In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

Oversimplified, but Brooks demonstrates that adding programmers to a late project makes it later, and shows why that is inevitable. Make time to read it. Your guess is correct, if the "problem" is defined broadly, for example, the compiler, the code editor, and so on. Thinking that smaller chunks may be attacked in parallel is risky, unless you have a very clean architecture and minimal coupling. And tasks defined and assigned by a product architect.