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…
How is the cost of copying close to zero or not apparent?
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 as fast as chez scheme on average, and faster than every other scheme system we've compared with.
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 boun…
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
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.
Well, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, for an arbitrary CL program it's impossible to tell for sure how much of the CL compiler and standard library it will need at run time, so SBCL takes the easy route and just includes everything. Some of the commercial Lisp compilers are a lot smarter at strippin…
SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.
That distinction isn't important here, though. It is the reason the resulting file is so big, but for all practical purposes it's a binary that statically links the full CL runtime.
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 no…
Link? Searched YouTube but no vids appear to match your description.
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…
"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.
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…
"So, again, not only is their terminology consistent with the rest of the industry"
You have said that twice. It was wrong both times.
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…
How is the cost of copying close to zero or not apparent?
Because persistent data structures that use structural sharing.
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 no…
Link? Searched YouTube but no vids appear to match your description.
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.
> thus aren't "native" in the same way
Sorry, no, this is nonsense. Scala source code is compiled to Java bytecode, which is interpreted and JITed by the JVM. Pixie source code is compiled to the Pixie bytecode which is interpreted and JITed by the Pixie VM. chrisseaton claims that "native" refers to the interpreter, but this is rubbish ... that's not what the industry means by "native".