Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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();
     }
   }


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)


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.


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.


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)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: