How about K? It's a functional, "clean minimal core" APL with ragged arrays and lambdas. Lisp-influenced, but much less Lispy than one would expect if it's "impossible for people who know Lisp to design a language that isn't Lisp(y)".
"I much preferred implementing and coding in LISP (sic), but once I was dealing with big data sets and then having to do fairly simple calculations, APL just seemed to have the better vocabulary." - Arthur Whitney (http://cacm.acm.org/opinion/interviews/26246-a-conversation-...)
You just supported my arguments, silentbicycle; it's "much less Lispy" but not "orthogonal to Lisp". Small, expression based, self-hosting, declarative, has a core-data structure it uses to represent most of its input ..
APL, Forth, and Smalltalk might not be proper functional programming languages, but they're of the same "spirit".
Now compare this to something horribly broken, like Basic ..
I suspected as much. "Lispiness" is a fuzzy concept, though - Lua is Lispier than Python, but is Tcl more or less Lispy than SML? Etc. K is probably the least Lispy language I can think of with that pedigree.
Joy may be another exception, but it's mainly an experimental / research language.
Some Lisps are more Lisp than others; compare Dylan to Emacs Lisp. Dylan has that refined taste, that well-thought out essence, even if it's an infix, algolish language in apperance. While elisp is an orthodox Lisp, in every sense, and is unpalatable because of its true-to-form "Lispiness".
There are languages that are semantically consistent, and that's probably what I meant by "Lispy". Then there are languages which are nothing but compiler hacks; you can tell whoever dreamed them up "grew" this hairball by tweaking a parser until it did something he wanted.
Also, take a look at the Lua 5 compiler. That fucker does matrices on par with Fortran, with just 500k worth of compiler + runtime!
I particularly loved their hack for sparse matrices; they're implemented as hash-tables where the indices are zero-based integers, so only the indices that are initialized are created. Meaning, you can have an array with a few indices without having to create all the empty cells in between. I benchmarked it and it's far more than adequate. Makes graph algorithms breezy.
Each table (dict, hash, whatchamacallit) has a hash portion and an array portion, and contiguous integer keys are stored internally in the array. So, tables automatically adapt their internal implementation for use as an array, a dict, or both, at runtime. They're unique to Lua, AFAIK.
It also has an interesting hash table optimization (that I don't quite grok). I've been reading through the Lua code bit by bit, but haven't made it there yet. Lots of other interesting stuff, though.
LuaJIT's not too shabby, either!
Lua's my favorite language for quick hacks, period. I wrote a library to add fairly idiomatic pattern matching (http://github.com/silentbicycle/tamale/). Every language needs pattern matching. :) I'm still working on explaining PM to people who aren't already into Erlang or ML, but it's documented now.
"I much preferred implementing and coding in LISP (sic), but once I was dealing with big data sets and then having to do fairly simple calculations, APL just seemed to have the better vocabulary." - Arthur Whitney (http://cacm.acm.org/opinion/interviews/26246-a-conversation-...)