[HN Gopher] Code Models
       ___________________________________________________________________
        
       Code Models
        
       Author : ludovicianul
       Score  : 110 points
       Date   : 2024-06-18 12:06 UTC (3 days ago)
        
 (HTM) web link (openjdk.org)
 (TXT) w3m dump (openjdk.org)
        
       | DarkNova6 wrote:
       | The article might not make sense without some context.
       | 
       | This is part of "Project Babylon" and its mission is to: "extend
       | the reach of Java to foreign programming models such as SQL,
       | differentiable programming, machine learning models, and GPUs.
       | Babylon will achieve this with an enhancement to reflective
       | programming in Java, called code reflection."
       | 
       | See: https://openjdk.org/projects/babylon/
        
         | dartos wrote:
         | Thanks, I was thinking LLMs
        
         | kalaka wrote:
         | When okr from leaders drop to individuals, due to pretending-
         | to-be-leader will change the intention causing deflection in
         | the core principle.
         | 
         | It is what it is.
        
         | brap wrote:
         | How does reflection help with this? Is it by making it easier
         | to write "compilers" from Java to whatever, using Java?
        
       | dekken_ wrote:
       | reminder: switch to openjdk if you haven't already
       | 
       | https://www.theregister.com/2024/06/20/oracle_java_licence_t...
        
       | albertzeyer wrote:
       | Oh: Automatic differentiation of Java code using Code Reflection:
       | https://openjdk.org/projects/babylon/articles/auto-diff
       | 
       | This sounds interesting.
       | 
       | I remember that Swift for TensorFlow was similar.
       | 
       | Maybe you could also consider JAX to be similar.
       | 
       | Basically, can you do now sth similar as JAX but for Java? The
       | article also talks about "the Babylon GPU work requires the
       | transformation of code models to GPU kernels".
        
       | kalaka wrote:
       | It looks complicated.
       | 
       | Here is my technique.
       | 
       | Trace the control flow and regenerate the flow on target
       | programming language.
       | 
       | In their's they have abstracted problem such as blocks and
       | operation. But adding more condition to the philosophy is hard
       | thing. The core principle needs simple
        
         | almostgotcaught wrote:
         | > Trace the control flow and regenerate the flow on target
         | programming language.
         | 
         | that's not a model of the code that's just a trace...
        
         | techbro92 wrote:
         | In general it's impossible to trace the flow of an entire
         | program due to the halting problem. Also most programs have a
         | lot of branches and this would lead to an explosion of possible
         | paths through the code to trace.
        
       | Dolpheyn wrote:
       | Is this a runtime MIR?
        
       | gmfawcett wrote:
       | It sounds cool but also like a remarkable level of scope creep
       | for the JVM. I realize that Java ecosystem is far beyond simple
       | these days. Nobody is spinning up a JVM implementation as a hobby
       | project. But sad to see the deep entrenchment that is caused when
       | an open standards platform is made so inconceivably complex that
       | there is simply no opportunity to innovate on alternative
       | implementations.
       | 
       | This is not an observation about this specific project, just
       | about the organizational pressure to extend standards based
       | systems beyond their core functionality, into territory where
       | only few players can afford to roam.
        
         | _old_dude_ wrote:
         | This is similar to the expression tree API of C# so no change
         | in the JVM is required, only cooperation between the java
         | compiler and the reflection API.
         | 
         | The code model can be computed by the compiler, inserted in the
         | classfile in a specific binary or text format and read at
         | runtime using the reflection API.
         | 
         | I've not taken a look to the implementation so it's speculation
         | but I do not think the JVM need to be changed.
        
       | xg15 wrote:
       | Oh great, the one way to make reflection even more unpredictable
       | than it already is...
       | 
       | So instead of "only" finding that my choice of method names,
       | class structure and presence or absence of ostensibly unused
       | class members can change programs behaviour in arbitrary ways,
       | now that property will extend to the implementation code itself?
       | 
       | Have fun getting reliable static analysis working on this
       | stuff...
        
       | hyperpape wrote:
       | This looks like it's building on top of this prior JEP
       | https://openjdk.org/jeps/457.
        
       ___________________________________________________________________
       (page generated 2024-06-21 23:01 UTC)