Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixie – A small, fast, native Lisp

pixielang.org

Post reply on HN
Print view View original

101–110 of 164 posts

Re: Pixie – A small, fast, native Lisp

#101

Post by jibalt »

hibbelig wrote: post #50
xaduha wrote: post #41

Earlier quoted context omitted.

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...

Re: Pixie – A small, fast, native Lisp

#102

Post by throwaway7645 »

samth wrote: post #92
_halgari wrote: post #86

I'm the original author of pixie, and yeah, I'm a bit surprised to see this hit HN today. It should be mentioned that I put about a year of work into this language, and then moved on about a year or so ago. One of the biggest reasons for my doing so is that I accomplished what I was looking for: a fast lisp that favored immutability and was built on the RPython toolchain (same as PyPy). But in the end the lack of sup…

As a somewhat different data point, we've been developing pycket, an implementation of Racket on top of rpython, for the past 3 years, and while it faces many of the same challenges, we've been very happy with the results. The JIT can remove almost all of the intermediate data structures caused by the functional nature of the language, and we support tail calls and first class continuations. Overall, pycket is almost…

Is that just a JIT for Racket or a different language?

Re: Pixie – A small, fast, native Lisp

#103

Post by jibalt »

mac01021 wrote: post #88
dgfgfdagasdfgfa wrote: post #85

Earlier quoted context omitted.

> 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".

Re: Pixie – A small, fast, native Lisp

#104

Post by throwaway7645 »

jacobush wrote: post #68
throwaway7645 wrote: post #44

Earlier quoted context omitted.

Do you use it though? I really like the concepts, but the speed could be better (I know Alexander talked about this), and docs could be more beginner friendly. It's a small expert community.

I have used it in commercial embedded hardware shipping tens of thousands of units, in the USD 1000 range. Speed is excellent for the most part - where it's not it's trivial to call out to C libraries. Agree about docs but what would really help at this point would be more QA on Stackoverflow. And a good Windows port.

Agreed on the Windows thing. I tend to stay away from Cygwin. I like the new Picolisp site btw. The code on Rosetta code is terse, and uses slightly different idioms than I'm used to.

Re: Pixie – A small, fast, native Lisp

#105

Post by sabauma »

throwaway7645 wrote: post #102
samth wrote: post #92

Earlier quoted context omitted.

As a somewhat different data point, we've been developing pycket, an implementation of Racket on top of rpython, for the past 3 years, and while it faces many of the same challenges, we've been very happy with the results. The JIT can remove almost all of the intermediate data structures caused by the functional nature of the language, and we support tail calls and first class continuations. Overall, pycket is almost…

Is that just a JIT for Racket or a different language?

Yes. It is for the Racket language.

Re: Pixie – A small, fast, native Lisp

#106

Post by [deleted] »

mac01021 wrote: post #88
dgfgfdagasdfgfa wrote: post #85

Earlier quoted context omitted.

> 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

[deleted]

Re: Pixie – A small, fast, native Lisp

#107

Post by throwaway91111 »

gkya wrote: post #62
jlarocco wrote: post #59

Earlier quoted context omitted.

Well, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, for an arbitrary CL program it's impossible to tell for sure how much of the CL compiler and standard library it will need at run time, so SBCL takes the easy route and just includes everything. Some of the commercial Lisp compilers are a lot smarter at strippin…

SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.

I wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?

Re: Pixie – A small, fast, native Lisp

#108

Post by throwaway91111 »

hota_mazi wrote: post #77
branchly2 wrote: post #32

Alas, this ambitious project appears to be not currently under active development. My largely uninformed armchair opinion as to why, is that the author is very performance-driven, and in the end it's very difficult to beat the JVM performance-wise. Lesson: if you want high-perf Clojure, you already have it on the JVM. Personally, I think there's room for a simple small native Clojure implementation where performance…

> it's very difficult to beat the JVM performance-wise Especially in Python, which is what Pixie is written in. I don't think a performance-driven developer would have picked Python in the first place.

It's written in rpython; I don't understand why it couldn't be competitive with the jvm.

Re: Pixie – A small, fast, native Lisp

#109

Post by xarthna1 »

_halgari wrote: post #86

I'm the original author of pixie, and yeah, I'm a bit surprised to see this hit HN today. It should be mentioned that I put about a year of work into this language, and then moved on about a year or so ago. One of the biggest reasons for my doing so is that I accomplished what I was looking for: a fast lisp that favored immutability and was built on the RPython toolchain (same as PyPy). But in the end the lack of sup…

Just wanted to tell you how impressed I was with Pixie. Thanks for taking the time to write it.

Re: Pixie – A small, fast, native Lisp

#110

Post by sabauma »

haberman wrote: post #90
copx wrote: post #27

> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable. Oh how the definition of "small" has changed. I actually would like to know how they managed to make something like this so big . To compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, a…

I agree with your point completely. I just want to add that throwing out raw numbers like "10.3MB" or "400 KB" is not very precise. Binaries can vary immensely based on whether they have debug info, string tables, etc. or whether these have been stripped away. I wrote a size profiling tool that can give much more precise measurements (like size(1) on steroids, see: https://github.com/google/bloaty ). Here is output f…

Its worth noting that the design of the RPython JIT will always result in a large amount of static data in the resulting binary. The RPython translator basically generates a bytecode representation of most of your interpreter and bakes that into the binary. You can probably expect at least a 2x size increase in the size of your binary. As a reference point, after stripping [Pycket](https://github.com/pycket/pycket)'s binaries are 6.1Mi without the JIT and 16Mi with the JIT.
Post reply on HN