Making the situation much, much worse to solve the problem is unfortunately unavoidable during the transition period.
This makes me lol. Marx should have included that in his Communist Manifesto right after the bit about taking despotic measures to guarantee freedom for the proletariat.
Of course, in the beginning, this cannot be effected except by means of despotic inroads on the rights of property, and on the conditions of bourgeois production; by means of measures, therefore, which appear economically insufficient and untenable, but which, in the course of the movement, outstrip themselves, necessitate further inroads upon the old social order, and are unavoidable as a means of entirely revolutionising the mode of production.
Ah yes, the good old "dictatorship" of the proletariat which introduces "despotic" inroads in order to create a communist utopia. For example, the Eastern bloc countries were "dictatorial" and "despotic" because they were never communist.
I think I will go about this slightly differently. When I finally get around to writing the language I have in my mind, it won't have a "new" stdlib, it'll probably just use the python standard library (with modifications for changed semantics). I guess one could say that it could be a potential source of issues, as there will be some concepts that just do not map from one language to the other. However, seeing as I'll probably be the only one using it, I'm not too worried.
That's a completely reasonable approach (although I personally would choose something other than Python as my base). In fact, a bunch of languages do this already--most any JVM language (especially ones unique to the JVM) and .NET language take most of their standard libraries from Java or C#.
The fundamental problem with this approach is that either your language is too different from the host for the library to map perfectly or it's too close to the host too be terribly interesting.
the problem with using an existing stdlib (semantic incompatibilities aside) is that then you end up unable to fix the warts.
Say, you are annoyed by dicts' oddly named `has_key` and `fromkeys`, either you change them (yet another stdlib) or you don't (no improvement).
Bigger C libraries like APR and GLib are already candidates for this. The only problem is, their language bindings did often mess up consistency anyway. This can be fixed with gobject-introspection or similar.
Side Comment: If Oracle prevails in copyrighting an API this problem will get worse.
I ran smack into a variant of this problem playing around with ARM chips, libc. Its one of the places where gcc has really let me down, because if you get an ARM cross compiler its expecting anything and everything. The various flavors of C library are all bulky and nicely modularized but somehow less useful. And of course there are things in there which assume an OS (stdio for example) or at least a model that the code adheres to) but embedded systems are sometimes not that easily adapted.
And there are libraries provided by the manufacturers which have copyright notices in them about how this code can only be compiled to run on their (the manufacturer's) brand of ARM and when I look at the code I keep thinking "Hmm, I bet if I dug up the code I wrote for SunOS 4.0 when I was but a wee kernel hacker to make libc work with shared libraries, that a lot of it would be eerily familiar :-)
So what it boils down to are that there are 'things' and the useful things are 'memory abstraction (bcopy/memcpy etc)' string abstractions 'str' and character abstractions 'is' and then io abstractions (open/close/read/write/seek/rewind) and then thread abstractions (fork/sleep/wake/longjmp/yield) and suddenly your USLS is basically an OS API (or it could be) and you're back to square zero.
So rather than a universal library, why not universal VIM code? VIM is already syntax aware based on your language you could add the ability to insert the appropriate code to do what you wanted to do while you were editing. So if you had a variable and you typed if a:upcase == b:upcase it would syntactically awarely conver a:upcase to 'strtoupper(a)' or u"$a" or a->upper() or what ever the language you were writing in needed. Sort of a markdown for library calls. Then you train your fingers to type the markdown and be done with it.
OS and libraries have different roles: an OS manages the sharing of resources between programs, while libraries implement common operations in programs. The abstraction aspect in both really is a side effect.
Back to the topic: I think the real obstacle to this USLS idea is that each language has its own idiomatic way to name things, so a common across languages naming scheme or convention will likely look somewhat alien in each of them, and we all know the importance of source code aesthetics for programmers. This might change only if polyglot programming becomes very common.
BTW, despite being used mostly for "turtle graphics" in middle schools, Logo is a real programming language, and does have an "uppercase" function -- http://rosettacode.org/wiki/String_case#Logo
Common Lisp's is actually called STRING-UPCASE, not string-upcase, though with the default reader settings that will work too.
I'm afraid this is going to be completely futile. Leaving aside the "yet another standard" issue, the real problem is that standard libraries need standard type systems and standard type systems are never programming language agnostic. Also, things like namespaces and function overloading have an impact on naming things.
Do you propose that things have the same name, even when the meaning is different?
Some of these functions change the string in-place (C), and others return a new string (Objective-C). Some languages have both options (Lisp), while others can't because strings are immutable (Python). Some languages define strings as arrays of characters, and others have some other opaque array-like structure made up of characters, and others have no concept of a character at all (just "length-1 strings"). And so on.
The biggest differences between languages are not names, but semantics. My editor will happily remind me of the proper name in any language, but that's the least of my worries since I've got to mentally shift gears anyway. The algorithm I write for different kinds of strings can be completely different.
I'm reminded of a similar issue with GUIs a few years back, when Redhat (I think) made themes to unify the look of GNOME and KDE, even though they still worked differently. The conclusion reached was that they should have unified the behavior first (always a good thing), rather than unifying the appearance first (which led to more confusion).
But that could be a problem for programming languages, since these differences are pretty fundamental.
> if I got your favourite language wrong, then please feel free to rip me apart in the comments
Well, "strupr" is not part of ISO C at all. In fact I'm having a hard time finding out just which libc it comes from. Unfortunately the only uppercase function in the standard C standard library is the one you write yourself using toupper().
Well, I find this topic rather meaningless, as every language has it's own code writing style and conventions, which may greatly differ, between C#, and, say, PHP.
Plus, AFAIK CLR plays exactly this role in .Net, providing common functions across supported languages.
The Common Lisp identifier names are the only standard I need. For my own personal use, I am not going to accept anything other then the Lisp naming conventions, which use lower case characters separated by dashes for identifiers. As such string-upper will continue to do just fine as it has been for decades.
28 comments
[ 6.0 ms ] story [ 66.0 ms ] threadThis makes me lol. Marx should have included that in his Communist Manifesto right after the bit about taking despotic measures to guarantee freedom for the proletariat.
http://xkcd.com/927/
http://xkcd.com/1061/
In your face, 16th century papacy!
Oh, yes... here it is: http://xkcd.com/927/
The fundamental problem with this approach is that either your language is too different from the host for the library to map perfectly or it's too close to the host too be terribly interesting.
PHP = strtoupper($str)
Ruby = "Hello".upcase
Since Ruby is a method on the string object and PHP takes the string as an argument. To make them the same you would need to do either
PHP = upcase($str)
Ruby = "Hello".upcase
In which case you lose context in PHP or
PHP = strtoupper($str)
Ruby = "Hello".strtoupper
In which case you are repeating yourself in ruby.
Side Comment: If Oracle prevails in copyrighting an API this problem will get worse.
I ran smack into a variant of this problem playing around with ARM chips, libc. Its one of the places where gcc has really let me down, because if you get an ARM cross compiler its expecting anything and everything. The various flavors of C library are all bulky and nicely modularized but somehow less useful. And of course there are things in there which assume an OS (stdio for example) or at least a model that the code adheres to) but embedded systems are sometimes not that easily adapted.
And there are libraries provided by the manufacturers which have copyright notices in them about how this code can only be compiled to run on their (the manufacturer's) brand of ARM and when I look at the code I keep thinking "Hmm, I bet if I dug up the code I wrote for SunOS 4.0 when I was but a wee kernel hacker to make libc work with shared libraries, that a lot of it would be eerily familiar :-)
So what it boils down to are that there are 'things' and the useful things are 'memory abstraction (bcopy/memcpy etc)' string abstractions 'str' and character abstractions 'is' and then io abstractions (open/close/read/write/seek/rewind) and then thread abstractions (fork/sleep/wake/longjmp/yield) and suddenly your USLS is basically an OS API (or it could be) and you're back to square zero.
So rather than a universal library, why not universal VIM code? VIM is already syntax aware based on your language you could add the ability to insert the appropriate code to do what you wanted to do while you were editing. So if you had a variable and you typed if a:upcase == b:upcase it would syntactically awarely conver a:upcase to 'strtoupper(a)' or u"$a" or a->upper() or what ever the language you were writing in needed. Sort of a markdown for library calls. Then you train your fingers to type the markdown and be done with it.
Back to the topic: I think the real obstacle to this USLS idea is that each language has its own idiomatic way to name things, so a common across languages naming scheme or convention will likely look somewhat alien in each of them, and we all know the importance of source code aesthetics for programmers. This might change only if polyglot programming becomes very common.
Common Lisp's is actually called STRING-UPCASE, not string-upcase, though with the default reader settings that will work too.
Some of these functions change the string in-place (C), and others return a new string (Objective-C). Some languages have both options (Lisp), while others can't because strings are immutable (Python). Some languages define strings as arrays of characters, and others have some other opaque array-like structure made up of characters, and others have no concept of a character at all (just "length-1 strings"). And so on.
The biggest differences between languages are not names, but semantics. My editor will happily remind me of the proper name in any language, but that's the least of my worries since I've got to mentally shift gears anyway. The algorithm I write for different kinds of strings can be completely different.
I'm reminded of a similar issue with GUIs a few years back, when Redhat (I think) made themes to unify the look of GNOME and KDE, even though they still worked differently. The conclusion reached was that they should have unified the behavior first (always a good thing), rather than unifying the appearance first (which led to more confusion).
But that could be a problem for programming languages, since these differences are pretty fundamental.
Well, "strupr" is not part of ISO C at all. In fact I'm having a hard time finding out just which libc it comes from. Unfortunately the only uppercase function in the standard C standard library is the one you write yourself using toupper().
A mapping/grouping of related functions in each language that allows you to perform searches like:
"toUpperCase in Ruby" "upcase in Python"
[1] http://duckduckhack.com/