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

Chris Angelico rosuav at gmail.com
Sun Jul 3 01:38:17 CEST 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 <rantingrick at gmail.com> 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



More information about the Python-list mailing list