Хорошо, в этом примере всё выглядит ОК.
А как быть в таком случае: у нас есть программа, которая использует Хабр, как источник данных о людях. Она получает N видов данных (например, список записей в блог, список друзей, профиль, ...) и может сделать это несколькими путями (через REST API, прямо через HTTP — scraping, а также из собственного кеша), и к тому же запрос может делать по id пользователя (число) или его имени (строка). Как видите, концептуально имеет полиморфную функцию get_data(kind, source, user), которая может менять поведение в зависимости от каждого из своих параметров. Как бы вы это выразили с помощью интерфейсов (да и, вообще, классического ООП), например, в том же C#?
А программа — это не обрабатываемая компилятором информация?
А что по вашему приведенный пример? Если это чистые данные, то где же закодированна логика работы Ant'а? Как он решает, что ему нужно сделать: заархивировать или разархивировать?
В двух словах, что я хотел сказать: если не создавать иерархий, то не будет полиморфизма в ООП.
Согласен, что, строго говоря, не верно. Можно реализовывать один интерфейс, можно наследовать только от одного базового класса, куда запихнуть все нужные методы и тоже самое будет. (Т.е. будет вырожденная иерархия из двух уровней). Но так ведь не получается.
Далее, чтобы получить всего-лишь 1 полиморфную функцию, нужно создать:
1. интерфейс
2. класс, который этот интерфейс реализует
3. инстанциировать этот класс
В целом, конечно, интерфейсы — это гораздо лучше класс-методов, но в чистом виде то никто так не делает: комбинируют и то, и то, правда же? (И интерфейсы, кстати, тоже наследуются, так что и тут иерархии создаются). А ведь полиморфизм в чистом виде — это разное поведение функции в зависимости от типов входных параметров (или каких-то еще критериев). Причем здесь интерфейсы/классы?
Знаете, на Lisp'е пишу почти каждый день. В то же время не скзал бы, что есть языки, которые мне противны.
Ну а почему вам софт-код на Lisp'е не понятен — вы же сами дали объяснение (опыт). И еще: быдлокод — он для маленьких задач (которые можно уместить в один файл) часто понятен, поскольку сразу видно ход мысли. Но вы же так не будете писать хоть что-то серьезное (я надеюсь :) И опять мы приходим к критериям хорошего кода. Для серьезных задач — это будет не возможность написать в лоб что-то, а возможность четко разделить интерфейс и реализацию, механизм и политику, возможность абстракции, отсутствие boilerplate, отсутствие нерегулярной ad hoc базы и т.д. По этим критериям Lisp даст фору любому языку.
Понятно, что Unix написан на С. А о его принципах можете почитать здесь: www.faqs.org/docs/artu/ch01s06.html Это я к тому, что слабая связность — это не фантастика.
Есть где-то даже исследования на этот счет. (Вот есть какая-то: chayden.net/eliza/Eliza/ Как-то не вериться, что там только 150 строк кода...)
Ну а на Lisp'е не до фига (не считая названных мною Lisp-машин, которые были 20 лет назад). А вы знаете, кстати, какое-то приложение на миллион строк на Javascript, или на Ruby, или даже на Python? Тем не менее, очень полезные языки, не находите?
Я привел ссылку на Yegge. Поищите в интернете по чему-то типа «big project fail oop» :)
Слабосвязные системы — это не научная фантастика. На этом принципе построен Unix (в некоторой мере).
Простите, если не понятно написал. «Не привязанному к иерархиям классов полиморфизму». Это о том, что полиморфизм в ОО-языках (читай C++, Java) не существует отдельно от наследования (будь то через механизм интерфейсов как в Java, или абстрактных классов (это в хорошем случае), или же простого наследования, которое повсеместно для это используется (в не очень хорошем случае)). Если ОО-язык отказывается от концепции наследования, то он теряет и полиморфизм. Не согласны? Как на счет примера Javascript?
Да нет, я заявляю, что Lisp намного понятнее (но не пытаюсь вас в этом убеждать: переубеждать кого-то — глупое занятие). Если вы хотите сделать это предметным спором, а не просто высказыванием своих убеждений, нужно сначала определить критерии «понятности», «хорошести» и т.д., о чем я вас попросил ниже. Разумеется, по некоторым критериям Lisp не будет понятным (например, по критерию наличия фигурных скобок ;)
Несколько сот тысяч строк — это должно быть что-то очень серьезное — эквивалент нескольким миллионам строк на C/Java/… За всю историю таких только несколько было, например известная система для компьютерной алгебры Macsyma (многие ученые прекрасно работают с ней и сейчас). Ну, все что было написано для Lisp-машины — это, явно, миллионы строк кода, но о них сейчас говорить не принято, потому как никто попробовать не может и сравнить (тем не менее Lisp-машины работали около 10 лет в очень многих научных учреждениях, проектных бюро и т.д., что доказывает, что на то время эта технология была вполне конкурентноспособна). Из современных примеров — QPX (http://itasoftware.com/solutions/qpx.html). Эта самая лучшая в мире система расчета цен на авиабилеты и стыковки маршрутов.
Жаль того несчастного, кому пришлось это писать. Но причем здесь Lisp? Можно с таким подходом и в Jave нагородить что-то подобное (только займет это, наверно, 10 экранов: представляете 10 вызовов Java-функций в одной строке?)
А не могли бы выложить Элизу на какой-то нормальный ресурс (paste.lisp.org)? А то не грузиться. Тем временем можете посмотреть на нормальную ее реализацию: norvig.com/paip/eliza.lisp
Вас, наверно, удивит, но самая распространенная SDK в мире — это Emacs (если сомневаетесь, то посчитайте, сколько людей пользуется им из книги Coders at Work. Около 10ка. Или вы скажете, что те люди, которые написали Unix, BitBlt и Firefox — это не реальный мир?)
Далее, если говорить о применимости Lisp'а в корпоративной среде (да и в целом в типичных задачах, с которыми сталкиваются большинство программистов), то вы зря делаете такой акцент на списках. Списки — это очень базовая вещь. Все нормальные современные языки прекрасно их поддерживают (взять тот же Python). Возможность Lisp, которые позволяют бороться со сложностью крупных систем (против которых, как уже показала практика, ООП-подход бессилен) — это возможность создания многослойных слабосвязанных систем за счет проблемно-ориентированного программирования (прежде всего на основе макросов) и не привязанного к необходимости городить иерархии классов полиморфизма.
Рекурсия — это одна из стратегий вычисления. Вы что, никогда рекурсию в С не использовали? Причем здесь Lisp? Так же само, как инкапсуляция — это абстрактная концепция, которую можна реализовать множеством способов. Когда мы говорит о языке программирования общего назначения, то такой язык должен позволять задействовать любые стратегии вычисления, реализовать любые не взаимопротиворечивые концепции. Common Lisp это позволяет сделать.
Ну а читаемость программы не должна в общем-то зависить от количества строк в ней: вы же читаете ее потоково, по нескольку строк, а не сразу 300, которые на экране не умещаются ;) Читаемость зависит от порядка в голове у того, кто программу написал.
А как быть в таком случае: у нас есть программа, которая использует Хабр, как источник данных о людях. Она получает N видов данных (например, список записей в блог, список друзей, профиль, ...) и может сделать это несколькими путями (через REST API, прямо через HTTP — scraping, а также из собственного кеша), и к тому же запрос может делать по id пользователя (число) или его имени (строка). Как видите, концептуально имеет полиморфную функцию get_data(kind, source, user), которая может менять поведение в зависимости от каждого из своих параметров. Как бы вы это выразили с помощью интерфейсов (да и, вообще, классического ООП), например, в том же C#?
А что по вашему приведенный пример? Если это чистые данные, то где же закодированна логика работы Ant'а? Как он решает, что ему нужно сделать: заархивировать или разархивировать?
Согласен, что, строго говоря, не верно. Можно реализовывать один интерфейс, можно наследовать только от одного базового класса, куда запихнуть все нужные методы и тоже самое будет. (Т.е. будет вырожденная иерархия из двух уровней). Но так ведь не получается.
Далее, чтобы получить всего-лишь 1 полиморфную функцию, нужно создать:
1. интерфейс
2. класс, который этот интерфейс реализует
3. инстанциировать этот класс
В целом, конечно, интерфейсы — это гораздо лучше класс-методов, но в чистом виде то никто так не делает: комбинируют и то, и то, правда же? (И интерфейсы, кстати, тоже наследуются, так что и тут иерархии создаются). А ведь полиморфизм в чистом виде — это разное поведение функции в зависимости от типов входных параметров (или каких-то еще критериев). Причем здесь интерфейсы/классы?
<gunzip dest=".">
<url url=«example.org/archive.tar.gz»/>
</gunzip>
Пока что ограничиваюсь статьями
* берем для примера первую же Ant Task из мануала (http://ant.apache.org/manual/CoreTasks/unpack.html):
/>
Объясните мне тогда, что же такое эта слобая связанность, будьте добры…
Ну а почему вам софт-код на Lisp'е не понятен — вы же сами дали объяснение (опыт). И еще: быдлокод — он для маленьких задач (которые можно уместить в один файл) часто понятен, поскольку сразу видно ход мысли. Но вы же так не будете писать хоть что-то серьезное (я надеюсь :) И опять мы приходим к критериям хорошего кода. Для серьезных задач — это будет не возможность написать в лоб что-то, а возможность четко разделить интерфейс и реализацию, механизм и политику, возможность абстракции, отсутствие boilerplate, отсутствие нерегулярной ad hoc базы и т.д. По этим критериям Lisp даст фору любому языку.
Ну а на Lisp'е не до фига (не считая названных мною Lisp-машин, которые были 20 лет назад). А вы знаете, кстати, какое-то приложение на миллион строк на Javascript, или на Ruby, или даже на Python? Тем не менее, очень полезные языки, не находите?
Слабосвязные системы — это не научная фантастика. На этом принципе построен Unix (в некоторой мере).
Простите, если не понятно написал. «Не привязанному к иерархиям классов полиморфизму». Это о том, что полиморфизм в ОО-языках (читай C++, Java) не существует отдельно от наследования (будь то через механизм интерфейсов как в Java, или абстрактных классов (это в хорошем случае), или же простого наследования, которое повсеместно для это используется (в не очень хорошем случае)). Если ОО-язык отказывается от концепции наследования, то он теряет и полиморфизм. Не согласны? Как на счет примера Javascript?
Единственная ремарка: ваше приложение занимает 700 строк кода, а у Норвига — 200.
А не могли бы выложить Элизу на какой-то нормальный ресурс (paste.lisp.org)? А то не грузиться. Тем временем можете посмотреть на нормальную ее реализацию: norvig.com/paip/eliza.lisp
Далее, если говорить о применимости Lisp'а в корпоративной среде (да и в целом в типичных задачах, с которыми сталкиваются большинство программистов), то вы зря делаете такой акцент на списках. Списки — это очень базовая вещь. Все нормальные современные языки прекрасно их поддерживают (взять тот же Python). Возможность Lisp, которые позволяют бороться со сложностью крупных систем (против которых, как уже показала практика, ООП-подход бессилен) — это возможность создания многослойных слабосвязанных систем за счет проблемно-ориентированного программирования (прежде всего на основе макросов) и не привязанного к необходимости городить иерархии классов полиморфизма.
Ну а читаемость программы не должна в общем-то зависить от количества строк в ней: вы же читаете ее потоково, по нескольку строк, а не сразу 300, которые на экране не умещаются ;) Читаемость зависит от порядка в голове у того, кто программу написал.
* steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html