
The Universal Standard Library - ryan-allen
http://clintonforbes.blogspot.com.au/2012/05/universal-standard-library.html
======
ken
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.

------
ChuckMcM
Ah to be young again :-)

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.

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

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

~~~
jhuni
To what 'bit' do you refer? Do you have a direct quote?

~~~
bitwize
_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._

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

------
rurounijones
So how do you work around the problems where, for example. (Simplest, quickest
example I could thing of.)

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.

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

------
nash
Wait... I've seen a discussion on this recently.

Oh, yes... here it is: <http://xkcd.com/927/>

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

------
mrsteveman1
I'm _fairly_ sure [@"String" lowercaseString] doesn't return an uppercase
string in Objective-C :)

~~~
forbes
Fixed. Thank you for contribution to the USLS.

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

------
kiba
This remind me of a XKCD comic about competing standard:

<http://xkcd.com/927/>

~~~
unimpressive
Or their latest comic:

<http://xkcd.com/1061/>

~~~
jcmhn
I figured that second one was mocking the papal bull laying out the rules for
leap years.

In your face, 16th century papacy!

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

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

------
0x09
> 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().

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

------
sanxiyn
This sounds like various W3C specifications written in WebIDL to me.

~~~
ZenPsycho
Yes sadly, when you set out to make a language agnostic standard library, what
you end up with is the browser DOM.

------
chrisfarms
this gave me an idea for a DuckDuckGo Instant Answer Plugin [1]....

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

------
halayli
strupr is not universal and not standard.

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

