Makale, Lisp tabanlı editörlerin (örneğin Lem) "100% Lisp" olmasının getirdiği iddia edilen üstün genişletilebilirlik argümanını sorguluyor. Bu tür editörlerin tamamen Lisp ile yazılmış ve Lisp ile scriptlenebilir olmasının, onları son derece özelleştirilebilir kıldığı yaygın bir inanıştır. Ancak yazar, bu argümanın bazı önemli noktaları gözden kaçırdığını belirtiyor. Yazar, Emacs gibi editörlerin sunduğu derinlebilirlik seviyesinin (örneğin, font ligatürlerini programlama, keyfi kodlama sistemleri tanımlama veya yeni satır karakterini geçersiz kılma gibi) sadece "100% Lisp" olmaktan çok daha fazlasını gerektirdiğini öne sürüyor. Bu tür "sıra dışı" özelliklerin genellikle sistemin Lisp olmayan %10'luk kısmına dayandığını ve gerçek genişletilebilirliğin bu karmaşık etkileşimlerde yattığını vurguluyor. Yazar, "100% Lisp" gibi bir kavramın pratik dünyada var olmadığını savunuyor. Steel Bank Common Lisp gibi Common Lisp runtime'larının bile iş parçacığı yönetimi, işletim sistemiyle arayüz oluşturma veya assembly kodu kullanma gibi nedenlerle tamamen Lisp ile yazılamadığını belirtiyor. Grafiksel editörler gibi GUI programları için de durum farklı değil; font yedeklemesi, giriş yöntemleri ve ekran okuyucuları gibi özellikler, platforma özgü API'lerle etkileşimi gerektirir. Foreign Function Interface (FFI) bu platforma özgü etkileşimleri bir dereceye kadar "saf" tutmaya yardımcı olsa da, genişletilebilirliği bu sınırların ötesine taşıyamaz. Modern uygulamaların işletim sistemiyle, donanımla ve çeşitli kütüphanelerle etkileşime girmesi gerektiğinden, tamamen "saf" bir program yazmak imkansızdır. Bu durum, genişletilebilirliğin sınırlarını belirler ve "100% Lisp" argümanının yüzeysel kaldığını gösterir.
Yazılım geliştirme ve sistem tasarımında genişletilebilirlik kavramının derinlemesine anlaşılması gerektiğini vurgular.