Что мы потеряли?
От: Mamut Швеция http://dmitriid.com
Дата: 24.08.06 07:06
Оценка: 41 (10) +1 :)
Вытянуто с comp.lang.erlang.general

Для нетерпеливых — вопрос находится в самом конце этой цитаты

(перевод мой)

К сожалению, я не смог стать частью "поколения 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# и т.д., и какие возможности теперь заново изобретают (в худших формах) в этих новых "язвках"?




[1] Я не имею ни малейшего представления, как перевести некоторые из этих терминов, поэтому оставил их, как есть.
... << RSDN@Home 1.2.0 alpha rev. 655>>


dmitriid.comGitHubLinkedIn
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.