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

Discussion in 'Python' started by rantingrick, Jul 2, 2011.

  1. rantingrick

    rantingrick Guest

    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
    rantingrick, Jul 2, 2011
    #1
    1. Advertising

  2. 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 <> 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
    Chris Angelico, Jul 3, 2011
    #2
    1. Advertising

  3. rantingrick

    rantingrick Guest

    On Jul 2, 6:38 pm, Chris Angelico <> wrote:

    [... snip expositions...]

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


    This is pretty much the entire argument, everything else is
    exposition.
    rantingrick, Jul 3, 2011
    #3
  4. rantingrick

    rantingrick Guest

    On Jul 2, 6:38 pm, Chris Angelico <> 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.
    rantingrick, Jul 3, 2011
    #4
  5. On Sun, Jul 3, 2011 at 10:21 AM, rantingrick <> 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
    Chris Angelico, Jul 3, 2011
    #5
  6. rantingrick

    rantingrick Guest

    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/
    rantingrick, Jul 3, 2011
    #6
  7. rantingrick

    Tim Chase Guest

    On 07/02/2011 06:46 PM, rantingrick wrote:
    > On Jul 2, 6:38 pm, Chris Angelico<> 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?
    Tim Chase, Jul 3, 2011
    #7
  8. On Sun, Jul 3, 2011 at 10:58 AM, rantingrick <> 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
    Chris Angelico, Jul 3, 2011
    #8
  9. rantingrick

    rantingrick Guest

    On Jul 2, 8:12 pm, Chris Angelico <> 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).
    rantingrick, Jul 3, 2011
    #9
  10. On Sun, Jul 3, 2011 at 11:43 AM, rantingrick <> 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
    Chris Angelico, Jul 3, 2011
    #10
  11. rantingrick

    rantingrick Guest

    > On Sat, Jul 2, 2011 at 7:37 PM, Dan Stromberg wrote:
    >
    > 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!
    rantingrick, Jul 3, 2011
    #11
  12. rantingrick

    rantingrick Guest

    On Jul 2, 8:49 pm, Chris Angelico <> wrote:
    > On Sun, Jul 3, 2011 at 11:43 AM, rantingrick <> 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.


    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!
    http://www.youtube.com/watch?v=xkp8fNODegU&feature=player_detailpage#t=472s
    rantingrick, Jul 3, 2011
    #12
  13. On Sun, Jul 3, 2011 at 12:24 PM, rantingrick <> wrote:
    > 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
    Chris Angelico, Jul 3, 2011
    #13
  14. rantingrick wrote:

    > Hello fellow programmers, scripters, hackers, and debutantes.



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



    --
    Steven
    Steven D'Aprano, Jul 3, 2011
    #14
  15. 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.

    --
    Greg
    Gregory Ewing, Jul 3, 2011
    #15
  16. rantingrick wrote:

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

    --
    Greg
    Gregory Ewing, Jul 3, 2011
    #16
  17. Chris Angelico wrote:

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

    --
    Greg
    Gregory Ewing, Jul 3, 2011
    #17
  18. rantingrick

    rantingrick Guest

    On Jul 2, 10:14 pm, Chris Angelico <> wrote:
    > 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.
    rantingrick, Jul 3, 2011
    #18
  19. rantingrick

    rantingrick Guest

    On Jul 2, 10:57 pm, Gregory Ewing <> wrote:
    > 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.
    rantingrick, Jul 3, 2011
    #19
  20. rantingrick

    rantingrick Guest

    On Jul 2, 11:00 pm, Gregory Ewing <> wrote:
    > rantingrick wrote:
    > > 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.


    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!
    rantingrick, Jul 3, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sergio

    Microsoft VM and Java wars

    sergio, Apr 10, 2004, in forum: Java
    Replies:
    4
    Views:
    373
    sergio
    Apr 11, 2004
  2. ashfaq
    Replies:
    0
    Views:
    594
    ashfaq
    Jan 19, 2012
  3. Eric I.
    Replies:
    0
    Views:
    238
    Eric I.
    Oct 5, 2008
  4. Gregory Brown
    Replies:
    0
    Views:
    114
    Gregory Brown
    Jun 15, 2009
  5. rantingrick
    Replies:
    3
    Views:
    589
    Steven D'Aprano
    Jul 3, 2011
Loading...

Share This Page