DevOps Zone is brought to you in partnership with:

I've been writing software since about 1993, spanning several different domains and programming languages. Always on the look for better and more fun ways to program. I spent much of my youth fencing, and recently I returned to the sport as a coach. Borislav is a DZone MVB and is not an employee of DZone and has posted 15 posts at DZone. You can read more from them at their website. View Full User Profile

Where are the JVM Scripting IDEs?

08.29.2014
| 8566 views |
  • submit to reddit

The raise of scripting languages in the past decade has been spectacular. And since the JVM platform is the largest, a few were designed specifically for that platform while many others were also implemented on top. It is thus that we have JRuby, Jython, Groovy, Clojure, Rhino, JavaFX and the more obscure (read more fun) things like Prolog and Scheme implementations. Production code is being written, dynamic language code bases are growing, whole projects don't even have any Java code proper. Yet when it comes to tooling, the space is meager to say the least.

What do we have? In Eclipse world, there's the Dynamic Languages Toolkit which you can explore at http://www.eclipse.org/dltk/, or some individual attempts like http://eclipsescript.org/ for the Rhino JavaScript interpreter or the Groovy plugin at http://groovy.codehaus.org/Eclipse+Plugin. All of those provide means to execute a script inside the Eclipse IDE and possible syntax highlighting and code completion. The Groovy plugin is really advanced in that it offers debugging facilities, which of course is possible because the Groovy implementation itself has support for it. That's great. But frankly, I'm not that impressed. Scripting seems to me a different beast than normal development. Normally you do scripting via a REPL, which is traditionally a very limited form of UI because it's constrained by the limitation of a terminal console. What text editors do to kind of emulate a REPL is let you select the expression to evaluate as a portion of the text, or take everything on a line, or if they are more advanced, then use the language's syntax to get to the smallest evaluate-able expression. It still feels a little awkward. Netbeans' support is similar. Still not impressed. "What more do you want?", you may ask. Well, don't know exactly, but more. There's something I do when I write code in scripting languages, a certain state of mind and a way of approaching problems that is not the same as with the static, verbose languages such as Java.

The truth is the IDE brought something to Java (and Pascal and C++ etc.) that made the vast majority of programmers never want to look back. Nothing of the sort has happened with dynamic languages. What did IDEs bring? Code completion was a late comer, compared to integrated debugging and the project management abilities. Code completion came in at about the same time as tools to navigate large code bases. Both of those need a structured representation of the code and until IDEs got powerful and fast enough to quickly generate and maintain in sync such a representation, we only had an editor+debugger+a project file. Now IDEs also include anything and everything around the development process, all with the idea that the programmer should not leave the environment (nevermind that we prefer to take a walk outside from time to time - I don't care about your integrated browser, Chrome is an Alt-tab away!).

Since I've been coding with scripting languages even before they became so hot, I had that IDE problem a long time ago. That is to say, more than 10 years ago. And there was one UI for scripting that I thought was not only quite original,  but a great match for the kind of scripting I was usually doing, namely exploring and testing APIs, writing utilities, throw away programs, prototypes, lots of activities that occasionally occupy a bigger portion of my time than end-user code.  That UI was the Mathematica notebook. If you have never heard of it, Mathematica (http://www.wolfram.com/mathematicais a commercial system that came out in the 90s and has steadily been growing its user base with even larger ambitions as of late. The heart of it is its term-rewrite programming language, nice graphics and sophisticated math algorithms, but the notion of a notebook, as a better than REPL interface, is applicable to any scripting (i.e. evaluation-based, interpreter) language. A notebook is a structured document that has input cells, output cells, groups of cells, groups of groups of cells etc. The output cells contain anything that the input produces which can be a complex graphic display or even an interactive component. That's perfect! How come we haven't seen it widely applied?

Thus Seco was born. On a first approximation, Seco is just a shell to JVM dynamic languages that imitates Mathematica's notebooks. It has its own ambition a bit beyond that, moving towards an experimental notion of software development as semi-structured evolutionary process. Because of that grand goal, which should not distract you from the practicality of the tool that I and a few friends and colleagues have been using for years, Seco has a few extras, like the fact that your work is always persisted on disk, the more advanced zoomable interface beyond the mere notebook concepts. The best way to see why this is worth blogging about is to play with it a little. Go visit http://kobrix.com/seco.jsp.

Seco was written almost in its entirety by a former Kobrix Software employee, Konstantin Vandev. It is about a decade old, but active development stopped a few years ago. I took a couple of hours here and there in the past months to fix some bugs, started implementing a new feature to have a centralized searchable repository for notebooks so people can backup their work remotely, access it and/or publish it. That feature is not ready, but I'd like to breathe some life into the project by making a release. So consider this an official Seco 0.5 release which besides the aforementioned bug fixes upgrades to the latest version of HyperGraphDB (the backing database where everything get stored) and removes dependency on the BerkeleyDB native library so it's pure Java now.

Published at DZone with permission of Borislav Iordanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Borislav Iordanov replied on Sun, 2014/08/31 - 3:41pm

I've received queries about using other than the pre-configured scripting languages. Here is the HOWTO on that: Adding Scripting Languages Wiki Page 

The prebuilt versions for those other languages are probably not the latest interpreters. Write back if that's important for you. 

Joop Eggen replied on Wed, 2014/09/03 - 10:17am

Two associations:

  • SmallTalks squeak (the world/system is persistent and incorporates the IDE)
  • Knuth's Web, Weave and Tangle (literate programming)

Borislav Iordanov replied on Wed, 2014/09/03 - 11:38am in response to: Joop Eggen

Joop,

That's exactly right. Both of those have been inspirations for Seco! 

Boris

Torsten Bergmann replied on Fri, 2014/09/05 - 5:39am

It is not new that dynamic languages are more productive than static, but when the applications and code grows you need better tools and a good IDE. You will be easily lost with some of the new and fashionable dynamic languages as they do not scale with the size of the software. Remember that maintenace is often higher than initial development. And managing thousand lines of code without good tools or refactoring is not fun.

So yes, have a look at Smalltalk as it provides a pure object oriented language, a dynamic and adoptable object system and IDE's with mature tools. Many things in software engineering directly come or were invented in Smalltalk (JUnit was a port of the original SUnit for Smalltalk from KentBeck, XP programming was invented in Smalltalk, Refactoring and Code Browsers, UI's, ...). Also Tablets and iPad go back to the original "Dynabook" ideas of Dr. Alan Kay - who invented object orientation, Smalltalk and the first UI systems that in fact were built using Smalltalk. 

In the last century Smalltalk was seen as an outsider because it was based on a virtual machine and computers were too slow to run it. Java increased the acceptance of VM's then and using virtualization technologies now is very common. Another problem for Smalltalk was that systems were not affordable by a usual programmer because of stupid management decisions at the former largest vendor (ParcPlace/Digitalk at that time).

Situation has changed drastically in recent years: computers are now fast enough to run VM based languages and meanwhile there are also free versions of Smalltalk available. 

I would recommend to check out the free, open source and MIT licensed "Pharo" environment:

  http://www.pharo.org

which currently is the most innovative open source Smalltalk system. Checkout the
free book collection http://pharo.pharocloud.com/pharobooks  to learn about it. 

But you can also have a look at commercial systems like Cincom Smalltalk or VA Smalltalk from Instantiations (formerly VisualAge for Smalltalk from IBM) who provide evaluation versions. 

BTW: Smalltalk is alwys coming with it's own portable virtual machine because it is still not possible to run Smalltalk with a decent performance on either JVM or .NET virtual machine.
Even #invokeDynamic (JSR-292) has not changed that as for the flexibility of a Smalltalk implementation more control is needed. The nice thing is that for Squeak and Pharo (and some other ST's as well) the virtual machine is also open source. 

Smalltalk has a long tradition in virtual machine building. For instance Lars Bak (author of V8 JavaScript engine and Dart) has built virtual machines for Smalltalk and Self before joining Google.

Borislav Iordanov replied on Fri, 2014/09/05 - 10:26am in response to: Torsten Bergmann

Torsten,

I think all your points are valid regarding virtual machines, how great Smalltalk is, and how limiting the JVM is when it comes to supporting more dynamic languages (less typing, more reflexivity). There are several adoptions problems though: (1) People get locked in a single programming language and a single view of what development should look like, no matter how great Smalltalk is, there are other languages that are also great or that people happen to appreciate or chose for whatever reasons (2) For better or worse, the JVM dominates, thanks to Sun's marketing dollars in the 90s, and Hotspot btw is also offspring from Self (according to Dave Ungar). Unfortunately, people follow the latest trends, and money combined with shameless promotions determine the latest trends, not technical superiority. There is also great work done by the Alan Kay and Viewpoints Research. Gilad Bracha's Newspeak is another effort in that direction that looks really nice, I'd encourage everybody to experiment with, try to make use of, and provide feedback on those environments. Software development should be fun and there shouldn't be limits to creativity. But very few people have any idea of the technical capabilities of those systems and almost nobody uses them for business software. The reason I chose the JVM for Seco, being fully aware of its limitations, is that I can actually use it in my day-to-day work. 

Cheers,

Boris

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.