5 ms·
His concern is valid, and while I think that we should never go back to C++ by breaking memory safety, he makes a good point. His languages are not expressive e
by jganetsk 17y ago
His concern is valid, and while I think that we should never go back to C++ by breaking memory safety, he makes a good point. His languages are not expressive enough to allow the programmer to do what he wants.
More languages maybe should have value types, like C#. Maybe they also should have linear types and/or uniqueness types.
Lots of mechanisms exist to enable aggressive (and scalable) memory management. There is no reason why we should just accept the current state of the art.
- mahmud 17y agoHis languages are not expressive enough to allow the programmer to do what he wants. His languages are Ruby and Common Lisp; dunno about ruby, but lisps allow you to have plenty of control over GC, up to and including turning it off, but usually the programmer knows better and uses something portable, like object pools, fixed containers in static memory areas, and destructive operations instead of fresh consing . The less portable options include: weak pointers, static-arrays, weak vectors, weak hashtables, finalizations, the last of which is a callback mechanism that lets you register a function to be invoked by Lisp before the object it's associated with is marked for GC. This is the GC docs for ACL 8.1: http://franz.com/support/documentation/8.1/doc/gc.htm http://franz.com/support/documentation/8.1/doc/gc.htm In SBCL, you can even allocate your object with C's malloc and free! That's right SB-ALIEN:MAKE-ALIEN and SB-ALIEN:FREE-ALIEN, you can also allocate objects in "foreign" space and tagged them yourself, so Lisp treats them as its own objects.