In terms of quick dynamically typed languages, I'm really starting to like Javascript, as I use it a lot for web projects, especially because it uses the same syntax as Actionscript (flash).
It would be an ideal language for shell scripting, making it easier to move code from the front and back end of a site, and less of the strange syntax of python.
Is there a good, javascript interpreter that is easy to install (I know there's one based on java, but that would mean installing all the java stuff to use),
I personally use SpiderMonkey, but here's an extensive list of ECMAScript shells
Example spidermonkey install and use on Ubuntu:
$ sudo apt-get install spidermonkey
$ js myfile.js
output
$ js
js> var f = function(){};
js> f();
Of course, in Windows, the JavaScript interpreter is shipped with the OS.
Just run cscript or wscript against any .js file.
There are four big javascript interpreters currently. V8, Squirrelfish, Spidermonkey and Rhino. I think more important than performance is how well it integrates into existing infrastructure, and I guess Rhino with its bridge to Java wins here.
Try jslibs, a scripting-focused standalone JS runtime and set of libraries that uses SpiderMonkey (the Gecko JS engine).
On the 'easy to translate' theme, there's also Lua.
It's somewhat similar to Javascript, but more 'orthogonal' (closer to functional roots).
The heavy orientation to 'pure' programming theory has made it really small and fast. It's the fastest scripting language around, and the JIT runs circles around the new JavaScript JITs that are starting to appear.
Also, since it was originally thought as an extension language, it has a very nice and clean interface to C, making it very easy to create bindings to any C library you might want to access.
Google's V8 can be used as a standalone interpreter. Configuring with scons sample=shell will build an executable named shell, that can be called like so: ./shell file.js.
You'll need some server-side JavaScript interpreter. Check out the following blog post. Something such as Rhino might be useful for you.
You might try toying around with SquirrelFish or v8, both should be runnable on the command line.
FYI, there is a built-in one already on modern windows platforms. You need to use JScript, but it's close enough. Same environment also allows for VBScript. To run a program you can execute something like:
cscript foo.js
The windows system API is a bit weird and frustrating if you expect the same flexibility as with basic JS objects, but they do have thorough documentation if you can handle digging through the MSDN pages and seeing all the examples in VBScript.
Not sure what's available for Linux/Mac in terms of js shell.
Well, for safety reasons, javascript had not been provided with file access right by design. So as a scripting language, it's a bit limited.
But still, if you really want to, spider monkey is your best option. Here is a tuto :
http://developer.mozilla.org/en/Introduction_to_the_JavaScript_shell
Node.JS. It's great. Has many modules. you can do all your file scripting with Node.
In my years I've found most Javascript developers find it quite easy to transfer over to PHP and vice versa - it isn't a direct answer to your question, although if you're working in ActionScript and JavaScript then you're best to stick with something like PHP (if you're not willing to move to Java, and stick with the ECMA base)
Related
I need my software which uses the Nashorn JavaScript engine to be compatible with Java 1.8 upwards.
If I use the one bundled with the JDK it will not work on Java >= 15. If I use the standalone Nashorn it will not be compatible with Java < 15.
Is there a way to keep compatibility? I have already thought about reflection but there might be more efficient ways.
Nashorn maintainer here. It should be possible to compile standalone Nashorn from sources for Java 11. I'm pretty sure we can't go below that, unfortunately. Are you using its API directly? In that case you unfortunately have a mismatch between built-in Nashorn's package names and the standalone version. If you can only rely on javax.script.* API then it should be possible to use both.
I want to understand your use case a bit better and help you arrive at a solution.
As you have noticed, Nashorn was deprecated in JEP 335 (JDK Enhancement Proposal) in Java 11 and it has subsequently been removed in JEP 372 that was delivered as part of Java 15. The motivation for the removal is
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.
Consequently, it will not be an option in the future. Instead I suggest that you take a look at options like GraalVM if you are looking for alternatives. As stated in the introduction:
It is designed for applications written in Java, JavaScript, LLVM-based languages such as C and C++, and other dynamic languages. It removes the isolation between programming languages and enables interoperability in a shared runtime.
If you cannot simply not distribute a standalone Nashorn JAR for JDKs <15, you should be able to build a multi-release version of it instead.
The root level should provide nothing, and then have all the actual classes in META-INF/versions/15/
Documentation: JAR Specification: Multi-release JAR files
Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out # http://ejohn.org/blog/web-workers/
Parallel.js of parallel.js.org (see also github source) is a single file JS library that has a nice API for multithreaded processing in JavaScript. It runs both in web browsers and in Node.js.
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Intel is coming up with an open-source project codenamed River Trail check out http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript/
Javascript is widely used to create apps in the web. How about desktop, etc? Gnome Shell is made of it. I'm just curious if there's a way or something which allows devs to access Gnome/Clutter graphics libraries?
The three best options that I know of are Rhino (using Swing, or other Java graphics frameworks), Seed, and Gjs.
Seed and Gjs are both Gnome projects that bind the GTK+ and Gnome libraries to JavaScript. Seed uses the JavaScriptCore runtime from WebKit and Gjs uses Mozilla's Spidermonkey engine. Gnome Shell is using Gjs.
Another option that, as far as I know, is still pretty immature is Gom. Instead of just a JavaScript binding for GTK+, it has an HTML-like DOM interface.
There are various ways to do this. Besides Rhino, V8/node.js is one of them.
Yes using Rhino although it looks like a convolated path...
Check this recent post by Alan Knowles.
I dont know much about the Gnome/Clutter graphics access, But several SSJS (Server-side_JavaScript) available that can work on Linux environments.
I am interested in getting started with CommonJS.
With JavaScript frameworks getting faster all the time, and parsing engines and compilers making JavaScript incredibly quick, it is surprising that a project such as CommonJS has not been initiated sooner.
What steps are involved in getting a test project up and running with what has been created so far?
It really depends on what you're actually looking to do. Persevere, for example, is a JSON database that is built on top of Rhino but is capable of working with CommonJS modules and is being built up around JSGI (the web server interface) going forward.
Narwhal is a fairly robust library of JavaScript and is specifically looking to track the CommonJS standard as it evolves. Narwhal runs on top of Rhino by default, but you can also install JavaScriptCore (and possibly v8) as additional "engines". JSC is very fast.
There are various web frameworks available (including Helma NG).
Node.js has been getting a lot of attention as a fast, v8-based, event-driven network services stack for JS. Node recently changed to use CommonJS modules.
SproutCore has a branch ("tiki") that is built on CommonJS modules. I, personally, am using that now for Bespin of which the client side is entirely CommonJS modules. (Ironically, the server side is currently in Python, but we do have plans to migrate to CommonJS on the server as well.)
The thing to remember about CommonJS is that it's an API spec. It's possible for there to be many implementations. Thus far, the only part of the spec that is widely supported are the modules... the rest is still baking, but coming along nicely.
CommonJS is not yet to the level of interop of, say, CPython/Jython/IronPython, but it certainly has that potential going forward.
What steps are involved in getting a
test project up and running with what
has been created so far?
I found the Narhwal quick start to be the fastest way to get up and running.
Have you tried starting here?
What are you stuck on?
It's gelling. You're early, unless you like living on the edge.
By the way, your wikipedia link has links to the projects that use CommonJS. You had the answer before you got here.
I just started using Node.js at home. It works and seems great.
The only issue I've encountered so far is that Windows support seems somewhat distant.
I believe Rhino works with Windows since it's a Javascript interpreter written in Java, but that also means it's slower than the Javascript-C implementations like V8. I don't think Rhino itself implements the CommonJS specification, but you can run something like Narwahl on top of it - as was mentioned by Kevin and Jeff.
I just did a quick job of installing Rhino, Ant (to build Rhino) and trying to get Narwhal running with Windows, but wasn't successful.
I suggest trying Node.js on a Linux box since that was my environment and it worked flawlessly.
For a while now, I have been using UltraEdit on my Windows box. The ability to write scripts with a familiar language (JavaScript) has proved to be extremely useful. The only problem is that I cannot use it on my Linux box at work. Is there a comparable text editor that runs on Linux and has an integrated scripting engine?
Not breaking the bank and being cross-platform would be great.
EDIT:While recordable macros are great, I use the scripting engine much more.
All of the major open-source editors and most of the others hava a scripting facility of some description - some (Emacs in particular) are famous for it. The only ones that don't tend to be very lightweight ones like pico.
vim has a native scripting language and can also be built with embedded Python, Tcl or Perl interepreters that can operate on selections, buffers etc through the plugin mechanism. Emacs is all about scripting - it's has a LISP interpreter built right into the core of the system and most of the editor is written in LISP. There is a running joke about emacs describing it as a LISP interpreter that someone just happened to use to write a text editor.
Vim's user interface is descended from vi, which is somewhat quirky but very powerful once you get used to it. It also does recorded keyboard macros particularly well and has a very nice regular expression search/replace facility.
Emacs is regarded as a bit of a baroque monstrosity and is very large and complex. However, its scripting capability is second to none and there is an enormous variety of macro packages that do many things. It has a very loyal following of people who swear by it; once you've gotten over the learning curve (there is an enormous body of resources on the web to help with this) it's a very powerful system indeed. You can customise emacs into a whole IDE and there are people around who claim to spend the majority of their tube time in it.
Both of these editors can work in text mode or with a GUI and are highly portable, running on a wide variety of platforms. They are both open-source.
I've used both; I used to use XEmacs (a major code-fork of emacs that goes back a number of years) back in the 1990s but went to vim later on. I even use vim on Windows.
If you find the user interface of Vim or Emacs a bit too much, there are a variety of other text editors available, many of which offer scripting. Examples of these are SciTE, which has a built in Lua interpreter, NEdit, which has a homebrew macro language of its own or GEdit, which is substantially written in Python (which can also be used for scripting it) and has a plugin API.
EDIT: Outside of a few specific projects (e.g. Mozilla) Javascript never got much traction as a stand-alone or embedded scripting language in open-source circles. Historically there wasn't a popular open-source Javascript interpreter that got widespread acceptance in the way that Python or Tcl/Tk did. Javascript is more widely used in closed source systems such as UltraEdit or InDesign (to name a couple) whereas other languages were more popular on open-source projects.
None of the open-source text editors that I am aware of feature javascript as an option for a scripting language (feel free to step in and comment or edit this if you know of one). You will probably have to move off Javascript to another language such as Python or LISP. However, now that QT comes with a Javascript interpreter (QTScript) you may find some of the KDE-based ones offering this as a scripting option, but I am not specifically aware of any off the top of my head.
emacs is free and has its own embedded lisp dialect which can be used to write nearly anything, including light scripting as well as mail user agents and IRC clients ;-)
There's a bit of a learning curve, but my experience with emacs has been very positive. I don't like modal interfaces too much, and no other editor puts the navigation shortcuts right under your fingers.
Vim is omnipresent and vimscript is really easy and text-editing oriented: http://vimdoc.sourceforge.net/htmldoc/usr_41.html
That comes by default. You can also use Python, Ruby, Perl, Scheme... but that requires compiling.
Python might be a good choice, since omnicomplete requires it. I run a separate binary for omnicomplete anyway since I like the ultra-lean vim for other usage, check here:
http://vim.wikia.com/wiki/Compile_a_separate_copy_of_Vim_for_Python_coding
Honestly I haven't used python to script vim per se. I usually code, python or not, with vanilla vim and no auto-complete. I do however call python and any other command from vim to process my files line by line, might reply with more about that if you are interested, but that doesn't require to compile anything, works as is.
EDIT: if you want a point-and-click editor, you can run Cream on gVim http://cream.sourceforge.net/download.html
I still think that vim takes little time to get used to and is VERY worth learning, more so considering you can use your basic vi knowledge to connect to a server via SSH no problem, and it's installed in any *nix. I like knowledge I can reuse, saves me time and trouble long term.
I use jEdit, that is a great editor and allows to be scripted with beanshell. As it is written in Java it runs well under Windows and Linux.
Simon Groenewolt mentioned, that a plugin (JavascriptShell) exists, that allows you to write Macros and Scripts also in Javascript, not only in Beanshell.
If you don't need really complex scripting, vim/gvim allows you to record a keystroke sequence and play it back. And you can give a repeat count on the playback, so you can record an operation on one line, then repeat it for the next 10,000 lines in one step.
Wow, I really don't want to start a holy war here, but all these Emacs recommendations are kind of missing the point. Emacs is very powerful, but let's be honest. It doesn't have a learning curve so much as a learning WALL. Going from a point-and-click IDE style editor like UltraEdit is going to be a huge culture shock.
And honestly, when someone says they like to write scripts in javascript, and are looking for something similar in Linux, the first thing you say is "learn LISP"?!
This is why people think Linux is hard to use
I'm going to go in another direction entirely and suggest Aptana Studio
It has built-in highlighting and code-completion for a variety of languages, and supports scripting in javascript with Eclipse Monkey. It is based on Eclipse, and therefore runs on java hence multiplatform. And it is available for free.
It's kind of cliche, but emacs. Or am I misunderstanding what UE's script engine is?
Try Emacs, either XEmacs or GNU Emacs.
I use gedit. You can write plugins in Python.
Komodo Edit is made on top of Mozilla's XUL Runner. It offers possibilities for extending it thorough either extensions (like Firefox) or macros, snippets, commands. You may write these snippets in either JavaScript or Python, which is nice, but you still have to know the API in order to do something useful.
Being built with Mozilla technology it runs on Linux too.
It looks like Komodo Edit, SciTE, and Eclipse Monkey are the winners. Komodo Edit seems to be most similar to Ultra Edit. SciTE is something I've used before, and Lua is not that difficult; SciTE's API though does not seem as extensive as Komodo Edit's API. Eclipse Monkey is something I am definitely going to use, but it requires Eclipse, which is definitely not a text editor.
EDIT: UltraEdit is coming out for Mac and Linux Soon.
The traditional way for doing scripted text editing in Linux is to use the facilities that have (almost) always been available in *nixes: sed, awk, grep, things of that nature. Sure, they maybe don't appear to be as "handy" as one might find an integrated Javascript engine, but they are very mature and work well. If this scripting language MUST be inside the editor, Emacs is probably a good one here too.
You could use an "integrated" type solution to solve the problem, as lots of others have mentioned, but IMHO the commandline is more powerful in this regard.
SciTE can be scripted with Lua and is a good, simple editor which behaves much the same way if you're switching between Linux and Windows every day.
I don't know what you're using the scripting capabilities in your editor for, but you may want to consider automating those tasks using Linux command-line tools such as sed or awk.