14 ms·

Pixie – A small, fast, native Lisp

315 points by throwaway7645 10y ago

abc_lisper 10y ago
What's the state of development of this? Did somebody use it with Raspberry pi? I want to use this over Clojure(only on pi) because I have read Clojure is slow on Raspberry pi(even 3, not sure how true that is). Also, how fast is this? How does it compare to other lisps(or schemes) in terms of speed? Can someone port the benchmarks to https://benchmarksgame.alioth.debian.org https://benchmarksgame.alioth.debian.org.
- empthought 10y ago
  I have used Chicken Scheme on Raspberry Pi to good effect. Clojure is likely slow because the JVM runtime requires much more disk access than compiled-to-C systems.
  - Flow 10y ago
    Have you tried any Clojure->Scheme compilers? After that stage you can use any Scheme->C/Whatever compiler.
    - Quequau 10y ago
      There are Clojure->Scheme compilers?
      - eatonphil 10y ago
        Close: https://github.com/takikawa/racket-clojure https://github.com/takikawa/racket-clojure https://docs.racket-lang.org/rackjure/index.html https://docs.racket-lang.org/rackjure/index.html
      - Flow 10y ago
        Yes, at least one, and I don't know how well it works. But here it is: https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
    - empthought 10y ago
      I don't see the point of Clojure without the JVM or without being the client side of a Clojure web application. Scheme is just fine by me.
- throwaway7645 10y ago
  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 had a REPL and compiled to native code via LLVM so I could give coworkers a .exe. Edit: Just looked at the github page. It doesn't look very active to me although I wouldn't say dead. The only small lisps I know of in development are Picolisp and Newlisp.
  - jacobush 10y ago
    PicoLisp is very small and extremely powerful at the same time. It has a built in Prolog...
    - throwaway7645 10y ago
      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.
      - jacobush 10y ago
        I have used it in commercial embedded hardware shipping tens of thousands of units, in the USD 1000 range. Speed is excellent for the most part - where it's not it's trivial to call out to C libraries. Agree about docs but what would really help at this point would be more QA on Stackoverflow. And a good Windows port.
        throwaway7645 10y ago
        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.
- ballpark 10y ago
  Have you tried Clojurescript on nodejs for Raspberry pi? We have used nodejs on Raspberry Pi with success. I've wanted to try Clojurescript on it, but our shop doesn't use it. I imagine it would work great with it's good JS interop features.
- mschaef 10y ago
  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 to usefully work on an RPi. :-)) https://github.com/mschaef/metlog/tree/master/metlog-agent https://github.com/mschaef/metlog/tree/master/metlog-agent
  - abc_lisper 10y ago
    That is good to hear. Ordered my pi!
    - ThatGeoGuy 10y ago
      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 http://wiki.call-cc.org/eggref/4/raspberry-pi-gpio).
spraak 10y ago
> 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
- throwaway7645 10y ago
  It sounds nice right?
- josteink 10y ago
  In that case... what about just regular plain old Common Lisp?
  - DannyB2 10y ago
    I'm not intending to criticize Common Lisp, which I loved back in the early 90's, but there are things to like about Clojure over Common Lisp.
    - na85 10y ago
      Such as?
      - DannyB2 10y ago
        A big one is persistent data structures. Where 'persistent' may not mean what you think it means. In Clojure it is impossible to surgically modify a data structure. That is, you can't do something like: (SETF (CAR (CDR x)) 'foo) which would alter a data structure. You can modify a data structure, but it returns a new data structure, yet the old one remains if it is not GC'able. All of the common data structures have this property. Sequences (eg, lists), arrays, maps and sets. If you change the 50 thousandth element of an array, this returns a new array. The old array is unaffected. Yet it gives the performance you expect of an array. (Meaning no apparent cost of copying.) If you're writing a search procedure, it is trivial to transform one chessboard into a different chessboard, but without concern about the cost of copying (close to zero), or having altered the original value (you haven't). Other variables that have a pointer to that first chessboard don't see any changes. There are other things such as a great story about concurrency. Hope that helps.
eximius 10y ago
Very neat but documentation is very sparse, from what I can tell.
xaduha 10y ago
http://www.red-lang.org 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.
- throwaway7645 10y ago
  Probably the language that I'm most looking forward to. It'd give you the ease of python with the speed of a native language and the best GUI DSL I've ever seen. Edit: Agreed that I don't like the author's use of native either.
- mapcars 10y ago
  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.
  - allover 10y ago
    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/ http://readable.sourceforge.net/
    - throwaway7645 10y ago
      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.
sigjuice 10y ago
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?
- markx 10y ago
  I actually prefer the mixture. It's a better visional cue.
- yarrel 10y ago
  Yes. The switch between different pairs if you're not using just parentheses is a real cognitive load.
- mschaef 10y ago
  I don't mind either syntax, but what's essential is an editor that highlights balancing parens, etc.
  - yellowapple 10y ago
    Hence why I love Emacs: http://melpa.milkbox.net/#/hl-anything http://melpa.milkbox.net/#/hl-anything
- krylon 10y ago
  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.)
- wavegeek 10y ago
  I agree. I recently had to write a project in Ruby and all this random syntax is driving me mad.
  - deleted 10y ago
    [deleted]
- 10y ago
JohnStrange 10y ago
I like it, will definitely take a look at it. The name is also good, it reminds of its similar cousin Pico lisp and the website is nice. Now we need libraries, many of them, and better docs. Good work!
Sir_Cmpwn 10y ago
Interestingly, this is (some of) the output of running the makefile: https://sr.ht/zMyE.png https://sr.ht/zMyE.png
- sabauma 10y ago
  The RPython translator generates views of the Mandelbrot set by default, presumably to give you something to look at during the long wait.
  - s_kilk 10y ago
    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 10y ago
      [deleted]
- deleted 10y ago
  [deleted]
jyriand 10y ago
Do I understand correctly that pixie is using clojure's lisp dialect and the only difference is that it is not running on JVM?
copx 10y ago
> 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, and a C FFI. Neither compilers (well, except C++ ones), nor stuff you usually find in standard libraries, nor a GC should require much code to implement, relatively speaking (e.g. compared to a WYSIWYG word processor). These things are usually small. The compilers for almost every language were < 1 MB in size for the longest time. I am not saying that Pixie being 10 MB in size is a problem. We have a lot more bandwidth and disk space nowadays, 10 MB is nothing. My point is that a "JIT, GC, and stdlib" package weighing this much cannot claim to be "small" for what it does.
- nine_k 10y ago
  I wonder if it's a stripped binary.
  - vram22 10y ago
    Yes, at least on Unixes, stripping could reduce the sizes of binaries by quite a bit.
- stcredzero 10y ago
  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 their image down to 45k.
  - throwaway7645 10y ago
    Interesting historical note!
  - 10y ago
lvh 10y ago
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.)
- mschaef 10y ago
  > 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.
  - lvh 10y ago
    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.
    - omginternets 10y ago
      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.
      - lvh 10y ago
        Hy is also great, but it is even further away from Clojure than Pixie is.
    - emidln 10y ago
      There was a tech demo for a talk where Tim Baldridge linked Python via the ffi and then was importing random things.
branchly2 10y ago
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 is not top-priority. Small footprint, quick startup, access to native C libs. Still holding out hope for that one.
- nickik 10y ago
  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 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.
- yellowapple 10y ago
  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/ 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.
  - jacobush 10y ago
    Picolisp. I found it very easy to embed.
  - mark_l_watson 10y ago
mschaef 10y ago
So this is great, but note that development has seemingly fallen off to close to zero over the last year: https://github.com/pixie-lang/pixie/graphs/contributors https://github.com/pixie-lang/pixie/graphs/contributors
chubot 10y ago
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 switches, and just plain not understanding your code once it reaches a certain size. There seems to be a fetish for JIT compilation in a lot of new language designs and it confuses me. Julia is probably the language making the best and most appropriate use of it. It actually has good data structures and types which complement it.
- dinkumthinkum 10y ago
  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. :)
  - chubot 10y ago
    I don't follow. Why aren't database web front ends performance sensitive? They seem like one of the slowest things out there, and some of the most widely used. My comments here on Steve Souders' realization is basically what I'm talking about: https://news.ycombinator.com/item?id=13346635 https://news.ycombinator.com/item?id=13346635 If you want to make systems fast, you work on the bottleneck. I'm saying that people think too often that summing integers is the bottleneck, when it plainly isn't. Although I have worked in the domain of numerical applications, thus my nod to Julia. Anybody who works in that domain isn't going to be using something like Pixie; it's too impoverished in terms of types and data representation.
jlarocco 10y ago
Any language claiming to be a fast Lisp should be required to show benchmark comparisons against SBCL and a few commercial Common Lisps. A native compiler for Clojure would be an interesting project, but completely new languages competing on speed or size are going to have a really tough time beating the existing Common Lisp implementations, not to mention the CL library ecosystem. Not to say the CL library world is very big compared to Python or Javascript, but it has most of the important bases covered, and it's certainly bigger than a brand new language like Pixie.
endergen 10y ago
This is going to get confused with Pixi, the more and more popular 2D rendering engine for Javascript: http://www.pixijs.com/ http://www.pixijs.com/
- iLemming 10y ago
  So what? Everything has a suffix in js-land.
_halgari 10y ago
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.
- samth 10y ago
  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 as fast as chez scheme on average, and faster than every other scheme system we've compared with.
  - throwaway7645 10y ago
    Is that just a JIT for Racket or a different language?
    - sabauma 10y ago
eschaton 10y ago
Why does the web site refer to "Lisp interpreters?" That phrasing perpetuates mistaken assumptions about Lisp-family languages, both about their implementation and their performance.
mikaelj 10y ago
As always, for all these small languages (MicroPython comes to mind, but even "real-world" languages such as Lua) - unless they grow a debugger, they'll always be silly toy languages nobody can use for serious work. I'd settle for a gdb backend, really. But printf-debugging is unacceptable.
deavmi 10y ago
Nice.

315 points by throwaway7645 10y ago

What's the state of development of this? Did somebody use it with Raspberry pi? I want to use this over Clojure(only on pi) because I have read Clojure is slow on Raspberry pi(even 3, not sure how true that is). Also, how fast is this? How does it compare to other lisps(or schemes) in terms of speed? Can someone port the benchmarks to https://benchmarksgame.alioth.debian.org https://benchmarksgame.alioth.debian.org.

empthought 10y ago
I have used Chicken Scheme on Raspberry Pi to good effect. Clojure is likely slow because the JVM runtime requires much more disk access than compiled-to-C systems.
- Flow 10y ago
  Have you tried any Clojure->Scheme compilers? After that stage you can use any Scheme->C/Whatever compiler.
  - Quequau 10y ago
    There are Clojure->Scheme compilers?
    - eatonphil 10y ago
      Close: https://github.com/takikawa/racket-clojure https://github.com/takikawa/racket-clojure https://docs.racket-lang.org/rackjure/index.html https://docs.racket-lang.org/rackjure/index.html
    - Flow 10y ago
      Yes, at least one, and I don't know how well it works. But here it is: https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
  - empthought 10y ago
    I don't see the point of Clojure without the JVM or without being the client side of a Clojure web application. Scheme is just fine by me.
throwaway7645 10y ago
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 had a REPL and compiled to native code via LLVM so I could give coworkers a .exe. Edit: Just looked at the github page. It doesn't look very active to me although I wouldn't say dead. The only small lisps I know of in development are Picolisp and Newlisp.
- jacobush 10y ago
  PicoLisp is very small and extremely powerful at the same time. It has a built in Prolog...
  - throwaway7645 10y ago
    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.
    - jacobush 10y ago
      I have used it in commercial embedded hardware shipping tens of thousands of units, in the USD 1000 range. Speed is excellent for the most part - where it's not it's trivial to call out to C libraries. Agree about docs but what would really help at this point would be more QA on Stackoverflow. And a good Windows port.
      - throwaway7645 10y ago
        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.
ballpark 10y ago
Have you tried Clojurescript on nodejs for Raspberry pi? We have used nodejs on Raspberry Pi with success. I've wanted to try Clojurescript on it, but our shop doesn't use it. I imagine it would work great with it's good JS interop features.
mschaef 10y ago
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 to usefully work on an RPi. :-)) https://github.com/mschaef/metlog/tree/master/metlog-agent https://github.com/mschaef/metlog/tree/master/metlog-agent
- abc_lisper 10y ago
  That is good to hear. Ordered my pi!
  - ThatGeoGuy 10y ago
    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 http://wiki.call-cc.org/eggref/4/raspberry-pi-gpio).

spraak 10y ago

> 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

throwaway7645 10y ago
It sounds nice right?
josteink 10y ago
In that case... what about just regular plain old Common Lisp?
- DannyB2 10y ago
  I'm not intending to criticize Common Lisp, which I loved back in the early 90's, but there are things to like about Clojure over Common Lisp.
  - na85 10y ago
    Such as?
    - DannyB2 10y ago
      A big one is persistent data structures. Where 'persistent' may not mean what you think it means. In Clojure it is impossible to surgically modify a data structure. That is, you can't do something like: (SETF (CAR (CDR x)) 'foo) which would alter a data structure. You can modify a data structure, but it returns a new data structure, yet the old one remains if it is not GC'able. All of the common data structures have this property. Sequences (eg, lists), arrays, maps and sets. If you change the 50 thousandth element of an array, this returns a new array. The old array is unaffected. Yet it gives the performance you expect of an array. (Meaning no apparent cost of copying.) If you're writing a search procedure, it is trivial to transform one chessboard into a different chessboard, but without concern about the cost of copying (close to zero), or having altered the original value (you haven't). Other variables that have a pointer to that first chessboard don't see any changes. There are other things such as a great story about concurrency. Hope that helps.

eximius 10y ago

Very neat but documentation is very sparse, from what I can tell.

xaduha 10y ago

http://www.red-lang.org 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.

throwaway7645 10y ago
Probably the language that I'm most looking forward to. It'd give you the ease of python with the speed of a native language and the best GUI DSL I've ever seen. Edit: Agreed that I don't like the author's use of native either.
mapcars 10y ago
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.
- allover 10y ago
  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/ http://readable.sourceforge.net/
  - throwaway7645 10y ago
    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.

sigjuice 10y ago

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?

markx 10y ago
I actually prefer the mixture. It's a better visional cue.
yarrel 10y ago
Yes. The switch between different pairs if you're not using just parentheses is a real cognitive load.
mschaef 10y ago
I don't mind either syntax, but what's essential is an editor that highlights balancing parens, etc.
- yellowapple 10y ago
  Hence why I love Emacs: http://melpa.milkbox.net/#/hl-anything http://melpa.milkbox.net/#/hl-anything
krylon 10y ago
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.)
wavegeek 10y ago
I agree. I recently had to write a project in Ruby and all this random syntax is driving me mad.
- deleted 10y ago
  [deleted]
10y ago

JohnStrange 10y ago

I like it, will definitely take a look at it. The name is also good, it reminds of its similar cousin Pico lisp and the website is nice. Now we need libraries, many of them, and better docs. Good work!

Sir_Cmpwn 10y ago

Interestingly, this is (some of) the output of running the makefile: https://sr.ht/zMyE.png https://sr.ht/zMyE.png

sabauma 10y ago
The RPython translator generates views of the Mandelbrot set by default, presumably to give you something to look at during the long wait.
- s_kilk 10y ago
  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 10y ago
    [deleted]
deleted 10y ago
[deleted]

jyriand 10y ago

Do I understand correctly that pixie is using clojure's lisp dialect and the only difference is that it is not running on JVM?

copx 10y ago

> 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, and a C FFI. Neither compilers (well, except C++ ones), nor stuff you usually find in standard libraries, nor a GC should require much code to implement, relatively speaking (e.g. compared to a WYSIWYG word processor). These things are usually small. The compilers for almost every language were < 1 MB in size for the longest time. I am not saying that Pixie being 10 MB in size is a problem. We have a lot more bandwidth and disk space nowadays, 10 MB is nothing. My point is that a "JIT, GC, and stdlib" package weighing this much cannot claim to be "small" for what it does.

nine_k 10y ago
I wonder if it's a stripped binary.
- vram22 10y ago
  Yes, at least on Unixes, stripping could reduce the sizes of binaries by quite a bit.
stcredzero 10y ago
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 their image down to 45k.
- throwaway7645 10y ago
  Interesting historical note!
- 10y ago

lvh 10y ago

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

mschaef 10y ago
> 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.
- lvh 10y ago
  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.
  - omginternets 10y ago
    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.
    - lvh 10y ago
      Hy is also great, but it is even further away from Clojure than Pixie is.
  - emidln 10y ago
    There was a tech demo for a talk where Tim Baldridge linked Python via the ffi and then was importing random things.

branchly2 10y ago

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 is not top-priority. Small footprint, quick startup, access to native C libs. Still holding out hope for that one.

nickik 10y ago
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 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.
yellowapple 10y ago
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/ 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.
- jacobush 10y ago
  Picolisp. I found it very easy to embed.
- mark_l_watson 10y ago

mschaef 10y ago

So this is great, but note that development has seemingly fallen off to close to zero over the last year: https://github.com/pixie-lang/pixie/graphs/contributors https://github.com/pixie-lang/pixie/graphs/contributors

chubot 10y ago

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 switches, and just plain not understanding your code once it reaches a certain size. There seems to be a fetish for JIT compilation in a lot of new language designs and it confuses me. Julia is probably the language making the best and most appropriate use of it. It actually has good data structures and types which complement it.

dinkumthinkum 10y ago
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. :)
- chubot 10y ago
  I don't follow. Why aren't database web front ends performance sensitive? They seem like one of the slowest things out there, and some of the most widely used. My comments here on Steve Souders' realization is basically what I'm talking about: https://news.ycombinator.com/item?id=13346635 https://news.ycombinator.com/item?id=13346635 If you want to make systems fast, you work on the bottleneck. I'm saying that people think too often that summing integers is the bottleneck, when it plainly isn't. Although I have worked in the domain of numerical applications, thus my nod to Julia. Anybody who works in that domain isn't going to be using something like Pixie; it's too impoverished in terms of types and data representation.

jlarocco 10y ago

Any language claiming to be a fast Lisp should be required to show benchmark comparisons against SBCL and a few commercial Common Lisps. A native compiler for Clojure would be an interesting project, but completely new languages competing on speed or size are going to have a really tough time beating the existing Common Lisp implementations, not to mention the CL library ecosystem. Not to say the CL library world is very big compared to Python or Javascript, but it has most of the important bases covered, and it's certainly bigger than a brand new language like Pixie.

endergen 10y ago

This is going to get confused with Pixi, the more and more popular 2D rendering engine for Javascript: http://www.pixijs.com/ http://www.pixijs.com/

iLemming 10y ago
So what? Everything has a suffix in js-land.

_halgari 10y ago

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.

samth 10y ago
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 as fast as chez scheme on average, and faster than every other scheme system we've compared with.
- throwaway7645 10y ago
  Is that just a JIT for Racket or a different language?
  - sabauma 10y ago

eschaton 10y ago

Why does the web site refer to "Lisp interpreters?" That phrasing perpetuates mistaken assumptions about Lisp-family languages, both about their implementation and their performance.

mikaelj 10y ago

As always, for all these small languages (MicroPython comes to mind, but even "real-world" languages such as Lua) - unless they grow a debugger, they'll always be silly toy languages nobody can use for serious work. I'd settle for a gdb backend, really. But printf-debugging is unacceptable.

deavmi 10y ago

Nice.