Object Pascal decline?

[Mr.Madguy]

You do realize all that sugar Delphi gives you is just doing all of what you have described under the hood..

I have converted a few Delphi apps that use those syntaxes and I don't see any advantage as for speed and code space between them.

 I have studied the ASM code of Delphi in those regards just so I could get good understanding of their features and found that most of them are just sugar syntax to fool the eye.

 All this does really is maybe allow you to punch out a piece of code a little faster but not by much, the end results in speed and space I have not really seen any benefit and I like any thing that gives me an edge, be it a smaller file or extra speed.

Syntax sugar is about describing things shorter and more naturally. For example if I would need to replace closures, I would need to describe them as interfaces and classes, that implement them. That description - is just extra code, that is unnecessary. It's just extra work for me. And it's ok, when you use closures just 3-5 times. Not hard to convert. But I have thousands of test cases.

And about multiple inheritance. Yeah, it can be avoided. But all solutions are "unnatural", require more code and slower. May be inheriting from several classes is wrong. But it's not true for polymorphism. Sometimes implementation of some methods needs to be shared between several classes, but they can't be inherited directly from class, that implements them. Because they're inherited from other classes. Easiest solution - to simply copy-paste this implementation. It's ok, when, again, you need to do it for just 2-3 methods and properties. But it's not ok, when you need to do it for hundreds of them. And making and tracking changes turns into hell. What's the purpose of inheritance then, if not to share code between implementations?

In this case you have 3 ways to solve your problem:
1) Interfaces, if you need to implement abstract classes and you're able to inherit implementations from each other - clunky solution.
2) Class composition, if each implementation should be in it's separate class - very clunky thing.
3) Aggregation - is combination of two above, each implementation can have it's own inheritance tree - but also very clunky.

I analyzed code under the hood and multiple inheritance should be faster, because it's more optimized. Example: class composition requires stub methods, i.e. methods, that contain call to method of other object only. I'm not sure, if such calls are optimized to have minimum possible code. And in case of multiple inheritance only very tiny Self fixup stub is inserted, that contains one asm instruction only. Only one extra instruction is needed in case of virtual inheritance - to read offset from VMT. And you don't need to describe hundreds of that stubs manually - it's done automatically. And of course you don't need to store and pass all that pointers to other objects then.

I.e. problem is with project scalability. If IDE/language allows you to use it for "toy" projects only, not professional ones - then it's used for "toy" projects only.

Example: Does Lazarus support project groups? Project groups aren't only about logical grouping of projects. They're about sharing units between them, that speeds up compilation.

[PascalDragon]

Example: Does Lazarus support project groups? Project groups aren't only about logical grouping of projects. They're about sharing units between them, that speeds up compilation.

See here. Also to speed up compilation in Lazarus you should use packages as the IDE compiles them in parallel if they have no dependencies on each other.

[JuhaManninen]

See here. Also to speed up compilation in Lazarus you should use packages as the IDE compiles them in parallel if they have no dependencies on each other.

Exactly. Lazarus packages are more advanced than Delphi packages.
A Lazarus package injects its search paths into a project where it is set as a dependency. You only need to open a package once in the IDE, then its location is remembered. No further configuration is needed.
Search paths of a Delphi package are typically added to global settings, thus polluting the name-space for all projects even if they don't need a certain package.
Maybe Delphi's Project Groups did similar things than Lazarus packages. I don't remember exactly how they worked.

[nomorelogic]

Currently Pascal is a reasonably good general purpose programming language.  A jack of all trades, master of none (sadly.)

I think this can be considered a value. Like "learn a language for all kinds of things".
From my point of view I notice that the pascal today is not used for something widely spread. I explain, there is no mail reader (e.g. thunderbird), there is no browser (you need use cef), there is no JVM written in pascal, etc.

I would like to share with you that I sometimes think that funding can be asked to users of this community: many small contributions could make an important contribution.
I bought the book lazarus handbook but I don’t think it can solve the problem. These contributions could be used to organize competitions with awards dedicated to IT schools around the world. With this you begin to bring the pascal in schools.

Part of the funds could be used to finance more professional products from the mail reader to a more complete TMEMO.

The ultimate goal would be to give more visibility to what you can do with lazarus / freepascal.

nomorelogic

[Mr.Madguy]

See here. Also to speed up compilation in Lazarus you should use packages as the IDE compiles them in parallel if they have no dependencies on each other.

I think, project groups have different purpose. Packages are more "permanent", i.e. you don't need to constantly change them. Project groups are about having several exe, dll or some other files in the same project, that can share code and build configurations between them. That means, that when you use "Compile project group" option, that units are recompiled only once.

I mean, that being able to open, manage and recompile many projects at once - isn't only advantage of using project groups. For me it's important feature. I have two projects, that consist of many dll files. So, when I make some changes in their common interface, like object factory, I need to recompile them all at once to make my project work properly. And I also need to recompile them for several platforms. And project group allows me to pick build configuration for all projects at once.

[marcov]

I hate the fact that Delphi/x64 single math is slow (translates to double under the hood)

Did you try to play with the $EXCESSPRECISION directive?

No. I checked and it is also in Seattle, worth a test, thanx

[JuhaManninen]

I think, project groups have different purpose. Packages are more "permanent", i.e. you don't need to constantly change them.

You can change Lazarus packages constantly if you want.
Please learn to place all shared code into packages. Lazarus project is not planning to replicate the flawed package concept of Delphi.

I mean, that being able to open, manage and recompile many projects at once - isn't only advantage of using project groups. For me it's important feature. I have two projects, that consist of many dll files. So, when I make some changes in their common interface, like object factory, I need to recompile them all at once to make my project work properly. And I also need to recompile them for several platforms. And project group allows me to pick build configuration for all projects at once.

Ok, shared build configuration for all projects in a project group is not implemented. It should be.

[440bx]

I would like to share with you that I sometimes think that funding can be asked to users of this community: many small contributions could make an important contribution.

No doubt that a good source of funding would be beneficial but, the real problem is that Borland and its descendants have introduced a fair number of inconsistencies in the language and, those cannot be removed now because doing so would break a lot of code.

That's the core of the problem.  The language has evolved in ways that are "problematic" (and that's putting it kindly.)  To make matters worse, to this day,  "problematic" features are still being added by the company responsible for the evolution of the language.  An additional problem, one that is important to large developers, is a lack of a reasonably current and robust standard.

It seems the objective is to turn Pascal into some sort of 4GL with mostly disregard for the inconsistencies introduced in the language along the way. 

I love Pascal but, I find it difficult to be optimistic about its future.

[nomorelogic]

Allow me a little provocation.
It all originates from having as a goal to "be compatible with". Great, this also attracted little programmers like me (I started from Delphi 1).
Today I no longer use delphi and, given how it evolves, I’m not going back and I think there are many who think as I do. Just To be clear: I don't care about what they are doing in delphi.

We all know that fpc can be compatible with different pascal dialects (e.g. Objfpc, Delphi, MacPas, ...). Clearly if an open source compiler must "be compatible with" what a private company is combining with a language... It’s actually hard to bet on.

I have in mind the goals of MSElang, so I think: why can’t an open source project like this release its pascal standard?
If tomorrow the one who carries on Delphi was no longer there, there would remain a language that had its evolutions for its reasons but then it is over.

An open source standard would remain, if valid.
In conclusion, if today it is true that it no longer makes sense to "be compatible with", maybe fpc can develop an own (new) standard removing all the "problematic" things?

The "compatibility with" may be carried forward, perhaps and if there is time, but the priority could be to evolve the pascal in the best possible way (if necessary, from scratch).

[FPK]

The "compatibility with" may be carried forward, perhaps and if there is time, but the priority could be to evolve the pascal in the best possible way (if necessary, from scratch).

This is not what the majority of the users want: if they wanted this, we would have already a group (normally, FPC developers are FPC power users) implementing a mode "futurepascal" in FPC. Not to mention the fact that I doubt that they would ever agree one standard. There is a reason why we had MSELang and e.g. NewPascal. Everybody wants to create his own little garden in this case.

[marcov]

. Clearly if an open source compiler must "be compatible with" what a private company is combining with a language... It’s actually hard to bet on.

How stable do you think an open source declaration of a standard is? Unlike e.g. multiparty standards like for C and C++ , such minority language definition (standard is IMHO too big a word) are likely to be the view of one certain generation of programmers, or in the case of MSELang just one person. Quite often the next generation of programmers floats on the waves of general IT trends before any of the previous targets have been properly achieved.

I have in mind the goals of MSElang, so I think: why can’t an open source project like this release its pascal standard?

What good would that do?

If tomorrow the one who carries on Delphi was no longer there, there would remain a language that had its evolutions for its reasons but then it is over.

No, the codebases are still alive, so compatibility is still important. Just look at e.g. Twinbasic, where 17 years after VB classic's demise a compatible is slowly standing up.

[PascalDragon]

See here. Also to speed up compilation in Lazarus you should use packages as the IDE compiles them in parallel if they have no dependencies on each other.

I think, project groups have different purpose. Packages are more "permanent", i.e. you don't need to constantly change them. Project groups are about having several exe, dll or some other files in the same project, that can share code and build configurations between them. That means, that when you use "Compile project group" option, that units are recompiled only once.

That means that you don't grasp what packages are able to do for you. Sharing code between projects is exactly what they're there for aside from allowing the installation of components inside the IDE. And projects groups add to this that you can have multiple application/library projects open as well.

[nomorelogic]

. Clearly if an open source compiler must "be compatible with" what a private company is combining with a language... It’s actually hard to bet on.

How stable do you think an open source declaration of a standard is? Unlike e.g. multiparty standards like for C and C++ , such minority language definition (standard is IMHO too big a word) are likely to be the view of one certain generation of programmers, or in the case of MSELang just one person. Quite often the next generation of programmers floats on the waves of general IT trends before any of the previous targets have been properly achieved.

I fully agree with you about "standard" is a too big word.
I wanted to say that if Borland made a de-facto standard, and today this "standard" took a bad turn, then this open source project could have its own de-facto standard.

About codebase and compatibility with Delphi They’re important, it’s true.
But it’s not open-source, and in the event of the company leaving, there’s a chance that no one will take the project forward.
The codebase that will remain will be that of fpc/lazarus that are open source.

What I wanted to say in general is that lazarus/fpc are far beyond compatibility with Delphi (where it was reached).
Perhaps "compatibility", to prevent it being a constraint or ballast, could simply be a component of this project that is really fantastic.

[PascalDragon]

About codebase and compatibility with Delphi They’re important, it’s true.
But it’s not open-source, and in the event of the company leaving, there’s a chance that no one will take the project forward.
The codebase that will remain will be that of fpc/lazarus that are open source.

What will also remain is the existing code base of Delphi projects. Should Delphi really go the way of the Dodo some time in the future then it would be even more important to have a compatible open source alternative.

What I wanted to say in general is that lazarus/fpc are far beyond compatibility with Delphi (where it was reached).
Perhaps "compatibility", to prevent it being a constraint or ballast, could simply be a component of this project that is really fantastic.

Most third party code that would be useful to have is written with Delphi in mind (e.g. Spring4D), thus Delphi compatibility is important. Not to mention that it brings features that are useful independently of Delphi compatibility (e.g. anonymous functions, extended RTTI) and where it makes absolutely no sense to implement them in an incompatible way.

[Sieben]

But there are also quite obvious bugs like this one that imo should not be replicated just for the sake of being compatible.