Re[17]: КОП в linux
От: Kolhoz Мухосранск  
Дата: 23.06.06 10:47
Оценка: +1
Здравствуйте, Андрей Хропов, Вы писали:

K>> Какого файла? А если я туда netcat вставил? Или ssh?

АХ>И? В чем проблема?
АХ>Передайте имя файла netcatу, а он дальше передаст.

Интересно, как бы вы предложили удалять гланды. Я, кажется, заранее догадываюсь.

АХ>то что вы пишете в Unix как

АХ>"ls | more"
АХ>можно записать как (условно)
АХ>"File result = more.Process( ls.Process(input) )".
АХ>more и ls некие компоненты.

АХ>Чуть больше слов, но суть та же.


Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например).

K>> Дао Unix way:

K>>- на каждую функциональную единицу — отдельный компонент
АХ>Правильно — в любой компонентной системе так.

Не в любой. В объектных моделях для этого функциональная единица должна совпадать с объектом. А это не всегда возможно. Скорее, это почти никогда не возможно — объектная иерархия редко совпадает с семантической.

K>>- к компоненту предъявляются требования:

K>> * возможность как программного так и интерактивного задействования всех его функций.
АХ>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?

Не понял вопроса. Легко и непринуждённо обеспечиваем.

K>> * корректное сообщение о любых исключительных ситуациях

АХ>Сообщение мало. Надо еще данные не убить по возможности.
АХ>Без поддержки исключений обработка ошибок — это геморрой жуткий.
АХ>Я уж не говорю про RAII. А это предполагает ОО.

ОО тут совершенно не при делах...

АХ>Эээ. Вот тут мне видится фундаментальный изъян.

АХ>Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате,
АХ>в unix way используется наименьший общий знаменатель — простой текст.

Не обязательно. Не нужна совместимость, на самом деле.

АХ>Часто программы работают все же не с простым текстом, а со структурированными данными

АХ>(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.

Ну так кто просит использовать простой текст там, где не требуется?

АХ>Вот LaTeX — это Unix way?

АХ>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?

Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе.

K>> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.

АХ>Имеют свои плюсы, но не универсальны.

Естественно. А Unix way не требует использования обязательно текстовых потоков.

K>> Что же? Объектно-ориентированную религию не предлагать, тошно-с.

АХ>Глупости говорите. ОО давно уже само-собой.

К счастью, далеко не везде.

AX> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .


Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть. В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне. Тут пока никаких языков нет и не предвидится. Как оно там внутри устроено — не колышет и не рвёт.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.