Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The end to all language wars and the great unity API to come!

Reply
Thread Tools

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

 
 
rantingrick
Guest
Posts: n/a
 
      07-02-2011
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
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      07-02-2011
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...

On Sun, Jul 3, 2011 at 8:59 AM, rantingrick <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
 
rantingrick
Guest
Posts: n/a
 
      07-02-2011
On Jul 2, 6:38*pm, Chris Angelico <(E-Mail Removed)> wrote:

[... snip expositions...]

> C or C++ bindings will cover most languages.
>
> Chris Angelico


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

 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011
On Jul 2, 6:38*pm, Chris Angelico <(E-Mail Removed)> wrote:
[...]
> 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.


 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-03-2011
On Sun, Jul 3, 2011 at 10:21 AM, rantingrick <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011

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/
 
Reply With Quote
 
Tim Chase
Guest
Posts: n/a
 
      07-03-2011
On 07/02/2011 06:46 PM, rantingrick wrote:
> On Jul 2, 6:38 pm, Chris Angelico<(E-Mail Removed)> wrote:
>>> 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.

>>
>> C or C++ bindings will cover most languages.

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



 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-03-2011
On Sun, Jul 3, 2011 at 10:58 AM, rantingrick <(E-Mail Removed)> wrote:
>
> 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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011
On Jul 2, 8:12*pm, Chris Angelico <(E-Mail Removed)> wrote:

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

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      07-03-2011
On Sun, Jul 3, 2011 at 11:43 AM, rantingrick <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The end to all language wars and the great unity API to come! rantingrick Ruby 3 07-03-2011 03:21 AM
API for Cisco Unity Express (CUE)? strict9 Cisco 2 05-18-2006 05:01 PM
Star Wars Q: How severe are the bars on widescreen Star Wars DVD set? TNEXTWAVE DVD Video 22 10-01-2004 10:44 PM
Re: Star Wars: Clone Wars on dvd? Machina3317 DVD Video 2 04-14-2004 01:11 PM
Re: Sound problems on DVDs (was Re: Star Wars digression was Re: The Myths of Gaming) (was: Star Wars digression was Re: The Myths of Gaming) Terry Austin DVD Video 0 12-02-2003 03:21 AM



Advertisments