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


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=xkp8f...ailpage#t=472s

 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      07-03-2011
On Sun, Jul 3, 2011 at 12:24 PM, rantingrick <(E-Mail Removed)> 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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-03-2011
rantingrick wrote:

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



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



--
Steven

 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      07-03-2011
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
 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      07-03-2011
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
 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      07-03-2011
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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011
On Jul 2, 10:14*pm, Chris Angelico <(E-Mail Removed)> 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.
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011
On Jul 2, 10:57*pm, Gregory Ewing <(E-Mail Removed)> 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.
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-03-2011
On Jul 2, 11:00*pm, Gregory Ewing <(E-Mail Removed)> 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!

 
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