8 ms·

How To Build And Deploy Common Lisp In The Cloud (And Comparing Rails)

48 points by vetler 14y ago

kinleyd 14y ago
Thanks for sharing. :)
lucian1900 14y ago
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.
irahul 14y ago
> 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.
- weavejester 14y ago
  I think the distinction is that Lisps have a separate read and eval, while other languages (like Ruby) combine the two operations into a single command. Having a separate read and eval can be useful, but in the context of a REPL I'm not sure it particularly matters.
- mattbriggs 14y ago
  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 14y ago
    > 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 14y ago
      >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 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.
- batista 14y ago
  >Just because you don't like what irb has to offer doesn't mean you get to define what REPL is. If you did it 50 or 30 years ago, as Lisp has, you do get to define what it is.
  - irahul 14y ago
    > If you did it 50 or 30 years ago, as Lisp has, you do get to define what it is. And isn't the lisp definitions of repl the same as mine?
gouranga 14y ago
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- 14y ago
  I use SBCL -- it works :) sorry about your eyes..
  - gouranga 14y ago
    You are forgiven ;-) Thanks for the SBCL tip.
ynniv 14y ago
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 https://github.com/mtravers/heroku-buildpack-cl and https://github.com/jsmpereira/heroku-buildpack-cl 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-scratch-using-hunchentoot-and-nginx/ https://zaries.wordpress.com/2010/11/09/lisp-web-server-from... . 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.
ScottBurson 14y ago
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).

48 points by vetler 14y ago

Thanks for sharing. :)

lucian1900 14y ago

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.

irahul 14y ago

> 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.

weavejester 14y ago
I think the distinction is that Lisps have a separate read and eval, while other languages (like Ruby) combine the two operations into a single command. Having a separate read and eval can be useful, but in the context of a REPL I'm not sure it particularly matters.
mattbriggs 14y ago
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 14y ago
  > 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 14y ago
    >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 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.
batista 14y ago
>Just because you don't like what irb has to offer doesn't mean you get to define what REPL is. If you did it 50 or 30 years ago, as Lisp has, you do get to define what it is.
- irahul 14y ago
  > If you did it 50 or 30 years ago, as Lisp has, you do get to define what it is. And isn't the lisp definitions of repl the same as mine?

gouranga 14y ago

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- 14y ago
I use SBCL -- it works :) sorry about your eyes..
- gouranga 14y ago
  You are forgiven ;-) Thanks for the SBCL tip.

ynniv 14y ago

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 https://github.com/mtravers/heroku-buildpack-cl and https://github.com/jsmpereira/heroku-buildpack-cl 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-scratch-using-hunchentoot-and-nginx/ https://zaries.wordpress.com/2010/11/09/lisp-web-server-from... . 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.

ScottBurson 14y ago

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).