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

41–50 of 164 posts

Re: Pixie – A small, fast, native Lisp

#41

Post by xaduha »

chrisseaton wrote: post #20
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.

They said that the interpreter was native. It is - it's AOT compiled. They didn't say that your program was natively compiled. Your program is interpreted - by the interpreter - the native intepreter - and then JIT compiled by meta-tracing the interpreter. Their terminology is totally consistent with how the field uses these terms. This technology operates at multiple levels of meta-implementation, so it is easy to g…

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

Re: Pixie – A small, fast, native Lisp

#42

Post by chrisseaton »

xaduha wrote: post #41
chrisseaton wrote: post #20

Earlier quoted context omitted.

They said that the interpreter was native. It is - it's AOT compiled. They didn't say that your program was natively compiled. Your program is interpreted - by the interpreter - the native intepreter - and then JIT compiled by meta-tracing the interpreter. Their terminology is totally consistent with how the field uses these terms. This technology operates at multiple levels of meta-implementation, so it is easy to g…

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

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.

Re: Pixie – A small, fast, native Lisp

#43

Post by throwaway7645 »

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…

Interesting historical note!

Re: Pixie – A small, fast, native Lisp

#44

Post by throwaway7645 »

jacobush wrote: post #33
throwaway7645 wrote: post #8

Earlier quoted context omitted.

I posted the link, but am not one of the developers. This got a little attention a couple of years ago, and I thought to look it up today. It has a nice website now at least. I really like the idea behind it (small install, lightweight, fast), but don't know how effective it will be without a larger community. I can honestly do without a lot of libraries as long as there are decent built-ins. I really wish Pixie just…

PicoLisp is very small and extremely powerful at the same time. It has a built in Prolog...

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.

Re: Pixie – A small, fast, native Lisp

#45

Post by nickik »

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…

Its a hobby project, its not nearly done, don't use it in production.

But, that said, that is basically what it is: https://github.com/clojit

I would love to write a JIT for it, but currently its a half done interpreter. You compile Clojure to Bytecode (of our own design, see clojit-doc) and a C interpreter (we started in Rust but the pre 1.0 chances and some other stuff killed that).

All of this is inspired by LuaJit, specifically my goal is to work on a tracing compiler. It just takes to much time to get there.

Re: Pixie – A small, fast, native Lisp

#46

Post by xaduha »

chrisseaton wrote: post #42
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).

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

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

Re: Pixie – A small, fast, native Lisp

#47

Post by yellowapple »

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 tinkering with some ideas for another language in that space (the Crafting Interpreters book is looking to be pretty helpful in getting me there: http://www.craftinginterpreters.com/), but it'd be really nice if there were enough options for me to not feel the need to create my own.

Re: Pixie – A small, fast, native Lisp

#48

Post by grayrest »

spraak wrote: post #5

> If you like Clojure, but are unhappy with the start-up time, or if you want something outside of the JVM ecosystem, then Pixie may be for you YES! :D

If this is a major concern for you, there are several clojurescript projects--Planck and Lumo--that have very fast startup. JVM Clojure is a bit faster than jsc/node clojurescript (~2x IIRC) but that shouldn't matter much for scripting/automation and lambda functions or equivalent on other clouds.

Re: Pixie – A small, fast, native Lisp

#49

Post by krylon »

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?

In a Lispy context, I find brackets confusing. But then again, I don't know Clojure.

(To me, it is a context thing, I think - in lagnuages like C/C#, there parens, brackets, parentheses and even angle brackets flying around, and it is not a problem at all.)

Re: Pixie – A small, fast, native Lisp

#50

Post by hibbelig »

xaduha wrote: post #41
chrisseaton wrote: post #20

Earlier quoted context omitted.

They said that the interpreter was native. It is - it's AOT compiled. They didn't say that your program was natively compiled. Your program is interpreted - by the interpreter - the native intepreter - and then JIT compiled by meta-tracing the interpreter. Their terminology is totally consistent with how the field uses these terms. This technology operates at multiple levels of meta-implementation, so it is easy to g…

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.
Post reply on HN