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

131–140 of 164 posts

Re: Pixie – A small, fast, native Lisp

#131

Post by jacobush »

throwaway7645 wrote: post #104
jacobush wrote: post #68

Earlier quoted context omitted.

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.

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.

Re: Pixie – A small, fast, native Lisp

#132

Post by Johnny_Brahms »

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?

I use [] only in certain spots for my scheme code. For binding variables in a let-block and for cond clauses.

(let ([a 5] [b 6]) (display a+b))

I find this easier to parse mentally, but I can see why one wouldn't do it, especially for cond clauses where you might end up having to actually browse parens to add or remove before or after the ].

I use paredit now, so there is really no need for me to do think about parens much at all, but old habits die hard.

Re: Pixie – A small, fast, native Lisp

#133

Post by coldtea »

jibalt wrote: post #96
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…

"They said that the interpreter was native" Sorry, but that's nonsense. "native lisp" means that the lisp source is compiled down to machine code. To claim that an interpreter is "native" is to misuse the terminology.

>"native lisp" means that the lisp source is compiled down to machine code

No, that would be a lisp that produces native code, not a native lisp.

To contrast, there are non native lisps written in Python, in Javascript , etc., including atop of other Lisps.

Re: Pixie – A small, fast, native Lisp

#134

Post by mapcars »

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/

>Does it implement 'readable'

Nope, it has it's own notation which I find very close to the Smalltalk one, for example:

  red>> a: [1]
  == [1]
  red>> pick head append a 1 + 1 2
  == 2
  red>> a
  == [1 2]
So the second expression is good example of how things work, this is how it looks if I put parens (which are unnecessary in this case):

  pick (head (append a (1 + 1))) 2
Here interpreter/compiler knows how many arguments each `word` (you can think `function`) needs, so `append` needs 2 - series and item to append, `head` only one - series, `pick` needs series and index to get element. But what about `+`?

  red>> type? :+
  == op!
Operators are infix things of two arguments and they get priority over function calls, that's why `append` is called with `a` and result of `1 + 1` and not with `a` and `1`.

It looks a bit tricky in the beginning, I understand, but it leads to very compact and easy to read code.

This is brief explanation which should help you to start reading and writing Red/Rebol code :)

Re: Pixie – A small, fast, native Lisp

#135

Post by kazinator »

lispm wrote: post #129
jfoutz wrote: post #116

Earlier quoted context omitted.

Perhaps i'm rusty. in this case (funcall #'+ 1 2 3) or the more scheme-ish (apply '+ '(1 2 3)) i think the symbol plus gets evaluated to # and then is called with 1 2 3 - CL will do apply, of course, not sure about scheme and funcall. I'm totally willing to accept my mental model is wrong, i don't have an interpreter handy. So if that's true, you run into this problem: (funcall (string->symbol "+") 1 2 3) (apply (str…

(funcall #'+ ...) does not do a symbol lookup and does not need to retrieve the function from a symbol in Common Lisp. (funcall '+ ...) would retrieve the function from the symbol. Treeshakers are generally used for application delivery in Lisp. When you do that, then one usually limits the amount of use of runtime dynamics. Typically you can tell the treeshaker what to remove or what to keep: the compiler, the symbo…

More briefly, in a half decent implementation, the + symbol is involved in the processing of (funcall #'+ ...) in the same ways and at the same times as it is involved in the plain call (+ ...).

Re: Pixie – A small, fast, native Lisp

#136

Post by kimi »

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…

There is Ferret - http://ferret-lang.org/ or https://github.com/nakkaya/ferret

From the docs: "Ferret is a free software Clojure implementation for real time embedded control systems"

Re: Pixie – A small, fast, native Lisp

#137

Post by floatboth »

na85 wrote: post #21
DannyB2 wrote: post #12

Earlier quoted context omitted.

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.

Such as?

Not having separate namespaces for values and functions ;-)

Re: Pixie – A small, fast, native Lisp

#138

Post by lispm »

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? Which aren't real executables, and aren't native.

Sure, you can for example run a Prolog interpreter on top of a Lisp interpreter. It's just not fast, but may have other qualities.

Re: Pixie – A small, fast, native Lisp

#139

Post by jacobush »

throwaway7645 wrote: post #104
jacobush wrote: post #68

Earlier quoted context omitted.

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.

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.

Cygwin is great for processing data and generally have a lot of tools one might be used to from Linux. But when targeting Windows, that is, creating a program FOR Windows, maybe for general distribution, cygwin feels very cumbersome to me. PicoLisp is MIT licensed and small, so could be an integral part of a Windows program. PicoLisp has promise on Windows, but someone would have to step up and maintain a Windows package for it. I have been daydreaming about it but I have too many half-finished projects under my belt to fool myself into starting that too.

Re: Pixie – A small, fast, native Lisp

#140

Post by mikaelj »

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.

Post reply on HN