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