3 ms·

I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users

I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users will just have to put up with the slight delay....

6ren 15y ago
Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. Seems a bit of overkill, but I like the idea of a transformation operating above the level of one language... I suppose the logical conclusion is compilation of arbitrary Java source to a scripting language, according to the performance characteristics required. It's nice that it would retain semantics and be transparent to the user, while rebalancing performance trade-offs.
- nessus42 15y ago
  Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
  - 6ren 15y ago
    Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
    - nessus42 15y ago
      Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. It seems as if it would be better to have have a JVM byte code to Python byte code translator, or something like that, if such a thing is possible. But I should think that it would be even better and easier to just have a version of the JVM (or an option on the JVM) that starts up much faster. If you're happy with just Java, doesn't BeanShell start up more quickly? (I don't know, because I've never used it.)
      - 6ren 15y ago
        > JVM byte code to Python byte code translator Yes; or a JVM that starts up faster, and split the code between them in the same way. I'm assuming there's a fundamental trade-off between startup delay and average speed, or we'd have had an instant option long ago. Um, if the problem is loading etc jars, this mightn't work. But one could still detect byte-code calls with hard-coded string arguments (for "--help" and text) and compile that to python.

6ren 15y ago

Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. Seems a bit of overkill, but I like the idea of a transformation operating above the level of one language... I suppose the logical conclusion is compilation of arbitrary Java source to a scripting language, according to the performance characteristics required. It's nice that it would retain semantics and be transparent to the user, while rebalancing performance trade-offs.

nessus42 15y ago
Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
- 6ren 15y ago
  Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
  - nessus42 15y ago
    Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. It seems as if it would be better to have have a JVM byte code to Python byte code translator, or something like that, if such a thing is possible. But I should think that it would be even better and easier to just have a version of the JVM (or an option on the JVM) that starts up much faster. If you're happy with just Java, doesn't BeanShell start up more quickly? (I don't know, because I've never used it.)
    - 6ren 15y ago
      > JVM byte code to Python byte code translator Yes; or a JVM that starts up faster, and split the code between them in the same way. I'm assuming there's a fundamental trade-off between startup delay and average speed, or we'd have had an instant option long ago. Um, if the problem is loading etc jars, this mightn't work. But one could still detect byte-code calls with hard-coded string arguments (for "--help" and text) and compile that to python.