posted on 2017-12-11 8:30:00 PM
Welcome to the first of hopefully many posts on providing a basic overview of the wonder language that is Common Lisp. Many folks over the years have provided many different versions of this talk (I will provide a few tutorials and book suggestions at the end of this post). However, one thing that is often ignored is how to actually setup a Common Lisp Development Environment. While the approach I have personally documented here may not be what others have suggested, since over time development environment and practices have changed amongst other reasons, it is the fastest way to get up and running so that we can concentrate on learning and writing actual CL code versus quitting after finding it difficult to get setup to begin learning.
One question that is often brought up when learning Common Lisp is the reason why we set up a development environment ahead of time? Why not first learn the language and then start writing code directly in the REPL? When I first started learning Lisp back in 2006 (and I was a bit naive back then and was unaware of SLIME), I took this approach while reading Practical Common Lisp (one of my first suggestions to learn Lisp, more on this later). However, I quickly realized, a few things: - As one does more scripting, at some point it becomes very useful to just pop up an editor and actually save your work to a file. - Most REPLs don't have readline commands built-in (at least the REPLs I've used never had read-line built-in).
For those of you aren't familiar, Readline is a library that gives nice emacs-style keybindings to applications. One of the features which I have often have used that is with this library is history (a nice way to look up commands and code previously executed).
There are other reasons, of course, why you should use a dev environment, but these are just from learning perspective.
Common Lisp was one of the first languages to have what we now called an Integrated Development Environment or IDE. Many of the features that were provided by the Lisp machines and dev environments like Interlisp-D were incorporated into modern IDEs for other programming languages like C++, Java, and so on. However, the introspection facilities of these IDEs still leave something to be desired, but I am getting ahead of myself since this is an introductory talk :-) So let's begin.
There are many barriers a newcomer to Common Lisp hits as he is first setting up and getting up to speed. Things like:
The list goes on... The solution to these needs has been released as a recent development, and that solution is Roswell. Roswell, as the site goes provides a nice tool to help manage different Common Lisp implementations, as well as unified way to test, build and distribute CL applications. There are many features in Roswell, and I will expand on Roswell in later posts, but first I would like to show how simple it is to get up and running with Common Lisp and SLIME with Roswell.
First we must download and install a few pre-requisites before we begin:
When you first install Roswell, all one has to do is run the command:
? ros setup
and Roswell will download SBCL (Steel Bank Common Lisp) and set it up with Quicklisp. To test this all works, all you have to do is run:
? ros run
and you'll see a SBCL prompt indicating it has been installed. run
(quit) and the shell to exit. Next we will install SLIME by running:
? ros emacs
This command will simply install SLIME using quicklisp (if it isn't already downloaded) and then it will actually open up emacs with a SLIME buffer available so you can get started writing lisp code. However, if this is your first installing SLIME with Roswell, you may end up having to first exit Emacs and add the following line (which is Of course can exit the SLIME buffer by type
M-x slime-quit-lisp if you want, and then exit Emacs using
C-x C-c. At this point, though, you are all setup to begin your lisp journey.
At this point, you are ready to begin your Common Lisp journey. A couple of suggestions on books that you can read to get you up and running include:
The books mentioned here cover the language fairly well and introduces all the basic aspects to day-to-day development in the program. Advanced topics like CLOS, Macros, and the Metaobject Protocol are introduced and covered in books like:
On top of the above book suggestions, I would also recommend Bagger's Little Bits of Lisp series located on Youtube. It is a small series of introductory Common Lisp videos and covers various topics, but not everything that are covered in the books. I would suggest to consider more as supplementary material to watch as you go on your journey to learning the language.
That's all for now. In the next installment, I will speak more about Roswell's features as well as using it to write shell scripts in Common Lisp as well as create executables.
posted on 2017-07-20 10:35:10
When I decided to write and setup this blog, a lot of folks started giving me suggestions on what tech stack to actually use to write it. I wanted to use some sort of static site generator but was entirely unsure which one to choose from since there are so many. Some of the candidates that I looked into (certainly useful for anyone who wants to get started on setting up either a basic static site or blog for themselves) include:
Knowing Common Lisp, and wanting to use it in a project, I decided to go with Coleslaw. Originally, I was a bit skeptical, and I tried a few things with it to learn how the basic customizations work (it is fairly mature in the number of features it offers), and I was really pleasantly surprised. Hats off to Mr. Brit Butler and community for creating such a nice static site generator for Common Lisp
I learnt a couple of things about Coleslaw as well as setting up my environment that I thought I'd share here so that others can get up and running quickly. I will say upfront that while these are more inconveniences than limitations in the tools, Coleslaw is ready to be used for high-quality static site generation, and in fact other folks online have used it for their personal and professional sites. However, with that being said, I sort of hit the following snags while starting up with Coleslaw:
the documentation says that one should setup a
$HOME that specifies the various base template variables when setting up the static site. This includes things like basic navigation urls, the site name and so on. The limitation to this nice approach of injecting this information to the templates, however, is if one wants to use coleslaw for multiple sites this becomes clearly infeasible. Now it was said elsewhere that it is possible to have a per-site config file, however when I tried setting that up, the generator complained it couldn't find the file and aborted itself. I'm assuming this is just a bug but I haven't investigated it further. Time permitting, I will look into this more.
One can use any theming you want to customize your site to your needs and there is plenty of clear documentation on how to do so. My suggestion is however, when starting at least, is to copy one of the previous themes and adjust them to your needs so you can get quickly deploy an initial version of your site. This is mainly because while theming is pretty straightforward and in fact most themes that come with Coleslaw are built on bootstrap with nice basic hooks into the config file, I still haven't found a way of adding more custom attributes to my config file that I want to populate my site with. Again, this is based on my personal experiences of using this for a while and as I learn more about it, I will surely keep people updated.
setting up a deployment pipeline to work with github pages isn't very well-documented. I'm basically learning as I go along. I'm still working through the kinks of my own personal approach to this, but I will certainly report how I have it all setup once completed.
All in all, I am fairly happy with my decision for using Coleslaw (at least for now). I will say as with any basic website development I've done it past, coleslaw still doesn't prevent you from messing with the CSS to get things just the way you want them. I think the tools for creating WYSIWYG web apps is long overdue. However, that is the subject of another post.