Исправление
vertexua,
(текущая версия)
:
Вот посмотришь на Лисп, сразу видно УГ, в первую секунду. Но ведь так нельзя, потому нужно
Итог Лисп - ЯП, который получил удобные фичи забесплатно путем введения УГшной нотации s-выражений. Фичи некоторые хорошие, символические манипуляции, макросы, но они все равно не переплевывают совершенно не пригодный к completion дизайн ЯП. Те кто считают что IDE не нужны или упоролись или писали проекты <2000 cтрочек. Лисп почти непригоден потому что в нем функции, а не методы объекта. Тоесть после списка не ставится точка или другой символ, который бы дал знак IDE чтобы отобразить методы, которые могут быть применены к объекту. Вместо этого если не знаешь всех функций, которые применимы к твоему объекту, то идешь читать документацию фактически на каждую функцию, которую не знаешь. Как можно не замечать такой мелочи, которая ускоряет программирование в разы и делит ЯП на два лагеря. Фимоз лиспоидов продолжается тем, что при наличии спецификаторов типов в Лиспе они не популярны, наверное потому что засоряют и без того нечитабельный код.
От ЯП веет стариной, сейчас бы так точно не делали. Костыли, нагромождения, неочевидность поведения. Если ООП в Java сравнивать с космическим кораблем без туалета, в Scala - с космическим кораблем-трасформером, то в CLOS - тоже корабль, который даже летает, но из дерева и надо запасаться скотчем. Пользоваться комбинаторами явно ну уж совсем болезненно. Хотя нужно признать, что когда они нужны, то в других языках для этого используется AOP фреймворк. Множественная диспетчеризация в рантайме достигается например в Scala паттерн матчингом, в котором еще можно условий напихать. А потом еще комбинировать partial functions
Ну и вдобавок код плохо читаемый из-за однородности синтаксиса. При всем том, что его однородность тоже не на 100% ;)
Вот фича рестартов вообщем полезна. Почему бы не реализовать ее в нормальном ЯП.
Исходная версия
vertexua,
:
Вот посмотришь на Лисп, сразу видно УГ, в первую секунду. Но ведь так нельзя, потому нужно
Итог Лисп - ЯП, который получил удобные фичи забесплатно путем введения УГшной нотации s-выражений. Фичи некоторые хорошие, символические манипуляции, макросы, но они все равно не переплевывают совершенно не пригодный к completion дизайн ЯП. Те кто считают что IDE не нужны или упоролись или писали проекты <2000 cтрочек. Лисп почти непригоден потому что в нем функции, а не методы объекта. Тоесть после списка не ставится точка или другой символ, который бы вызвал методы, которые могут быть применены к объекту. Вместо этого если не знаешь всех функций, то идешь читать документацию фактически на каждую функцию, которую не знаешь. Как можно не замечать такой мелочи, которая ускоряет программирование в разы и делит ЯП на два лагеря. Фимоз лиспоидов продолжается тем, что при наличии спецификаторов типов в Лиспе они не популярны, наверное потому что засоряют и без того нечитабельный код.
От ЯП веет стариной, сейчас бы так точно не делали. Костыли, нагромождения, неочевидность поведения. Если ООП в Java сравнивать с космическим кораблем без туалета, в Scala - с космическим кораблем-трасформером, то в CLOS - тоже корабль, который даже летает, но из дерева и надо запасаться скотчем. Пользоваться комбинаторами явно ну уж совсем болезненно. Хотя нужно признать, что когда они нужны, то в других языках для этого используется AOP фреймворк. Множественная диспетчеризация в рантайме достигается например в Scala паттерн матчингом, в котором еще можно условий напихать. А потом еще комбинировать partial functions
Ну и вдобавок код плохо читаемый из-за однородности синтаксиса. При всем том, что его однородность тоже не на 100% ;)
Вот фича рестартов вообщем полезна. Почему бы не реализовать ее в нормальном ЯП.