От: | Mamut | http://dmitriid.com | |
Дата: | 24.08.06 07:06 | ||
Оценка: | 41 (10) +1 |
К сожалению, я не смог стать частью "поколения Lisp" — весь мой опыт с этим языком заключается в в том, что я заставил свой emacs работать так, как мне надо. До сих пор Lisp для меня — величайшая тайна. Мне удалось раздобыть выкинутую кем-то книгу по Лиспу, написанную в 1982 году Уинстоном и Хорном (Winston and Horn). Что приводит меня в изумление — это те типы проблем, которые решались в конце 70-х. Из оглавения [1]:
Глава 18: Lisp in Lisp (Building an interpreter) 24: Symbolic pattern matching 26: Rule based expert systems and forward chaining 30: Procedure writing programs
и т.д.
Что меня волнует, так это то, что "старые" языки могли выполнять задачи, которые (как мне кажется) сложны или вообще невыполнимы в современных языках. Как так произошло, что все эти Java и C# потеряли все эти возможности, а называются "современными"?
Я заметил одну ОЧЕНЬ беспокоящую тенденцию в мире Java (к сожалению, одной ногой я глубоко увяз в грязном мире консультаций по Websphere). Такое впечатление, что люди обнаружили, что они могут модифицировать свой код не изнутри, а снаружи. Так, теперь можно написать кучу маленьких файлов XML, которые описывают поведения или что-то похожее. Эти файлы могут выглядеть вот так (взято с http://static.springframework.org/spring-webflow/docs/1.0-rc3/reference/flow-definition.html#flow-xml — из очень популярного фреймворка Spring для J2EE) :
<flow start-state="displaySearchForm"> <view-state id="displaySearchForm" view="searchForm"> <transition on="submit" to="processFormSubmission"/> <transition on="cancel" to="processCancellation"/> </view-state> ... </flow>
(Этот код описывает порядок выполнения (flow) веб-страницы, передающей куда-то данные). Проблема заключается в том, что XML *внешний* по отношению к коду, который на самом деле что-то выполняет, и не зависит от него. Но для меня это проблема, потому что код, отвечающий за выполнение, настолько тесно связан с этим кодом, что они на самом деле неразделимы. (Выше у вас может быть описана форма, содержащая три поля, и поэтому отправляющий код должен понимать эти три поля). Таким образом, для того, чтобы изменить поведение страницы, вам необходимо создать код, понимающий такое поведение... Поэтому поведение связано, *тесно* связано, с кодом, отвечающим за него. Не забывайте, что XML не компилируется и никак не проверяется, кроме как на правильность структуры, и могущие возникнуть проблемы нельзя никак определить до тех пор, пока вы его не протестируете или не развернете на сайте. В прошлом названия из кода выше были бы классами или экземплярами класса и компилятор мог бы сразу обнаружить ошибку. Теперь они потеряли эту немаловажную возможность.
Кажется, что им удалось изобрести новый скриптовый язык поверх Java, который на самом деле имитирует то, что у нас уже было лет десять тому назад в ASP/JSP/VB, но имимтирует намного хуже, потому что XML — это не язык, а структура данных...
Возвращаясь к отправной точке — какие возможности мы потеряли, перейдя с Lisp/Smalltalk на всякие VB/Delphi/C++? а потом на всякие Java/C# и т.д., и какие возможности теперь заново изобретают (в худших формах) в этих новых "язвках"?