[joshka]

Another option is any classless java file is just a class with the same name as the file implementing Runnable.

E.g. Foo.java

   println("foo")

Becomes:

   class Foo implements Runnable {
     void run() {
       System.out.println("foo");
     }
   }

Then running java Foo.java instead just stubs a main() that looks like:

   class Main {
     void main() {
       new Foo().run();
     }
   }

[usrusr]

Instantly my mind wants to "javaify" it again, that is, generalizing it to some general case by involving qualified names:

Instead of stubbornly implementing Runnable from those flat files, mix in the well-established concept of single-function-interfaces (Runnable is just one of many) and introduce a top-level "extends" that makes the file body an SFI implementation:

  extends java.lang.Runnable;
  java.lang.System.out.println("Hello world");

(and it only gets better if you also add the rule "in absence of any imports statements, an implicit import java.lang.*; is added)

[joshka]

Yeah, I hadn't quite figured how you'd mix this such that the arguments are passed by convention, so your point about single function interfaces is a good one there.

BTW, I think the pedantic view on this based on the (mailing list discussion) is that it becomes java.lang.StaticImports.println("Hello"), which calls System.out.println.

[ajnin]

You'd be limited very quickly since Java does not have local methods. This would work for only very simple scripts that fit in a single method.

[joshka]

The context of this is entirely what is the lowest amount of ceremony that we need in order to reduce the teaching overhead of a java program. This really comes down to simple first up, with easy exits towards more complex. That very much looks like to me:

1. Single file single function imperative

2. Single file multi-function imperative (introduce multiple functions)

3. OO (introduce classes etc)