Yes, you are right, from the point of view of formalism C and C++ are standardized. And Pascal and Object Pascal are not standardized. I.e. more specifically, there is no committee for Pascal and Object Pascal. However, practice shows something else. Apparently this standardization of C and C++ works, but there are many exceptions in the operation of these compilers.
I can only disagree. While I don't work with C and C++ anymore (aside from a few side projects), I used both languages very intensively for quite some time. And while it's true that some parts of the standard tend to not be adopted (C++ had multiple approaches for modules), in general if you write ISO compliant C and C++ code it works identical on all major compilers.
The problem is neither the standard noch the compilers. The problem is that a lot of C and C++ developers specifically work outside the standard. For example, the C standard says that int is a signed type with at least 15 significant bits and long at least having 31 (31 significant bits in going from -2^31..2^31). In practice it's very compiler and target dependent. On many 32 bit systems and compilers both are 32 bit, but on 64 bit systems often int is 32 bit and long 64.
The problem now is if you have programmers writing code assuming that int is 32 bit and long is 64 bit, then you port this to another compiler and it breaks. But thats not the fault of the compiler or standard, the standard specifies the type int32_t and so on, which guarantee to be 2nd complement with an exact bit number. So the actual problem is that many programmers rather write "int" than "int32_t" and then wonder why it breaks on porting to another system.
If you are writing ISO compliant C, your code will run identical on GCC, Clang, MSVC, Intel C, Boarland C++, etc. It's just that a lot of C developers don't know the standard very well.
In practice, to maintain strict control over the development of the language, sometimes it works better when there is a single entity setting the rules of the game (unless it suffers from schizophrenia). These smaller entities then have no choice but to comply or disappear. But there are exceptions, e.g. C# or Swift. Although C# probably has a more stable specification than Swift. On the other hand, decision-makers at Apple have no qualms about changing the rules of the game every now and then, and in many different matters (corporate schizophrenia?). Either way, the problem, as usual, is people who don't want to cooperate with each other, but everyone wants to show how important and smart they are. But this is a non-IT topic, so I will take a break here.
I mean it generally depends. Languages like C# and Swift work well because the company that makes these decisions also takes the effort to make it attractive. Swift while being a really good language, is only really a thing because it's the native language for iOS and MacOS. Without that probably no one would use it. Similarly Microsoft put C# with .Net, ASP and also their contracts with Unity, into a very good position.
If you want an example of where this didn't work well, you can look at the very same companies. Besides Swift Apple first developed Objective C, and everyone hated it. And Microsoft besides C# introduced VB.Net.
Why isn't there? The FPC programming team is a committee 
Does it need to have the "anointing" of corporate CEOs, like the C++ committee? Luckily for us, no
Well the thing about Standardization organizations is that they are open to anyone and work transparently. For example if I want to contribute to an ISO standard, joining the ISO working groups, while being annoying, is not very difficult. All you need to do is to join your national Standardization Organization, so for me here in Germany it would be the DIN, which granted is tailored towards companies and costs like a Thousand euros per year, so it's not really free, but this is literally the only payment you have to do and it's fixed.
From that point onwards a lot of beurocracy has to be done, with different roles and positions. The first step is to join the national mirror working group. Basically whenever the ISO makes a new proposal, it is sent to all the UN member state standardization organizations, where the mirror working groups can then have an internal vote and this vote is then given to the ISO committee. So taking my example I would be then as a member of DIN get to vote for the opinion that DIN/Germany would hand in at the ISO.
As part of this vote the member states can elect delegates which will then become members of the working group. Besides the national delegates theres also the option to get chosen as independent expert. Once you're in there you can take part in the comittee work, if you want to take the role of editor or other special roles you can apply for that in the comittee work.
Lastly once the draft is finalized it will again be given to the national SDOs to get the final vote. Meaning no matter if you get delegated or anything, as long as you become a member in your national SDO you will have a vote.
I myself am for my work right now in this process of getting into certain standardization working group, and while it's a beurocratic pain that takes many months, it is quite non discriminatory and does not depend on budget or something.
Also important is that the SDOs have clear procedures for the working groups, where the discussions and decisions are well documented each meeting is preceded by minutes outlining the topics, decisions and reasoning, and everything will be published so that every single decision can be traced back to why it was taken, when and by whom.
There are different governance models, each with their pros and cons. The three most notable are standardization through an SDO, maintainance through a Foundation and Private ownership. SDOs are the most transparent and give everyone the opportunity to contribute with equal voting power, independent of money. On the flip side they have a lot of beurocratic overhead and tend to underspecify. Foundations (like for example with Python) tend to favor the contributers who "donate"/invest the most money, here often voting power is proportional to financial contributions. And private ownership tends to have a very specific target and vision that is important for the maintainer, e.g. Swift is specifically designed for iOS development, to the degree that Swift for Linux or Windows is just an after thought. But the Maintainer has no obligations other than to themselves. For private projects (as Zig or how I would also consider the FPC to a certain degree) it's often a question of vision of the maintainers, while for companies it's usually first and foremost their personal business interests.
So the reason why the FPC maintainers are not comparable to an SDO commitee is simply that there are no rules for them. There are no general organizational rules like there are for SDOs (e.g. EU Regulation 2012/1025 for european SDOs), there are no Rules of Procedure for the working groups and official subgroups, there are no formalities, no requirements on documentation and no formal voting. You can't sue them if they don't follow procedure, and they aren't responsible to anyone but themselves.
Not saying that this is necessarily a bad thing, personally I find it better than the embarcadero approach. That said, looking at extended Pascal standardized by ISO there are a lot of things in there that are very well thought out and are something that would be still beneficial today
Recent
