Hacker News new | past | comments | ask | show | jobs | submit login

It's useless information then, any real executable is native. In that sense you can say Perl is native (Python, Ruby, JavaScript/nodejs).



They mention Clojure, and the Clojure interpreter is a Java program, which is not native. So there is nonzero information in mentioning that the interpreter is native.


Sorry, but you have absolutely no idea what you're talking about. Clojure produces Java bytecode, which is interpreted (and JITed) by the JVM, which is a native program.

See http://stackoverflow.com/questions/3107299/how-do-clojure-pr...


Well yes any real executable is native. The perl executable is indeed a native program. It's a native interpreter for Perl.

But there are also interpreted interpreters aren't there? Which aren't real executables, and aren't native. It would be possible to write an interpreted interpreter for Perl, maybe in a language like Ruby. Jython is a real example of an interpreted interpreter (if you ignore that the JVM has a JIT, but it isn't AOT, which you've said that you think is an important criteria).

And so it isn't useless information.

The distinction is particularly relevant here because the RPython technology they are using to build their interpreter means they can either interpret their interpreter using the Python interpreter, or they can make a native interpreter by compiling their interpreter to native AOT. That's probably why they used that particular wording.

So, again, not only is their terminology consistent with the rest of the industry, they are also making a specific and interesting point here, and it isn't useless information.


They put that in a headline - A small, fast, native Lisp. It's missleading/clickbaity.


I think it's meant as in comparison to Scala and the like, which run on the JVM, and thus aren't "native" in the same way (right? or am I misinformed about Scala?). There's a lot of languages that sit on top of the JVM at this point, so they might have seen it as a distinguishing characteristic.


> thus aren't "native" in the same way

Sorry, no, this is nonsense. Scala source code is compiled to Java bytecode, which is interpreted and JITed by the JVM. Pixie source code is compiled to the Pixie bytecode which is interpreted and JITed by the Pixie VM. chrisseaton claims that "native" refers to the interpreter, but this is rubbish ... that's not what the industry means by "native".


> But there are also interpreted interpreters aren't there?

I mean, not in use.... What would be the point? Every other interpreter worth using is AOT compiled, it's hardly something to boast about.

One exception might be JRuby, I suppose. Kind of a strange comparison to go out of your way to disabuse.


Not strange at all. The main language inspiring pixie is clojure, whose interpreter runs on the JVM. I might even go so far as to say that the main reason to use pixie is because you want to write clojure but can't afford to use a JVM for the task at hand


There's no such thing as the Clojure interpreter. Clojure programs are translated into Java bytecode, which runs on the JVM, which is a native program. (see http://stackoverflow.com/questions/3107299/how-do-clojure-pr...)

Pixie programs are translated into Pixie bytecode, which runs on the Pixie VM. Bytecode is, by definition, not "native".


If we're going by the traditional idea of "bytecode interpreter" or "threaded interpreter", clojure is emphatically not one of them. It JIT compiles the lisp to JVM bytecode; the equivalent in Pixie would be JIT compiling to native code.

IIRC with RPython/pypy the two techniques are interleaved, but most users I've seen opt for some JIT optimization.


> But there are also interpreted interpreters aren't there? Which aren't real executables, and aren't native.

Sure, you can for example run a Prolog interpreter on top of a Lisp interpreter. It's just not fast, but may have other qualities.


"So, again, not only is their terminology consistent with the rest of the industry"

You have said that twice. It was wrong both times.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: