Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Poor documentation for common lisp Web Development.

626 views
Skip to first unread message

Bigos

unread,
Feb 2, 2017, 9:09:35 AM2/2/17
to
Recently I looked into prospects of experimenting with web development with Common Lisp and found the quality of documentation appalling.

The only decent introductory tutorials that I could are six years old!
http://www.adamtornhill.com/articles/lispweb.htm

The world did not stand still and some Lispers recommend to use different libraries.
http://eudoxia.me/article/common-lisp-sotu-2015#web-development

says following:
Stop using Hunchentoot directly. Use Clack, or even better, one of the frameworks built on it.

However, there's a problem, the documentation for Clack or Lucerne is useless. You can only use it to show the example code running. That's all. If I want to change anything I have to edit the code, then kill the slime, then start it again.

So what should I do? should I ignore advice from eudoxia.me website and use Hunchentoot directly?

In the ideal world, if eudoxia.me is right one would expect some good quality tutorial similar to the one that was written by Adam Tornhill to appear. People would be using Clack and share the news of success. However, the opposite is true. Another tutorial using Hunchentoot and the author recommending to give up
on Lisp.
https://blog.jeaye.com/2015/09/27/parenscript-ajax

Why do I bother? I have tried Parenscript last year. I had a Hunchentoot server with one HTML page and Parenscript, which was pleasant to use. There are some applications where requests per second do not matter. If the application is successfulI can always have more servers. The problem is difficulty involved in the development. Could Lisp be useful, so that I do not need a team of developers fighting the blurb language deficiencies. Would benefits from the Lisp power outweigh time lost due to lack of decent documentation?
Message has been deleted

jeosol

unread,
Feb 3, 2017, 12:19:27 PM2/3/17
to
You won't believe this Bigos, but I could have written the above post myself. In fact, I contacted jeaye when I saw his post via reddit and he replied me that he has been trying to tell people the post is old and is not recommending to use CL for web dev, and would rather suggest Clojure. He also said he had released a couple of projects with Clojure. There are other former lispers that have suggested same.

First of all, let me say that I don't have any websites running CL. Like you, I am putting tools/codes together so far -- so early stages for me on web front but I do have codes written for my model.

Converting will be an issue for me as I moved the codes from C/C++ to CL (mostly use SBCL). I have a been a little stubborn not heeding calls to switch to Clojure.

So what I have done on the CL for web development.

I have tried Clack and I couldn't get it to work well (my fault I suspect). Had some problems. Retried a couple of times and after asking some experienced lispers I decided to go bare with Hunchentoot for a start so I understand things before using frameworks. I was able to test things directly but it can be a lot of work. I do see the importance of having frameworks, they can help you with lots of lifting. But I didn't get it to work for non-trivial problem. I may go back now I have used hunchentoot.

Perhaps, experienced lispers who are using CL for production web apps can chime in.

By the way, Pavel is/was writing a book about web development in CL but I am not sure it's been completed. Check it here: https://leanpub.com/fullstacklisp

Dimitri Fontaine

unread,
Feb 3, 2017, 3:03:32 PM2/3/17
to
jeosol <jeron...@gmail.com> writes:
> Perhaps, experienced lispers who are using CL for production web apps can
> chime in. I wouldn't mind helping to write (with some examples) tutorials,
> code, etc, to help others because I know how difficult it was for me looking
> for decent examples.

I don't know about “experienced”… but you can have a look at some of my
CL web projects, they tend to use the same set of tools: hunchentoot and
a local copy of simple-routes, which is my current favorite way to
express http routes on top of a bare hunchentoot setup:

https://github.com/dimitri/pgcharts
https://github.com/dimitri/pginstall
https://github.com/dimitri/tapoueh.org

You can see simple-routes in action here:

https://github.com/dimitri/pgcharts/blob/master/src/server.lisp
https://github.com/dimitri/pginstall/blob/master/src/server/server.lisp

HTH, Regards,
--
dim

jeosol

unread,
Feb 4, 2017, 1:31:28 PM2/4/17
to
Merci mon ami.

This would be very useful for studying. Like the NBA example -- I follow the game. I will study the examples.

> I don't know about “experienced”… but you can have a look at some of my
> CL web projects, they tend to use the same set of tools: hunchentoot and
> a local copy of simple-routes, which is my current favorite way to
> express http routes on top of a bare hunchentoot setup:
>

Experienced in my book, for sure.

Thanks,

Albert van der Horst

unread,
Feb 4, 2017, 8:26:25 PM2/4/17
to
In article <3dff4a67-51a9-44f9...@googlegroups.com>,
Bigos <ruby....@googlemail.com> wrote:
>Recently I looked into prospects of experimenting with web development with=
> Common Lisp and found the quality of documentation appalling.
>
>The only decent introductory tutorials that I could are six years old!
>http://www.adamtornhill.com/articles/lispweb.htm

The only programs I really trust are those without known defects for
at least 5 years, and no improvements to the docs possible for
about the same time, especially if they are wide used.
Common Lisp is quite mature, so the argument that there should be
recent changes to introductory material is absurd.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Bigos

unread,
Feb 5, 2017, 7:25:22 PM2/5/17
to
On 05/02/17 01:26, Albert van der Horst wrote:
> Common Lisp is quite mature, so the argument that there should be
> recent changes to introductory material is absurd.
>

I agree, but...

A website that comes near the top when you search for
common lisp libraries
suggests to disregard a widely used solution and switch to a new and
unproven library promising significant benefits.

Maturity is a double edged sword. How do you keep up with the changes
around you? Is the website promising those improvements telling the
truth? How do I sift the truth from lies?

Should I disregard other claims of this website?
http://eudoxia.me/article/common-lisp-sotu-2015#web-development

Kaz Kylheku

unread,
Feb 5, 2017, 7:30:32 PM2/5/17
to
On 2017-02-06, Bigos <ruby....@googlemail.com> wrote:
> On 05/02/17 01:26, Albert van der Horst wrote:
>> Common Lisp is quite mature, so the argument that there should be
>> recent changes to introductory material is absurd.
>>
>
> I agree, but...
>
> A website that comes near the top when you search for
> common lisp libraries
> suggests to disregard a widely used solution and switch to a new and
> unproven library promising significant benefits.

So, because Google boosts active sites in its ranking, everyone should
make code changes just for the heck of it to stay ahead in the index.

Marco Antoniotti

unread,
Feb 6, 2017, 1:21:43 AM2/6/17
to
On Monday, February 6, 2017 at 1:25:22 AM UTC+1, Bigos wrote:
> On 05/02/17 01:26, Albert van der Horst wrote:
> > Common Lisp is quite mature, so the argument that there should be
> > recent changes to introductory material is absurd.
> >
>
> I agree, but...
>
> A website that comes near the top when you search for
> common lisp libraries
> suggests to disregard a widely used solution and switch to a new and
> unproven library promising significant benefits.

You want to do Common Lisp. At this point it is all about not using "widely used solutions" :)

Cheers
--
MA

Bigos

unread,
Feb 6, 2017, 9:17:16 AM2/6/17
to
Looks like I am on my own. I will remember Albert van der Horst's 5
years rule, which is at odds with the widely accepted wisdom, but makes
sense here.

I guess I will be a bit wiser after this experience. It's never too late
for that.

Kaz Kylheku

unread,
Feb 6, 2017, 9:54:54 AM2/6/17
to
On 2017-02-06, Bigos <ruby....@googlemail.com> wrote:
> I guess I will be a bit wiser after this experience.

Nope; I'm predicting you will still use the Google search engine, and
see churning, unstable, "hot" stuff ranked ahead of mature stuff.

Bigos

unread,
Feb 6, 2017, 11:33:41 AM2/6/17
to
I promise not to trust too much the Google page rank.

a.daniel...@gmail.com

unread,
Feb 22, 2017, 1:14:29 PM2/22/17
to
I also make use of web app structure for many of my small CL projects.

For the server side I have used Portable Allegroserve directly and I have used Hutchentoot directly. I use some other server side CL tools that are currently even more out of favor - but they work rather well for my simple needs, I've been able to extend and adapt them slightly, and the authors respond to email, so what the heck? I like my environment, and it's been assembled from looking around on Cliki and Google. I've looked for tool descriptions that speak of small and simple rather than industrial and mega, and a little trial and error has paid off quite well.

All this talk about abandoning CL and going to Clojure, or abandoning Hutch and going to an abstract layer, but that new thing's already been abandoned too - I think if you make your living on web apps, and you work in a community of web app industry, and you ever hope to scale to millions of transactions per minute, then there has been a lot of evolution over the years, and there is good reason. But I'm a team of one doing small apps and programs.

I like my CL web app approach because it lets me automate point and click interactions with other web apps I need to use in my work. I get a cross-platform usable GUI, and also I like the ability to host the application either locally on a PC or divide it server/client style across computers. I've been able to share some apps at work just be giving the IP address of my server process.

polymorph self

unread,
Feb 28, 2017, 7:27:42 PM2/28/17
to
Any words here from the wookie devs?
The clack guy?
The lisp on lines people?
The hunchntoot guy?
The antiweb guy?
anyone using mongrel2 and common lisp?
anyoen using prevayler(lisp version) and lisp?
anyone porting www.happstack.com to lisp?(looks like most powerful functional framework with built in database)
anyone porting gnoga/ada to lisp? (this looks wow because mobiel desktop and web same code base with NO javascript!)
anyone using the paul graham strategy of simply forking a lisp interpreter for each client, and then lisp having a conversation with the client?
anyone using coreserver(seemingly closest thing to happtack in lisp)
clack guy?
is bknr around?
did the doug hoyt guy publish a web library/framework?
did the AMOP guy do an oo lisp webs frameowkr with an oo databse?

Munawar Cheema

unread,
Mar 7, 2017, 3:21:12 PM3/7/17
to
Five years is still pretty recent. Eskill Steenberg prefers to use ANSI C 1989 for his entire code base. https://www.youtube.com/watch?v=443UNeGrFoM&t=1324s

Bigos

unread,
Mar 7, 2017, 8:58:28 PM3/7/17
to
Your suggestion to use simple-routes has improved readability of my code dramatically. Thank you very much. Although I did not have a chance to try it month ago I am really pleased with it. https://github.com/bigos/simple-web-app/blob/master/simple-web-app.lisp

Dimitri Fontaine

unread,
Mar 8, 2017, 4:57:32 AM3/8/17
to
Bigos <ruby....@googlemail.com> writes:
> Your suggestion to use simple-routes has improved readability of my code
> dramatically. Thank you very much. Although I did not have a chance to try
> it month ago I am really pleased with it.
> https://github.com/bigos/simple-web-app/blob/master/simple-web-app.lisp

You don't need to restart the acceptor when you edit the route ;-)

It's something I fixed in the lib IIRC so that I could have several web
applications running in parallel in the same hunchentoot web server.
Doing it that way you can just hack your *routes* away and don't need to
reload anything when you do:

(setf *acceptor*
(make-instance 'simpleroutes-acceptor
:routes '*routes*
:port (or port *port*)
:document-root (or root *root-directory*)
:access-log-destination (or logs *access-log-file*)
:message-log-destination (or logs *logfile*)))

See the following for the file history and my hacks:

https://github.com/dimitri/pgcharts/commits/master/lib/simple-routes.lisp
https://github.com/dimitri/pgcharts/commit/42cdffd48e703bcc79ce2d9f8c863bb8533fdace

Regards,
--
dim

Bigos

unread,
Mar 28, 2017, 4:50:47 PM3/28/17
to
I have tried much simpler solution which achieves the same effect
https://github.com/bigos/my-routes

What you think?

Gavino himself

unread,
Apr 1, 2017, 12:11:56 AM4/1/17
to
holy shit that is the most interesting youtube like I have seen in months
WOA
can lisp do better?
any mmporg in lisp?
0 new messages