Hacker News Reader

Comment by blharr | Hacker News Reader

Confused by this approach, people want to write in interpreted languages and have it compiled with an LLM?

How would you do things like dynamic code execution or reflection? Lots of properties are stripped as part of the compilation that you wouldn't be able to refer back to.

Are you just saying write python -> interpret it -> compile it -> convert to assembly? Because I believe that already exists, but is difficult to just do that all the time because of the compile step and having to convert to static typing

View on HN

The same way c# used to do it. C# provided dynamic code generation in both byte-code-level, and AST/lamba implementations. And even provided an interactive C# "interpreter" that actually used dynamic code generation under the covers. All of which died with .net core. I rather suspected that Microsoft decided that dynamic code generation was far too useful for writing cloaked viruses, and not quite generally useful enough to justify the effort.

You'd have to generate reflection data at compile time. And llvm supports dynamic code generation, so that's not a problem either.

Not really sure why anyone would want to do an interpreted language though.

Expression Trees and IQueryable<T> compilation did not die and remain fully supported features. For example EF Core uses them for query compilation. 'dynamic' did not die either even though it should not be used because there are usually better constructs for this.

>dynamic code execution

Run the code through actual Python or NodeJs. Once you are happy with result, compile it to native.

>reflection.

Reflection can be "unrolled" to static values during compilation.

>Are you just saying write python -> interpret it -> compile it -> convert to assembly? Because I believe that already exists,

It exists in the sense that you still have all the python interpreter code for dynamic typing baked into in the executable. This would remove all of this.

Reply on news.ycombinator.com