... and that aren't really that important, such as displaced arrays.
Ah! About a month ago, I would have agreed with this. Then, I realized that they are indispensable if you want a routine to compare the elements of 2 arbitrary arrays.
Code: Select all
(defun array-equal (array1 array2 &key (test #'number-equal))
"Return true if the elements of the array are equal."
(when (equal (array-dimensions array1) (array-dimensions array2))
(make-array (array-total-size array1)
:element-type (array-element-type array1)
(make-array (array-total-size array2)
:element-type (array-element-type array2)
I won't even insult you with the code I was using prior to this. I realize this may not be the "fastest" implementation, but it is getting the job done at the moment and I can always optimize later if necessary.
Which kind of sums up why I'd just as soon embrace the "Fundamental problems with the Common Lisp language", they're not inhibiting me from solving my problems. There are many parts of the language that I don't use, but as I've used it more, I've started to realize why those concepts are there. The current example is LOOP. I've avoided LOOP and found ways to use DOLIST, DOTIMES, DO and DO*. Recently, I kept finding myself using DO and friends in a unaesthetic manner and the rationale for LOOP clicked. Now I need to go learn LOOP. I'm realizing that the number of concepts in CL is beneficial.
I don't have enough knowledge to know if "hard to compile" is an insurmountable problem. Maybe "too much memory" can be solved with ECL http://ecls.sourceforge.net/
or something like L http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
"Unimportant features that are hard to implement" seems like a combination of "Too many concepts" and "Hard to compile efficiently", so I don't quite see how that is a separate problem from the previous problems.
"Not portable" is a problem that isn't a problem. It is a problem if portability between implementations is your goal. It isn't a problem if portability between systems is your goal. But portability between systems might be a problem if you choose an implementation that isn't portable. Luckily, there are several implementations available so you can choose one that fits your problem.
"Archaic naming" is a non-issue because CL has "Too many concepts", so you don't have to use the "Archaic naming". I'd like to take this opportunity to suggest starting an annual Common Lisp programming challenge along the lines of the "Obfuscated Code Contest" called the "Archaic Code Contest".
"Not uniformly object-oriented" has actually been a problem for me. But, compared to the conceptual limitations that I've hit my head against in other languages, I can live with it.
Sometimes I think the "Fundamental problem with Common Lisp" is that it is just good enough to enable us to envision the "perfect" programming environment, but not bad enough to motivate us to define and implement it.