SearchYC.com

I think arc like macros should go in Anarki. What does everyone else think? I like seeing everything arc in one place - even if it is CL or Scheme macros.

Considering that arc doesn't even have slime support - it's accurate. Now when using slime supported lisps, the environments are at least comparable. Debugging in Smalltalk is awesome and straightforward after you are up to speed. It still takes more dedication to learn slime well enough to debug a gnarly bug.

Both smalltalk and lisp will allow you to create DSLs (domain specific languages) easily for your application. Both see code as data and allow customization of internals. They do this through different approaches. Each approach has different strengths and weaknesses. Also some people are just more comfortable with one approach over another.

I think it speaks volumes about Smalltalk that Avi Bryant could just add continuations (saved closures) to the language for seaside. This sort of ability to add powerful new forms to a language is key and helps set it apart from other languages and put it in the same category as Lisp.

If you are interested there are interesting "History of" papers on Smalltalk and Lisp from the HOPL ACM conferences. They help explain the different philosophies in detail and do a great job of explaining why each language is the way that it is.

CL:

UCW - http://common-lisp.net/project/ucw/features.html

hunchentoot - http://weitz.de/hunchentoot/

weblocks - http://common-lisp.net/project/cl-weblocks/

Scheme (gauche):

kahua - http://www.kahua.org/show/en

Outside the lispy box - smalltalk:

seaside - http://www.seaside.st/

A thread on an actual enterprise web based lisp system:

http://groups.google.com/group/comp.lang.lisp/browse_thread/...

On top of this consider that if you use something like sbcl you'll then be able to use slime and all that it adds when debugging. Also you'll get a number of relatively stable libraries without having to port them to arc.

http://common-lisp.net/project/slime/

You also get some nice persistence libraries such as elephant in CL. These could make life easier if you had complex objects or structures that needed more than just hashs.

http://common-lisp.net/project/elephant/

I think the number one thing plaguing SBCL is multiple threads causing problems. A friend mentioned that hashes should be threadsafe now. That is a move in the right direction. I know I've had problems with threading in SBCL in the past, but that was years ago.

I have thought about what my back up is if I run into too many problems in arc or lisp. Especially if I needed to hire people or contract work. I have my own ideas for how to address such problems, but I think it should be kept in mind when making a decision as to what framework and language to use.

Personally I think using Anarki is fast, straightforward and community friendly... So that may be my choice in the end when arc3/mz372 has some time to stabilize.

Is there a reason you are avoiding source control?

Libraries are both a weakness and strength for lisps. Yes there are libs that do EVERYTHING out there. Each one has a different style and approach. There are no standard methodologies across the libraries. This makes it difficult. Everytime a developer brings in another library they have to figure out how to use it. Versus interfacing with libraries in python, ruby or even Java / C#... everything is much more uniform.

There is a bigger opportunity with small to medium size experimental projects. I think a great example is: http://www.pageonetimes.com/ which is based on PG's news code.

personal-finance-management system

In the past I've implemented front and back-end financial software. I think it's a huge undertaking and best implemented with as many tested and true libraries as you can find. It's absolutely possible in arc, but why use arc when it's not the best choice (for now atleast). Meanwhile there are a number of other areas where the code will not be nearly as library dependent.

a dedicated arc IDE

I think an IDE is a great idea. In my opinion, the way to do it is to use existing IDEs. DrScheme (already works...), Eclipse, SLIME all come to mind. Now before everyone goes nutty thinking we need our own IDE - yeah eventually. But who is going to put in hundreds of hours of time into implementing a new IDE when you could plug into three existing IDEs in a fraction of the time.