I think Arc is perfect for what you want - it was designed from the ground-up for "exploratory programming". Arc not only preserves its Lisp roots "under the hood", it also captures the spirit of Lisp, IMO. It clears away what I consider to be syntactical pollution in, say, Common Lisp.
Lisp has a bad reputation for being difficult; the most difficult thing about Lisp is the concept of quotation (and quasi-quotation). At the REPL (http://tryarc.org/):
> (list 1 (+ 1 1) 3)
(1 2 3)
This list contains a sub-list - (+ 1 1) - which is itself evaluated to give the final list that Arc returns.
> (list 1 '(+ 1 1) 3)
(1 (+ 1 1) 3)
Putting a single-quote in front of the sub-list causes the interpreter to not evaluate that list but, instead, to return it in quoted form, exactly as-is.
> '(list 1 (+ 1 1) 3)
(list 1 (+ 1 1) 3)
We can quote the whole list if we like, in which case, the whole list is returned as-is. Quotation is "blocking", that is, once the interpreter hits a single-quote, it stops evaluating the quoted list and any sub-lists within it.
> `(list 1 (+ 1 1) 3)
(list 1 (+ 1 1) 3)
The back-tick is the quasi-quote operator and has a similar effect as quote when applied to a whole list. However, it acts differently when we apply the unquote operator (comma) to sub-lists:
> `(list 1 ,(+ 1 1) 3)
(list 1 2 3)
Here, the whole list was quoted but the interpreter did not stop traversing the list, searching for unquoted lists. When found, the unquoted list was evaluated.
Keeping track of exactly when/where you need to use quotation or quasi-quotation can sometimes be challenging. Everything else about Lisp is completely straightforward, that is, no more difficult than any other, more common, language.
I'd describe myself as a bottom-up thinker. [But I'm unopposed to the description "top-down" because . . . "which way is up?"] I like to work from axioms to outcomes. I'm frustrated under other conditions.