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

71–80 of 164 posts

Re: Pixie – A small, fast, native Lisp

#71

Post by allover »

mapcars wrote: post #15
xaduha wrote: post #13

http://www.red-lang.org for those who doesn't necessarily need Lisp, but appreciates homoiconicity and other nice things. > This executable is a full blown native interpreter with a JIT, GC, etc. > A small, fast, native lisp I have issue with the use of the word 'native' here. For me 'native' mostly means AOT compiling.

To me Rebol/Red is more lisp than some other lisps out there. It doesn't have so much parens, true, but the idea of like code is data and DLS possibilities are huge things.

First I've heard of Red. Does it implement 'readable' [1] or is it a [parallel school of thought] (can't think of right phrase here but you get what I mean)?

Also has anyone tried to create a 'readable' [1] flavour of Clojure yet? If not, why is that, do lispers consider all the parens to really not be a barrier?

[1] http://readable.sourceforge.net/

Re: Pixie – A small, fast, native Lisp

#72

Post by kazinator »

sigjuice wrote: post #18

I find it very hard to work with a mixture of brackets and parentheses. Does anyone else prefer an all-parentheses syntax for reading and typing?

I hate the stupidly gratuitous use of vectors in specific syntactic roles like the denotation of variable bindings.

That applies regardless of how they are spelled, be it [...] or #(...).

Re: Pixie – A small, fast, native Lisp

#73

Post by ThatGeoGuy »

abc_lisper wrote: post #52
mschaef wrote: post #38

Earlier quoted context omitted.

I run some very simple Clojure [1] on an RPi 2 as part of a home monitoring system. Startup is considerably longer than on other platforms (30 sec or so), but I haven't had any issues with runtime performance, and having a Lisp running on what is essentially an embedded platform is very useful. (It'd be easy to make the argument that my agent code doesn't do much, but it doesn't diminish the fact that Clojure is able…

That is good to hear. Ordered my pi!

Not that I know if it helps, since you seem predisposed to Clojure, but CHICKEN Scheme on a Pi also works quite well. We even have direct bindings to GPIO and the like, since someone has gone ahead and packaged a library that speaks to the GPIO through the wiringPi project (http://wiki.call-cc.org/eggref/4/raspberry-pi-gpio).

Re: Pixie – A small, fast, native Lisp

#75

Post by lvh »

mschaef wrote: post #34
lvh wrote: post #28

As someone who loves both PyPy and Clojure, I wish Pixie was right up my alley. But I don't understand why the choice was made to be ... sort-of like Clojure, but not all the way, as opposed to just-another-Clojure-implementation. Why can't I have a .cljc file that runs on Pixie? (Not voluntelling halgari to do things! I would just like tn understand.)

> sort-of like Clojure, but not all the way, I tend to agree... but doesn't 'all the way Clojure' imply at least some exposure of an underlying runtime, be it either Java (Clojure) or JavaScript (ClojureScript)? I'm admittedly a bit behind the curve wrt the latest developments in the Clojure along these lines.

Yes! Being able to call PyPy things natively would be a godsend; PyPy is a great runtime and already has a good Python implementation. It has significantly fewer compatibility issues than, say, Jython.

Re: Pixie – A small, fast, native Lisp

#76

Post by oska »

stcredzero wrote: post #39
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…

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, and a C FFI. Back in the day, Smalltalk was criticized as bloated because one ended up with stripped binary+image of about 2MB. Someone around that time got SqueakVM+image down to just under 400k. There were specialized Smalltalks in company R&D that got the…

The Oberon Operating System and compiler was 131 KB. [1]

[1] http://users.cms.caltech.edu/~cs140/140a/Oberon/system_faq.h...

Re: Pixie – A small, fast, native Lisp

#77

Post by hota_mazi »

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.

Re: Pixie – A small, fast, native Lisp

#78

Post by [deleted] »

s_kilk wrote: post #55
sabauma wrote: post #36

Earlier quoted context omitted.

The RPython translator generates views of the Mandelbrot set by default, presumably to give you something to look at during the long wait.

That's pretty cool. I kinda wish the likes of NPM would output cool skeletons and heavy-metal vampire chicks while I wait ten minutes for it to install stuff.

[deleted]

Re: Pixie – A small, fast, native Lisp

#79

Post by mark_l_watson »

yellowapple wrote: post #47
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…

I'm generally in demand of small, quick startup, easy-to-embed languages that aren't Lua (I can't stand Lua; I feel like every time I've had to deal with Lua code was far more painful than reasonably possible). There's mruby and maybe a couple others. I was hoping Pixie might be another contender in that space, but it doesn't seem to be after all (or if it is, it's very poorly documented to that effect). I've been ti…

In the last, I have been very happy with Gambit Scheme for building small pre-compiled executables for command line utilities, etc. A lot of people use Chichen Scheme for the same purpose.

Re: Pixie – A small, fast, native Lisp

#80

Post by stable-point »

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 is not written in Python, it is written in RPython:

> So this is written in Python? > It's actually written in RPython, the same language PyPy is written in. make build_with_jit will compile Pixie using the PyPy toolchain. After some time, it will produce an executable called pixie-vm. This executable is a full blown native interpreter with a JIT, GC, etc. So yes, the guts are written in RPython, just like the guts of most lisp interpreters are written in C. At runtime the only thing that is interpreted is the Pixie bytecode, that is until the JIT kicks in...

Post reply on HN