

How To Build And Deploy Common Lisp In The Cloud (And Comparing Rails) - vetler
http://kuomarc.wordpress.com/2012/05/13/12-steps-to-build-and-deploy-common-lisp-in-the-cloud-and-comparing-rails/

======
irahul
> the irb shell is not a real REPL.

What is a true repl?

    
    
        loop { puts eval(gets) }
    

is a REPL. Just because you don't like what irb has to offer doesn't mean you
get to define what REPL is.

> You can also do stuff like retrieve a database entry as a CLOS object and
> inspect or manipulate it

That's great. Just like you can retrieve database entries as activerecord
objects.

> While I was taking SaaS-class, I missed the parentheses and as always, I got
> curious: how would Common Lisp compare?

For a regular CRUD task, Common Lisp compares badly. You say Rails convention
is a steep learning curve, but I don't see how your folder structure is any
easier to grok than Rails' if I am not already familiar with it. As far as
naming convnetion goes, that might bite you sometimes when you are just
starting, but use generators and "do as what is already done" and you will be
good.

Common Lisp has its niceties - generally produces fast code, some abstractions
are better done with macros etc. But for now, when compared to Rails for a
regular CRUD app, it isn't going to look good. Someone can alwasy write Rails
for Common Lisp, and then implement all plugins which ease development(devise,
kaminari, paperclip...) - but no one has yet.

~~~
mattbriggs
When was the last time you ran your web server through erb, and modified small
chunks of code, then checked how they worked without leaving your editor? I'm
a professional rails dev, and for me it's "never". That "interactive
development" is how all lisp coder work, and is probably what the OP was
referring to.

~~~
irahul
> That "interactive development" is how all lisp coder work, and is probably
> what the OP was referring to.

I write Clojure and Racket, and no, I don't work that way. How do you modify
small chunks of templates and then check how it looks in the browser without
leaving your editor, and how is that a property of lisp?

Also, I was pointing out that you don't get to define REPL to comply with what
you think it should mean. I didn't say anything about _interactive
development_. As far as I know, the interactive development in Common Lisp
world refers to emacs-slime marriage, which apart from evaluation, enables the
debugger when an error happens. I use Clojure with Vim(VimClojure). Though
VimClojure can evaluate code, I don't do it using VimClojure but use tmux to
send text to a clojure repl. Same goes for racket(the sending buffer to repl
part). Not being dropped into a debugger automagically is a convenience, but
not so much that I switch to emacs-slime.

~~~
mattbriggs
>How do you modify small chunks of templates and then check how it looks in
the browser without leaving your editor

<https://github.com/weavejester/hiccup>

>and how is that a property of lisp?

The "lisp way" is to convert the problem into something solvable by lists,
then convert those lists into whatever they need to be. Lisp is _amazing_ at
processing lists, so this style of programming plays to the languages
strengths.

>Also, I was pointing out that you don't get to define REPL to comply with
what you think it should mean. I didn't say anything about interactive
development.

Granted. But there is a fairly old idea that when you are working on code, it
should be against a running version. Smalltalk was the ultimate expression of
that, (where there is no difference between editor and app), but the typical
way that a lisper works is the next best thing. When you are used to working
that way, it is hard to go back, since the feedback cycle is just so tight,
and exploratory coding is so simple.

~~~
irahul
>>How do you modify small chunks of templates and then check how it looks in
the browser without leaving your editor

> <https://github.com/weavejester/hiccup>

hiccup is just another approach to do html generation. This style of html
generation is common in lisps - Racket uses it as well. hiccup(or this genre
of templating) can be conveniently implemented in Ruby, or any language for
that matter. I prefer explicit templates(particularly slim). Additionally, I
don't see what I gain by the fact that I can potentially change my hiccup
input, run it in the repl and see what html it produces. If the library is
well tested, I won't have a need to check if it is producing html
corresponding to the input list.

> Lisp is _amazing_ at processing lists, so this style of programming plays to
> the languages strengths.

I don't think _Lisp is amazing at processing list_ is the reason behind this
style of programming - Ruby has excellent seq abstractions(from the top of my
head, I can't think of a list abstraction/method that lisp supports that Ruby
doesn't). The fact that this style of programming is common is due to Lisp's
s-expr syntax.

> But there is a fairly old idea that when you are working on code, it should
> be against a running version. Smalltalk was the ultimate expression of that,
> (where there is no difference between editor and app), but the typical way
> that a lisper works is the next best thing.

I still see only one thing(emacs-slime drops to the debugger if evaluation
fails) that lisp has extra of. Ruby, Python et al have the same feedback
cycle. The things that can be interactively tested in Lisp can most probably
be tested Ruby. You wrote a function which takes a sentence and qualifies it
as happy/sad - irrespective of whether it's lisp or Ruby, you drop in the repl
and feed it your input, or you write tests and run them. You changed your app
to allow facebook login, you either interactively run it in the browser or
write a test.

------
ynniv
This is a survey at best. It jumps to strange or unsupported conclusions like
"the irb shell is not a true REPL" and "Rails is probably the best way to go
about a complex web application", and impressive WTFs like "Perhaps to get the
best of both worlds, I should investigate calling Lisp code from Rails?"

However it does show step by step how to deploy Hunchentoot on Heroku. This
builds on <https://github.com/mtravers/heroku-buildpack-cl> and
<https://github.com/jsmpereira/heroku-buildpack-cl>, and includes Hunchentoot
sample code similar to [https://zaries.wordpress.com/2010/11/09/lisp-web-
server-from...](https://zaries.wordpress.com/2010/11/09/lisp-web-server-from-
scratch-using-hunchentoot-and-nginx/) .

It is this reliance on the frameworks and tutorials of others that makes a
final bullet point ring hollow: "Lisp lacks a true community, the kind that
powerfully drives Rails forward, resulting in great libraries, superb
documentation and tutorials aplenty."

Skip the commentary, follow the code.

------
gouranga
Another fucking blog using grey on white text. My poor eyes :(

Updated comment: article rocks - there goes my evening. Wonder if it'll work
with SBCL.

~~~
mck-
I use SBCL -- it works :) sorry about your eyes..

~~~
gouranga
You are forgiven ;-)

Thanks for the SBCL tip.

------
ScottBurson
There are some Common Lisp Web frameworks; you don't have to build your app
directly out of Hunchentoot handlers and CL-WHO. I'm using Weblocks, for
example. It has a variety of useful "widgets" including sorted, paginated
tables.

The Weblocks learning curve is substantial, admittedly, but now that I've
climbed it I find it very easy and fast to work in. I gather Rails has a bit
of a learning curve as well.

I recommend Weblocks to those who already know Common Lisp, want a
sophisticated, powerful framework, and don't mind extending it themselves when
needed (obviously it's not as mature as Rails).

------
lucian1900
It's not very hard to do direct manipulation in the repl with Python & Django,
I do it all the time when debugging.

I'm not sure how hard it is with Ruby & Rails.

------
kinleyd
Thanks for sharing. :)

