Julia as scripting language for larger project

[Fengyang Wang]

Hi,

I learned Julia recently, and I must say it has been incredible for scientific work. I am in love with the clean, modern syntax. Props to the developers for their tireless efforts to improve this language even further!

Historically, Lua and Javascript have been the most common choices for scripting languages in larger projects... Lua because it is so easy to integrate with C(++), and Javascript primarily because it is so easy to integrate with Java. I would like Julia to fill this role for one of my current projects, but I have identified some hurdles.

1. For now, security is not important because scripts are assumed to be trusted. However, a plan for scripts to eventually be downloaded from the Internet is in the works. I could not find a Julia sandbox, however. Does such a sandbox exist?
   
2. My customers may not necessarily be computer-literate, and I can't expect them to install Julia. Also, due to the rapid pace of Julia development, it may be advantageous to install a portable Julia entirely for this project only. My project currently targets Windows, Linux, and Mac OSX. Is there a portable way to install a portable Julia, or will I have to create separate installation code for each OS?
3. My current understanding is that I should write the public API in Julia, and use ccall internally to call back into my project. Is this the correct method?

Thanks in advance!

[Isaiah Norton]

Does such a sandbox exist?

 

1. No

Is there a portable way to install a portable Julia

 

2. The installation process is platform-specific. The "generic linux binaries" should work on any reasonably recent linux. The Windows installer can be unpackaged and used like a portable binary. Not sure about OS X. You will probably be best off bundling these into whatever installer system you choose for your overall application.

3. Projects with an embedded scripting language tend to fall along a continuum between "outside in" -- driving everything from Julia via ccall; and "inside out" -- using Julia's C embedding API (http://docs.julialang.org/en/latest/manual/embedding/). The choice depends on your goals and the overall project architecture.

(relevant: "Embed vs extend" https://twistedmatrix.com/users/glyph/rant/extendit.html). 

[Fengyang Wang]

Thank you for your response! This has been very helpful.

[Stefan Karpinski]

Is JavaScript actually easy to integrate with Java?

[Benjamin Deonovic]

Not sure what you mean by julia sandbox, but there is https://www.juliabox.org/ if you want to try out julia without having to install on your machine. 

[Isaiah Norton]

In this context, sandboxing means restricting the privileges allowed to untrusted code: https://en.wikipedia.org/wiki/Sandbox_(computer_security)

Sandboxing is what allows one to run arbitrary JavaScript code (from "wherever") in your web browser without generally needing to worry about what that code would like to do-to or read-from the rest of the browser or computer. I think this is basically a non-goal for Julia in any current time horizon. Reliable sandboxing is generally quite hard, and would be even more so in a language that relies so deeply on ccall.

[Jeffrey Sarnoff]

It is easy to get Java from Javascript, just drop the script.
Integrating the two -- naah; if it were, node.js would have an older sibling ''java.js"

[Tony Kelman]

I suspect it can be if you use Nashorn.

On sandboxing, we could potentially look into experimenting with PNaCl as a backend. Or use existing sandboxes that exist across all browsers by compiling to js with Emscripten, or WebAssembly as that develops.

[Fengyang Wang]

On Wednesday, August 26, 2015 at 1:17:06 PM UTC-4, Stefan Karpinski wrote:

Is JavaScript actually easy to integrate with Java?

Java has always come bundled with a Javascript interpreter (first Rhino, now Nashorn). It can be used like this:

package sample1;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class Hello {

  public static void main(String... args) throws Throwable {
    ScriptEngineManager engineManager = 
new ScriptEngineManager();
    ScriptEngine engine = 
engineManager.getEngineByName("nashorn");
    engine.eval("function sum(a, b) { return a + b; }");
    System.out.println(engine.eval("sum(1, 2);"));
  }
}

I took this example from the docs: http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html

[Stefan Karpinski]

Joke's on NetScape.

[Páll Haraldsson]

On Wednesday, August 26, 2015 at 5:17:06 PM UTC, Stefan Karpinski wrote:

Is JavaScript actually easy to integrate with Java?

Not really..(?) up to recently. Java was just confused with JavaScript in the beginning.

There is some new work, forget name, to get Java to work in a browser, without a plug-in, implemented in JavaScript (I assume/recall a JVM).. That might be easy, and possibly you can call back and forth.

[Páll Haraldsson]

On Wednesday, August 26, 2015 at 4:23:29 PM UTC, Fengyang Wang wrote:

Hi,

I learned Julia recently, and I must say it has been incredible for scientific work. I am in love with the clean, modern syntax. Props to the developers for their tireless efforts to improve this language even further!

Historically, Lua and Javascript have been the most common choices for scripting languages in larger projects... Lua because it is so easy to integrate with C(++), and Javascript primarily because it is so easy to integrate with Java. I would like Julia to fill this role for one of my current projects, but I have identified some hurdles.

I know Lua is hugely much used, in say, games, more than Python, but is it somehow (or Python, assume not with JavaScript) good/better to integrate with C++ (not just C)? I understand Keno's Cxx.jl is best in class for that. [Of the few games using Python, one is Eve Online (the say biggest multi-player (in a sense, in the world), in Stackless Python, made by people I know here in Iceland.. Blender also uses Python.]

1. For now, security is not important because scripts are assumed to be trusted. However, a plan for scripts to eventually be downloaded from the Internet is in the works. I could not find a Julia sandbox, however. Does such a sandbox exist?
   

No, as already answered. Some other languages, like C# and Rust, have "managed", otherwise "safe". I've wondered if it could be done in Julia - e.g. by disallowing ccall (and more..). It would break most of Julia.. but say, there where exceptions. Only disallow ccall in your code and not the standard library. I'm not sure how easy if would even be, this disallowing (possible with a macro that looks for ccall?), as ccall is a keyword. And even if you could do this, say be changing core Julia, how easy would it be to get around (as you can modify the standard library at runtime..)?

1. 
   
2. My customers may not necessarily be computer-literate, and I can't expect them to install Julia. Also, due to the rapid pace of Julia development, it may be advantageous to install a portable Julia entirely for this project only. My project currently targets Windows, Linux, and Mac OSX. Is there a portable way to install a portable Julia, or will I have to create separate installation code for each OS?

See my other answer I just gave in another thread.

-- 

Palli.

[Scott Jones]

On Thursday, August 27, 2015 at 12:52:34 PM UTC+2, Páll Haraldsson wrote:

On Wednesday, August 26, 2015 at 5:17:06 PM UTC, Stefan Karpinski wrote:

Is JavaScript actually easy to integrate with Java?

Not really..(?) up to recently. Java was just confused with JavaScript in the beginning.

From Wikipedia:

Although it was developed under the name Mocha, the language was officially called LiveScript when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript^[11] when it was deployed in the Netscape browser version 2.0B3.^[12]

The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. The final choice of name caused confusion, giving the impression that the language was a spin-off of the Java programming language, and the choice has been characterized as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new web programming language.^[13][14]

Rhino was added in 2000 (i.e. JavaScript implemented in the JVM), years later.