Best delphi so far?

[Mike Torrettinni 198]

I used Delphi 7 for a long time and have very fond memories, until upgraded to D2006 - which I had to restart once a day, when project grew, as IDE used so much memory. Crazy.

Then upgraded to XE7, which was good, but code completion and error insight were broken, badly. Now in 10.2.3 it's a little better than XE7, but still probably years away from stable code completion and error insight.

But, I did have to use D2006 a few months back and the speed of IDE compared to 10.2.3 is like night and day, D2006 is so much faster, everything is instant, opening files, forms, menus, debugging... while in 10.2.3 everything has a little delay, noticeably slower.

Of course I prefer 10.2.3, which includes generics and all other improvements. I would be OK with even slower IDE to get working code completion and error insight. If it's the size of project that affects code completion and error insight then OK, let it be slow... but make it work without failing.

[Edwin Yip 154]

POV1:

• D7 is the last non-.net IDE
• D2007 is the last non-unicode edition, but will a lot of language features added
• D2009 is the first unicode edition.
• When was FMX/Linux added?

POV2:

Check the 'Downloads' column of the statistics data of Andy's IDEFixPack

 

POV3:

List of Delphi language features and version in which they were introduced/deprecated

[A.M. Hoornweg 144]

18 hours ago, Dany Marmur said:

Just count the years 🙂 "Deleted" will be the VM as in "will not be maintained further".

The IDE which you use to edit the project and the compiler which you use to build & deliver need not be the same... I use FinalBuilder for my builds so I can specify which compiler to use.  So I can edit in one Delphi version and build using another. 

 

Often, if I migrate a project to a newer Delphi version, I want to avoid breaking things.  So I keep editing using the old IDE until it compiles without warnings in both compiler versions. This way the conversion can be a gradual process and I can still publish new releases and bugfixes if the conversion isn't ready yet.

 

And sometimes it is useful to deliberately use an older compiler in the build process if it produces much smaller compiled code.  The difference between Delphi 2009 and Rio is quite dramatic.  Now I know that this doesn't make much sense in single-executable projects but it does have an impact if the project contains two dozen DLL's that suddenly triple in size.

 

[Georgge Bakh 29]

On 7/2/2019 at 11:51 PM, Bill Meyer said:

Unit dependency cycles are a whole other issue. I can suggest you watch Anders Hejlsberg's video on modern compiler construction. Or just consider with a whiteboard what happens with a small collection of units (A, B, C, D) when:

A uses B, B uses C, C uses A and B uses D, but D uses A and B. It's a mess, and when you consider a larger application, the mess is multiplicative.

If you see no reason for the result, I submit you may have spent little time understanding the process. I have spent a number of years dealing with legacy code in large projects, and untangling things is a challenge.

I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit.

But I still think that code tools should not break or slow down with unit dependency cycles.

And I know what I'm talking about as writing pascal code tools is my current pet project.

[Lars Fosdal 1792]

The last 8-9 years I've had the luxury of pretty much staying current with the Delphi versions. We usually skip the first releases like 10.2 or 10,3 and migrate when the 10.2.1 or 10.3.1 arrive. This has become a little harder as the so-called minor upgrades now also have a lot of changes and even new stuff., but we tend to wait for the first "fix pack". That allows the new versions mature for a while so that TMS, EurekaLog, FastReports, and others can work out any new quirks, and the bleeding edge crowd can draw first blood, but as I said, we do aspire to move on to the latest version as soon as it seems tried and tested. Back in the day, skipping several versions often raised headaches when finally deciding to migrate as you had to deal with multiple incompatibilities or breaking changes, so I much prefer the current approach. 

 

To be honest, in some cases I actually wish that EMBT would be bolder and more often introduce breaking changes to tidy up old sins.

 

On the topic of unit dependency cycles, I tend to view them as a design weakness.  It is a quick workaround for properly designing with DI and other tools that eliminate unit inter-dependencies. Yet, working with code that has evolved over a long time, they can be hard to eliminate as they are so deeply ingrained.  We have one particular unit that causes a compiler internal error whenever we change something in its interface section and do a compile in the IDE.  At that point only a Build All resolves the problem.

[Bill Meyer 337]

6 hours ago, Lars Fosdal said:

On the topic of unit dependency cycles, I tend to view them as a design weakness.  It is a quick workaround for properly designing with DI and other tools that eliminate unit inter-dependencies. Yet, working with code that has evolved over a long time, they can be hard to eliminate as they are so deeply ingrained.  We have one particular unit that causes a compiler internal error whenever we change something in its interface section and do a compile in the IDE.  At that point only a Build All resolves the problem.

There is little question that they are a design weakness. In fact, that is a gross understatement. The apparent need for such cycles is a clear indicator that some units contain things which should be separated. Often a class has become a Swiss Army knife, providing too much functionality, marginally related. That's bad design, and substantial refactoring may be needed. The same pathology can be introduced, however, in simple procedural modules, where once again, too many loosely related elements are kept together.

Unit dependency cycles:

• are multiplicative, so should be eliminated as early as possible
• exact a penalty in build times, and in one major project, I have seen exponential increase in build times as new modules are added, using the old
• render code analysis difficult, at best
• are often difficult to remove, as they usually require redesign

I have observed that unit dependency cycles are often commonplace in legacy code projects. Further challenges lurk where such tangled modules have been recycled into new projects.

[Bill Meyer 337]

19 hours ago, Georgge Bakh said:

I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit.

But I still think that code tools should not break or slow down with unit dependency cycles.

And I know what I'm talking about as writing pascal code tools is my current pet project.

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design.

Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees.

It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.

Edited July 5, 2019 by Bill Meyer

[mael 29]

On 7/2/2019 at 10:51 PM, Bill Meyer said:

There may well be other strategies which might be applied to avoid the issue with search path, but I consider it poor practice not to name all your own units as members of the project. 

When using components or libraries, I think it is poor practice to include them in your projects, since they are shared files. They should be compiled independently to ensure you use the same version and state everywhere. All major Delphi components work this way, and you don't include the RTL or VCL units in your projects, either.

 

When placing components on the form, this should work seamlessly, and not require editing project specific library paths (or the IDE should do it automatically).

 

The IDE is just buggy regarding code completion and parsing, to more or less severe degrees depending on the version. This scenario is a very standard one, and should work.

Edited July 7, 2019 by mael

[Georgge Bakh 29]

On 7/5/2019 at 6:28 PM, Bill Meyer said:

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design.

Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees.

It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.

Again, I didn't stated that it's simple. I know that dealing with broken code is hard.

But it should be a code tools developer problem. Not users.

[Bill Meyer 337]

17 hours ago, mael said:

When using components or libraries, I think it is poor practice to include them in your projects, since they are shared files. They should be compiled independently to ensure you use the same version and state everywhere. All major Delphi components work this way, and you don't include the RTL or VCL units in your projects, either.

 

When placing components on the form, this should work seamlessly, and not require editing project specific library paths (or the IDE should do it automatically).

 

The IDE is just buggy regarding code completion and parsing, to more or less severe degrees depending on the version. This scenario is a very standard one, and should work.

I was not speaking of components or libraries. But all of the units you write for your application should be in the DPR. Relying on the search path does affect the IDE, whether we like it or not.

 

Yes, there are defects in the IDE with regard to Code Completion and Error Insight, but following lazy practices which can be shown to exacerbate the problem is just foolish.

[Bill Meyer 337]

17 hours ago, Georgge Bakh said:

Again, I didn't stated that it's simple. I know that dealing with broken code is hard.

But it should be a code tools developer problem. Not users.

Refactoring is rarely simple, but it is essential. Redesign can be even more of a challenge in legacy code, as there tends to be a lack of documentation, and often poor naming practices obfuscate the purpose of the code.

I don't see any way that the IDE could be held responsible for performing to overcome the creation of developers. 

[Georgge Bakh 29]

6 hours ago, Bill Meyer said:

I was not speaking of components or libraries. But all of the units you write for your application should be in the DPR. Relying on the search path does affect the IDE, whether we like it or not.

 

Yes, there are defects in the IDE with regard to Code Completion and Error Insight, but following lazy practices which can be shown to exacerbate the problem is just foolish.

I have no idea what is the difference for an IDE are units included in .dpr or not.

But what is the purpose of including in uses clause of a .dpr units which are not actually used in that file?

What if a unit become shared between projects (i.e. become a library)? Should it be removed from .dpr?