When the revolution comes, the creators of standard libraries are going to have some explaining to do.
Below is the Top 20 from the (mostly meaningless) TIOBE popular programming languages chart, and the name of the function to transform a string to upper case in that language:
(This list was quickly researched so if I got your favourite language wrong, then please feel free to rip me apart in the comments.)
Even ignoring the capitalization of the function names, it astonishes me that there are very few cases where the name is the same in different languages. I'm the kind of demented person that works in different languages for different jobs and this diversity gets very annoying. It is not unusual for me to work in 3 or 4 different languages in a week and I can tell you that remembering the language syntax is much easier than remembering all of the different names of all of the different common functions.
Now you may think this is a minor gripe but the "upper case" example is obviously only one of hundreds of commonly used functions. The inconsistency is nothing if not consistent.
The Solution
The CSIRO (Australia) has calculated in a 2010 study that the amount of time wasted annually by the estimated six million professional software developers world-wide due to inconsistent standard library naming is equal to the GDP of Portugal [citation needed].
Being the nice guy that I am, I will single handedly solve this issue once and for all by:
Below is the Top 20 from the (mostly meaningless) TIOBE popular programming languages chart, and the name of the function to transform a string to upper case in that language:
| C | strupr |
| Java | toUpperCase |
| C++ | transform (with toupper parameter) |
| Objective-C | uppercaseString |
| C# | ToUpper |
| PHP | strtoupper |
| (Visual) Basic | UCase |
| Python | upper |
| Perl | uc |
| JavaScript | toUpperCase |
| Ruby | upcase |
| Visual Basic .NET | ToUpper |
| PL/SQL | UPPER |
| Delphi/Object Pascal | uppercase |
| Lisp | string-upcase (Common Lisp) |
| Logo (really?) | instruct turtle to take bigger strides |
| Pascal | uppercase |
| Transact-SQL | UPPER |
| Ada | To_Upper |
| Lua | upper |
(This list was quickly researched so if I got your favourite language wrong, then please feel free to rip me apart in the comments.)
Even ignoring the capitalization of the function names, it astonishes me that there are very few cases where the name is the same in different languages. I'm the kind of demented person that works in different languages for different jobs and this diversity gets very annoying. It is not unusual for me to work in 3 or 4 different languages in a week and I can tell you that remembering the language syntax is much easier than remembering all of the different names of all of the different common functions.
Now you may think this is a minor gripe but the "upper case" example is obviously only one of hundreds of commonly used functions. The inconsistency is nothing if not consistent.
The Solution
The CSIRO (Australia) has calculated in a 2010 study that the amount of time wasted annually by the estimated six million professional software developers world-wide due to inconsistent standard library naming is equal to the GDP of Portugal [citation needed].
Being the nice guy that I am, I will single handedly solve this issue once and for all by:
- Creating a new set of namespaces, class names (if needed), function names and type signatures (if needed) that will be known as the "Universal Standard Library Specification" (USLS). The USLS committee will consist of one person - me. All decisions will be final.
- Standard library implementors will implement the standard. This will be done initially with aliases and wrapper functions. Minor variations due to allowable characters in identifiers (eg. - ? !) will be acceptable upon payment of a nominal fee per variation to the USLS committee.
Of course the USLS project will initially make the inconsistency problem even worse by introducing yet another set of names and polluting the internal consistency of existing code-bases. Making the situation much, much worse to solve the problem is unfortunately unavoidable during the transition period. The USLS committee expects the transition period to last for no more than 30 - 50 years before the USLS becomes commonplace.
If you support my project please leave feedback in the comments. If the support is large enough then I will be starting a Kickstarter campaign in the coming days to raise money to buy the USLS a Nissan GTR. The powerful 4WD sports saloon will be required to carry USLS documents to standard library implementors in a timely manner.
