"Common Lisp is not a beautiful crystal of programming language design. It's a scruffy workshop with a big pegboard wall of tools, a thin layer of sawdust on the floor, a filing cabinet in the office with a couple of drawers that open perpendicular to the rest, [...]"
"This historical baggage is a price paid to ensure Common Lisp had a future."
I have a feeling that Quicklisp slowly fades away into an unmaintained state. While still being the CL library manager & the CL online package library.
I believe there is an incredible amount of manual work invovled to keep it barely going.
Should we try to reform and renovate #Quicklisp and move it to a point where it appears to be a modern package manager & repository like any other language offers?
I probably sound heretic. I just feel that Quicklisp is an unopened treasure trove and vital to #CommonLisp 's adoption.
I don't think I would have gone down this road, if not for @screwtape 's advocacy.
My snap judgment idealism and Java OO hatred made me assume scheme and lisp1 was they way. (not saying it isn't this is just for me)
It's kinda serendipity because I have OO baggage in my brain from C++ and Java. CL's CLOS is so much nicer, but my previous OO knowledge is a foil that has helped me take it in.
In 1984, 40 years ago, Digital Press published the book "Common LISP: Reference Manual" by Guy L. Steele Jr. and others, more widely known as the first edition of "Common Lisp: The Language" or CLtL1. It was an early major milestone of a Lisp standardization process completed a decade later.
in terms of industry programming languages that any programmer can hit the ground running with little to no ramp up, #elixir does the best job imo. I never used ruby, but its all so obvious you can just get to work. and for distributed systems that need to scale in a flexible way, the #beam eliminates nearly everything that makes webapp development horrible. it's hard to make a good argument for any other industrial virtual machine. #commonlisp implementations being the exception.
I'm looking for a Lisp resource I run across but can't find anymore.
It's a Common Lisp reference similar to the HyperSpec or possibly based on its text, but with a clean web design and modern HTML formatting. The name of the resource rhymes with "spec" or "hyperspec".
I just built and installed ECL #CommonLisp (hompage) onto my computer, and after playing around with it for only a few minutes, I am quite impressed with it!
First off, the entire installation is only 40 MB, so this is definitely one of the more compact Common Lisp implementations I have ever seen.
It emits C code, native shared libraries, native static libraries, and native executables.
It uses libffi for C interoperability.
It provides ASDF, and the ability to install packages from QuickLisp
It implements Lisp standard processes on top of Pthreads
It provides some bindings to Qt4 for GUI programming
It implements all of CLOS
All of that in just 40 MB (not including Qt, which you need to install separately). The only drawback so far is that the documentation has some gaps in it.
But I definitely want to play around with #ECL some more. The trouble is most Common Lisp packages written nowadays only support SBCL. I would like to see how much of the Common Lisp ecosystem I can actually use through ECL. I wonder if I could maybe port something like the Lem text editor over to ECL instead of building it with SBCL, but that might prove impossible.
Anyway, my overall impression right now is that I have a very lightweight but powerful Common Lisp compiler at my disposal now that can easily be embedded into any C program I want, which is very exciting!
The Common Lisp code in "How to Solve It in LISP" by Patrick Hall (1989) is a bit archaic.
But this work is unusual and intersting in that, unlike contemporary Lisp books, the examples don't focus just on AI but also a range of ordinary programming domains such as math, business, data structures, simulation, and more. Plus the cover is the weirdest of Lisp books.
Interesting: it seems that #CommonLisp does not have a PARSE-FLOAT function or something to that effect. It has PARSE-INTEGER but to parse a float, you either need to build it yourself or use an external library.
A few years ago I have created a visual overview of (mostly) Common Lisp related books... Good thing: even the older ones can be useful, given that the core language hasn't changed that much over the last years.
TIL Tail call optimization is the default in most modern Common Lisp implementations. It is not a Scheme exclusive any more (I was under the impression...).
But, how do I find out, in SBCL for example, that I do a proper TCO function call?
The Scheme language's small size isn't necessarily a strength
So I was reading through part of the EmacsWiki and in the article on the Scheme programming language there are references to this ancient online debate from August of the year 2000 at the comp.lang.lisp Usenet group started by the late Erik Naggum, who was apparently a somewhat opinionated and inflammatory individual, who brought up the Scheme/Common Lisp debate on comment thread about someone being confused about how the CASE clause works.
The Scheme language standard at the time was R5RS, Naggum's argument is a common refrain from Scheme fans such as myself, and he was arguing with Kent Pitman ( @kentpitman ) who was one of the sub-committee chairs of the Common Lisp X3J13 standardization process, and is the editor and maintainer of the Common Lisp HyperSpec, an online form of the Common Lisp specification. Kent Pittman's reply I thought was very well-reasoned, and worth re-posting here (quote):
I just absolutely don't believe the Scheme standard is fairly cited as a model of a "better" standard. It is enormously vague on numerous matters of consequence. It omits really essential functionality that would be needed to write any seriously portable programs. It was stagnant for years on quibbles over some of the silliest syntax details. In my opinion, it's a toy language. There are real commercial Scheme implementations, but only by the sheer will of those implementers who've gone beyond the so-called standard and written in the things that the standard ought to have said in order to make the language finally useful. It achieves its "prettiness" and its "smallness" on the back of just plain leaving stuff out where it would appear to "clutter", and whatever you think of CL, I personally reject any claim that the Scheme is a model of improvement.
(end quote)
I wouldn't go so far as to call Scheme a "toy language" because the parts of the standard that are well-defined are solid and very useful. But yes, it seems the only useful implementations do solve these problems not addressed by the standard in completely different ways that makes it very difficult to write a Scheme program on one implementation that runs on another. Try to write one program that runs on MIT Scheme, Guile, Chez, Racket, Bigloo, Cyclone, Stklos, and Gambit. Try to even compute what set of SRFI (language extensions) are common to all of them. Most Scheme programmers have to pick just one implementation and stick to it without much hope of ever porting their programs to other implementations. It is possible to do it, easier than porting a program from Python to C++, but still not at all as easy as running the same Common Lisp program on SBCL, ECL, ABCL, or Franz.
So I do agree with @kentpitman that there are some pretty important details left up to the implementers simply because none of them could agree on what to do and punted the issue rather than resolve it. Later (after the aforementioned Usenet debate) R6RS would try to solve these issues, but that standard was mostly rejected by the larger part of the Scheme community due to a lack of consensus. Much of that work lives on in the SRFIs, while Chez Scheme (R. Kent Dybvig) seems to be sticking to R6RS and is one of the most well-respected Scheme implementations, and a kind of flagship of that standard.
I still have hope for R7RS-large though, which might end up being even larger than X3J13 when all is said and done. Unfortunately, recently John Cowan, chair of the R7RS-large standardization committee threw his hands up in resignation a few months ago after almost 10 years of trying to hammer-out consensus over details of the new R7RS-large standard. Daphne Preston Kendal ( @dpk ) has taken over and is fully capable of continuing the work.
It might be interesting if some Schemers could get together and write a new fully R7RS-compliant Scheme-to-Scheme compiler in R7RS-small Scheme, with all of the COND-EXPAND expressions in place to run on all of the major R7RS-compatible Scheme implementations. This compiler would simply translate its input into code that the host Scheme compiler can compile, deferring low-level implementation details to the host. The compiler should be one massive file that you could just load into any Scheme compiler and it just works. Then this compiler maybe, just maybe could become The Scheme Standard. A good starting point would be the work of Marc Nieper-Wißkirchen who has written Rapid Scheme which compiles R7RS Scheme to another host Scheme, but it only supports Chibi and Larceny as the hosts.
Uncommon opinion (but not necessarily unpopular): I love languages with large standard libraries. I enjoy flipping through the language documentation, scouting for interesting functions or classes that may eventually come in handy.
My favorite large library language is Common Lisp but of course there are many others such as Smalltalk, Python, and Java.
TIL: Function designators in Common Lisp:
(funcall 'foo 0)
(funcall #'foo 0)
Both work, however, if there is a function named FOO in the lexical environment (i.e. via FLET/LABELS), #' (= FUNCTION) will use that while ' (= QUOTE) will always ignore the lexical environment.