Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110228 > unrolled thread

Request for opinions: A cross language development tool

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Request for opinions: A cross language development tool Tal Zion <tal@bridge-dev.com> - 2016-06-21 15:10 +0300
    Re: Request for opinions: A cross language development tool Christian Gollwitzer <auriocus@gmx.de> - 2016-06-21 14:39 +0200
      Re: Request for opinions: A cross language development tool Tal Zion <tal@bridge-dev.com> - 2016-06-21 17:06 +0300
        Re: Request for opinions: A cross language development tool BartC <bc@freeuk.com> - 2016-06-21 19:02 +0100
      Re: Request for opinions: A cross language development tool Chris Angelico <rosuav@gmail.com> - 2016-06-22 03:36 +1000
      Re: Request for opinions: A cross language development tool Tal Zion <tal@bridge-dev.com> - 2016-06-21 21:01 +0300
        Re: Request for opinions: A cross language development tool Laurent Pointal <laurent.pointal@free.fr> - 2016-06-23 09:36 +0200
          Re: Request for opinions: A cross language development tool Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:07 +0300
      Re: Request for opinions: A cross language development tool Chris Angelico <rosuav@gmail.com> - 2016-06-22 04:26 +1000
      Re: Request for opinions: A cross language development tool Tal Zion <tal@bridge-dev.com> - 2016-06-21 21:30 +0300
      Re: Request for opinions: A cross language development tool Chris Angelico <rosuav@gmail.com> - 2016-06-22 05:28 +1000
    Re: Request for opinions: A cross language development tool Steven D'Aprano <steve@pearwood.info> - 2016-06-22 02:25 +1000

#110228 — Request for opinions: A cross language development tool

*

Hey!

I would like to know your opinions about a project a friend and I have 
been developing for about a year now, which we really think could 
empower Python. Today Python is mostly used on servers. Many people who 
want to develop an app will choose Python to write the backend and 
develop frontends in Java, Swift, Javascript, etc. We think Python is 
great, and we don't see why we shouldn't be able to write a native iOS, 
Android or web app entirely in Python. After all, these languages share 
the same concepts, more or less (classes, functions, exceptions, etc) 
and what really separates them is syntax. We're proposing a new 
approach: developers will code in their favorite language, such as 
Python (woot woot!), and be able to import Java, Swift and Javascript 
code from Python, and use that code as if it were written in Python. 
Python code will run on just about any platform, including the web.


**

So how does this magic work? We developed a new compiler platform called 
Bridge. At the heart of Bridge is the Bridge Extensible Code 
Representation (BECR). Code in any language is parsed into an AST and is 
then translated to the BECR. The BECR supports common programming 
concepts (if, for, while, etc) and it can also be extended to support 
new concepts in order to ease the translation from the source language. 
Therefore, the translation from the source language’s AST to the BECR is 
easy as it**merely translates syntax. Then, Bridge translates the BECR 
to LLVM IR and from there the code can be compiled to x86, arm, asm.js 
or any other LLVM backend*. *After code has been translated to BECR, it 
doesn’t matter what the source language was, and the syntax barriers 
that stopped languages from working together disappear. This means that 
once more languages will be translated to the BECR, they will be able to 
work seamlessly together.

**

Today, we have a basic demo showing an Android app written in Python 
displaying native Android buttons and labels inside a native scroll 
view. In this demo, Python code can import Java classes and inherit from 
them.


Soon Bridge will be released as an open source project. We’d love to 
hear your opinions about this project. We’re really excited and we can’t 
wait to see Python being used in more and more places!


**

Thanks, Tal**

*

[toc] | [next] | [standalone]

#110229

Am 21.06.16 um 14:10 schrieb Tal Zion:
> develop frontends in Java, Swift, Javascript, etc.
 >
> So how does this magic work? We developed a new compiler platform called
> Bridge. At the heart of Bridge is the Bridge Extensible Code
> Representation (BECR). Code in any language is parsed into an AST and is
> then translated to the BECR. [.....]
> easy as it**merely translates syntax. Then, Bridge translates the BECR
> to LLVM IR and from there the code can be compiled to x86, arm, asm.js
> or any other LLVM backend*.

So you have repeated .NET, or Parrot, or the JVM. What is new in your 
system that sets it apart from these?

> Soon Bridge will be released as an open source project. We’d love to
> hear your opinions about this project. We’re really excited and we can’t
> wait to see Python being used in more and more places!

Make sure you can do better than those:

http://ironpython.net/ (Python on .NET)
http://parrot.org/ (Python on the Perl-VM)
http://www.jython.org/ (Python on the JVM)

All of those projects promise a seamless integration of several 
languages in a single VM. ALl of them have failed in the sense that the 
languages have not converged onto that platform.

	Christian

[toc] | [prev] | [next] | [standalone]

#110233

On 06/21/2016 03:39 PM, Christian Gollwitzer wrote:
> Am 21.06.16 um 14:10 schrieb Tal Zion:
>> develop frontends in Java, Swift, Javascript, etc.
> >
>> So how does this magic work? We developed a new compiler platform called
>> Bridge. At the heart of Bridge is the Bridge Extensible Code
>> Representation (BECR). Code in any language is parsed into an AST and is
>> then translated to the BECR. [.....]
>> easy as it**merely translates syntax. Then, Bridge translates the BECR
>> to LLVM IR and from there the code can be compiled to x86, arm, asm.js
>> or any other LLVM backend*.
>
> So you have repeated .NET, or Parrot, or the JVM. What is new in your 
> system that sets it apart from these?
>
>> Soon Bridge will be released as an open source project. We’d love to
>> hear your opinions about this project. We’re really excited and we can’t
>> wait to see Python being used in more and more places!
>
> Make sure you can do better than those:
>
> http://ironpython.net/ (Python on .NET)
> http://parrot.org/ (Python on the Perl-VM)
> http://www.jython.org/ (Python on the JVM)
>
> All of those projects promise a seamless integration of several 
> languages in a single VM. ALl of them have failed in the sense that 
> the languages have not converged onto that platform.
>
>     Christian

Hi Christian,
Thank you for your opinion, it is much appreciated.
There are similarities but there are also a few important implementation 
differences:

* It is easier to add languages to Bridge than it is to any of the above 
platforms: In order to make Python run on those platforms, those 
projects needed to write a compiler from Python to those platforms' 
respective intermediate languages. That is a very hard task. In Bridge, 
we provide the BECR, which makes it easy to re-use concepts implemented 
in other languages. For example, after we are done adding enough 
concepts to the BECR to compile 100% of Python's features, adding Ruby 
will be relatively easy as there are many similar concepts between the 
two languages.

* Bridge enables Python code to interact with more languages through our 
external interfaces: Bridge code can interact with libraries not 
compiled to Bridge. So Python code will be able to call Swift, 
Objective-C, Java, and C code, to name a few, even if they weren't 
compiled to Bridge.

* Bridge integrates with CPython in order to provide the same experience 
developers are used to: There are many Python modules written in C which 
are not usable in the above platforms. In Bridge you can use any CPython 
module. So when you are creating a Python list in Bridge, you are 
actually using CPython's list implementation.

* Bridge makes Python faster: Python code compiled through Bridge is 
compiled to native code. Because we are leveraging LLVM's many 
optimizations, Python code will run faster than ever.

* Bridge is more hackable: Using plugins, Bridge is much more accessible 
to community participation.

Most importantly, Bridge will enable Python code to run on many new 
platforms (iOS, Android, web browsers..), while none of the above 
platforms provide this ability. We aren't looking to compete with 
CPython, but rather to complement it.

Tal

[toc] | [prev] | [next] | [standalone]

#110254

On 21/06/2016 15:06, Tal Zion wrote:

> * Bridge makes Python faster: Python code compiled through Bridge is
> compiled to native code. Because we are leveraging LLVM's many
> optimizations, Python code will run faster than ever.

In that case forget any of your other claims. Making any Python code 
faster is useful in itself. But the problems are well-known.

How do you turn:

     a = b + c

into native code for example? (Since this can mean myriad different 
things, which you will not know until runtime, sometimes not until the 
line before. And not even then if 'a=b+c' is a run-time argument of 
'exec()'.

And one big advantage of Python is being able to try different things 
and run them instantly. It sounds like you will be using a complicated 
tool-chain performing a series of transformations, or does that all 
happen instantly too?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110251

On Wed, Jun 22, 2016 at 12:06 AM, Tal Zion <tal@bridge-dev.com> wrote:
> * Bridge makes Python faster: Python code compiled through Bridge is
> compiled to native code. Because we are leveraging LLVM's many
> optimizations, Python code will run faster than ever.

Can you run *any* Python program through Bridge? Absolutely anything?
Can you guarantee language compatibility?

And if you can - what version of Python are you compatible with?

ChrisA

[toc] | [prev] | [next] | [standalone]

#110258

Bridge compiles Python modules into native code, which requires us to 
support Python *language* features (for, while, class, generators, etc) 
but it reuses CPython's libraries (list, dict, str, etc) so we don't 
implement those, and it also uses CPython's ast module in order to parse 
Python code. So once we are done supporting all of the language 
features, any Python code should work. Currently we have quite a few 
language features to implement, but we're working on it =) We're 
targeting Python 3.5.

Tal

On 06/21/2016 08:36 PM, Chris Angelico wrote:
> On Wed, Jun 22, 2016 at 12:06 AM, Tal Zion <tal@bridge-dev.com> wrote:
>> * Bridge makes Python faster: Python code compiled through Bridge is
>> compiled to native code. Because we are leveraging LLVM's many
>> optimizations, Python code will run faster than ever.
> Can you run *any* Python program through Bridge? Absolutely anything?
> Can you guarantee language compatibility?
>
> And if you can - what version of Python are you compatible with?
>
> ChrisA

[toc] | [prev] | [next] | [standalone]

#110377

Tal Zion wrote:

> Bridge compiles Python modules into native code, 

What is "native", really microprocessor executable binary ? How do you adapt 
to diversity?

> which requires us to
> support Python *language* features (for, while, class, generators, etc)
> but it reuses CPython's libraries (list, dict, str, etc) 

Hum, "etc" is important here, CPython libraries makes Python power 
("batteries included"). And running such code on client side have 
*important* security concerns… I won't see people allowing automatically 
loaded Python scripts (or their binaries) execution on their system as is 
without a security layer.

> so we don't
> implement those, and it also uses CPython's ast module in order to parse
> Python code. So once we are done supporting all of the language
> features, any Python code should work. 

Supporting features is not only parsing code, it's providing same execution 
semantic. And its a reason it would be more complicated to use exactly same 
execution kernel to run other languages.

> Currently we have quite a few
> language features to implement, but we're working on it =) We're
> targeting Python 3.5.

You seem to start a new, potentially complex project (devil is in details), 
ignoring other works which already did same job:

Apart from ironpython, parrot, jython, already listed, you can look at:
 
Brython to run Python with a JavaScript/ECMAScript engine
	http://brython.info/

MicroPython to run Python on small embedded systems
	https://micropython.org/

Also look at https://wiki.python.org/moin/WebBrowserProgramming where there 
are many other projects of that kind.

You want Python on the web browser, try to produce asm.js code, you will 
benefit of all work done on JavaScript engines, and of security layers. 
But… you will have to rewrite the batteries into pure Python mixed with 
asm.js code, this is huge work.

Bon courage.

A+
L.Pointal.

> 
> Tal
> 
> On 06/21/2016 08:36 PM, Chris Angelico wrote:
>> On Wed, Jun 22, 2016 at 12:06 AM, Tal Zion <tal@bridge-dev.com> wrote:
>>> * Bridge makes Python faster: Python code compiled through Bridge is
>>> compiled to native code. Because we are leveraging LLVM's many
>>> optimizations, Python code will run faster than ever.
>> Can you run *any* Python program through Bridge? Absolutely anything?
>> Can you guarantee language compatibility?
>>
>> And if you can - what version of Python are you compatible with?
>>
>> ChrisA

[toc] | [prev] | [next] | [standalone]

#110387

Laurent Pointal <laurent.pointal@free.fr>:

> Tal Zion wrote:
>> Bridge compiles Python modules into native code, 
>
> What is "native", really microprocessor executable binary ? How do you
> adapt to diversity?

They don't need to adapt to different CPU types. They can list supported
targets. Also, they could generate, say, C code to achieve a great level
of portability.

> And running such code on client side have *important* security
> concerns

That's no different for any C program running on your system. It has
access to *everything* in the vast collection of OS libraries through
direct linking and dlopen(3).

In fact, that's no different for any interpreted Python module loaded in
from PyPI.

>> so we don't implement those, and it also uses CPython's ast module in
>> order to parse Python code. So once we are done supporting all of the
>> language features, any Python code should work.
>
> Supporting features is not only parsing code, it's providing same
> execution semantic.

I think that's where the native code comes in.

> You seem to start a new, potentially complex project (devil is in
> details), ignoring other works which already did same job:

Let them. Some of the greatest things have come about that way.

> this is huge work.
>
> Bon courage.

That's the attitude!


Marko

[toc] | [prev] | [next] | [standalone]

#110259

On Wed, Jun 22, 2016 at 4:01 AM, Tal Zion <tal@bridge-dev.com> wrote:
> Bridge compiles Python modules into native code, which requires us to
> support Python *language* features (for, while, class, generators, etc) but
> it reuses CPython's libraries (list, dict, str, etc) so we don't implement
> those, and it also uses CPython's ast module in order to parse Python code.
> So once we are done supporting all of the language features, any Python code
> should work. Currently we have quite a few language features to implement,
> but we're working on it =) We're targeting Python 3.5.

Okay, so how do you handle exec and eval?

ChrisA

[toc] | [prev] | [next] | [standalone]

#110261

We use CPython's implementation of exec and eval.

Tal

On 06/21/2016 09:26 PM, Chris Angelico wrote:
> On Wed, Jun 22, 2016 at 4:01 AM, Tal Zion <tal@bridge-dev.com> wrote:
>> Bridge compiles Python modules into native code, which requires us to
>> support Python *language* features (for, while, class, generators, etc) but
>> it reuses CPython's libraries (list, dict, str, etc) so we don't implement
>> those, and it also uses CPython's ast module in order to parse Python code.
>> So once we are done supporting all of the language features, any Python code
>> should work. Currently we have quite a few language features to implement,
>> but we're working on it =) We're targeting Python 3.5.
> Okay, so how do you handle exec and eval?
>
> ChrisA

[toc] | [prev] | [next] | [standalone]

#110264

On Wed, Jun 22, 2016 at 4:30 AM, Tal Zion <tal@bridge-dev.com> wrote:
> We use CPython's implementation of exec and eval.
>

(Please don't keep top-posting.)

Okay. So as I understand it, this requires the full CPython
interpreter to be included at run-time; how does this help you work
seamlessly with other languages? How is this different from simply
having CPython (or PyPy, since you're messing with performance - PyPy
JIT-compiles to native code, so it can be pretty fast), Ruby, etc, etc
all installed and operating separately?

Here's a concrete example. Python has several data types for storing
numbers. Notably, int (which can store *any* integer), and float
(which can store non-integers as well, but has roughly 53 bits of
storage). JavaScript has only the latter. So how can the two
interoperate correctly? Can Python code call a JavaScript function?
Vice versa? And if not, how seamlessly are the languages actually able
to work together?

ChrisA

[toc] | [prev] | [next] | [standalone]

#110241

On Tue, 21 Jun 2016 10:10 pm, Tal Zion wrote:

> *
> 
> Hey!
> 
> I would like to know your opinions about a project a friend and I have
> been developing for about a year now, which we really think could
> empower Python. Today Python is mostly used on servers. 

Really?

> Many people who 
> want to develop an app will choose Python to write the backend and
> develop frontends in Java, Swift, Javascript, etc. We think Python is
> great, and we don't see why we shouldn't be able to write a native iOS,
> Android or web app entirely in Python.

I'm not sure about iOS, but you can write desktop applications in Python,
and Android apps in Python, and web apps, although it's probably true that
most people will use HTML and Javascript for the front end.


> After all, these languages share 
> the same concepts, more or less (classes, functions, exceptions, etc)
> and what really separates them is syntax. We're proposing a new
> approach: developers will code in their favorite language, such as
> Python (woot woot!), and be able to import Java, Swift and Javascript
> code from Python, and use that code as if it were written in Python.

In a sense, this is bringing Python back to its roots as a glue language,
for bringing C or Fortran libraries together.

Be aware that there is a LOT of prior art here:

Kivy (multi-platform Python framework)

Julia's PyCall (allow Julia code to call Python code, and vice versa)

https://www.euroscipy.org/2014/schedule/presentation/53/

Integrating Python with the .Net and Mono framework:

- Python for .Net;
- IronPython

Integrating Python with Java:

- Jython
- JPype

Integration with C++:

- Boost
- SWIG
- Weave (part of SciPy)

etc. So I think you may need to explain better exactly what your project
does that the others don't do.



> Python code will run on just about any platform, including the web.
> 
> 
> **
> 
> So how does this magic work? We developed a new compiler platform called
> Bridge. At the heart of Bridge is the Bridge Extensible Code
> Representation (BECR). Code in any language is parsed into an AST and is
> then translated to the BECR. The BECR supports common programming
> concepts (if, for, while, etc) and it can also be extended to support
> new concepts in order to ease the translation from the source language.
> Therefore, the translation from the source language’s AST to the BECR is
> easy as it**merely translates syntax. Then, Bridge translates the BECR
> to LLVM IR and from there the code can be compiled to x86, arm, asm.js
> or any other LLVM backend*. *After code has been translated to BECR, it
> doesn’t matter what the source language was, and the syntax barriers
> that stopped languages from working together disappear. This means that
> once more languages will be translated to the BECR, they will be able to
> work seamlessly together.

Sounds very optimistic. It's not just *syntax* barriers that stop languages
from working together. Consider:

    x += y;

which is legal syntax in both C and Python (and probably a lot of other
languages). But the *semantics* are not necessarily the same. They're
likely to be different -- sometimes very different.


> **
> 
> Today, we have a basic demo showing an Android app written in Python
> displaying native Android buttons and labels inside a native scroll
> view. In this demo, Python code can import Java classes and inherit from
> them.

That's nice. How do we see that demo?


> Soon Bridge will be released as an open source project. We’d love to
> hear your opinions about this project. We’re really excited and we can’t
> wait to see Python being used in more and more places!
> 
> 
> **
> 
> Thanks, Tal**
> 
> *

-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web