Slashdot Mirror

They offer nothing except a GUI !
You could achieve the all the "special" jEdit functionality, ex: search and replace with the result of a script, in Vim with VimScript but I prefer BeanShell to VimScript so I use jEdit...

Can you possibly choose two slower languages (both at parsing and interpreter/JIT speed) for a web language?

Beanshell and IDL. They're both pathetically slow, yet I know of people who use them for web client tasks and use them a lot.

There's no hope for some folks.

I've used BeanShell for scripting in Java, so I'm just wondering what advantage Groovy would have.

http://www.beanshell.org/

Regarding #4 and #5, the Beanshell project has been providing an interactive command line and runtime evaluation of Java code since 2000.

scsh and BeanShell are both scripting languages that are pretty cool, the first uses Scheme and the second uses Java.

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

Smart programmers may use Eclipse and the command line at the same time, but not for the same things, so this is not an "either-or" issue or a "lack of better tools" issue. In my Java projects (developed with Eclipse) I use to use BeanShell, which, when used interactively, is run from the command line (which in turn is running inside Emacs...). You can run the Beanshell Console in the Eclipse console, but it's quite painful. Similarly, when grepping or analysing line-oriented log files created by your Eclipse-developed applications, there's hardly anything better than the Unix toolchest (I challenge you to show me an equally efficient set of tools inside the Eclipse or VStudio environment).

Perhaps you would like BeanShell

Maybe it's too late for your project, but I've always loved using BeanShell.

Speaking of Wine, I don't use it a lot. I have some Windows foreign-language-study programs that run just fine under it. Some Windows games run all right under it; the occasional crash is part of the fun :). The one application I'd like to see working better is Personal Ancestral File, but the Linux alternatives are competitive. I use OpenOffice or Koffice or emacs for office stuff, and write new software in perl or Java or C#, all of which are cross-platform.

Say, can I use an interpreted scripting language on the JVM? Which one would be most suited?

• Rhino Javascript engine - built in to Java SE 6
• Groovy - An agile dynamic language for the Java Platform
• BeanShell: Lightweight Scripting for Java
• The Sleep Scripting Project

Reason #4: Still no shell

There will be a shell, even an object oriented one. It's called "Monad" (aka "Windows PowerShell" aka "Microsoft Shell" aka "MSH"). To be fair, it will probably not be included in the OS but provided as a separate download.

Being object oriented, it can leaverage the DotNET framework. Monad seems to be quite similar to "BeanShell" (aka "bsh" aka "JSR-274") nobody uses (and understands) beside some software developers.

Interesting post, just have issue with this one point:

For the same reasons as above. Quick, easy, graphical, sharable. Java is more restricted in that it can't really be run as a script - it can barely be run when compiled into bytecode! - so you don't get the same feel of "what happens when I change this here".

Java can very easily be run as a script throught the use of BeanShell which is now officiallyl JSR 274

I threw together a pretty simple IDE for kids to do this called JTurtle. Still needs a little work, but it was a fun app to write :)
Kids get syntax highlighting, a C/C++/Java style syntax, and instant feedback. JTurtle can be used to write procedural or object oriented scripts and the full java API is accessible if they want to do something more advanced.

From what I've seen, Groovy's a half-baked programming language and unfinished product. See this criticism for a start.

If you want to do embedded scripting in Java, I suggest Bean Shell instead. As a library, Bean Shell is about 280K, Groovy is about 1.7M. And Bean Shell has been around for a lot longer.

I'd like to see Sun add closures and better support for lists/maps in Java itself (e.g. a map function). I'm hoping that pressure from Ruby will make the language grow. C# already made them change their mind about Generics.

I think Java is a reasonable first language to learn. I learned languages in the following order:

• BASIC
• FORTRAN
• PL/1
• C
• C++
• Perl
• Java
• C#

I've played with Python, PHP, Lisp, Scheme, Modula-2, and Ruby, but I don't claim to know them well enough to be productive. One of these days I'll try SmallTalk.

Making the jump from C to C++ and actually writing object oriented code was a big switch. For a while I was writing C in C++. I think the earlier you introduce people to object oriented concepts the better. However, I don't teach programming so that's just my personal viewpoint.

I have mixed feelings about using command line interpreters to teach languages. On the one hand it does give instant feedback. On the other hand it teaches people to think in a scripting, sequential way rather than a building block object oriented way.

However, you can do command line interpreters in Java. The one that I know about is BeanShell. It's pretty useful in general.

I've been using Beanshell for a while and it works pretty well. I like that it allows to write scripts in java syntax.
My only gripe is that there isn't a safe way to kill a script that is running in a seperate thread. Groovy any better in that respect?

BTW, here's a little app I wrote using swing & beanshell.

I presume it's written in C#/.NET, so what's to say we can't run it under Mono?

Who knows, we might be lucky and this is the first project Microsoft will release under it's GPL-like license? MS taking over the heart of the Linux geeks - their SHELL! ;)

Or Gnome could just incorporate BeanShell instead...

I have to agree with this. I learned Java when I was 9 years old, it was my first programming language, and is still my favorite (I started with a pre 1.0 release). I found that in teaching Java, the best option (for roughly the first 4 lessons) is to use Beanshell. It gets the basic concepts (like variables, methods and even classes) across very quickly (literally 4 lessons), and the you switch to a "real" environment to teach more advanced topics. (I tought Java to the younger students when I was in matric).

The VM takes up a lot of memory and the startup time basically rules out efficient little programs (think Unix commands).

AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop.

It's worth mentioning here that Lisp's debugging environments are among the very worst I have ever had the misfortune to use. I'm not talking about free gunk like CMUCL. I'm talking supposedly high-quality, commercial systems like Lispworks or Allegro. Truly awful compared to even xxgdb. Dark ages.

As to a topline read-eval-print loop, have I got a treat for you: BeanShell is exactly what you want. A Lisp-like command-line for Java. Fan-tastic! Oh, and it's embedded in most modern IDEs to.

This is BS. Neither Java nor C# have the equivalents of read, eval, compile,

No, they don't have them "as primitives", but they have the primitives that let you implement those. For example, if you want Lisp-like read and eval functionality, you can use Beanshell.

As I was saying, you may not like the way Java provides dynamic features, but it does provide lots of dynamic features.

or even change-class as language primitives.

I believe the Java debugging interface specifies that, and it works about as well (take that as you like).

Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language.

Well, neither does Java, really. Java specifies an intermediate level representation, somewhat below the source, but way above machine code.

The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. [...] t is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode.

Well, the situation is a little more complex. You don't reflect over machine code, but the VM dynamically maintains a one-to-one correspondence between VM code and machine code.

The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines.

Sorry, but that's not how the JVM or CLR work. They are not arbitrary stack machines, they impose restrictions that make them basically just binary representations of the macro-expanded and canonicalized source code using postfix notation. You compile them using the same high-performance compilation strategies you might use with a C, Fortran, or Lisp source compiler. They are no harder and no easier to parallelize than any other representation of an imperative language.

As for "the" Smalltalk approach, there is no such thing. The original Smalltalk used a stack-based bytecode interpreter, recent versions of Smalltalk (and Self) are using the same JIT approach as Java. I don't know of any Lisp system using a high-performnce JIT (other than those based on the JVM or CLR, of course), and I think that's a major problem with Lisp.

Java's choice of "binary postfix program representation after canonicalization" instead of Lisp's "weakly parsed uncanonicalized symbols-plus-lists" seems to be a winning combination: manipulating code at that level is slightly less intuitive, but it avoids many of the complexities and limitations of Lisp code walkers. As a result, people have been able to implement things in bullet proof was in Java that ended up being at best flaky using code walkers.

Let me just be clear again: I'm not saying that Java is "better" than Lisp, or worse than Lisp, In fact, I'm pretty neutral on the matter: I think both systems have some brilliant ideas, and both systems have some absolutely awful design flaws. Neither language meets my standards for careful language design or good taste. But I do appreciate the good points each has to offer and I believe both languages and systems have contributed significantly to progress in the state of the art.

Why the compounding of a task into another task to achieve the same result. Running the scripts I require to run through Java adds another step to running them that I do not require. Therefore it is a solution to a problem that is more complex than alternate solutions that exist to the same problem.

How is that complex?

It is more complex than what I require. Since you do not know what I do, you are hardly in a position to judge. I on the other hand can readily judge whether running my scripts through Java is something that I require. Believe me, its not.

Is that complex?

No, and this is where things get delicious, I'm talking about scripting, you know, writing text files with commands in them that you launch using a command interpreter of some kind. Not running a command prompt that the so called "Examples" of yours show. Its actually more complex to call a script from Java than your poor examples reflect. How about a link to demonstrate: BeanShell Example - Calling scripts from Java

If it is, I think you should be careful about what problems you are trying to solve. Stick to simple ones.

I think that you should perhaps take some of your own advice. I know how to run a command prompt, I know how to run a script, I know how to run Java. Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.

I looked at the scriptometer page, but didn't find much about Java scripting environments (not JavaScript). I'm a long time user of Bean Shell and consider it to be damn near perfect, though I know there are other interpreters. While it does not have such scripty features as weak typing (there are other solutions that do), it does allow for very quick scripting for a Java programmer and leverages all available Java libraries! And as I said, it's not just one language, but a whole class of them to choose from. That's some powerful stuff.

What about Beanshell! It is a scripting language for Java-based applications like jEdit. Beanshell will interpret ordinary java source files in addition to class files. You can even write a simple web browser in less than 74 lines of code! It surely should have been considered along if languages such as Pike, Lua, and Haskell were thought of.

This entire analysis seems suspect. Take the first section. For JavaScript, their implementation uses NJS, which hasn't even stabilized with a 1.0 release yet! They also have a unix bias: many applications have no need of the shebang, #!. Even though, a script in another language could easily be written to implement that feature. Shebang support is a trivial and doesn't deserve the 15points awarded. Furthermore, awarding points for "program(s) can be passed on command line" is silly. That is a horrible horrible style of coding guaranteed to make scripts hard to maintain.

Their second section is not complet and has a heavy bias against Java and C#. The subsections, "smallest" and "hello world," are silly. I never understood why having a small size for the simplest program is important for nontrivial applications. (For that matter, I never understood why programmers wish for the "least typing" in a language. I never never never code for least typing, since that often makes programs unreadable!) Finally, their coding style is inconsistent. For instance, they use for Java:

public class formatting {
public static void main(String[] args) {
int a=1;
int b=2;
System.out.println("" + a + " + " + b + " = " + (a + b));
}
}

Yet the authors throw these conventions out with JavaScript:

a=1; b=2; System.print(a, " + ", b, " = ", a + b, "\n")

(Also note that the numbers reported and counted don't match, but I may just be missing something.) Why? Java and C# seem destine to loose with the author's methods. As I said, this entire report seems biased and unscientific.

P.S. /. needs to fix the site's source code white-space style. This is getting ridiculous.

What about Beanshell! It is a scripting language for Java-based applications like jEdit. Beanshell will interpret ordinary java source files in addition to class files. You can even write a simple web browser in less than 74 lines of code! It surely should have been considered along if languages such as Pike, Lua, and Haskell were thought of.

This entire analysis seems suspect. Take the first section. For JavaScript, their implementation uses NJS, which hasn't even stabilized with a 1.0 release yet! They also have a unix bias: many applications have no need of the shebang, #!. Even though, a script in another language could easily be written to implement that feature. Shebang support is a trivial and doesn't deserve the 15points awarded. Furthermore, awarding points for "program(s) can be passed on command line" is silly. That is a horrible horrible style of coding guaranteed to make scripts hard to maintain.

Their second section is not complet and has a heavy bias against Java and C#. The subsections, "smallest" and "hello world," are silly. I never understood why having a small size for the simplest program is important for nontrivial applications. (For that matter, I never understood why programmers wish for the "least typing" in a language. I never never never code for least typing, since that often makes programs unreadable!) Finally, their coding style is inconsistent. For instance, they use for Java:

public class formatting {
public static void main(String[] args) {
int a=1;
int b=2;
System.out.println("" + a + " + " + b + " = " + (a + b));
}
}

Yet the authors throw these conventions out with JavaScript:

a=1; b=2; System.print(a, " + ", b, " = ", a + b, "\n")

(Also note that the numbers reported and counted don't match, but I may just be missing something.) Why? Java and C# seem destine to loose with the author's methods. As I said, this entire report seems biased and unscientific.

P.S. /. needs to fix the site's source code white-space style. This is getting ridiculous.

The BeanShell lets you use pure Java as a scripting language and it's almost trivial to include the BeanShell in your Java application.
See http://www.beanshell.org/.

Yes, the correct technology to use would have been BeanShell.

What exactly is the difference between 1) using a CLI and then writing "for x in ..." or 2) using a GUI and then writing a short script?

None, and that's my point. For any GUI to be sufficiently flexible that you can do things as easily as you can with a shell, it must include a scripting language. That's all an XTerm is, BTW. A GUI app running (and only running) a script interpreter.

GUIs are insufficient except for the most basic tasks. Any sufficiently complex task either requires (a) scripting, or (b) a lot of time.

I agree with your sentiment that Bash (or CSH, or their derivatives) aren't the best scripting languages. They're useful mainly because they're entrenched. Most serious CLI users have a favorite, more advanced, scripting language they prefer to use, such as Ruby, Perl, or Python. Take a look at Bean Shell (BSH). It is a Java-ish scripting language and shell environment, and you have access to the full Java API (including Swing). This makes it handy to script together GUIs. Personally, I don't like the language much, but a lot of people do, and you might, too.

I don't know if you are talking about invoking scripts from Java, in which case you a lot of alternatives, from beanshell to jython (the python implentation in Java) and most of them could be run through BSF to have an uniform API.
DinamicJava on the other hand is an interpreter of a superset of Java.
I don't know what you find annoying: compiling and executing. That's the norm for most programs. Java programs are Just In Time Compiled but that is done transparently by the virtual machine and is faster than interpreted.

The sad thing is that Beanshell actually should be called Javascript, since that is exactly what it is. LiveScript or ECMAScript are both superior names. Perhaps it could be called rhinoscript or webscript, too. Anything else would have been better.

There is a kick-ass scripting language for Java, it's just not produced by Sun. Check out BeanShell. It makes a wonderful embedded scripting language as well as a standalone toy. I've used it in comercial applications and to play with adding new features on the fly. You can download BeanShell here.

It's not exactly Java, but Beanshell works pretty nicely

eval() of new programming code? One but not the other.

Ever heard about Beanshell?

it may help...

You are missing the point about this shell making heavy use of the .NET framework. Presumably, any .NET object would be accessible to the command line... Given that they intend for their whole OS to be based on .NET, this means the command line may offer access to more functionality than /bin/sh offers on a UNIX platform.
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell, rather than a simple shell replacement.
If this achieves its potential, Linux/UNIX may end up playing catch-up on the CLI front as well as on the GUI front. Good move for Microsoft, and one that would be hard to counter in the open/free software world because we have no universal object-based virtual machine/interface for use as a basis.
Or rather, I should say we have too many - Java, CORBA, the Mozila components, and even .NET (Mono). Microsoft could, if it plays nice, actually set a new portable standard for shells (based on .NET on Windows and Mono on UNIX). Of course, knowing Microsoft, they'll blow it by succumbing to the temptation of poisoning it with all sort of Windos-isms. This will be interesting to watch...

This is the signal for an embarrased cough, because, um, LISP isn't at the very edge of innovation. Not one of the differences cited by the article has no close equivalent in the Java space, for example - even instant evaluation is supported by BeanShell, which - while technically a different language - supports almost all of the Java syntax and API. And all objects carry function pointers implicitly. If you don't grok that, either you don't understand OOP, or you're making a false mountain ("Java doesn't have function pointers!") out of a molehill ("Java anonymous classes are long-winded to write, and they can only see local variables if they're declared final"). Big deal.

Ant is also capable of checking to see if required libraries are available. The sample JBoss development project includes this capability to check for the existence of the XDoclet task.

For instance, there is this task that ships with Ant:
Available Task

Most of the time in Java you don't have to worry that much about what endianness, etc. that you would normally do with C or C++, so I think in practice Ant does a very capable job.

If one uses BeanShell you can also do some pretty powerful custom tasks, including writing light-weight Java scripts (not a typo :-) to do all kinds of checks if you need to... not to mention that it is relatively simple to write Ant tasks for all kinds of build needs, including creating jars of classes by dependencies, code metric collection, etc.

I know of a development house that generated a pretty sophisticated code work set system using Ant scripts, add-on tasks, and some bean shell scripts.

It also has some options to avoid recompiling all Java files when only some have changed, just like make.

Any Java project I have seen that uses Ant and distributes source has been very easy for me to compile... I would say as easy as autoconf if not easier... and I've found Ant a lot simpler to learn than autoconf.

Having said that, there are some irritating things with Ant (trying to make filesets out of paths is one that springs to mind). And I am certainly a fan of ./configure;make;make install.... but it is all about the right tool for the right job, and Ant is pretty much the de facto answer as far as Java development is concerned.

I'm assuming you're talking about java.awt.Robot. This, with BeanShell would allow test scripts for GUIs to be built.. A more sophisticated system would be able to capture AWT events, and store them in a file for later playback...

I find also extremely useful the ability of Emacs (thanks to Ange-FTP) to edit files remotely: is is just as simple as opening ``/username@host:/remote/file/name'', and everything (dired and completion included) just works as if it was on a local filesystem, so I don't even have to move from my workstation...

OTOH, for those who like having everyting and the sink but don't feel comfortable with Emacs, I'd say that JEdit is surely the best choice for them: it is completely scriptable using BeanShell, a Java-like scripting language, and has lots and lots of plugins for additional functionalities.

You can use emacs inside cygnus.
I launch emacs from cygnus: I got a fair environment,
and I can compile/dev unix code.
Cygnus has some problems, but for small task you
can try this solution...
Another Javaized option is Beanshell

what i sometimes look for an editor/ide is if it *doesn't* have the features i *don't* want. i really don't want an integrated java debugger, or code browser, or other things i consider bloat.

that's what i liked about EditPlus, it was configurable, bare-bones, and cheap.

i moved to jEdit earlier this year. it's highly configurable, the plugins are a brilliant concept (just get the components i want!) and something that most don't point out is: there's actually a major advantage to this editor being written in Java....

...and that advantage is BeanShell. beanshell is basically a java interpreter written in... java. it may sound silly at first, but this means you can script jEdit components at runtime without compiling. manipulate text, communicate with plugins, write your do-it-all ultimate macro, or just execute that java math expression you want to test out. it's also a great "scratchpad" for trying out code snippets to see if you get the results you expect, without having to create a class/static main method, compile, etc. just type in a few lines of code and go.

check out the jedit plugins here (i wish there was a cvs plugin! anyone care to do a port?)

see the jedit community page (experimental plugins, lots of beanshell macros, etc) here

I use perl, python, sh, javascript for scripting, but sometimes find myself writing scripts in java (when you code in it all day it tends to stick in the mind).

Luckily there is a script interpreter for java called beanshell (FAQ) so my scripts actually will run.

I use perl, python, sh, javascript for scripting, but sometimes find myself writing scripts in java (when you code in it all day it tends to stick in the mind).

Luckily there is a script interpreter for java called beanshell (FAQ) so my scripts actually will run.

You may be right there - but I doubt it would keep them all that honest. :-)

Personally, I'm not a huge fan of implementation inheritance in the first place. I prefer composition in most cases from a design standpoint.

I'm also not sure that it is very far ahead of what's already possible with the JVM. I've already used Rhino, Beanshell, DynamicJava and JPython. All of them interoperated pretty seamlessly through the common denominator of Java objects, and with RMI and/or CORBA, you even get a fair degree of language and network transparency.