["Jantzen, G?nter" Tue, Jun 22, 2004 at 01:36:15PM +0200]

...

Anthony Baxter wrote: Consider what works, then worry about what's got some supposed "industry standard" elephant stamp on it. If we worried about "industry standards" we'd be all implementing in ECMAScript, Java, and C#, _not_ Python.

I did not suggest to implement something in C++ I only suggested to search for better reasons to make a decision.

When choosing a library for a backend you will always have integration issues.

Indeed.

It is never a fun to cross language borders. But as long as you wourk with 'industry standards' like Java, C or C++ you have a good chance to solve this problem one time and to encapsulate this stuff with a thin wrapper.

Well, to my ears an "industry standard" is usually the label vendors put on their product. Moreover, with PyPy we cross language borders all the time. It is inherent to the kind of project we are doing. For practical matters, integration issues and the "consider that works" principle are very important to our kind of evolutionary development. Anyway, i imagine that if we use joeq or LLVM as a backend we might very well rewrite the most interesting parts in Python at some point, depending on our experiences and the actual development. But for now, it's "does it do the job" and "does it integrate well enough".

For this reason it is more important to look from a design perspective.

I think we do but use a different definition of "design" then what is considered "design" in large companies which usually develop in terms of UML diagrams, workflow specifications/engines and model-driven code-generators using "standard" components etc.pp. No offense meant :-)

When choosing a backend, ask yourself if it will support the features which are your needs.

OK, i guess we all agree here.

I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me.

I am not a native speaker myself but i would think this is a just a somewhat stronger word for "backwards". just my 2ec. cheers, holger

["Jantzen, G?nter" Tue, Jun 22, 2004 at 01:36:15PM +0200]

...

Anthony Baxter wrote: Consider what works, then worry about what's got some supposed "industry standard" elephant stamp on it. If we worried about "industry standards" we'd be all implementing in ECMAScript, Java, and C#, _not_ Python.

I did not suggest to implement something in C++ I only suggested to search for better reasons to make a decision.

When choosing a library for a backend you will always have integration issues.

Indeed.

It is never a fun to cross language borders. But as long as you wourk with 'industry standards' like Java, C or C++ you have a good chance to solve this problem one time and to encapsulate this stuff with a thin wrapper.

Well, to my ears an "industry standard" is usually the label vendors put on their product. Moreover, with PyPy we cross language borders all the time. It is inherent to the kind of project we are doing. For practical matters, integration issues and the "consider that works" principle are very important to our kind of evolutionary development. Anyway, i imagine that if we use joeq or LLVM as a backend we might very well rewrite the most interesting parts in Python at some point, depending on our experiences and the actual development. But for now, it's "does it do the job" and "does it integrate well enough".

For this reason it is more important to look from a design perspective.

I think we do but use a different definition of "design" then what is considered "design" in large companies which usually develop in terms of UML diagrams, workflow specifications/engines and model-driven code-generators using "standard" components etc.pp. No offense meant :-)

When choosing a backend, ask yourself if it will support the features which are your needs.

OK, i guess we all agree here.

I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me.

I am not a native speaker myself but i would think this is a just a somewhat stronger word for "backwards". just my 2ec. cheers, holger