Earlier quoted context omitted.
Agreed about linked lists; that virtually all functional languages make them the default/literal data structure is IMO a poor practical design choice (no matter how theoretically elegant) and is the primary culprit for their reputation for slowness. And the tendency for functional compile-to-JS langs to emulate linked lists in Javascript and keep them the default data structure is downright laughable.
(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…
Say you have (pseudocode)
Array(4 16 5 20)
What's its type? Array
Array
Array
Array
Array(Int Int Int Int)
None of these lend themselves easily to paradigms other than imperative, true. But this is because they unnecessarily discard known information. The type of an array ought to be itself: assert Array(4 16 5 20) hasType Array(4 16 5 20)
=> Ok
assert Array(4 16 5 20) hasType Array
=> Error("Expected Array but got Array(4 16 5 20). Hint: Typeclass Array cannot be directly instantiated")
assert Array(4 16 5 20) hasTypeclass Array
=> Ok
Fully functional and referentially transparent.