HN user

redline6561

48 karma
Posts0
Comments24
View on HN
No posts found.

Hi, Patrick! Sprocketnes has been helpful reading as I've worked on my own emulator. Ian Piumarta's lib6502 uses plain C macros. It's even almost as short as cl-6502...though I don't think it's quite as readable. ;)

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!

That magic actually comes courtesy of [SnabbSwitch](https://github.com/SnabbCo/snabbswitch/wiki), latest project of the inimitable Luke Gorrie. Luke is also publishing SnabbSwitch semi-regularly as a [readable program](http://blog.lukego.com/blog/2012/10/24/readable-programs/).

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.

Me too! Common Lisp actually was intended for system programming historically, back from when Lisp Machines had a shot at ruling the world. Consequently, there is quite nice support for low-level programming.

I've been stalled out on that for a month or two. The PPU has been quite tricky. I'll probably take inspiration from [nesemu1](http://bisqwit.iki.fi/jutut/kuvat/programming_examples/nesem...) for the next rewrite.

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.

ClojureScript 15 years ago

I would assume however that threading concerns have not been taken into account for the "Clojure-in-Clojure" on display in ClojureScript however, based on https://github.com/clojure/clojurescript/wiki/Differences-fr...

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.

The Spirit of Lisp 16 years ago

I'm sorry I didn't get my point across very clearly. Perhaps my writing style is to blame. I often start writing when I "feel it" and figure out what I'm really trying to say as I go then go back and rework as necessary. Too top heavy, I suppose.

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. :-/

> "But then you might as well just use Postrgresql and Postmodern."

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.

BKNR-datastore seems really nice but I haven't gotten a chance to play with it yet. Do you know if it supports concurrent writes yet? I know it didn't circa 2008 or so...

Well, the two prominent web frameworks are Weblocks and UCW but their documentation is...wanting. I'm working on a Weblocks tutorial right now but I gave a bit of a survey of the CL web landscape recently: http://redlinernotes.com/blog/?p=1232

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

That's pretty accurate. I'm still a dumb noob about programming generally but I've been using and lurking in #lisp and the "community at large" for ~2 years now.

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.

Apologies for the site being down at the moment. I'd reset the server but I'm in Chicago. I know that PLT Scheme recently had a system for optional types implemented and there was a paper posted on Lambda-the-ultimate.org. I think it's in SVN. http://lambda-the-ultimate.org/node/2622

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'm going to finalize this post tonight but in the meantime I want to elucidate the main point before the discussion gets off-topic.

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.

No. At least, there are multiple compilers for it if you want to go by that. There are a variety of reasons that I didn't want to cover C/C++. I mention in the second paragraph that I'm interested in the subset of languages that have achieved some mainstream success. By some success, I mean less than 20% of software companies actually hire for those languages. That second paragraph is all really about me copping out of dealing with C, C++, Java, or C#. I know. Classy, right?

Hi. I acknowledge that this wasn't well defended. Honestly, I didn't know many people even read my site and I certainly didn't post the article expecting it to make it's way to Y-Combinator. It was a personal draft that I was going to touch up tomorrow but I have a 5am flight so I'm going to sleep for now. Suffice it so say I plan to learn Common Lisp and tried to stress in the first paragraph or so that these are personal inexperienced opinions. I'll try to give it a fair treatment later on when I'm able. Call this an early impression.