genomics_viz VS sbcl

Hold mine :D https://github.com/anchpop/genomics_viz/blob/master/genomics...

That's one expression because it used to be part of a giant comprehension, but I moved it into a function for a bit more readability. I'm considering moving it back just for kicks though.

On the positive side, one can also study the works of brilliant minds... like the original work on the Common Lisp Object System and its metaobject protocol. It added support for object-oriented programming to Lisp and was originally developed with a prototype implementation, which could be loaded into a running Common Lisp.

https://mitpress.mit.edu/9780262610742/the-art-of-the-metaob...

The toy implementation from the book: https://github.com/binghe/closette

A real implementation, here for SBCL: https://github.com/sbcl/sbcl/tree/master/src/pcl

> CL is like clay,not even lego bricks.

There is also the "Big ball of mud" metaphor, which is attributed to Joel Moses, comparing it to the diamond like structure of APL:

  "Lisp, on the other hand, is a ball of mud.  It looks ugly, but you

The real reason to learn SBCL, is because that is an existence proof that garbage-collected multi-paradigm (procedural, functional, object-oriented) dynamic languages don't have to suck performance wise (speed and memory usage). I'm going to go off the rails and say that 'defmacro' isn't the reason one should use a lisp. ~90% of 'defmacro' instances are really just to prevent evaluating expressions, which could also have been done with a lighter syntax (e.g. reader macro) for lambda. Why didn't lisp catch on? Some 30-40% of people really hate parenthesis with a passion. There is no accounting for taste I guess. Lisp advocates also spent too many decades comparing lisp to C (instead of Python or Haskell or Java). And it seems like there was at one time a faction that looked down on free-software/GPL for a while, so there wasn't as much activity that people (especially college students) could see and engage with. The standard library is sparse and could use a CLOSified refresh, but everyone disagrees on how that should look. Too many lofty promises of 10x or greater productivity gains, and not enough wins showing it. Who knows, I haven't looked as common lisp in a while, maybe there are now vectorized/parallel array libraries targeting GPU's now that everyone uses, because things "just work" out of the box. Or a polished off McClim, or other lispy gui, instead of wrapping Tk. That combined with the usual network effects.

https://www.sbcl.org/

Based on the commit message [0], and the references to "user code" in this document, my guess is that user programs have or will have access, but it's not finalized enough to be documented.

That being said, I suppose if you're developing an internal API for a compiler/interpreter, your "users" could be other parts of the project rather than language users.

https://github.com/sbcl/sbcl/commit/7f65522a16d857e41aa61cd0...

See for example:

https://github.com/sbcl/sbcl/blob/master/doc/internals-notes...

related: the Immix inspired parallel-mark-region GC developed by Hayley Patton (https://github.com/no-defun-allowed/swcl) got merged recently into SBCL.

https://github.com/sbcl/sbcl/blob/master/doc/internals-notes...

https://applied-langua.ge/~hayley/swcl-gc.pdf

build with

    ./make.sh --without-gencgc --with-mark-region-gc (on x86-64/Linux and x86-64/macOS only at the moment).

The Immix inspired mark-region GC developed by Hayley Patton (https://github.com/no-defun-allowed/swcl) got merged recently, which is pretty cool news for SBCL users.