...and the author has lost me (I did read the entire post though).
> If GitHub is down today I can't deploy anyway so I might as well embrace the server requirement as a perk.
Just because you can't deploy doesn't mean others can't as well. (Also, GitHub != Git. Period.)
Heck, the entire idea of DVCS is that you should be able to continue to work even after the servers are down. If you can't, then it's not Git problem.
It seems that the author didn't even understand the concepts and ideas, or the rationals behind DVCS, let alone Git. As a someone who had lived through the period when SVN was the only game in town (and not wanting to return to those dark days), seeing the author pining for the "good 'ol days" of SVN-like, centralized VCS is just silly.
The sad thing is, having a mandatory high school level statistics & probability class alone is not enough, you'll also need a good curriculum and a competent teacher to go along with it. Otherwise, it wouldn't work: a bad curriculum taught badly by a unmotivated or unqualified teacher will almost always fail to teach the intuition, or, even worse, alienates students from the materials.
I have no idea why that reply got downvoted as well. It is essentially how I installed Firefox on my Debian stable laptop , and it has been working great as far.
I'm sorry, but what is stopping you or other people from using distros with faster release cycle or rolling release?
If anything, there are so many rolling release distros nowadays, that Debian Stable is a breath of fresh air in the sea of release first, fix later mentality (especially when it comes to desktop environment).
But I digress, in the end just choose the distro that suits your needs and requirements and be happy.
Interestingly, it was originally written in Python, but the author decided to rewrite the entire thing in Common Lisp due mainly to Python's poor performance and the lack of native thread support. The result Common Lisp version is 30 times faster than the old Python one. More info can be found in the author's blog post [1].
>Package management is a non-thing in SBCL. It just doesn't exist.
When is the last time you use SBCL, or Common Lisp in general? Quicklisp (https://www.quicklisp.org/beta/), which is a modern package manager that supports resolving dependency and works across almost all currently active Common Lisp implementations (and not just SBCL), has been a thing for years now.
>The basic HTTP server, hunchentoot IIRC, crashes after it serves its first request
Would love to see the backtrace to see the reasons (and to submit a bug report if the issue warrant one), as from my experience Hunchentoot is very stable. I regularly used it in my freelance jobs without any issues.
It is one of the most active implementation of Common Lisp (other being Clozure CL) and one of the fastest thanks to its support of optional type hinting (which it had long, long before gradual typing become in vogue recently). With some type hinting, it is possible to generate a code that's almost as fast as C (in certain cases, of course, but still much better than other implementations).
>Nobody seems to have done any serious work in SBCL in over a decade.
Could you please elaborate on what you mean by this?
SBCL releases a new version that contains both enhancements and bugfixes every couple of months, with the latest version (version 1.4.9, released on June 28, 2018, ~5 days ago) came one just one month after the previous version, 1.4.8, so I really don't understand what you mean when you said that no one "seems to have done any serious work in SBCL in over a decade".
Or did you meant to say that no one use SBCL to do serious work? Well, with some googling, I'm sure you'll be able to find that, while not many, there are companies that use SBCL (and other Common Lisp implementations) in production and other non-trivial works (not to mention various freelancers who use SBCL to put foods on the table). Some of those companies are also involves with the development of SBCL as well.
>Basic things are either completely missing or broken.
Care to list them? One of the strength of SBCL is that the devs are very responsive, especially to bug reports, so I'm sure they would be more than happy to fix the problems that you encountered.
> All that survived into Common Lisp but I am not up on the current state of lisp implementations and have no idea if people bother to take advantage of it any more.
There are implementations of Common Lisp, most notably CMU CL and SBCL, that take advantage of the (optional) type declaration of Common Lisp to increase efficiency and provide type checking.
Thank you for your hard work. I've just upgraded from Jessie to Stretch on my main laptop and the process is silky smooth.
Even though I only started using Debian with Jessie (was using Ubuntu and Arch before that), I've come to love and depend on Debian's quality, stability, and reliability.
Yeah, that paragraph is a bit misleading (and the whole readme could use some more love).
Roswell is basically a tool that help you quickly setup a Lisp development environment. You can think of it as Ruby Version Manager (RVM) for Common Lisp. It can be used to install the latest version of the Lisp implementation of your choice (which is really a great feature if you use Debian stable or Ubuntu LTS), easily switch between various implementations, and even switch between different versions of each implementation. This makes testing your Lisp code across multiple implementations a breeze, especially when you use Roswell with CI tools.
That the majority of Roswell developers are web developers and use it to develop, test and deploy web apps are merely a coincidence. Roswell can be used to develop all kinds of applications.
Regarding the fragmentation issue, on Linux there are basically two major open source implementations that most people use nowadays: SBCL and Clozure Common Lisp (CCL). So it's hardly an issue at all.
Common Lisp _IS_ the consolidation of various Lisp dialects that you've asked about.
Back in the 70s and 80s there are numerous Lisp dialects (way, _way_ more then there are today, since each dialects has their own sub-dialect and so forth), and so Common Lisp was created back in the 80s (the work started in 1981 and finished in 1994) to unified various Lisp dialects into one common language.
And Common Lisp accomplishes that objective, well mostly anyway. Soon(-ish) most people, companies, and institutions ported their Lisp code base to Common Lisp, and by the late 80's and early 90's, when you say Lisp most people will (correctly) assume that you mean Common Lisp, not MacLisp or InterLisp, or some earlier, long depreciated dialects.
Now, about Scheme. Remember when I said that Common Lisp _mostly_ accomplishes its objective of unifying various Lisp dialects? Yeah, basically the Scheme community didn't like how Common Lisp turns out, so they decided to stick with Scheme. And it is understandable why they feel this way, because despite outward appearance, the two languages are very different, with Scheme focuses on small (and mathematically elegant) core language, while Common Lisp, with its focus on being practical, is a huge language with a standard library that includes everything and a kitchen sink. Scheme also has a totally different evaluation model compared to Common Lisp and its own macro system with emphasis on hygienic. Not to mention that Scheme has its own standard, the R*RS (now in its 6th revision, with 7th in the drafting process).
Now, the thing about Common Lisp is that it is very hard, if not downright impossible, to change its standard. This means that it is not easy to make a substantial changes to the language and has the wider community adopt it (and we haven't even talk about changes that will break backward compatibility here). This is one of the reason that Rich Hickey created Clojure as an entirely new Lisp dialect (before this, he had implemented a Java FFI for Common Lisp). Clojure has a new syntax that is far more consistent than Common Lisp (which comes at the cost of breaking backward compatibility), as well as many new and experimental features, such as immutability, asynchronous operations, and the focus on functional programming style. All of these would be very hard to introduce into Common Lisp without significant efforts and time.
The core of Racket, its syntax and basic constructs, is basically the small and elegant Scheme we all known and love. What set Racket apart is all of the additional features that was built around that tiny core (its own OO system, for example), as well as a huge standard library.