Delphi compiler need to be opensourced

[AlekXL 8]

1 hour ago, Rudy Velthuis said:

Nor am I willing to hire someone to fix them for me. People who could do that would probably require large fees too.

Are you a company CEO ? Some companies invested in Delphi so much, that could easy spend, say, 10 grand for fixing annoying issue. And probably you don't realize how low those fees on emerging markets

 

1 hour ago, Rudy Velthuis said:

They should, IMO, implement managed records properly, not only so they could create shared pointers and the like (that can be done with the hlp of interfaces already, see Barry Kelly's blof posts and things like Spring4D). 

Look what are you saying! Shared_ptr is OK, and on-demand ARC is "not easy" -- For your information my on-demand ARC proposition is actually the shared pointers , but backed by compiler magic!

Why bother then, you would ask? Because Delphi compiler is not C++, is not insanely clever, sophisticated and stable compiler to implement those pointers in effective manner. It would screw up, undoubtedly! And on top of that we will get ugly c-like syntax, with braces, brackets, or how you call that. Get 

var shared := Auto<TObject>.Wrap (TObject.Create);

instead of

shared:= auto TObject.Create;

I'd prefer first class solution over ugly workaround for Delphi language deficiency.

Edited April 18, 2019 by AlekXL

[AlekXL 8]

33 minutes ago, Rudy Velthuis said:

And you think that open source volunteers would do a better job because...?

Because their no point to do bad work for free. You either put your utmost, or just don't do. At least this is true for someone like me.

And if those fixes is to be refunded by EMBT, you would wonder how cheap it will cost, especially from "3rd world" people.

---

and if I were cynical, I'd say "open-source volunteers would do a better job because" anyone would do a better job. But I'm not, so I'd refrain from that standpoint

Edited April 18, 2019 by AlekXL
typos

[AlekXL 8]

22 minutes ago, Rudy Velthuis said:

Ah, yes, once again. <sigh>

  

Delphi has been called doomed, or dying, or on the way out for almost as long as it exists.   

But Delphi is dying. Job market is close to non-existent. Freelance jobs too, unlike C# or C++. What's the point of your denial?

And, your answer on mixing ARC and non-ARC is awaited  https://en.delphipraxis.net/topic/988-on-demand-arc-feature-discussed/

Edited April 18, 2019 by AlekXL

[Rudy Velthuis 91]

1 minute ago, AlekXL said:

Are you a company CEO ? Some companies invested in Delphi so much, that could easy spend, say, 10 grand for fixing annoying issue. And probably you don't realize how low those fees on emerging markets

I do have my own clinic, and I could call myself CEO, but not, not in the business.

 

And 10 grand is nothing. The "fixer" would have to try to understand the complete source code, would have to find a solution without rewriting the entire compiler and without breaking anything. Think of a few zeroes more left of the decimal point, and not a few weeks, but a few years. And if things go wrong, he would face a lot of criticims and would probably have to fight for his fees too. And what makes you think you can find someone capable of doing or willing to do it at all?

1 minute ago, AlekXL said:

Look what are you saying! Shared_ptr is OK, and on-demand ARC is "not easy" -- For your information my on-demand ARC proposition is actually the shared pointers , but backed by compiler magic!

Why bother then, you would ask? Because Delphi compiler is not insanely clever, sophisticated and stable to implement those pointers in effective manner. It would screw up, undoubtedly! And on top of that we will get ugly c-like syntax, with braces, brackets, or how you call that. Get 

var shared := Auto<TObject>.Wrap (TObject.Create);

instead of

shared:= auto TObject.Create;

 

Sorry, I have no idea what you want or mean with the above pseudo-code, or with your "ARC = shared pointers backed by compiler magic". Makes no sense.

It may dampen your enthusiasm, but you may want to think about that a little longer.

 

I know what I have said. I don't care about your "ARC but not ARC" ("dead ARC"). I do care about better code generation, but not about laming ARC by not properly counting.

 

I personally find it a pity that they are phasing out ARC instead of improving upon it. But you will not see non-ARC code peacefully coexist with ARC. Your kind of "dead ARC" may coexist with proper (live) ARC (although I even doubt that), but what would be the advantage of carrying along that much dea weight? That would not be an improvement.

 

And of course the compiler/runtime can be made thus that they can be useful. They were almost there, but there were some issues. I'm sure these could have been solved, had there been enough time.

And the main advantage would not have been shared pointers, it would have been the opportunity to manually tune records with methods and operators to make them much more lightweight and performant. Shared pointers and some other scenarios would have been a nice side effect. You could write your own refcounted types, including optimized dynamic arrays (these also suffer from the runtime typeinfo/RTTI slowdown). You could have dynarrays with COW without havin to use interfaces. etc.etc.

 

But that is off-topic. Again: there is no indication that an open source team, well paid or not, could or would do better. FPC is already well on the way, so why didn't anyone create a new team, fork FPC, concentrate on the few platforms that make sense and make that great language you want? Because no one wants to pay for it, or has so much enthusiasm he will do it for free or is capable enough.

 

If opensourcing had been a viable alternative, someone would have improved FPC, or a fork, well beyond Delphi already (either by a team of highly motivated and capable enthusiasts, or a team of capable paid developers). And if Embarcadero can build a great IDE and debugger, what makes you think an icnlined team of developers couldn't do the same? So there would be a better Lazarus with a proper debugger, and there would be an incredibly cool compiler and runtime. But obviously that didn't happen yet. Guess why.

[Rudy Velthuis 91]

40 minutes ago, AlekXL said:

And on top of that we will get ugly c-like syntax, with braces, brackets, or how you call that.

What nonsense! MRecords were implemented (although not flawless) and there was no indication of curly braces, except for comments. There was not even a special syntax required. You just had:

 

type
  MyMRec = record
    constructor Create; overload;                       // default constructor
    destructor Destroy;                                 // destructor
    constructor Create(const Other: MyMRec);            // copy constructor
    class operator Assign(const Other: MyMRec): MyMRec; // overloaded assignment operator
  end;

And you would use the record like any other record. But these special methods would be called where necessary, i.e. calling our implementation, instead of the runtime typeinfo-based routines like _InitializeRecord, _FinalizeRecord or _CopyRecord.

So stop talking nonsense if you don't even know what you are talking about.

Edited April 18, 2019 by Rudy Velthuis

[Rudy Velthuis 91]

44 minutes ago, AlekXL said:

And probably you don't realize how low those fees on emerging markets

But then you get what you pay for... You probably want a capable person, and these don't come so cheap.

[Rudy Velthuis 91]

1 hour ago, AlekXL said:

Pay for a fix! Give some $50-$100 to poor student (some of them are incredibly bright), and own his work.

What a business model. Jeez! Don't tell me that was a serious suggestion?

[AlekXL 8]

38 minutes ago, Rudy Velthuis said:

And 10 grand is nothing.

For who? It's 3 months of work of top C++ developer. In Russia. Seasoned, clever. Cream of the crop. Or half-year of Delphi one.

38 minutes ago, Rudy Velthuis said:

The "fixer" would have to try to understand the complete source code

No, if the source code is not bloated mess.

You just need cover your work against the tests, run modifier version against existing ones, and  do a public beta-test..

38 minutes ago, Rudy Velthuis said:

Sorry, I have no idea what you want or mean with the above pseudo-code, or with your "ARC = shared pointers backed by compiler magic". Makes no sense.

It may dampen your enthusiasm, but you may want to think about that a little longer.

My point is shared_ptr pattern implemented with "mrecords" would be visually ugly, limited (no inheritance), inefficient both in speed and size, -- and also debugger-unfriendly. I would ask myself -- why would I use Delphi, if C++ does it just do same much better?

38 minutes ago, Rudy Velthuis said:

And what makes you think you can find someone capable of doing or willing to do it at all?

I know some developer who'd do it. For several grand, anyway.

38 minutes ago, Rudy Velthuis said:

I know what I have said. I don't care about your "ARC but not ARC" ("dead ARC"). I do care about better code generation, but not about laming ARC by not properly counting

And now dismissal. This is typical for you, isn't it?

38 minutes ago, Rudy Velthuis said:

But you will not see non-ARC code peacefully coexist with ARC. Your kind of "dead ARC" may coexist with proper (live) ARC (although I even doubt that), but what would be the advantage of carrying along that much dea weight?

  

Advantage is automatic memory management of designated instances, and keeping classic manual-control model for others, and compatibly with legacy code(which is a much, even Marco now realized that). Every Unicode string carry as much of dead weight (codepage), and still you don't complain that?

38 minutes ago, Rudy Velthuis said:

That would not be an improvement. 

Someone is terribly wrong here, and I don't think it's me. At least I pointed out advantages, I would ask Dalia, which is also ARC fan, but I doubt she would respond without prejudice.

 

 

 

Edited April 18, 2019 by AlekXL

[AlekXL 8]

38 minutes ago, Rudy Velthuis said:

And of course the compiler/runtime can be made thus that they can be useful. They were almost there, but there were some issues. I'm sure these could have been solved, had there been enough time. 

It's terribly offtopic here, and even it's not mine off-topic to boot! Those records with default and copy  ctors are nice. No one argues that. Although I'd rather see old TP objects to return in all their glory.

Because, records are  - just records.. Code without inheritance and polymorphism either is to achieve very simple tasks, or to create  ugly, bloated, and hard-to-maintain solution.

Yes, records with managed fields would be faster - which means they wouldn't terribly slow. So? If you are for speed, well, C++ is still way faster.

47 minutes ago, Rudy Velthuis said:

FPC is already well on the way, so why didn't anyone create a new team, fork FPC, concentrate on the few platforms that make sense and make that great language you want? Because no one wants to pay for it, or has so much enthusiasm he will do it for free or is capable enough.

Because it's GPL infected. Otherwise we would see many forks of it. Paid ones, too. GPL is hostile to developer. I already wrote here my maxim:

Quote

If your code is free, most likely you are not

 

51 minutes ago, Rudy Velthuis said:

And if Embarcadero can build a great IDE and debugger

Not so great. 32-bit Windows debugger is OK mostly. 64-bit is worse. GDB on android is outright horrible mess.

And It was Borland, mostly, who created Delphi. Not Embarcadero.

52 minutes ago, Rudy Velthuis said:

what makes you think an  icnlined team of developers couldn't do the same?

How many years it'll take? 30 years maybe, like from Turbo Pascal -> Delphi Rio? Lazarus is adopting LLDB now (not usable for now), there is hope. And honestly, being still ugly, FPC/Lazarus is actually already usage. I would say FPC is reaching critical mass. Actually, I'm considering opening new topic here, dedicated Delphi-compatible FPC development.

[Rudy Velthuis 91]

25 minutes ago, AlekXL said:

My point is shared_ptr pattern implemented with "mrecords" would be visually ugly, limited (no inheritance), inefficient both in speed and size, -- and also debugger-unfriendly.

What makes you think so? I don't see why they should be ugly, limited or inefficient. They would be far more efficient than ARC.

 

28 minutes ago, AlekXL said:

Advantage is automatic memory management of designated instances, and keeping classic manual-control model for others, and compatibly with legacy code(which is a much, even Marco now realized that). Every Unicode string carry as much of dead weight (codepage), and still you don't complain that?

ARC routines would have to check if an object is ARCed or not, each time. Code that receives objects must know if it i must free them or not. Etc. Would be a terrible mess and you would be draggin along the refcounts. The refcounting routines might cop out early, but they would have to be called for each access. It ia also a mess for the user. He must constantly invesitage if an object must/can/should be freed or not. They would not coexist peacefully.

[Joseph MItzen 251]

1 hour ago, Rudy Velthuis said:

Delphi has been called doomed, or dying, or on the way out for almost as long as it exists.

No, it hasn't. This is a rhetorical technique invented by Bruce McGee to dismiss any evidence of problems in the Delphi ecosystem. It's also a logical fallacy. Whatever unnamed people may have said about Delphi in another time under different circumstances has no bearing on what actual people are saying about Delphi now under these circumstances. "They laughed at Galileo!" has no bearing on criticism that my new perpetual motion machine can't work.

 

1 hour ago, Rudy Velthuis said:

And yet it is still going strong

No, it's not "going strong". That's simply factually inaccurate. There exists no quantifiable metric that pegs Delphi as "going strong". On the other hand, every quantifiable metric indicates the opposite. Pascal has long since passed its peak of popularity and it's untenable to argue otherwise. Like Marco Cantu repeatedly stating that he disagrees that the .NET ecosystem is stronger than the Delphi ecosystem, if we don't ever acknowledge the problems we can't find the solutions. Or to quote Saul Alinsky, in order to get to where you're going, you first have to figure out where you are.

 

If Delphi was "going strong", the current owner could just pump $100 million dollars or so into hiring new teams to completely rewrite the desktop compilers, buy JetBrains to get their IDE technology, maybe buy Digia solely to get their engineers' cross-platform GUI expertise, etc. In reality, every realistic conversation about what should be done to Delphi acknowledges they have very limited resources devoted to the product and surely not enough to work on major changes to IDE, compilers and frameworks at the same time. MVP Warren Postma, for instance, has related conversations with the Delphi team in which they privately acknowledged the problems with the IDE parser and that it needs a complete rewrite but management refuses to ok the time to do so. That's the reality we find ourselves in and the reality in which solutions must exist.

 

[Rudy Velthuis 91]

6 minutes ago, AlekXL said:

Not so great. 32-bit Windows debugger is OK mostly. 64-bit is worse. GDB on android is outright horrible mess.

Well then, if it is not so great, it should even be easier to do better. But obviously, not even that is done by anyone. So again, what makes you think you could find capable people inclined to spend a lot of time to produce a product you would like? What if they decide in a direction away from your wishes? Another OS project? You said a company could hire capable developers (and note that a run-of-the-milll C++ developer is not nearly a language developer -- these do earn good money, if they are good -- and if they are not good, we don't need them). Well yes, perhaps, I am not so sure they actually would. And if they do, these developers would fix the problems they encounter, not yours or mine.

[Rudy Velthuis 91]

4 minutes ago, Joseph MItzen said:

1 hour ago, Rudy Velthuis said:

Delphi has been called doomed, or dying, or on the way out for almost as long as it exists.

No, it hasn't. This is a rhetorical technique invented by Bruce McGee

No, it isn't a rhetorical technique, It is true. I have seen it myself. As long as I have been on the newsgroups (1996), people have called Delphi doomed or dying or something along those lines. Mainly because of poor marketing it has been in a much worse state and people were almost right before Borland forked off CodeGear, and yet is still going strong (yes it really is, see below).

 

6 minutes ago, Joseph MItzen said:

1 hour ago, Rudy Velthuis said:

And yet it is still going strong

No, it's not "going strong". That's simply factually inaccurate.

According to Embarcadero, and from what I see in forums like this, Idera's and on Stack Overflow, I think it is accuratet. I see lots of newbies coming from other languages having problems with some of the idioms (like 1-based strings <g>, static arrays or pointers). It seems to be selling well, despite some of the current problems with 10.3.  Oh, it is not doing as well as your beloved Python, but that's OK, Delphi has never been the top choice, but still strong enough to survive and get better (you don't survive if you don't improve).

[AlekXL 8]

54 minutes ago, Rudy Velthuis said:

nonsense! MRecords were implemented (although not flawless) and there was no indication of curly braces, except for comments. There was not even a special syntax required. You just had: 

 

55 minutes ago, Rudy Velthuis said:

And you would use the record like any other record. But these special methods would be called where necessary, i.e. calling our implementation, instead of the runtime typeinfo-based routines like _InitializeRecord, _FinalizeRecord or _CopyRecord.

So stop talking nonsense if you don't even know what you are talking about.

And now who is being rude, Rudy? Not even smartly so.. I was talking about SharedPtr pattern implementation with your fancy mrecords.

32 minutes ago, AlekXL said:

My point is shared_ptr pattern implemented with "mrecords" would be visually ugly, limited (no inheritance), inefficient both in speed and size, -- and also debugger-unfriendly. I would ask myself -- why would I use Delphi, if C++ does it just do same much better?

-------

11 minutes ago, Rudy Velthuis said:

ARC routines would have to check if an object is ARCed or not, each time.

No. Only for those variables which of auto class. Simple non-ARC-capable variable thus wouldn't generate any overhead. I need to repeat that, do I?

type 
TSomeClassDesignedToBeAlwaysAuto=class auto(TObject)// this class, and all his descendants are ref-Counted. 
end;

var simple:TObject;// no overhead, incapable of holding arc-object, due to compile time error, except unsafe typecast 
var autoExplicit: auto TObject;// incapable of holding non-arc-object, due to compile-time error
var auto :TSomeClassDesignedToBeAlwaysAuto;//same traits as autoExplicit

12 minutes ago, Rudy Velthuis said:

Code that receives objects must know if it i must free them or not

And It would, on compile-time.

20 minutes ago, Rudy Velthuis said:

The refcounting routines might cop out early, but they would have to be called for each access.

Why? Only on assignment and by-ref parameter passing..

 

21 minutes ago, Rudy Velthuis said:

It ia also a mess for the user

Don't like it? Don't use it. Go classical manual memory management. You would have choice then, unlike in present ARC

[Rudy Velthuis 91]

9 minutes ago, AlekXL said:

32 minutes ago, Rudy Velthuis said:

Code that receives objects must know if it i must free them or not

And It would, on compile-time.

At compile time?

procedure MyContainer.Add(A: TObject); 

Add does not know if A is ARC-ed or not. But it may have to know, in order to free it, much much later on, or in order to refcount it. Not at compile time. It must query the object at runtime, perhaps even several times.

Edited April 18, 2019 by Rudy Velthuis

[AlekXL 8]

1 minute ago, Rudy Velthuis said:

At compile time?

procedure MyContainer.Add(A: TObject); 

Add does not know if A is ARC-ed or not. But it may have to know, in order to free it, much much later on. Not at compile time. It must query the object at runtime.

No! Add knows, A param is not ARCed. Otherwize it would be

procedure MyContainer.Add(A:auto TObject); 

 

[Rudy Velthuis 91]

11 minutes ago, AlekXL said:

And now who is being rude, Rudy?

Are you saying that I am wrong? Calling you on your behaviour is not rude.

 

You obvioulsy have no clue about mrecords, but condemn them anyway and make absurd claims about them (e.g. about the curly braces). I merely called you on that.

 

And I don't want to convince you not to open source the compiler, because you can't do that anyway. You want to convince others, I don't, because I don't have to. I am merely telling you that your plan won't work and that is not a good idea.

[Rudy Velthuis 91]

12 minutes ago, AlekXL said:

No! Add knows, A param is not ARCed. Otherwize it would be

procedure MyContainer.Add(A:auto TObject); 

 

Wait a second. I can only pass non-ARCed objects to that container?

 

Well, thanks for making my proof. These types can obviously not peacefully co-exist. You obviously can't pass ARCed objects to that container.

 

Perhaps you could, with a second overload, but then later on, in the destructor, each object (you would have a mix of ARCed and DEADARCed objects) would have to be queried at runtime, if it it must be released or be freed. So no, not at compile time.

 

This means you can use one kind of objects along with the other, but they must live in completely separated environments, or if you mix, you must constantly query their ARCedness at runtime. Well, that is not peaceful or easy coexistence.

 

That is similar to using objects as interfaces and as objects at the same time. Not exactly the same, but very similar. I mentioned that already, i.e. the problems with interfaces. There are a few others too.

Edited April 18, 2019 by Rudy Velthuis

[AlekXL 8]

25 minutes ago, Rudy Velthuis said:

I don't see why they should be ugly, limited or inefficient. They would be far more efficient than ARC.

Because SharedPtr would be generic. You can't avoid that. So yes, brackets , braces, <whatever>. Type inference sucks when it comes to generics.

// Auto is "mrecord" implementing shared_ptr pattern
var shared := Auto<TObject>.Wrap (TObject.Create);//uglies, stupid type inference, like present, I think
var shared2 := Auto.Wrap(TObject.Create);// smarter, type infered, but still ugly -- abusing parens, like C++
var shared3= auto TObject.Create;// on-demand ARC, by AlekXL. compiler magic!

4 minutes ago, Rudy Velthuis said:

Are you saying that I am wrong?

yes. I'm saying just that.

[Rudy Velthuis 91]

7 minutes ago, AlekXL said:

Because SharedPtr would be generic. You can't avoid that. So yes, brackets , braces, <whatever>. Type inference sucks when it comes to generics.

Are you against generics too? I have done generic shared pointers, and they did not necesarily require a type in braces, when used. Type inference was actually implemented for generics well before it was implemented for inline variables. 

7 minutes ago, AlekXL said:

// Auto is "mrecord" implementing shared_ptr pattern
var shared := Auto<TObject>.Wrap (TObject.Create);//uglies, stupid type inference, like present, I think
var shared2 := Auto.Wrap(TObject.Create);// smarter, type infered, but still ugly -- abusing parens, like C++
var shared3= auto TObject.Create;// on-demand ARC, by AlekXL. compiler magic!

yes. I'm saying just that.

But I was right: you obviously have absolutely no clue about mrecords, but you condemn them and make silly claims about them. That can easily be seen in your posts, and that proves I am not wrong. Jeez!

 

FWIW, my shared pointer works like this:

 

    var MyObject := Share(TMyObject.Create);

 

No more. I hate introducing keywords when a library function/construct can solve things as well.

[Bill Meyer 337]

2 minutes ago, Rudy Velthuis said:

No more. I hate introducing keywords when a library function/construct can solve things as well.

Historically, the growth of Delphi has been very spare in introducing new keywords, and that is one of its strengths.

[AlekXL 8]

2 minutes ago, Rudy Velthuis said:

12 minutes ago, AlekXL said:

No! Add knows, A param is not ARCed. Otherwize it would be

procedure MyContainer.Add(A:auto TObject); 

 

Wait a second. I can only pass non-ARCed objects to that container? 

Again, you are rushing, the container you quoted is designed for ARC. Could you pass non-ARCed instance there. I guess yes. It would be some overhead on _AddRef and _Release, but the code would work as expected anyway

 

Alternatively, you could pass ARC-ed instance to a non ARC-ed container, provided(if you're sure), you use operator unsafe ( initially I thought about unsafe function , but it's not pascal way to abuse parens, so unsafe is low-priority right-associative operator)

procedure MyContainer.Add(A:TObject); //can only hold non-ARCed or unsafe instances

begin
 var auto1 := auto TObject.Create();
MyContainer.Add( unsafe auto1);//you used unsafe, now you are on your own. Risk it, if you are sure
end;

Of course, adding Arc-ed instance to a TObjectList , which ownObjects=true  is outright stupid.

But TList<auto TObject> standard generic is quite alright.

Again, from the compiler standpoint  auto class type is not fully compatible with non-auto same_class

type TAutoObject=auto TObject;

TAutoObject would share VMT with TObject, maybe even RTTI (not sure), but still it's different type

 

[AlekXL 8]

4 minutes ago, Rudy Velthuis said:

var MyObject := Share(TMyObject.Create);

clarify full signature of Share function.

(signature stands for full declaration)

[Rudy Velthuis 91]

1 minute ago, AlekXL said:

Of course, adding Arc-ed instance to a TObjectList , which ownObjects=true  is outright stupid. 

No, it isn't. It can make a lot of sense, especially if you want to mix both types. Your way means you can't easily mix DEADÀRCed and ARCed objects. There may be other reasons to query the ARCedness when objects are mixed, and that must be done at runtime.

 

Again, no easy or peaceful coexistence.

[AlekXL 8]

3 minutes ago, Bill Meyer said:

Historically, the growth of Delphi has been very spare in introducing new keywords, and that is one of its strengths

but a lot of directives, right? automated, varargs, protected, strict protected, reintroduce, dynamic, dispid  and more and more ...

Delphi power is about readability --  less braces, brackets, and parens, comparing to C/C++. They are pain to read, pain to write

Attributes especially compiler-like like [ref] [unsafe] [weak] [volatile] -- this is real blasphemy

Generics syntax are just barely better.

 

It's wouldn't hurt anyone to add a keyword or two.