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

81–90 of 164 posts

Re: Pixie – A small, fast, native Lisp

#81

Post by throwaway7645 »

allover wrote: post #71
mapcars wrote: post #15

Earlier quoted context omitted.

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/

Red is basically Rebol rewritten with an important distinction. It comes with a sister language called Red/System that is basically a lightweight static systems language like C, but a lot closer to Red. Therefore, you can run the interpreter or drop down to native code when you need it. The 1.0 release should AOT compile what it can, then JIT, then lastly interpret what you have to. It is hoimoconic like lisp, but not a lisp. There is no install, just a 1 MB interpreter and compiler that can target a lot of architectures. The draw GUI DSL is pretty amazing. There is a Rebol YouTube vid (Red is 98% compatible) where a guy makes a zillion little cool apps with only a few lines of code each.

Re: Pixie – A small, fast, native Lisp

#82

Post by kbenson »

xaduha wrote: post #46
chrisseaton wrote: post #42

Earlier quoted context omitted.

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.

I think it's meant as in comparison to Scala and the like, which run on the JVM, and thus aren't "native" in the same way (right? or am I misinformed about Scala?). There's a lot of languages that sit on top of the JVM at this point, so they might have seen it as a distinguishing characteristic.

Re: Pixie – A small, fast, native Lisp

#83

Post by [deleted] »

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.

[deleted]

Re: Pixie – A small, fast, native Lisp

#84

Post by weavejester »

junke wrote: post #61
hkjgkjy wrote: post #56

Earlier quoted context omitted.

Well, in most cases `[]` is used just like you'd use a quoted list `'()`. Clojure vectors are nice for the performance they give. Having maps with `{}` syntax is also nice if you ask me. Makes reading a little bit faster.

> Clojure vectors are nice for the performance they give. What difference does it make when representing code?

Vectors eval to themselves, while lists eval to a function/macro/special-form call.

Vectors also differ from lists in that they are ordered and indexed, so in macros and special forms they tend to be used to represent positional bindings.

Re: Pixie – A small, fast, native Lisp

#85

Post by dgfgfdagasdfgfa »

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…

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

Re: Pixie – A small, fast, native Lisp

#86

Post by _halgari »

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 supporting libraries and ecosystem became a battle I no longer wanted to fight.

Another goal I had was to see how far I could push immutability into the JIT. I learned a lot along the way, but it turns out that the RPython JITs aren't really that happy with VMs that are 99.99% pure. At one point I had a almost 100% immutable VM running for Pixie...as in each instruction executed created a new instance of the VM. It worked, but the JIT generated by RPython wasn't exactly happy with that execution model. There was so much noise in the maintenance of the immutable structures that the JIT couldn't figure out how to remove them all, and even when it could the JIT pauses were too high.

So anyways, after pouring 4 hours a day of my spare time into Pixie for a full year, I needed to move on.

Some other developers have commit rights and have pushed it along a bit, but I think it's somewhat a language looking for usecase.

And these days ClojureScript on Node.js could probably be made to handle most peoples needs.

Re: Pixie – A small, fast, native Lisp

#87

Post by dinkumthinkum »

chubot wrote: post #58

In my experience, whether code like summing integers takes 6 instructions or 600 doesn't influence the speed of 95% of code and 95% of systems. If you could magically port real Python or ruby or JavaScript code to pixie, but keep the same algorithms and architecture, I doubt it would change much. Slowness is more influenced by things like data structure layout, allocation patterns, serial vs parallel I/O, context swi…

What do you mean in your experience? Summing integers can take two orders of magnitude more time and it doesn't matter? I think it goes without saying in discussions of performance, we narrow our focus to performance sensitive applications and not CRUD database web frontends. I can tell you in the vast majority of performance sensitive numerical applications, that would matter. It would have to be massively disk bound for it to be overshadowed completely by I/O. Just saying. :)

Re: Pixie – A small, fast, native Lisp

#88

Post by mac01021 »

dgfgfdagasdfgfa wrote: post #85
chrisseaton wrote: post #42

Earlier quoted context omitted.

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…

> 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

Re: Pixie – A small, fast, native Lisp

#89

Post by omginternets »

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.

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.

Re: Pixie – A small, fast, native Lisp

#90

Post by haberman »

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 for LuaJIT:

    $ bloaty src/luajit -n 5
         VM SIZE                     FILE SIZE
     --------------               --------------
      74.3%   323Ki .text           323Ki  73.8%
      12.5%  54.5Ki .eh_frame      54.5Ki  12.4%
       7.6%  33.2Ki .rodata        33.2Ki   7.6%
       2.2%  9.72Ki [Other]        12.9Ki   2.9%
       2.1%  9.03Ki .eh_frame_hdr  9.03Ki   2.1%
       1.2%  5.41Ki .dynsym        5.41Ki   1.2%
     100.0%   435Ki TOTAL           438Ki 100.0%
And for Pixie:

    $ bloaty pixie/pixie-vm -n 5
         VM SIZE               FILE SIZE
     --------------         --------------
      57.5%  4.39Mi .text    4.39Mi  44.7%
      33.7%  2.58Mi .data    2.58Mi  26.3%
       0.0%       0 .symtab  1.31Mi  13.4%
       0.0%       0 .strtab   978Ki   9.7%
       8.8%   688Ki [Other]   595Ki   5.9%
       0.0%       8 [None]        0   0.0%
     100.0%  7.64Mi TOTAL    9.82Mi 100.0%
In this case, neither binary had debug info. Pixie does appear to have a symbol table though, which LuaJIT has mostly stripped.

In general, I think "VM size" is the best general number to cite when talking about binary size, since it avoids penalizing binaries for keeping around debug info or symbol tables. Symbol tables and debug info are useful; we don't want people to feel pressured to strip them just to avoid looking bad in conversations about binary size.

Post reply on HN