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

141–150 of 164 posts

Re: Pixie – A small, fast, native Lisp

#141

Post by hkjgkjy »

_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…

Clojure developer here, was interested in Pixie since you announced it.

The only reason why I have not tried it out yet is

* No mention of installing it with `nix-env -i pixie`, `apt-get install pixie` or `brew install pixie`. Sorry, but I'm that lazy :(. If you make it Linux-only, a mac user can do `docker run -ti pixie -v /src:.` as well.

* No mention of how to connect from your editor. A small Emacs mode which let's you C-x C-e is all that would have made me use it.

It's lazy and dumb, but that is the truth. So for me the only reason for not being a Pixie developer full time are those 2 UX things.

Thanks for your work and keep it up :-).

Re: Pixie – A small, fast, native Lisp

#142

Post by throwaway7645 »

jacobush wrote: post #131
throwaway7645 wrote: post #104

Earlier quoted context omitted.

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.

Come to think of it, some docker and other fancy container magic could also help adoption. And other such things people use nowadays. Maybe a nodejs integration? Stuff like that.

My dream would be to just use something like Picolisp on Windows without the workarounds. Maybe that can be done via the new Bash on Windows10? Idk.

Re: Pixie – A small, fast, native Lisp

#143

Post by emidln »

lvh wrote: post #75
mschaef wrote: post #34

Earlier quoted context omitted.

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

There was a tech demo for a talk where Tim Baldridge linked Python via the ffi and then was importing random things.

Re: Pixie – A small, fast, native Lisp

#144

Post by baldfat »

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…

I hope this continues to be developed. I love coding in Racket. I remember when I first started coding in Python years ago and then I ran into Racket (Wanting to learn Functional programming) and I even liked Racket coding even more.

Re: Pixie – A small, fast, native Lisp

#145

Post by baldfat »

shakna wrote: post #127
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…

Interested in the speed you're seeing. I use Gambit-C scheme for most of my scheme needs because of the speed, but it seriously lacks in libraries, that Racket has in abundance.

https://github.com/pycket/pycket-bench

Re: Pixie – A small, fast, native Lisp

#146

Post by sabauma »

shakna wrote: post #127
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…

Interested in the speed you're seeing. I use Gambit-C scheme for most of my scheme needs because of the speed, but it seriously lacks in libraries, that Racket has in abundance.

Pycket has different performance characteristics from many of the AOT systems we compared against. On average Pycket is ~2x faster than the Racket VM, ranging from ~3x slower to ~300x faster depending on the benchmark. Last I checked, Pycket's mean performance was about 10% slower than Chez Scheme. The cost you pay for this performance is a rather significant warmup time for many benchmarks.

As for libraries, the only major feature that Pycket does not support is Racket's FFI, most built in functions can be implemented pretty easily if missing.

Re: Pixie – A small, fast, native Lisp

#147

Post by lvh »

omginternets wrote: post #89
lvh wrote: post #75

Earlier quoted context omitted.

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.

I'm taking a shot in the dark, but have you looked at the Hy language? I imagine it must be relatively straightforward to port this over to RPython.

Hy is also great, but it is even further away from Clojure than Pixie is.

Re: Pixie – A small, fast, native Lisp

#148

Post by throwaway91111 »

lispm wrote: post #121
throwaway91111 wrote: post #107

Earlier quoted context omitted.

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

SBCL does treeshaking? I thought it just dumps the image.

Well that would explain it. Any idea why they don't tree shake?

Re: Pixie – A small, fast, native Lisp

#149

Post by sabauma »

baldfat wrote: post #145
shakna wrote: post #127

Earlier quoted context omitted.

Interested in the speed you're seeing. I use Gambit-C scheme for most of my scheme needs because of the speed, but it seriously lacks in libraries, that Racket has in abundance.

https://github.com/pycket/pycket-bench

Much of the data in that repo is old/outdated. This (https://github.com/pycket/pycket-bench/blob/master/output/20...) figure was the one used in the paper, which includes Gambit.
Post reply on HN