The announcement speaks as if web applications in Common Lisp was itself a solved problem.

The community surrounding that isn't exactly vibrant.

An example from an attempt to find a viable/nice Common Lisp templating library for making web apps (a problem for me before, I hate CL-WHO. Vile.)

http://www.cl-user.net/asp/U5Hd/sdataQGW2OvQLz758DQdX8yMX8yB...

Hrm. Yes. Hrm. Seems promising, exceeeept...

https://groups.google.com/group/cl-terrace/web/djula

The Google Group for it has...disappeared?

http://common-lisp.net/project/bpm/darcs/djula/

Yay, code!

That hasn't been touched since 2008!

CL-WHO, which I think is the most popular way to solve this problem hasn't been touched in 2 to 7 months, depending on how you measure it.

See here:

https://github.com/edicl/cl-who

The Ningle web framework for Clack, found here: https://github.com/fukamachi/ningle

Not been touched in 4-8 months.

Caveman (clack framework): https://github.com/fukamachi/caveman/ 4-8 months.

HTML-TEMPLATE hasn't been touched since Tue, 02 Dec 2008.

The most popular web server for CL, Hunchentoot hasn't been touched (based on the darcs repo anyway) since Tue, 24 Aug 2010.

Take a look for yourself: http://common-lisp.net/~loliveira/ediware/

The Common Lisp community is moribund at best.

I would PREFER to use Common Lisp over, say, Clojure or Python however the fact is that there just aren't enough people using it or maintaining web development software for it to overcome the time expenditure trade-offs.

So, can we drop the triumphant tone as it concerns CL? Even Paul Graham tells most people to just use Clojure.

"The most popular web server for CL, Hunchentoot hasn't been touched (based on the darcs repo anyway) since Tue, 24 Aug 2010."

That statement is just untrue, take a look yourself. https://github.com/edicl/hunchentoot/commits/master

Also there is an active community in Japan from what I can gather from github.com

They done cl-annot[1], which is a way to annotate functions with the @ syntax from python. Clack[2], the WSGI-equivalent for cl. And the Caveman[3] and Ningle[4] webframeworks.

[1]: https://github.com/arielnetworks/cl-annot [2]: https://github.com/fukamachi/clack [3]: https://github.com/fukamachi/caveman [4]: https://github.com/fukamachi/ningle

I linked Ningle and Caveman in my post and mentioned Clack too. What's your point?

They're relatively unmaintained and I still can't find a templating library for CL that isn't awful.

I'm using CL-WHO at the moment and I admit it's not necessarily the easiest way to generate html. But I did spot an alternative the other day called Spinneret: https://github.com/ruricolist/spinneret

I haven't got round to testing it, but it sounds good so I might try writing my next project with it. Having said that, CL-WHO has had some updates recently to add basic support for HTML5. Hunchentoot is also getting fairly consistent updates, I think there is even a websocket extension for it now.

I think Quicklisp has been responsible for a resurgence recently in Common Lisp. It used to be quite a pain for new people to get libraries up and running, which of course affected how much they get used/tested; so a common refrain was "Not happy? Just write your own". Now it's much easier to share and use libraries, and I'm seeing a fair bit of interesting development.

My favourite example at the moment is cl-parallel: http://lparallel.org/ Clean documentation, nice looking abstractions for seamlessly parallelizing code, I'm looking forward to trying it out next.

Dude, spinneret makes the same goddamn mistake.

I don't want my HTML templates in my Common Lisp code!

Most of my projects have a separate frontend guy who needs to be able to write the templates himself without touching or knowing the backend code. Django, Rails, Flask, Sinatra et al understand and respect this.

For some reason, most Clojure and Common Lisp libraries fail to grok this. I don't know why.

I want plain HTML files with some simple (mustache or Django/Jinja-style) tokens for injecting data provided by a hash-map/dictionary/assoc-list.

That's. It.

Good point. Maybe it's something to do with the fact that Lispers are so used to the whole "Code is Data, Data is Code" concept that you get within the Lisp family of languages? I guess I don't really see too much difference anymore between: <head>foo</head><body>bar</body> and (:head foo(:body bar)) Except that the 2nd I consider far more flexible for my personal needs. YMMV

The way I separate it out (and keep it sane!) is by trying to stick to a fairly strict MVC style and keep the backend code in separate functions away from the frontend cl-who templates. But this does still require some initial work in translating the initial html templates to my lisp templates, so I'll agree with you there.

And yes, it certainly does make it more difficult when dealing with 3rd party designers. I have to translate all their basic html templates into lisp/cl-who syntax. But I don't find that too much of a hardship tbh and the tradeoffs are worth it.

>I have to translate all their basic html templates into lisp/cl-who syntax. But I don't find that too much of a hardship tbh and the tradeoffs are worth it.

That would not work for more complicated projects at all.

I think the templating library you are looking for is cl-mustache. I am using it currently for a SQL template engine in one of my internal work projects.

First one that's shown promise.

Please look more closely. This is "for developers creating mobile applications, rather than web applications". And I don't see any "triumphant tone", but rather just a nice announcement.

I pick Clojure more often for my uses (not that I'm as liberated as I'd like in choosing tools), but I can imagine situations where I'd instead use Common Lisp.

Please look more closely. This is about the fact that their post about their mobile product took it for granted that web applications was some kind of conquered country for Common Lisp community when it's far from that. Also, their post had that triumphant tone + the Paul Graham name-dropping I referred to.

Any discussion of Common Lisp tends towards a classic comp.lang.lisp style flamewar. Strawman exaggerations, complaints about the state of Common Lisp libraries, arguments about someone's "tone"...

There is also a lib called 'HTML-TEMPLATE' ( http://weitz.de/html-template/ ) which is IMO a bit easier to use than CL-WHO.

Hunchentoot has been updated, it is just maintained by somebody else now AFAIK ( https://github.com/edicl/hunchentoot/downloads ). I do remember that there was a version (1.2?) that had some backward compatibility problems and that was last year.

Try quicklisp ( http://www.quicklisp.org/ ) for all your lib needs, it is a nice lib repository and it is very up to date (though still beta).

I already use quicklisp.

I don't like any templating system that mixes frontend with backend.

Clojure isn't an option on iOS. No Java, right?

I hadn't been following this lately, so went to check the status of Clojure on iOS Da Goog turns up one person suggesting ClojureScript which (while nifty) isn't the same thing. Another site suggests compiling Clojure to Scheme (which is going to be clumsy at best) or ActionScript (gaaaaaaaah!).

Of course, good luck on getting anything with a functioning REPL on iOS anyway (even the original package under discussion).

Why would you compile Clojure to Scheme? If you know Clojure, wouldn't you be able to write Scheme without too much difficulty?

I don't know; maybe you have existing Clojure code that you need to use?

"Of course, good luck on getting anything with a functioning REPL on iOS anyway"

Ruby Motion comes pretty close.

I am a little skeptical of the platform portability. A high quality application has a lot of UI code. Then, if you're Doing It Right, on iOS, you're probably going to use Core Data and/or iCloud for backend storage. For networking, you need to manage the activity indicator, etc.

So it seems like there are two choices:

1. There's a wrapper library on top of UIKit instead of straight bindings. Not good, more levels of junk, and can't really provide access to the entirety of the API since it doesn't 100% match with Android.

2. It's platform portable... as long as you don't actually use any system frameworks. In that case, it could be nice for games, I guess, but would it be fast enough?

I'm not jumping to any conclusions before I try it. I prefer CL over pretty much any language given the choice. It is a fine tool for making software. Having an in-point to writing native CL code for mobile devices sounds pretty good and not too far off to be too good.

I wonder whether this is something built on top of either ECL or Gambit-C, or something completely new? I'm certainly interested to find out more. ATM Gambit-C is top of my list of "alternatives for Lisp on iOS & Android".

Awesome.how big do you think is the market ?