Most programming languages today are highly centralized. In cases such as Python, Perl, and Java, there is a single organization that controls the production of a "canonical" compiler and standard libraries. Other programming languages like C or C++ may have no reference implementation, but their development is governed by detailed standards that are administered by a single body (such as ANSI).
Additionally, libraries for programming languages are centralized. Generally a library is the creation of a single person or small group of people, and any changes to the library must be vetted by the maintainers before they can attain widespread use. Anyone can make a fork of an existing library, but a fork will not be as trusted since it doesn't come from the original library maintainers.
I believe that centralization (of compilers and libraries) is detrimental to the long-term development of a programming language. Centralization forces the language to conform to the vision of just a few developers, which might not be in tune with the needs of the community. Additionally, it requires a great deal of effort to produce a full library or compiler revision, shutting out the people who might want to contribute just one small function. My ideal programming language would be capable of growing organically over time as its users develop bits of functionality for it.
The two most important considerations for the core implementation/specification should be extensibility and provability. Extensibility is obvious: the core language must allow users to extend it in fundamental ways, through things like lisp-style macros and source code transformations. Provability means that the language should facilitate the use of formal methods. The language should come with a logical formalism allowing one to formally assert and prove things about the operation of programs. This is necessary because much of the functionality of the language may be implemented by untrusted third parties, and we need a way to verify that code from these people works as claimed.
Once we have a core language, we need a collaboration tool that allows people to add bite-size contributions. I believe that this purpose is best served by a function-level source code distribution network. When someone has produced a snippet of code--a function, perhaps--that person posts his individual snippet to the network. Other people review and rate the code to check that it is not malicious and that it has no bugs. Code should also be rated based on its usefulness. Then when someone wants to do something with the language, he or she looks on the network for a highly-rated function that does it. The network should also provide significant search functionality to help a user find the function he needs.
Additionally, libraries for programming languages are centralized. Generally a library is the creation of a single person or small group of people, and any changes to the library must be vetted by the maintainers before they can attain widespread use. Anyone can make a fork of an existing library, but a fork will not be as trusted since it doesn't come from the original library maintainers.
I believe that centralization (of compilers and libraries) is detrimental to the long-term development of a programming language. Centralization forces the language to conform to the vision of just a few developers, which might not be in tune with the needs of the community. Additionally, it requires a great deal of effort to produce a full library or compiler revision, shutting out the people who might want to contribute just one small function. My ideal programming language would be capable of growing organically over time as its users develop bits of functionality for it.
Design of an Organic Programming Language
First, to avoid centralization, the core implementation/specification of the language should be as small as possible. It should lay out the basics of function calls and a type system--barely a step or two above the lambda calculus. It should be agnostic with respect to as many language features as possible, perhaps not even specifying integers or strings. Even basic language features should be decentralized and user-implemented instead of built-in.The two most important considerations for the core implementation/specification should be extensibility and provability. Extensibility is obvious: the core language must allow users to extend it in fundamental ways, through things like lisp-style macros and source code transformations. Provability means that the language should facilitate the use of formal methods. The language should come with a logical formalism allowing one to formally assert and prove things about the operation of programs. This is necessary because much of the functionality of the language may be implemented by untrusted third parties, and we need a way to verify that code from these people works as claimed.
Once we have a core language, we need a collaboration tool that allows people to add bite-size contributions. I believe that this purpose is best served by a function-level source code distribution network. When someone has produced a snippet of code--a function, perhaps--that person posts his individual snippet to the network. Other people review and rate the code to check that it is not malicious and that it has no bugs. Code should also be rated based on its usefulness. Then when someone wants to do something with the language, he or she looks on the network for a highly-rated function that does it. The network should also provide significant search functionality to help a user find the function he needs.