48 karma · joined April 3, 2008
He and Andy Wingo (http://wingolog.org) both write very well on language issues though they may skew towards implementation concerns over design concerns.
Keep up the great work on Rust, been waiting on the gc/scheduler stuff to shake out a little bit. Looking forward to 0.8!
Basically, you write markdown comments in the code and there is a Makefile that uses awk and sed to grab them out, cat some things together and pass it to an awesome LaTeX stylesheet written by Pete Kazmier. See: https://github.com/redline6561/cl-6502/tree/master/src/doc and the Makefile in the parent directory.
Related (with screenshot!): http://blog.redlinernotes.com/posts/So-Close-and-Yet-So-Far....
If I can wind up with a NES emulator that is "fast enough" and 2500 lines of code instead of 75,000 (Fceux) or 150,000 (Nestopia) then I'll be happy.
That suggests to me that concerns over thread safety that are taken into account in the Java implementation, say of the core data structures, STM, etc, are not taken into account in the std. lib. of ClojureScript. That would make it unlikely for this code to be a useful origin or starting point for, say, an LLVM backend.
Rich is a very clever fellow and makes fascinating trade offs between pragmatism and idealism in his language design. He continues to build languages quite tied to some existing runtimes which embrace their advantages and drawbacks. Consequentially, it will be very important to keep the rationale in mind while evaluating the real impact of ClojureScript. https://github.com/clojure/clojurescript/wiki/Rationale As neat as it would be to see, it will be a long time before an x86 or ARM backend emerges.
As far as I know, the G1 Garbage Collector in the JVM is still the top of the crop of production GCs and even Haskell with GHC7 is still working towards something of similar potency. See http://hackage.haskell.org/trac/ghc/blog/new-gc-preview
Concurrent GCs and other aspects of runtimes geared towards heavy concurrency are insanely hard. Just something to keep in mind.
Anyway, my point was to celebrate the "heads down, working" nature of a lot of common lispers and to try doing some minor image adjustment. (Common) Lispers don't do terribly much promotion of the language and community or some of its shared values. That often complicates things because folks show up with the wrong idea.
I was hoping this would celebrate where "we" are and maybe clear some things up a little for outsiders. Seems I missed that latter goal. :-/
Yeah, that's what I figured. I doubt for anything I'll work on soon that the lock will be an issue. Just curious. :)
I didn't realize the hold used to be backed by bknr. That's cool. Thanks for the heads up.
Damn shameless self promoters. Anyway, seeing as UCW and Weblocks aren't well documented a lot of people just grab Postmodern or CL-SQL for DB stuff (there are some NoSQL solutions around if that's your fancy), then CL-Who or HTML-Template and Hunchentoot (web server) for the rest.
All the above libraries are easily installable via quicklisp. God bless Xach. And Amazon AWS. :)
The best thing to do for new users is probably to show up on #lisp and solicit recommended libraries for X, I'm afraid. Or google and read extensively, selecting for newer information where possible.
Whatever happened with the startup you were working on?
Apparently, Bigloo has supported this for a while: http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-22.html
One should also consider that there are implementations like Gambit-C and Chicken that compile to type-annotated languages, not that it's necessarily what you had in mind. Just food for thought.
I was really trying to write more about the fact that the implementations and communities we have (which are often harped on) are sufficient. The problem is a lack of community formed around sharing code and building tools, libraries, etc which I feel could be solved by a module system. It's a sociological issue. My Common Lisp comment was off-the-cuff but not meant to be as judgmental as it sounded. As I've said, it's an impression but I'll write more about the later. Let's keep the focus on how to solve the problem of sharing code between lisps. That's what I see as the big thing holding lisps (of all stripes) back.