You know how when programming in e.g. Java, it's nice to have a good IDE to auto-insert common code patterns so you don't have to do a lot of typing? In Arc all the code patterns are already squeezed out, so I can write nice programs without a lot of typing in a plain editor. I find this makes writing programs in Arc a pleasure, so it's simply more fun for me :-)

I do find Arc particularly useful when I'm working on algorithms, where I'm trying to figure out what to do. The conciseness, simplicity, and transparency of Arc means that I can get close to working on a direct expression of the algorithm itself, instead of a more verbose translation of the algorithm into a more cumbersome verbose implementation. (See my write up on a parser combinator http://awwx.ws/combinator/ for an example). This makes it easier to change the algorithm, because I don't have to mentally translate the implementation back into the algorithm to work on it.

I think your question of Arc vs. .Net, Java, etc. may be a bit of a false dichotomy however. If I were writing a program, and to take Java as an example again, if there was some powerful Java library that I could use or some Java-based cloud computing environment would be useful to me, I wouldn't be thinking "OK, so should I use Arc or use Java?" Instead I'd be calling the Java library from Arc, or running Arc inside of the Java-based cloud computing environment.

There is some overhead to using Arc, it is slower than other languages so you may find that you need to work on optimization sooner than you otherwise would; calling a e.g. Java library from Arc can be less convenient than simply calling the library from the same language it's implemented in.

So for any particular project I think it comes down to a cost/benefit analysis. When I'm in a "known problem, known solution" kind of situation where I just need to crank out some code to get something done, I often will just grab Perl or Java or Python, whatever tool happens to be quickest to implement the particular task in because of the libraries the language has available or the environment it runs in. I'll probably end up writing some "boilerplate" type code, but I'm only writing it once and I know what to write, so I don't care all that much.

1. Why Lisp? 2. Given Lisp, why Arc?

Given your background, I think what you're asking is mainly question 1. Here's a few answers to Why Lisp? I use Lisp because it's closer to the way I think. It allows me not to have to worry about variable types. [0] It has integers that aren't bounded. [1] There's a REPL. [2]

Now, given Lisp, why Arc? I like Arc because, although I haven't tried out a lot of Lisps (I'm only on chapter 7 of ANSI Common Lisp, so I'm just learning), it seems concise. I like that it's evolving, and I like pg's goal of trying to make shorter programs. I don't like how long keywords are in many Lisps. Arc is a good Lisp getting better.

[0]You can assign types to variables in Lisp, but this only needs to be done for speed.

[1]My friend and I talk about Project Euler often. He's using C; I'm using Arc. I've never had to worry about integer overflow. He's had to use a 200-cell array of integers to simulate a 200-digit number, and he's had to write his own operators to add, subtract, multiply, and divide these arrays.

So I understand that Arc is meant to be a truly Dynamic Language, with the ability to quickly create code to produce or work on some outcome.

I live in a data centric world. So the heart of the software that I always work on, lives in the database or data layer.

Then processes are developed in order to govern, manage and act on that data.

These processes then must eixsts and operate in a way to take and deliver to businesses the ability to work and make use of their data to achieve their desired goals.

What has drawn my interest to Arc and also actually F# (.Net) is Organic Programming or Organic Development.

The idea is this.: Take and development a Business solution, in a non-traditional way, to where the code, data, and processes operate in a more biological fashion. In a more organic nature.

So for example how Cells in a body store information, how they replicate and send information, and how the master set of that information resides, and how processes attach to that data, operate on that data, and then the processes go away... repeat, repeat, etc. etc.

With the onset of Cloud Computing platforms, I believe we have the possibilitiy of doing just that.

I believe at the heart of such a thing, is a true Dynamic Language, that is not compile centric, but Dynamic, Reflective, and gives the ability to adapt.

So these my interest, now the problem I see with say Arc is how to make use of that in a Google.com AppEngine, or a Microsoft Azure Platform.

It seems I can make use of F# with .Net, but I am always looking for the next possible wave or thing, and it seems that Arc could have a chance...

What are your thoughts on these matters?

As you can see I am approach this from an Architect level, once you can see the puzzle, the pieces are easily put into place.

Why?

You can run Arc on a virtual server for $7/month. Less than the price of a pizza.

If there was some one thing that could only be done inside Google AppEngine or Microsoft Azure, write a little bit of native code (Python or F#) to do it inside the platform, and then have your Arc server connect to it to do that task.

So you make a good point as to how Arc can run in the cloud. I guess Arc could fit best in a platform stack like a cloud version of LAMP... somethng of that nature.

Amazon is hosting MySQL Database Services in the cloud, so you could take and have that as your database, and Arc make use of that.

Still what I am seeing though, and what I am running into from an Architect, design point of view, is fitting Arc into the puzzle.

I am trying to see if Arc gains me anything, in achieving what I laid out, with a more Organic approach, reflective nature for a system of record or business platform, that would allow a more organic, dynamic solution.

What I see though, is having to have Arc run on a seperate platform, or at least on-premise at the client, in a seperate platform, than the core data and solution run on.

That may be fine, but what I am trying to really get at, is what will Arc offer me, over using F# as my Dynamic Language, for example. To give that reflective, Dynamic, Organic in nature Functional development of a system of record or a business platform.

That's what I am trying to see... what would be the case I would make, that would bring Arc into the answer.

I am asking to, in way because I would really like to try and find a valid use for it, and follow it development, and contribute to it's development and growth as a language.

But if it comes down, to it's another Dynamic Language, it's hard for a business then to commit resources to learning it, making use of it, and deploying or employing it's use.

See what I am getting at?

And I offer all comments on that matter, because I am very interested at what Arc can possibly bring. I am looking for what all that could, is, and might be.

First, do you like Arc? Do you read the tutorial (http://ycombinator.com/arc/tut.txt) and say, "Oh, yes, this a language I want to program in"?

Second, are you in a "known problem, known solution", "known problem, unknown solution", or a "unknown problem, unknown solution" situation? Do you know yet exactly what it means for you for data to be "organic" or "dynamic"? Arc is an excellent language for prototyping, sketching out ideas, trying things out. In a day you could make a small web application that stores and retrieves data, and you could try one one "dynamic" or "reflective" thing and see what you thought of it when you tried it out for real.

Third, are you offering SaaS, software-as-a-service, as for example how Salesforce does? That is, are you storing your customer's data for them? Now you can use whatever server language you want, your customers won't know or care. If Arc gives you a competitive advantage because of its flexibility, you can go ahead and use Arc.

And, by the way, I wouldn't start off using MySQL to store data. Just keep it all in memory backed by files on disk. SQL databases are good at quickly looking up records on computers that don't have very much memory, but they aren't particularly "dynamic" or "organic".