eudox

19 ms·

151.
by eudox 12y ago
>the title implies "the heavy lifting" is written in LISP. Woo uses fast-http[0], quri[1], and http-body[2], all written in pure Common Lisp and very, very fast. [0]: https://github.com/fukamachi/fast-http
152.
by eudox 12y ago
I read it on a tweet somewhere.
153.
by eudox 12y ago
As a fun aside: The Symbolics network code called READ on untrusted data on more than one occasion.
154.
by eudox 12y ago
I wrote cmacro[0] and magma[1] with the goal of a augmenting C while keeping it C-like. [0]: https://github.com/eudoxia0/cmacro [1]: https://github.com/eudoxia0/magma
155.
by eudox 12y ago
Xmonad is a thin wrapper over the C X11 api, etc.
156.
by eudox 12y ago
While I love the way POV-Ray (And OpenSCAD, for that matter) does things, it bothers me that its language is more about specifying rendering than describing the objects in the scene. That is, the textual commands directly used for rendering
157.
by eudox 12y ago
I was briefly part of the "OOP is overrated, functional programming is in" camp. OOP is enterprise, functional programming is "simple" because it's just functions and data, you know, all the usual party lines. Well,
158.
by eudox 12y ago
That has nothing to do with the scoping. There's no way to know whether "left = right" means "Set 'left' to 'right'" or "Create a new variable 'left', with value 'right'&
159.
by eudox 12y ago
HackerCupid when.
160.
by eudox 12y ago
Same, I also thought it randomly picked a user when you opened the page.
161.
by eudox 12y ago
>Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime syste
162.
by eudox 12y ago
SBCL (And other compilers) implement a type inference engine to reduce type checks, and you can also provide your own type declarations, i.e. gradual typing before it had that name.
163.
by eudox 12y ago
From the Reddit thread: http://www.reddit.com/r/lisp/comments/2klhpn/quri_a_uri_libr... >Right. When I was profiling Wookie, I found URL parsing was the third bottleneck (the first is HTTP request par
164.
by eudox 12y ago
When he first posted it, it did, it looks like recent changes have brought that down: https://github.com/fukamachi/woo/commit/be4a0db688af05ee204e...
165.
by eudox 12y ago
I agree entirely, but at the same time, I think too often people make social rather than technical decisions. Lots of stars on GitHub and a well-designed website are usually indicative of a good project -- but people put too much faith
166.
by eudox 12y ago
When you compare the time fukamachi's spent on these libraries to the time spent on Clack, Caveman, etc., it's pretty clear there's obsession with performance. As aroman said, "The real story here is that people are work
167.
by eudox 12y ago
You're right, and I always make this mistake for the reason that AOT/JIT look the same from the outside.
168.
by eudox 12y ago
Quicklisp is CL's package manager, so that's necessary to install dependencies. You can install it with: $ curl -O http://beta.quicklisp.org/quicklisp.lisp $ sbcl --load quicklisp.lisp \ --eval
169.
by eudox 12y ago
I'd recommend SBCL, since a high-performance JIT compiler is likely to give more representative results than a bytecode VM like CLISP. Plus, I'd expect some minor portability errors to arise when you push the envelope like this. B
170.
by eudox 12y ago
For context, Eitaro Fukamachi has been working on a whole bunch of things relating to the low-level parts of Common Lisp web development: A fast HTTP parser, a fast URI parser[0], a libuv-based web server[1] (That outperforms Node!), and he
171.
by eudox 12y ago
>What web servers/stack are Lispers using these days? Clack ( https://github.com/fukamachi/clack )
172.
by eudox 12y ago
>quicklisp users feel free to correct me Common Lisp certainly doesn't have as many libraries as Python or Ruby, but let's not exaggerate. The ecosystem is broad and deep enough for the average programmer -- me, here -- to be p
173.
by eudox 12y ago
My experience with Common Lisp, Python and JavaScript, is that Common Lisp (More through intrinsic properties, rather than a specific choice of tools), provides a better development environment.
174.
by eudox 12y ago
This is so old. Have a better story instead: http://www.infinityplus.co.uk/stories/shanidar.htm
175.
by eudox 12y ago
They are about as similar as Python and Ruby. Everything from the names of operators to the stance on mutability, to the more obscure corners (Compiler macros, reader macros, etc).
176.
by eudox 12y ago
I'm not an expert in Common Lisp internals, but there are some things that don't look like they could be entirely put in an executable without bringing the compiler and runtime along. I'm not just talking about things like a
177.
by eudox 12y ago
http://log.irc.tymoon.eu/freenode/lisp?around=2014-09-25T18:... Essentially, LLVM does tons of low-level optimizations but Clasp does few high-level, CL-specific ones. SBCL, on the other hand, mostly does CL-level opti
178.
by eudox 12y ago
>Programmers can expose C++ classes as well as functions and class methods with a single line of code that provides the Clasp name and a pointer to the function/method. Hellooooo Qt without Smoke bindings.
179.
by eudox 12y ago
Thank you for the encouragement, and best of luck to you :)
180.
by eudox 12y ago
Most Common Lisp implementations are written in Common Lisp.

More ›