> If you write your own malloc and free like that ... you're responsible for safety as well (e.g. use after free bugs) which LISP will no longer protect you against.
That's right. There's no such thing as a free (no pun intended) lunch.
> (by the way, writing a performant, bugfree, concurrent malloc and free is not that easy :)),
The reason it's hard to write a malloc for C is that it has to manage variable-length blocks.
> That's not to mention that LISP has to interact with C on a regular basis for things like system calls, and comes with a runtime that prevents it from playing nicely as an embedded library
No, that's just wrong. There's nothing about Lisp that prevents it from being implemented as an embedded library, e.g.:
> You could probably argue that some of the above problems could be mitigated if everyone adopted SBCL as the standard
No, I'm saying use the right tool for the job. If you really need every last bit of speed and you don't care about safety or engineering cost then by all means use C or C++. But if you want safety, reliability, and the sort of run-time dynamism described in the original article you're better off using Lisp or its progeny.
I'm also saying that if you want performance and you also want to use Lisp, you can. But at the end of the day there are fundamental tradeoffs in computing between speed, safety, dynamism, and engineering cost that no language will save you from.
There are many contexts in which your malloc won't perform well, and many more where it will fall over in a concurrent environment (unless LISP uses atomic operations and locks by default, in which case you have much bigger performance problems to worry about). Concurrency without garbage collection is nontrivial, though I don't blame you for not thinking about it all that much if you rarely interact with such languages. It's great to learn about some of LISP's better-performing utilities (push and pop for example) but let's not get carried away. Also, allocating fixed-length blocks of memory is a perfectly reasonable allocation strategy in C.
> No, that's just wrong.
From the link, embeddable common LISP comes with a runtime, which makes it inappropriate in many contexts. I didn't say that LISP couldn't interact with C (obviously it can!) only that it's not particularly convenient. From the link, it supports inline C, which is great, but again you're not really using LISP at this point.
> No, I'm saying use the right tool for the job.
Oh, sure, I don't think we're disagreeing on that. Certainly most of the prominent Rust developers will immediately point you to a language like Haskell, Nimrod or Python if they will satisfy your usecase. It's just that some of your posts suggested that you think LISP could in principle be used in all the places C++ is used, which I don't think is necessarily true, and certainly it wouldn't be convenient to do so. For people who do have to use C++, I think these LISPy features are a nice way to make the experience more tolerable, and I think that's all the article was getting at.
Good point (but you have that problem in any language). However, PUSH conses, so my code is wrong in that regard (you have to use a pre-allocated free vector, not a free list). So I concede the point: writing your own allocator in Lisp is not trivial. But it can be done.
That's right. There's no such thing as a free (no pun intended) lunch.
> (by the way, writing a performant, bugfree, concurrent malloc and free is not that easy :)),
It's pretty easy, actually:
(defvar free-list)
(defun initial-malloc (n) (dotimes (i n) (push (cons nil nil) free-list)))
(defun my-cons (car cdr) (setf (caar free-list) car (cdar free-list) cdr) (pop free-list))
(defun free (cons) (push cons free-list))
The reason it's hard to write a malloc for C is that it has to manage variable-length blocks.
> That's not to mention that LISP has to interact with C on a regular basis for things like system calls, and comes with a runtime that prevents it from playing nicely as an embedded library
No, that's just wrong. There's nothing about Lisp that prevents it from being implemented as an embedded library, e.g.:
http://en.wikipedia.org/wiki/Embeddable_Common_Lisp
> You could probably argue that some of the above problems could be mitigated if everyone adopted SBCL as the standard
No, I'm saying use the right tool for the job. If you really need every last bit of speed and you don't care about safety or engineering cost then by all means use C or C++. But if you want safety, reliability, and the sort of run-time dynamism described in the original article you're better off using Lisp or its progeny.
I'm also saying that if you want performance and you also want to use Lisp, you can. But at the end of the day there are fundamental tradeoffs in computing between speed, safety, dynamism, and engineering cost that no language will save you from.