Не проснулся ещё? У этого треда есть два явных и взаимозаменяемых «маркера»: ник автора и слово «Lisp» в заголовке. Любой из этих маркеров с огромной вероятностью указывает на то, что в треде рассказано о каком-то маргинальном «ненужно».
Я думал, на этом будут аргументы по-конкретнее, как от человека который реально на практике сравнивал обе альтернативы. По такой логике и MS Wondows должны быть более вылизан.
В LW отладчик умеет несколько больше чем Slime. А что умеет встроеный в SBCL вооббще никому не интересно из-за ограниченности интерфейса:(
А никому не известная библиотчка fast-io где-то в 30 раз быстрее «стандартной» обертки дефакто flexi-streams. А то что встроено в SBCL не умеет newline отличных от юникса и ... ну вы поняли зачем fast-io. Все по стандарту, все опенсорс и собственно ... сношайся как хочешь - инструменты ведь дали:( Коммитерам SBCL важен компилятор в некоторой части а IO из-за особеностей архитектыры уже по остаточному приниципу. Поэтому в бенчах SBCL на коне в жизни ... хм, бесплатный и ждет ваш код.
Cтроку очевидно не только читать но и write в правильной последовательности байтов надо:) А при чтении будет выпадать #\Linefeed портя логику работы. CCL как бывшая коммерческая реализация догадывается вот о таком моменте, а SBCL вот нет с момента рождения. А ближайшее решение flexy-streams вмесо стандартных потоков и про его скорость я уже говорил.
Поэтому в бенчах SBCL на коне в жизни … хм, бесплатный и ждет ваш код.
Мне вот интересно, они сделали что-нибудь со сборщиком мусора на x86, который всецело полагается на быстрые page faults? Он и так на больших объёмам данных был не шибко быстрый, а после двух лет приветов от Интела дешёвого в ядре для юзерспейса ничего не осталось.