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

Pixie: A small fast, native lisp

github.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Pixie: A small fast, native lisp

#41

Post by andrewchambers »

gopalv wrote: post #9

This is a lisp engine written in python - RPython, to be precise. It literally compiles the lisp code into python bytecode, which is pretty neat - sort of like clojure is for the JVM. https://github.com/pixie-lang/pixie/blob/master/pixie/vm/com... Perhaps not magical, but I like the effort (though lisp-as-shell has to contend with emacs first).

You have misunderstood. Rpython compiles to C and then to a binary. There is no python bytecode there. Only pixie bytecode being interpreted by the compiled binary.

It also has a Jit engine inside it.

Re: Pixie: A small fast, native lisp

#42

Post by andrewchambers »

daveloyall wrote: post #30
_halgari wrote: post #20

Earlier quoted context omitted.

Added a few comments in the README about that.

Pixie implements its own virtual machine. Isn't that how all the tiny lisps do it? :) You know, maybe 'magic' simply sets the bar higher than the project is prepared to support. Consider 'clever'.

Umm, I don't think you understand fully what it is. it is using rpython which is a meta tracing jit. pretty magic if you read about it.

Re: Pixie: A small fast, native lisp

#43

Post by andrewchambers »

JoshTriplett wrote: post #4
GuiA wrote: post #2

What's magical about it?

I'm wondering the same thing. I dug through the entire repository, and I didn't see any references to "magical" properties.

Did you look through the rpython codebase too? Thats where the real magic is.

Re: Pixie: A small fast, native lisp

#44

Post by andrewchambers »

dTal wrote: post #18
cryptolect wrote: post #10

I'm happy to see that some new 'modern lisp on x' projects are taking design cues from Clojure (See Rhine and now Pixie).

Clojure's success, I believe, is due to retaining Java's semantics (preserving library compatibility) while overhauling its syntax. Fighting the semantics of your host language/VM just makes work and causes trouble. Therefore, if you want a "Clojure on Python" that preserves the benefits of the original, you need to give it Python semantics, not Java/Clojure's. Hylang is that project - it uses Clojure syntax where se…

Only hylang has a lot of stupid limitations and problems like scope leakage.

Re: Pixie: A small fast, native lisp

#45

Post by andrewchambers »

drtse4 wrote: post #19
nsmartt wrote: post #7

Earlier quoted context omitted.

There are 61 commits and only one contributor. This isn't a good complaint, and the snark makes it worse.

Thanks, i already noticed the age of the project :). The ""complaint"" is obviously valid, i'd add at least half a page of examples to explain what it does and how to try it, just to increase the chance of contribution. No snarkiness was intended... but looks like it came out that way.

Did you even read the readme? He clearly says hes changing a bunch of stuff and doesn't think outside people can contribute much yet.

Re: Pixie: A small fast, native lisp

#47

Post by carry_bit »

_halgari wrote: post #33
sktatlo wrote: post #31

Earlier quoted context omitted.

This is an amazing effort! Now to clojure compatibility. You can only gain by making it clojure compatible. What would be the possible reasons to diverge? Another one: what are your plans for namespaces and code packaging and distribution? What are your thoughts about a build system? I think the world doesn't need another build and package distribution system. Which one would you reuse?

I love clojure, let me make this clear. But there are certain aspects of the language that don't apply if you are writing a VM from scratch in RPython. If I could make multimethods dispatching on types as fast as protocols, what is the point of protocols? A great example of this is the (fn [& args]) bit. In Clojure, variadic parameters are passed in as a ISeq. In Pixie they are a vector (or an immutable array actuall…

One advantage of having protocols in addition to multimethods is that you need to implement all methods in a protocol. This eases documentation, and is useful for methods that are fundamentally tied together.

Re: Pixie: A small fast, native lisp

#48

Post by vosper »

andrewchambers wrote: post #44
dTal wrote: post #18

Earlier quoted context omitted.

Clojure's success, I believe, is due to retaining Java's semantics (preserving library compatibility) while overhauling its syntax. Fighting the semantics of your host language/VM just makes work and causes trouble. Therefore, if you want a "Clojure on Python" that preserves the benefits of the original, you need to give it Python semantics, not Java/Clojure's. Hylang is that project - it uses Clojure syntax where se…

Only hylang has a lot of stupid limitations and problems like scope leakage.

I'm completely unfamiliar with Hylang - could you please elaborate on its limitations?

Re: Pixie: A small fast, native lisp

#49

Post by sklogic »

sedachv wrote: post #37
sklogic wrote: post #24

Earlier quoted context omitted.

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

> And it's a Lisp-2, which is quite a deterrent for many. I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.

For me it's clearly a deterrent - it does not fit at all into my model of building hierarchies of DSLs.

Re: Pixie: A small fast, native lisp

#50

Post by sklogic »

lispm wrote: post #32
sklogic wrote: post #24

Earlier quoted context omitted.

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

Depends on what you mean by 'big'. Physically it is not too big for typical applications. 'mentally' it may be too big for some developers. After a while then greenspun's tenth rule kicks in... 'Common Lisp' also does not mean it needs the full language. Some applications use subsets.

Big is over 1000 pages of a spec.
Post reply on HN