Leaderboard

Seriously???? You would leave five year old alone in control of the house when parents are away? Actually, it would be more like leaving the five year old with matches and can of gasoline. Let me say it again: Somebody (Embarcadero employee), extremely knowledgeable in particular code base would have to be gatekeeper - managing pull requests and communicating with community in general. That somebody would have to be top gun compiler engineer, someone from existing team who knows code base well, not someone who would they just throw in working for peanuts. So yes, under current circumstances that would take valuable resources away from current compiler development. And that is something we (or Embarcadero) cannot afford at this time. Yes, it would be good if Embarcadero would expand their core teams. That would be good move regardless of open sourcing . But even if they manage to hire good engineers today, it would still take quite some time before such expanded team could bear the burden of open sourcing. LOL And leaving amateurs to rampage all over the compiler, yeah, that would end really well. As far as RTL/VCL/FMX is concerned, it is not about catering for all old versions in existence out there. It is about going forward, so no compiler version would not pose a problem.

I would gladly forego the open sourcing if we could just get such a team now.

It is pretty obvious that you do not care. You should care because this is a public forum, not just yours. Now we have told you several times to move your specific discussions about technical details of the Delphi-language to a separate thread. Most of these posts are offtopic now. You did not care at all. Do I really have to explain to you why it is important for us to stay on a topic? It is not that complicated. If any other person wants find find some information later, they will look for the thread-title to decide for reading a topic or not. This „let us talk about everything“-threads do not help anyone.

LOL! I mean, coming from you, that is funny. <g>

If it were so desirable and/or so easy to maintain the Delphi compiler, I wonder why FPC didn't make Delphi obsolete already. I guess because after all there are not so many people capable of maintaining, nor enough people inclined to do it. I also gues that the task is not so easy. I have said it before, and I'll say it again: I use a lot of open source and I love open source and I have participated in open source, but the notion of "open source it so you can always fix it yourself" is pure nonsense. Even if I suffer from some bugs (and indeed, Rio seems to have quite some new bugs and slowdowns caused by the -- incompletely -- removed mrecords, i.e. the runtime changes still affect current code, even if mrecords themselves were removed again), I am not capable nor willing to read the entire (possibly hard-to-read) source code of the entire compiler and then I'm not capable of making a decision what I can safely change without causing a multitude of other bugs. I will leave that to others. I am not so sure there are enough "others" who could or are willing to maintain the Delphi compiler. Nor am I willing to hire someone to fix them for me. People who could do that would probably require large fees too. So no, open sourcing the compiler is useless, IMO. Rather lean on Embarcadero and confront them with "love withdrawal" or other sticks behind your back and let them do it. I agree we need bug fixes and new features. But open sourcing won't provide them. Only pressue on Embarcadero can.

EMBT needs a long-term strategy. This could include a open source part. (Only) Open Sourceing Delphi (or parts) isn't the solution, it can be the end.

I am not sabotaging anything. I am merely presenting the facts that must be taken into account. Without that it may look like open sourcing the compiler is just one GitHub click away and Embarcadero is not doing that "good" move on purpose because <insert conspiracy theory du jpur> Also, when it comes to sabotaging, like I already said, you don't need any help in that area, you are perfectly doing that yourself. Your request lacks any real arguments and is basically insult to everyone working at Embarcadero.

You are really an expert in convincing others to support your ideas. Using a tone like that is certain to win them over. <g> I did not read the entire topic (7 pages an counting...) and I will not. If you had anything useful to say, then repeat it. But no matter what you wrote, I'll write it again: no, they won't easily coexist at all.

I'm just curious. Do either of you have a stopping condition?

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

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. 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.

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). 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).

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. 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.

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/

@AlekXL Please consider reading your posts while taking your opponents point of view. Then please consider them to be human beings. Then alter your text, defusing the disses, then take a deep breath, read it again, insert some final niceties and finally post it. Moderators have been lenient thus far, but patience is growing short.

Probably Alek definitely simplifies and exaggerates with ease the entire process of opening and managing sources. However, one thing is certain. Delphi requires quick and bold changes, or else it will drown.

It could be an option to have a (restricted access) repository somewere with the RTL/VCL code where "the community" collects patches for everybody to use. But that poses several questions: Which versions of the RTL/VCL are maintained there? Only ever the latest one? But what about people who are stuck with older versions for whatever reason? What about forward- and backporting fixes if multple RTL/VCL versions are maintained? Who maintains it? This/ese person(s) would be the gate keeper(s) to proposed patches. Who grants / revokes access and on which criteria? Is every Delphi customer allowed access, even if he only ever bought Delphi 1? Or is it restricted to the version(s) he bought? How does he prove that? Even if only the latest RTL/VCL is maintained, what about the .x.y Delphi releases? These are of lately only available to customers with subscription. I think that could be quickly become a nightmare for the maintainer(s), not just the technical issues, but even more the legal issues.

Yes, but sometimes it takes several iterations for some fix, or needed feature to end up in release. And patching on your own takes time. If everyone has to do it that is huge waste of time.

I know that, but how many successful pull requests have you gotten into RTL/VCL/FMX so far?

My comment under the QP request that explains my stance on the matter. I don't want to enter into endless discussion there because it is ultimately the wrong place. @Marco Cantu enabling access to compiler (or any other sources) and allowing community contributions does not mean giving it for free. You can put up any license terms you want. I know that enforcing license is harder than having closed source, but people that will violate such licenses will just use cracked versions anyway - that is far simpler that rebuilding compiler on their own, only handful of developers would go that route. While Delphi compiler code might be worth studying for those interested in compilers, I highly doubt there is any ground breaking technology there worth stealing nowadays. From that perspective opening compiler (or other sources) does not seem like showstopper. @All however, open sourcing (I will use that term, regardless of what the actual licensing model would be) is not as simple as mere dumping source on GitHub. Somebody (Embarcadero employee), extremely knowledgeable in particular codebase would have to be gatekeeper - managing pull requests and communicating with community in general. In order to open sourcing to be successful endeavor there must be significant number of contributions made, without that - the whole thing makes no sense for Embarcadero (and for the community as well - beyond satisfying everyone's curiosity). In that case gatekeeper(s) will have their hands full. Not to mention that for every successful contribution, there will be countess others that will have to be reviewed and rejected for various reasons. That part introduces additional cost to Embarcadero and ability to develop code on their own, because part of the resources that would be used to developing in house will have to be spent for community interaction. Eventually, gains from community code can outweigh the costs, but that would take some time. Also, in code base that large, it may take years for community to start contributing in meaningful manner. And gate keeping would have to start immediately. There will be developers that will jump in from the start trying to fix their pet pevee without looking at bigger picture (breaking things like bull in a china shop). Now, that might look like - it it would take long time, let's start early then... but like I said, initial cost in terms of resources might be too high. Especially, now when there is a lot of work to do on various compilers - new ones (Android and macOS 64bit), including introducing some new features that are already in the works. From that perspective, open sourcing compiler in general... yes, but I don't think now (or any time soon) would be the right time. Right now (or soon enough), opening up sources to RTL/VCL/FMX would be much better move - we already have the sources, we already know our way around them. Community at large can more successfully contribute to those sources than to the compiler. Again, that kind of project would also have some initial cost, but I believe it could pay off much sooner. Open sourcing is the double edged sword - in order to be successful it takes resources that would otherwise be spent on in house development (with much higher initial progress rate). But the push for open sourcing (because, of the illusion that community can fix things faster and better) is greater in times when internal resources are spread thin, than in the times when everything works peachy. So it is kind of damned if you do damned if you don't situation.