Short version:

This. Very this. I think Arc's smallness is a Good Thing.

---

Long version (do I have too much spare time on my hands...?):

The funny thing is, when I first started programming in Arc, I had almost no Lisp experience, and almost no functional programming experience either. Sure, I knew lambdas and closures (due to my JavaScript experience), but I didn't write my JavaScript in a very functional style. I kinda sorta understood the concept behind recursion, but when I tried to read a program written in recursive style, I didn't understand it and my brain hurt.

Yet, I was able to start writing programs in Arc... and anytime I had a question like, "I wonder how that function works", I could just look in arc.arc and see for myself. Despite all the limitations described above, I didn't have a very hard time learning Arc. After a short while (maybe 2 days or so), I had even started to get into the "rhythm" of Arc, reading and understanding code by it's context, rather than having to parse each individual node. I even forced myself to learn to read recursion a bit better.

I thought this was astonishing. Being able to pick up and quickly learn and use a language and paradigm that I had almost no experience with, just by reading the language itself. It was like how a baby learns to speak a language, except I'm not a baby, so I don't have that magical ability anymore. I didn't have that experience with Python. I could pick up and use Python because it was similar to JavaScript (both tend to emphasize imperative/procedural style), but I'm still constantly looking up how to do things in the Python documentation...

And then there's Racket. Racket has a large amount of documentation, and they even have a search engine to trawl through it and find what you want. Yet I still have a hard time figuring out what a function does, even though they give me what parameters the function expects, what value the function returns, a brief description of what the function does, and sometimes even examples!

I find Arc easier to learn and use, despite (or perhaps because of?) it's philosophy that "code is the spec". In a sense, I think being smaller is better for exploratory programming. Having a nice, robust, stable language with tons of well-written big libraries is great for writing robust programs. But I think a lot of that just gets in the way when you want to fool around and experiment.

In that situation, I think you're better off axiomitizing things as much as possible. Lisp does that by (over?)emphasizing lists, and then having a bunch of functions that operate on lists. You can then go in later and change the datatype to a hash table or whatever, once the program is in a more complete state.

It's easier to add things, than it is to take things away. Lua wins not because it can do everything, but because it's small, and smallness is good in embedded languages. I think Arc wins for a similar reason: it's small. I think it'd be a lot harder to evolve that kind of smallness in an existing language, compared to starting with a clean slate.

Oh yeah, maybe it would help if you thought of Arc as being more of a thin skin on top of an existing language (like Scheme). This is actually true in pgArc, Anarki, and ar, because they let you access the underlying Racket functions. So you get the niceness of Arc by default, but you can tap into Racket's libraries when you need to.

I also plan to eventually do the same thing with Arubic... allowing Arc programs to import and use Python libraries. And if I recall correctly, jarc and rainbow also let you call into Java's libraries. And then wart, which I assume lets you call CL functions.