- a Compilable script engine is possible
- The Python code itself could be optimized somehow
- A different language with better performance could be used
-
Polyglot programming on the Java Platform (28 messages)
- Posted by: Joseph Ottinger
- Posted on: October 09 2007 10:47 EDT
Recently, polyglot programming has become a bit of a meme, with many pointing out how different languages bring different strengths. Polyglot, in this context, allows programmers to use scripting for some tasks, Java for other tasks, with other languages like C# providing other external services. JSR 223 is the JSR providing the Scripting API for Java. The concept behind it is that a programmer gets a ScriptEngine, which refers to a mechanism executing scripts in a given language, and then passes that ScriptEngine source code in some fashion – through a Reader or InputStream, or even as individual lines of code. Thus, the Java platform itself can be used as a launch point for polyglot programming, after a sense, in that you can write modules in various languages (JavaScript, Ruby, Python, Groovy, BSF) and use them from within a Java framework and on the Java platform. A test was written using the exact same algorithms, using Jython and Java. The code was taken from "Programming Collective Intelligence," by Toby Segaran, chapter six. The test created a naïve bayesian classifier, trained the classifier with sample ham and spam, and then ran two thousand sets of ten tests against the classifiers. The only timed elements were the loops getting the classifications. While the results varied somewhat, an example of a run showing good results for both Java and Jython yielded the following: the Java code ran in 312 ms, and the Jython code ran in 37500ms. This is the Python code taken directly from the book, ported almost line for line into Java (with some variations due to different semantics in the languages.) The only optimization in the Java code was the use of Javolution for collections, and even in that case, Javolution's fast iterator mechanisms were not used. There are potentially ways to fix the script's performance:Threaded Messages (28)
- Re: Polyglot programming on the Java Platform by James Watson on October 09 2007 11:35 EDT
- Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 11:59 EDT
-
Re: Polyglot programming on the Java Platform by James Watson on October 09 2007 12:52 EDT
-
Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 12:58 EDT
-
Re: Polyglot programming on the Java Platform by Erik Engbrecht on October 09 2007 01:05 EDT
- Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 01:18 EDT
- Re: Polyglot programming on the Java Platform by James Watson on October 09 2007 01:24 EDT
-
Re: Polyglot programming on the Java Platform by Erik Engbrecht on October 09 2007 01:05 EDT
-
Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 12:58 EDT
- Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 12:55 EDT
-
Re: Polyglot programming on the Java Platform by James Watson on October 09 2007 12:52 EDT
- Re: Polyglot programming on the Java Platform by Joseph Ottinger on October 09 2007 11:59 EDT
- Re: Polyglot programming on the Java Platform by James Watson on October 09 2007 13:39 EDT
- Simplification by Sal F on October 09 2007 15:59 EDT
- Re: Simplification by Erik Engbrecht on October 09 2007 18:17 EDT
-
Re: Simplification by Sal F on October 10 2007 12:23 EDT
-
Re: Simplification by James Watson on October 10 2007 01:04 EDT
- Re: Simplification by Sal F on October 10 2007 02:50 EDT
-
Re: Simplification by Erik Engbrecht on October 10 2007 03:33 EDT
-
Re: Simplification by Sal F on October 10 2007 04:01 EDT
-
Re: Simplification by Erik Engbrecht on October 11 2007 06:46 EDT
-
Re: Simplification by Sal F on October 11 2007 09:52 EDT
-
Re: Simplification by Erik Engbrecht on October 11 2007 11:28 EDT
-
Re: Simplification by Sal F on October 11 2007 12:39 EDT
-
Re: Simplification by James Watson on October 12 2007 09:29 EDT
-
Re: Simplification by Sal F on October 15 2007 11:30 EDT
-
C++ and Java by Erik Engbrecht on October 16 2007 06:25 EDT
-
Re: C++ and Java by Sal F on October 19 2007 11:38 EDT
- Re: C++ and Java by Erik Engbrecht on October 22 2007 04:46 EDT
-
Re: C++ and Java by Sal F on October 19 2007 11:38 EDT
-
C++ and Java by Erik Engbrecht on October 16 2007 06:25 EDT
-
Re: Simplification by Sal F on October 15 2007 11:30 EDT
-
Re: Simplification by James Watson on October 12 2007 09:29 EDT
-
Re: Simplification by Sal F on October 11 2007 12:39 EDT
-
Re: Simplification by Erik Engbrecht on October 11 2007 11:28 EDT
-
Re: Simplification by Sal F on October 11 2007 09:52 EDT
-
Re: Simplification by Erik Engbrecht on October 11 2007 06:46 EDT
-
Re: Simplification by Sal F on October 10 2007 04:01 EDT
-
Re: Simplification by James Watson on October 10 2007 01:04 EDT
-
Re: Simplification by Sal F on October 10 2007 12:23 EDT
- Re: Simplification by Erik Engbrecht on October 09 2007 18:17 EDT
- Multiple languages as an academic exercise by Tor Iver Wilhelmsen on October 10 2007 04:10 EDT
- not academic: pnuts by Dirk Vleugels on October 10 2007 09:35 EDT
- Re: Multiple languages as an academic exercise by James Watson on October 10 2007 10:45 EDT
-
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: James Watson
- Posted on: October 09 2007 11:35 EDT
- in response to Joseph Ottinger
I don't see where I can find the code for the script or the Java version. It would be nice to see that if only to make the discussion more concrete. One of the nice things I find about using Jython is that it's really very easy to use Java libraries and Objects. So where most Python developers probably know the python XML libraries in-and-out, I use the Saxon-b library with some basic Python wrappers to get an XML API with Xquery support. I guess my point is that if the script is running slow, there's probably a bottleneck in the code that could either be changed to use a 3rd party Java library or some custom Java code. Also, the addition of an invokedynamic bytecode should theoretically make Jython much faster in addition to making the lives of the Jython development team (you rock!) a lot easier. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: October 09 2007 11:59 EDT
- in response to James Watson
I don't see where I can find the code for the script or the Java version. It would be nice to see that if only to make the discussion more concrete.
I can send it to you if you'd like. The java code will be in the ci-bayes project on java.net fairly soon (i.e., as soon as I can be bothered creating a decent build.xml for it) and the python code... is just one file. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: James Watson
- Posted on: October 09 2007 12:52 EDT
- in response to Joseph Ottinger
I don't even really care to see the Java. Can you post the python script? I'm just curious if I can see where the slowdown is coming from and if I'm right in my wild guess that there's a bottleneck that could be resolved by using the Java libraries instead of the python libraries.I don't see where I can find the code for the script or the Java version. It would be nice to see that if only to make the discussion more concrete.
I can send it to you if you'd like. The java code will be in the ci-bayes project on java.net fairly soon (i.e., as soon as I can be bothered creating a decent build.xml for it) and the python code... is just one file. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: October 09 2007 12:58 EDT
- in response to James Watson
As I said, it's posted - and that's an interesting idea. I didn't consider using the Java library from within the python code, because that would have reduced the portability of python... I wonder how valid I consider that to be.I don't see where I can find the code for the script or the Java version. It would be nice to see that if only to make the discussion more concrete.
I can send it to you if you'd like. The java code will be in the ci-bayes project on java.net fairly soon (i.e., as soon as I can be bothered creating a decent build.xml for it) and the python code... is just one file.
I don't even really care to see the Java. Can you post the python script? I'm just curious if I can see where the slowdown is coming from and if I'm right in my wild guess that there's a bottleneck that could be resolved by using the Java libraries instead of the python libraries. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 09 2007 13:05 EDT
- in response to Joseph Ottinger
As I said, it's posted - and that's an interesting idea. I didn't consider using the Java library from within the python code, because that would have reduced the portability of python... I wonder how valid I consider that to be.
I think it's valid. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: October 09 2007 13:18 EDT
- in response to Erik Engbrecht
In the context of writing polyglot stuff on the java platform... I think you're right. I'd be interested in seeing if the python code could be optimized for jython.As I said, it's posted - and that's an interesting idea. I didn't consider using the Java library from within the python code, because that would have reduced the portability of python... I wonder how valid I consider that to be.
I think it's valid. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: James Watson
- Posted on: October 09 2007 13:24 EDT
- in response to Joseph Ottinger
I didn't consider using the Java library from within the python code, because that would have reduced the portability of python... I wonder how valid I consider that to be.
Well, the entire thing rewritten in Java isn't portable Python either ;-) But one thing you can do to mitigate this is create a module that hides the use of Java libs so that if you needed to port it, you could implement it with pure python or with the corresponding 'scaffold' language in the target environment. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: October 09 2007 12:55 EDT
- in response to Joseph Ottinger
And the project is now populated in SVN on java.net: https://ci-bayes.dev.java.net . If you need the python code, it's there in SVN too, under /lib/.I don't see where I can find the code for the script or the Java version. It would be nice to see that if only to make the discussion more concrete.
I can send it to you if you'd like. The java code will be in the ci-bayes project on java.net fairly soon (i.e., as soon as I can be bothered creating a decent build.xml for it) and the python code... is just one file. -
Re: Polyglot programming on the Java Platform[ Go to top ]
- Posted by: James Watson
- Posted on: October 09 2007 13:39 EDT
- in response to Joseph Ottinger
Nothing is popping-out at me when looking at the python script. Maybe if I looked more closely. Probably the python code itself could be optimized a little. -
Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 09 2007 15:59 EDT
- in response to Joseph Ottinger
I think the more 'prefessional' term used is generally 'Metaprogramming'. There is a new industry niche forming, understandable so, of coders using tools such as GWT which generate code from Java. The advantage? You *don't have* to use Javascript with GWT, just Java. Now imagine if the same is done with all other languages a developer needs to use today - SQL for a RDBMs (being obsoleted by Hibernate?), GLSL for hardware shading in the 3d world (why? Java metaprogramming library would work) and C++ or C for small-footprint applications? Why not just generate the code from Java? So the questions really isn't about performance - if you need performance, Java is there and proven especially on the server platform. The question is about Simplification. Why 'polyglot' for AJAX? When you can do it all in Java with something like GWT? Extending this further - Java could be generating/interfacing any other language as well. Soon the 'source' language won't be Java anymore, but likely something more suitable for Metaprogramming. I'll put $$ on this one =) -
Re: Simplification[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 09 2007 18:17 EDT
- in response to Sal F
Soon the 'source' language won't be Java anymore, but likely something more suitable for Metaprogramming. I'll put $$ on this one =)
What language would you bet on? The thing is I think static typing is required but I can't think of any statically typed languages with really good metaprogramming capabilities. C++ has metaprogramming it's confusing. I know there's interest in adding metaprogramming to Scala, but I don't think there's anything concrete being done. -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 10 2007 12:23 EDT
- in response to Erik Engbrecht
Of, course it my opinion - albiet a stubborn one, but, If you look at all the toolsets, Java to Javascript via GWT or j2s, Actionscript via j2as, etc. the common thread is they all work of of Java's AST (Abstract Syntax Tree). Java (at lease pre Java 5) has such a 'pure' syntactic structure that it makes it easy for AST-based metaprogramming tools to be made. And Java has proven itself the industry leader for Enterprise Stuff, and even if you don't agree with that you have to admit its successful to some degree. The point being - Java's AST is proven to 'Work'. So, if all tools work from an Abstract Syntax of Java, not actually Java itself, then theres no reason for the first step. Why start from Java? Just like Eclipse allows you to edit Java code via a representation of the syntax tree (per JST mechanics), for all the developer knows that AST could be persisted in some other format... XML, for example. You can 'create' a Java AST from UML editors, or from a parser of any other OOP language, really. So the developer isn't limited to creating the Java AST from Java, with the proper toolset, he'll be able to create the AST from a variety of sources... choose your language? Or don't use one at all? UML w/state mechanics works fine =)Soon the 'source' language won't be Java anymore, but likely something more suitable for Metaprogramming. I'll put $$ on this one =)
What language would you bet on?
The thing is I think static typing is required but I can't think of any statically typed languages with really good metaprogramming capabilities. C++ has metaprogramming it's confusing.
I know there's interest in adding metaprogramming to Scala, but I don't think there's anything concrete being done. -
Re: Simplification[ Go to top ]
- Posted by: James Watson
- Posted on: October 10 2007 13:04 EDT
- in response to Sal F
Or don't use one at all? UML w/state mechanics works fine
UML is a language. That's what the 'L' stands for: 'language'. -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 10 2007 14:50 EDT
- in response to James Watson
You're right - I should clarify. 'Domain Specific Languages', are distinctly different from 'programming languages' in the traditional sense. UML is a sortof 'Domain Specific Language' catering to modelling objects and their relations. As opposed to the traditional sense, a 'typed' language which details procedural logic.Or don't use one at all? UML w/state mechanics works fine
UML is a language. That's what the 'L' stands for: 'language'. -
Re: Simplification[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 10 2007 15:33 EDT
- in response to Sal F
If you look at all the toolsets, Java to Javascript via GWT or j2s, Actionscript via j2as, etc. the common thread is they all work of of Java's AST (Abstract Syntax Tree).
This is just code generation, not metaprogramming. -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 10 2007 16:01 EDT
- in response to Erik Engbrecht
I would argue, metaprogramming *is* code generation =) Or more accurately - procedural logic that creates code which, embodies other procedural logic. Whether it crosses language boundries (generate 'other' languages) or stays within the current language (say, reflexive languages) it still classifies as a metaprogram.If you look at all the toolsets, Java to Javascript via GWT or j2s, Actionscript via j2as, etc. the common thread is they all work of of Java's AST (Abstract Syntax Tree).
This is just code generation, not metaprogramming. -
Re: Simplification[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 11 2007 06:46 EDT
- in response to Sal F
Or more accurately - procedural logic that creates code which, embodies other procedural logic. Whether it crosses language boundries (generate 'other' languages) or stays within the current language (say, reflexive languages) it still classifies as a metaprogram.
Why procedural logic? That seems rather limiting to me. -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 11 2007 09:52 EDT
- in response to Erik Engbrecht
As opposed to... fuzzy logic? :)Or more accurately - procedural logic that creates code which, embodies other procedural logic. Whether it crosses language boundries (generate 'other' languages) or stays within the current language (say, reflexive languages) it still classifies as a metaprogram.
Why procedural logic? That seems rather limiting to me. -
Re: Simplification[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 11 2007 11:28 EDT
- in response to Sal F
As opposed to declarative and functional.Or more accurately - procedural logic that creates code which, embodies other procedural logic. Whether it crosses language boundries (generate 'other' languages) or stays within the current language (say, reflexive languages) it still classifies as a metaprogram.
Why procedural logic? That seems rather limiting to me.
As opposed to... fuzzy logic? :) -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 11 2007 12:39 EDT
- in response to Erik Engbrecht
I was kidding :) Since a microprocessor only understands procedural statements, ultimately even todays 'declarative' and 'functional' languages are just ultimately wrappers around procedural machine code. If a declarative language was used to generate code I would still consider it a metaprogram... I hope it makes sense? Would be interested in hearing opinions :) Its an interesting area I *do* think all programmers are going to be dwelling in the next few years...
Why procedural logic? That seems rather limiting to me.
As opposed to... fuzzy logic? :)
As opposed to declarative and functional. -
Re: Simplification[ Go to top ]
- Posted by: James Watson
- Posted on: October 12 2007 09:29 EDT
- in response to Sal F
Since a microprocessor only understands procedural statements,
Is machine code procedural? It doesn't even really have enough structure to be called that.ultimately even todays 'declarative' and 'functional' languages are just ultimately wrappers around procedural machine code.
Assuming for the moment that this is correct, I think you are drawing some pretty shaky conclusions from it. How a high-level language is translated into executable instructions is largely irrelevant when developing in that language. There were a number of machines developed to run LISP natively in the past. If a procedural language were compiled into LISP to run on these machines, does that make the procedural code just a wrapper around functional code? -
Re: Simplification[ Go to top ]
- Posted by: Sal F
- Posted on: October 15 2007 11:30 EDT
- in response to James Watson
ultimately even todays 'declarative' and 'functional' languages are just ultimately wrappers around procedural machine code.
Assuming for the moment that this is correct, I think you are drawing some pretty shaky conclusions from it. How a high-level language is translated into executable instructions is largely irrelevant when developing in that language.
There were a number of machines developed to run LISP natively in the past. If a procedural language were compiled into LISP to run on these machines, does that make the procedural code just a wrapper around functional code? -
C++ and Java[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 16 2007 18:25 EDT
- in response to Sal F
Ultimately I think the language barriers will break down, since C++ and Java are really only different syntacticly, by semantically equivalent, programmer toolsets I think will merge similairly.
I think C++ templates make it significantly more expressive than Java, assuming you can make sense of them. I would not call the two languages semantically equivalent beyond the fact that they are both turing complete. -
Re: C++ and Java[ Go to top ]
- Posted by: Sal F
- Posted on: October 19 2007 11:38 EDT
- in response to Erik Engbrecht
If you examine how templates work behind the scenes - they're really just a glorified 'copy/paste' of the code, once for each use of a different template type. The C++ compiler basically duplicates code, replacing templatized types with the requested type in the duplicated version(s). So in that sense - it is still just a syntactic difference, a shortcut that just shortens what 'can' be done in Java. Also keep in mind, that Java's 'Object' centric use in collections API and felxible type casting eliminates the need for templatizing.... But I would much much rather *not* move into a language argument, as that is acually contrary to my point, that: - Java is a kind of subset of C++, it is an Object Oriented language, compiles into bytecode, runs under a VM - C++ is a 'pre compiled language' it is object oriented, supports the same things Java does in terms of inheritance, polymorphism - Many other languages are similair 'enough' - Python is basically Java with whitespace instead of brackets, less necessary explicit typing, lots of syntactic differences - but the bottom line, its an Object Oriented language capable of the same patterns Java and C++ are. So if it *is* possible to merge all languages at an abstract level (say, an Abstract Syntax Tree is used on the backend that is similair to Java's), it is theoretically possibly to input and output any other language from that syntax tree. Not all features of all languages are supported obviously, as the programmer is working with a 'least common denominator' but he gains the advantage that his 'Object Oriented' code patterns are adaptable to any environment - a huge plus for sacrificing something small... say, typing brackets instead of braces... I think developer tools are going to go this route. Already it has started, with Java to Javascript via GWT, Java to Actionscript via j2as, and modelling tools that give UML to Java... Of course, just my opinion still =)
I think C++ templates make it significantly more expressive than Java, assuming you can make sense of them. I would not call the two languages semantically equivalent beyond the fact that they are both turing complete. -
Re: C++ and Java[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: October 22 2007 16:46 EDT
- in response to Sal F
So if it *is* possible to merge all languages at an abstract level (say, an Abstract Syntax Tree is used on the backend that is similair to Java's), it is theoretically possibly to input and output any other language from that syntax tree.
Hmmm...yes and no. It would probably be possible to create such as AST, but converting many languages to Java's AST would result in a loss of semantic information. For example, consider a tail-recursive method in Scala. There are essentially two potential translations to Java: (1) A tail-recursive Java method (2) A Java method with a loop "for" or "while" loop #1 would result in a Java method that, in source, looks a lot like the Scala method. Semantic information such as variable mutability (val/var in Scala, final/not final in Java) would be preserved. Mostly the changes would be minor shifts in syntax. However, the Java method would compile into a recursive method at the bytecode level, while the Scala method would compile into a loop due to optimization of tail-recursion. So in the translation process from Scala to the Java AST, you either lose some of the semantic information that enables you to reason about the code, or you lose semantic information about how the code will be executed by the machine. Both are very important. -
Multiple languages as an academic exercise[ Go to top ]
- Posted by: Tor Iver Wilhelmsen
- Posted on: October 10 2007 04:10 EDT
- in response to Joseph Ottinger
The JVM was written for Java. That's the language it's most suited to run. Other languages generally jump through hoops in order to run on it - with the exception of Groovy of course, which also targets the JVM. It's the same thing in .Net: It's made to run C# code, other languages like managed C++ and Visual Basic .Net end up sufficiently different from their non-CLR-targeted variants to confuse programmers - at least in the beginning. Microsoft even wanted to make VB.Net more different from VB 6 but were deluged by protests from VB users. So, Microsoft can beat their chests about 50 languages (Eiffel, Haskell etc.) or whatever number they use, but in reality there is ONE: C#. (And whatever is used for inline code - VBScript.Net? - in ASP.Net.) As for cross-language scripting engines: Microsoft also has something like that in Windows, where you can register e.g. ActiveState's Python and Perl ports as "Windows Scripting Hosts" and use Python code in web pages rendered in Internet Explorer. However, this is hardly ever used since it would require exctra effort from the user. And further: Of the languages Microsoft provide, just Javascript is generally used simply because other browsers are more cross-platform and do not use WSH. Therefore they cannot run VBScript code. The same will probably be the case with the JSE 1.6 scripting engine: Reduce the usage to just the Sun-provided language(s). -
not academic: pnuts[ Go to top ]
- Posted by: Dirk Vleugels
- Posted on: October 10 2007 09:35 EDT
- in response to Tor Iver Wilhelmsen
The JVM was written for Java. That's the language it's most suited to run. Other languages generally jump through hoops in order to run on it - with the exception of Groovy of course, which also targets the JVM.
The same holds for Pnuts https://pnuts.dev.java.net/ Which is the fastest scripting language on the JVM by a *huge* margin (and we tried them all). Just a tad unacquainted... Cheers, Dirk
-
Re: Multiple languages as an academic exercise[ Go to top ]
- Posted by: James Watson
- Posted on: October 10 2007 10:45 EDT
- in response to Tor Iver Wilhelmsen
The JVM was written for Java. That's the language it's most suited to run. Other languages generally jump through hoops in order to run on it - with the exception of Groovy of course, which also targets the JVM.
This is true but as I understand it, the invokedynamic bytecode instruction, is not useful to Java and remove a lot of the hoops in addition to making scripting languages run faster. I think it's pretty much a done deal that it will be added in 1.7.