The end to all language wars and the great unity API to come!


R

rantingrick

Hello fellow programmers, scripters, hackers, and debutantes.

I have cross posted this thread to three groups that i believe need to
unite under the flag of unity for the benefit of all. Because when we
unite we not only help ourselves, we promote freedom. In the next few
paragraphs i will expose the source of this problem and propose a
viable solution for how WE can solve the problem!

It saddens me when i see API's that don't include at least three
language choices. No *one* language is going to please the masses. I
understand *WHY* this happens however it should never, *EVER* happen
and i cannot lay blame solely on application developers because "we"
have failed to provide them NOT ONLY with a unifying API model, but
also our respective "plugin" interfaces to that unifying model.

Yes folks "WE" are to blame for this dilemma. Who is "we" exactly?
"We" is any language community who's language exhibits the traits of
an API scripting language. For me that group includes (at the minimum)
Python, Ruby, Basic, Perl, JavaScript, and whoever else wants to be
part of this group.

Everyone knows that no one language can solve all problems. And
likewise everyone knows that even when two languages are similar (in
few ways, or in many ways) people are always going to draw lines in
the sand and prefer to use one language over another. It is natural to
simply ones working environment. How many of you folks speak English
on Mondays and Mandarin on Tuesdays and Spanish on Wednesdays and
French on Thursdays and Bulgarian on Fridays and Pig Latin on
Saturdays and Orc on Sundays? Anyone? Why i am not surprised!

But we do this very same asinine thing on a daily basis whist jumping
through the productivity limiting hoops. The stench of which rises up
from every community of language developers in the world. We have not
only created a mutual cess pool of laziness and selfishness , we are
wallowing and rooting around in it completely oblivious of our
collectively bombastic stupidity.

So i ask yous, why should we continue to propagate hateful feelings,
or have some among us feel left out because their favorite language is
not included as an alternative in the API they are using at the time?
Why should i need to switch back and forth between multiple languages,
multiple syntaxes, multiple editors, multiple help files, multiple API
help files, and suffer multiple headaches just because the status quo
is to be selfish and not care about the greater "Programming
Community".

"Community". Hmm, now that is a word that can be applied in many
dimensions. The "Python Community" is a community that inherits from
the "Programming Community"... as is the "Ruby Community" and the
"JavaScript Community" and so on and so forth. We are naturally good
at taking care of our immediate community but for the community once
removed we are failing miserably! And this community is the most
important community of all! When we damage the programming community
we damage ourselves and everyone else!

[Thought Exercise] Just imagine for a second if automobiles where
engineered the way programming languages are currently engineered. But
wait! Before we jump into insightful analyolgies we must first
understand why the automobile is such a versatile feat of engineering.
The automobile -- no matter how large or small, not matter if truck or
car or motorcycle or moped-- is designed to interface with a system...
the "highway" system. The user of an automobile is never restricted
from driving his favorite car. He is always happy because he is free.
Free to choose and free to be.... HOWEVER NOT THE CASE WITH APIs!

For API's we have just tossed freedom to the wind fro the sake of
selfishness. We would have multiple language developers creating
languages without any regard for a language independent system to plug
said language into. But i am here to tell you that we can be different
with our language style and still promote the freedom to choose. The
tool is NOT Ruby or Python or whatever. The tool is software which
manifests itself as "ones" and "zeros". Layers of abstraction that all
compile to the same base units... 1's and 0's. Languages are
abstractions of ones and zeros. Languages are NOT tools. Therefore we
all have a vested interest in a unifying API.

Well some would say... " it is up to the developer of an application
what language they choose"... and this is true. But i say they can
choose to allow the users to choose thereby maintaining not only a
happier user base, but a more productive one as well.

When are we going to see the light and start unifying our collective
differences into a singular plug and play API and allowing the user of
"our" abstraction language, "our" for loop, or "our" version of
stdout.write the ultimate of all choices... the choice of FREEDOM.

for danish inspirations see:

http://wiki.services.openoffice.org/wiki/Uno

Thank You
 
Ad

Advertisements

C

Chris Angelico

I know I shouldn't get sucked into responding to a rant, but it's like
a black hole - it's inevitable you'll cross the horizon...

It saddens me when i see API's that don't include at least three
language choices. No *one* language is going to please the masses.

This is pretty much the entire argument, everything else is exposition.

It takes work to suit your API to a different language. Let's take GNU
Aspell as an example; it's a good tool, and the ability to spell-check
something is sufficiently general that many programs can make use of
it.

Its list of "supported languages" isn't what we're looking for, though
(it lists Afrikaans, Greek, English, etc); from what I see, it
supports only C++. Should the Aspell team offer bindings for every
known language? In your post, you recommend supporting a minimum of
three. Which three? Why?

I'm a great fan of an obscure language named Pike. Do I expect Aspell
to be available for Pike? No, and I wouldn't even if your
three-language rule were followed. So how can I implement a
spellchecker in my code? By writing glue. I'll write a module that
exposes the C++ API to Pike. (This is actually a real example. I ended
up writing my aspell hook to run as a separate process for isolation's
sake, but it comes to the same thing.)

Unless the world consolidates into a smaller number of languages, this
is always going to be the case. You want the freedom to choose your
language and your API separately? You HAVE that freedom - you just
have to write your own glue. Glue-writing is a skill in the same way
that UI-building is; learn to do it well and you can do it quickly.
There's no need to demand that other people write your glue for you,
because chances are they won't do as good a job as an expert in the
language.

C or C++ bindings will cover most languages.

Chris Angelico
 
R

rantingrick

[... snip expositions...]
C or C++ bindings will cover most languages.

Chris Angelico

This is pretty much the entire argument, everything else is
exposition.
 
R

rantingrick

It takes work to suit your API to a different language. Let's take GNU
Aspell as an example; [...] Should the Aspell team offer bindings for every
known language? In your post, you recommend supporting a minimum of
three. Which three? Why?

No. Aspell should offer bindings for THE "Unity API" and the
respective "abstraction communities" are then responsible for
maintaining a plugin for their "abstraction" into THE Unity API.
I'm a great fan of an obscure language named Pike. Do I expect Aspell
to be available for Pike?

You should expect this. However if it is not available you cannot
blame Aspell for that! No, you MUST blame the pike community.

But first we have to blame EVERYONE because the unity API does not
exist... not yet! Or at least the mindset for it does not exists.
No, and I wouldn't even if your
three-language rule were followed.

My rule is for "unlimited unity" not "limited numbers".
So how can I implement a
spellchecker in my code? By writing glue. I'll write a module that
exposes the C++ API to Pike. (This is actually a real example. I ended
up writing my aspell hook to run as a separate process for isolation's
sake, but it comes to the same thing.)

Yeah and they have a name for that... "reinventing the wheel". An end
user should NEVER EVER have to write glue code so their "abstraction
of choice" can be used to to script an API. That's like expecting
automobile drivers to build a car from a hunk of iron ore every time!
No, we have car manufactures who specialize in building cars. However
the respective programming language communities are all oblivious to
the greater picture. An iteration is an iteration whether you use the
"for x in iterable: x.blah()" or the "iterable.each{|x| x.blah}" or
WHATEVER syntax you choose to use. It all boils down to the same 1's
and 0's. Can't you see how our own sense of selfish pride is defeating
productivity and discovery? Can't you see?

It's fine to speak French, or Japanese, or English if you want. But
eventually we will need a unifying natural language and likewise a
unifying programming language.

[Note to community] Actually from now on i want everyone to stop using
the words programming and language together. Instead of "X programming
language" i want to you say "X abstraction layer".

Python programming language --> Python abstraction layer.
Ruby programming language --> Ruby abstraction layer.
X programming language --> X abstraction layer.

You see, we constantly refer to languages as tools, and this mindset
is lunacy! All languages compile to 1's and 0's. Languages are not
TOOLS they are all ABSTRACTIONS of a single virtual tool AND THAT TOOL
IS SOFTWARE!). So stop brainwashing yourselves and others with these
foolish descriptors! Begin to focus your mind on unity and
standardization. Then and only then can we combine our singular minds
into the hive mind.
 
C

Chris Angelico

No. Aspell should offer bindings for THE "Unity API" and the
respective "abstraction communities" are then responsible for
maintaining a plugin for their "abstraction" into THE Unity API.

Your proposed "Unity API" (which I assume has nothing to do with Natty
Narwhal's preferred interface) already exists. It's the C language.
It's an abstraction layer between CPython, Pike, etc, and the
underlying hardware. The C standard library has a huge set of utility
functions like strcmp, malloc, and so on; by writing your code in C,
you simply enhance the C library. Language authors make use of this
enhanced C library to write functions to be called from that language.

And I don't *blame* the PIke community; since I'm a part of it, and
I'm quite probably the only part of it to need/want Aspell, I just
write the facilities I want.

ChrisA
 
R

rantingrick

Take Pidgin[1] as an example. Pidgin is a universal chat client. It's
a glue between the many chat clients that exist... It's a monkey patch
for chat multiplicity but you get the idea. However the Unity API
cannot be a monkey patch. It must be a mutual undertaking from the
beginning. Don't you people understand? Multiplicity is undermining
our future evolution.

[Anecdote]
Once when i was a very young lad (long before computers were
mainstream) i became terribly troubled by the fact that every
generation must spend roughly a quarter of it's lifetime just catching
up to the knowledge of the last generation. This fact does not seem
very troublesome at first glance, but lets create a microcosm...
<Tangential Meanderings>...what if you suffered from amnesia every
morning and you had to spend 1/4 of the day catching up to where you
were the day before? This would kill your productivity! But that is
not the point i am making here folks! <\back on track> The fact that
we constantly re-invent the wheel is a product of a very important
missing feature of most humans of which is devastating to our
evolution as intelligent agents.

[The Punchline]
Anyway, my solution to this collective "re-education" was the upload.
We could simply plug up, upload all former knowledge, and off we'd
go!

[The Knockout]
However when i shared my solution with someone [unnamed] he laughed
and said: "But that would take the challenge out of life. Nothing
remaining to learn if you can just download it"... aghast with horror
i just shook my head. This person had no imagination!

[The Moral]
Stop being sheep and start the revolution people! Stop being slaves to
multiplicity and be the master of the singularity. Our future (or lack
thereof) is in YOUR hands!

[1] http://www.pidgin.im/
 
Ad

Advertisements

T

Tim Chase

This is pretty much the entire argument, everything else is
exposition.

So you've got 3 interfaces: C, C++, and for the die-hards,
Assembly. Sounds like you should be happy then ;-)

(what? they weren't *your* top-3 language choices?)

-tkc


One API to rule them all,
One API to find them,
One API to bring them all
and in the darkness create bindings for them?
 
C

Chris Angelico

Take Pidgin[1] as an example. Pidgin is a universal chat client. It's
a glue between the many chat clients that exist... It's a monkey patch
for chat multiplicity but you get the idea. However the Unity API
cannot be a monkey patch. It must be a mutual undertaking from the
beginning. Don't you people understand? Multiplicity is undermining
our future evolution.

It's protocol glue, not programming code glue. There's a difference;
Pidgin replaces "chat client X", rather than piggybacking onto it.
Proliferation of code layers results in a performance penalty that
proliferation of chat clients doesn't. However, there is still a
parallel.

Any universal protocol will suffer either from complexity or
narrowness - some suffer from both. If every API has to go through
this Unity API, then either Unity will be as powerful and complex as C
with all its libraries, or it'll overly restrict things. That's why
Unity is really just C.

ChrisA
 
R

rantingrick

Any universal protocol will suffer either from complexity or
narrowness - some suffer from both. If every API has to go through
this Unity API, then either Unity will be as powerful and complex as C
with all its libraries, or it'll overly restrict things. That's why
Unity is really just C.

Well i never said we could not just use c of course. I'm trying to
lubricate the imagination here :).

However you have to convince the application devs of that. Most just
create bindings for a well known language like Python or Ruby and call
it a day. However some idiots go as far as writing their own mini
language (Audacity comes to mind!) and we cannot allow this to
happen!

The same problem exists in GUI's. Why the hell is there so many GUI
libraries? How many different label widgets do we need to re-invent?
It's ludicrous! Okay somebody might argue that we cannot just have one
because it would be too large. WHAT! Again imagination is the missing
link here. There is a simple solution... it's called "from GUI import
subset.x.y.z"!

I mean what is the point of having two languages with the exact same
syntax?

Ruby: print 'blah'
Python: print 'blah'

Ruby: for x in blah: blah_blah_blah
Python: for x in blah: blah_blah_blah

WHAT?

This multiplicity reminds me of a beginning CS student code:

def add(1,2):
return 1+2
def add(3,4):
return 3+4
def ...


Instead of:

def add(x, y);
return x+y

asinine!

Devs preach of code re-use but they propagate multiplicity in their
language design. Sadly we are still in the stone age of programming
and i don't know if i'll live long enough to see a real revolution.
People are waiting in breads lines all day but do not consider why?
(or they are too afraid to ask).
 
C

Chris Angelico

I mean what is the point of having two languages with the exact same
syntax?

Ruby: print 'blah'
Python: print 'blah'

Ruby: for x in blah: blah_blah_blah
Python: for x in blah: blah_blah_blah

WHAT?

What's the point of having fifty languages in which "x+y" is an
expression whose value is the sum of x and y? Let's ditch 'em all and
just use one language, since _obviously_ the languages have the exact
same syntax.

Common syntax is an aid to learning. It means you can transfer
knowledge from one language to another. It doesn't make either
useless.

Chris Angelico
 
R

rantingrick

Adding a new API is seldom the way to decrease the number of API's.
At least, not without -=very=- centralized control over which API's
get used.

I actually rather like it that no language has achieved the
dominance today that C once enjoyed, rightly or wrongly.

You make a good point Dan! Like of most of my threads this one is
evolving into something deeper and more profound. Like i recently
pointed out in my last post we have many languages that are just
slightly different (and sometimes spitting images) of others. For
example Python and Ruby share some very close similarities. Of course
they share many differences also but the point is we are duplicating
too much methodology in our language designs.

You make the argument that C is really all you need. And i whole
hearty agree however you must also agree that there is a great need
for Python and Ruby type languages. Languages that are much more user
friendly than C and don't require memory management.

Remember, most API users are not always CS majors. C is not beyond the
scope of any normal functioning human being however it does require
not only a steeper learning curve but caution whilst wielding it. I
mean who wants a seg fault when scripting Open Office, or how about
writing a page of boilerplate for what amounts to a half page script?

For me the ideal situation we could have is a unity of all the high
level languages. Dump all the repeated syntax's and try to compile the
best of all into as few "scripting langages" as possible. Of we can do
it in one GREAT, if not three or so sounds about correct.

Then these "cream of the crop" could be integrated tightly with
extension writing. So that you could start at the scripting level and
move down as needed for speed and low level stuff when needed.

But we need the application devs to take part or the whole house of
cards comes tumbling down. And how do you motivate people to use a
certain API. Simplicity is one way, peer pressure is another, bulling
when necessarily can help. Whatever it takes because we all have a
vested interest in unity. We must start the ball rolling.Continuing to
propagate selfishness is a self defeating process. If you build it
they will come!
 
Ad

Advertisements

R

rantingrick

What's the point of having fifty languages in which "x+y" is an
expression whose value is the sum of x and y? Let's ditch 'em all and
just use one language, since _obviously_ the languages have the exact
same syntax.

It seem ludicrous at first glance but it is true! We have to much re-
inventing going on!
Common syntax is an aid to learning. It means you can transfer
knowledge from one language to another. It doesn't make either
useless.

Why do you constantly propagate multiplicity? Why do you feel that we
need 100 or so languages when about three would cover everything? Sure
people are free to create whatever Frankenstein language they want in
the confines of their hobby time, but we need standards and we need
them NOW.

We want the world and we want it now!
 
C

Chris Angelico

Why do you constantly propagate multiplicity? Why do you feel that we
need 100 or so languages when about three would cover everything? Sure
people are free to create whatever Frankenstein language they want in
the confines of their hobby time, but we need standards and we need
them NOW.

I specced up "the perfect language" a while ago. It gave you a clean
slate with no facilities but one: Define Operator. Then you define
whatever you want - let's say you start by defining = as assignment.
Give it a precedence and associativity, mark it as binary, and start
using it. Now, define + the same way, and -, and so on. Let's define
the letter 'd' as an operator - a binary or unary operator, such that
'2d6' means 'roll two six-sided dice, return the sum' (and unary 'd20'
is equivalent to binary '1d20').

What's wrong with this language? It doesn't do anything, and it does
everything. You could use the language for one thing and I use it for
another thing. There is NO connection. We may as well be using
different languages.

You could have three languages in the world, if one is assembly
language (for the one chip that everyone uses), one is this
clean-slate language, and one is C. Have we improved anything? No. It
won't be any easier to write an API for something; and it'll be a lot
harder to maintain code ("wait wha? This programmer's defined + and *
in opposite precedence to usual!"). But hey, there's only one language
that you need to learn!

Chris Angelico
 
S

Steven D'Aprano

rantingrick said:
Hello fellow programmers, scripters, hackers, and debutantes.


Your ideas are intriguing to me and I wish to subscribe to your newsletter.
 
G

Gregory Ewing

The place where this "Unity API" idea of yours falls down
is that an API is only truly easy to use when it's designed
to closely match the characteristics of the language it's
being used from.

For example, Python has a very powerful feature that most
other languages don't have anything remotely like: very
flexible keyword arguments.

A truly Pythonic API will take advantage of them wherever
it makes sense. An extreme example is PyGUI, where you can
write things like

win = Window(title = "Fred", width = 300, height = 100,
position = (30, 50), movable = True, resizable = True)

In fact, almost *any* attribute of any PyGUI object can be
specified using keyword arguments in the constructor. In
your typical C or C++ based API, either you have a constructor
taking a zillion positional parameters that all have to be
in the right order, or you have to set all the attributes
individually afterwards:

win = Window()
win.title = "Fred"
win.width = 300
win.height = 100
win.position = (30, 50)
win.movable = True
win.resizable = True

Either way you end up with an API that feels very awkward
when used from Python.
 
G

Gregory Ewing

rantingrick said:
Ruby: for x in blah: blah_blah_blah
Python: for x in blah: blah_blah_blah

Here you're making the mistake of thinking that surface syntax
is all that matters. Although the 'for' statements in Python and
Ruby look very similar, underneath they're based on quite
different mechanisms. They're not equivalent: the Python way
leads to various powerful things such as generators; the Ruby
way lends itself more to user-defined control structures.
 
Ad

Advertisements

G

Gregory Ewing

Chris said:
Your proposed "Unity API" (which I assume has nothing to do with Natty
Narwhal's preferred interface) already exists. It's the C language.

Or maybe GObject Introspection is closer to what you
have in mind?

A library that supports GI advertises enough information
about itself for dynamic languages such as Python and Ruby
to automatically construct fairly object-oriented interfaces.

It's not perfect, though; for example, the old PyGtk module
used to let you access most of what Gtk calls "properties"
using Python attribute access, but with GI you have to
call the get_property and set_property functions. Also
you often can't just call a class to construct an object,
but have to call a separate constructor function instead.
 
R

rantingrick

I specced up "the perfect language" a while ago. It gave you a clean
slate with no facilities but one: Define Operator. [...]

That was some great satire :) but the last thing we need is users with
that much power. Take the example of Ruby allowing you to redefine
built in types... disastrous. I understand that freedom is good
however unbridled freedom is a recipe for disaster.
 
R

rantingrick

The place where this "Unity API" idea of yours falls down
is that an API is only truly easy to use when it's designed
to closely match the characteristics of the language it's
being used from.

For example, Python has a very powerful feature that most
other languages don't have anything remotely like: very
flexible keyword arguments.
[...]


   win = Window(title = "Fred", width = 300, height = 100,
     position = (30, 50), movable = True, resizable = True)

With all due respect that's a frail argument Greg. I agree that
python's keyword arguments are great but they can actually cause code
to get messy when so many are passed in a notation like you present
*ahem* ESPECIALLY when "somebody" refuses to follow the style guide
(hint-hint).

I would do this for clarity...

win = Window(
title="Fred",
width=300,
height=100,
position=(30, 50),
movable=True,
resizable=True,
)

psst: removed python style guide abominations :)
Strangely however it looks very similar to your next notation...
   win = Window()
   win.title = "Fred"
   win.width = 300
   win.height = 100
   win.position = (30, 50)
   win.movable = True
   win.resizable = True

hmm? I think it's actually easier to read in this final form. However
i will agree that C's requirements for function parameters are a real
pain in the arse. Thank Guido for Python!
Either way you end up with an API that feels very awkward
when used from Python.

I think we need to provide a better example (than just mere
conjecture) before we assume how an "imaginary" API would "feel". And
don't forget, any API can feel awkward since you've only got the hooks
that the devs deemed worthy for you to have. I can't tell you how many
obstacles I've had to code around because an API was lacking or buggy.
Turned my otherwise beautiful code into an Orwellian nightmare.
 
Ad

Advertisements

R

rantingrick

Here you're making the mistake of thinking that surface syntax
is all that matters. Although the 'for' statements in Python and
Ruby look very similar, underneath they're based on quite
different mechanisms. They're not equivalent: the Python way
leads to various powerful things such as generators; the Ruby
way lends itself more to user-defined control structures.

I agree however i see merit in both approaches. But why must we have
completely different languages just for that those two approaches? We
don't it's just a religious thing. Doesn't make sense to me. If Guido
and Matz got together over some sake and Monty Python i'll bet they
could hash out a singular replacement fro Ruby and Python in no time!
 

Top