3 ms·

In contrast I think that going all in on Java scares away people who like to experiment.

eternalban 6y ago
Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you not do on a virtual machine based language, with open byte code/vm spec, open class loaders, and compile and runtime instrumentation and meta- capabilities? I used to do the switch the superclass at loadtime to experiment with adaptable programs. This was circa late 90s. Loads of fun (npi). What scares many away from Java is that it is now a very huge mental object. But not wanting to admit this, they simply pass along FUD.
- fctorial 6y ago
  > I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
  - eternalban 6y ago
    It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using classpaths. Assume a stub package com.foo.Context which is simply an extension of Object, and derive components from com.foo.Context.SuperClass. You simply need to provide a different eponymous package for the adapted instance of the code. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
    - hderms 6y ago
      I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured. Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.
      - eternalban 6y ago
        I'm pretty sure (but am hedging here :) that you would get any errors in the verification phase of loading a class. What you saw may have been due to bugs in that library you were using. Anyway, this was before ASM and other bytecode engineering libraries. Today I would not directly hack the class def myself.

Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you not do on a virtual machine based language, with open byte code/vm spec, open class loaders, and compile and runtime instrumentation and meta- capabilities? I used to do the switch the superclass at loadtime to experiment with adaptable programs. This was circa late 90s. Loads of fun (npi). What scares many away from Java is that it is now a very huge mental object. But not wanting to admit this, they simply pass along FUD.

fctorial 6y ago
> I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
- eternalban 6y ago
  It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using classpaths. Assume a stub package com.foo.Context which is simply an extension of Object, and derive components from com.foo.Context.SuperClass. You simply need to provide a different eponymous package for the adapted instance of the code. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
  - hderms 6y ago
    I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured. Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.
    - eternalban 6y ago
      I'm pretty sure (but am hedging here :) that you would get any errors in the verification phase of loading a class. What you saw may have been due to bugs in that library you were using. Anyway, this was before ASM and other bytecode engineering libraries. Today I would not directly hack the class def myself.