Re: Несколько вопросов вразброс
Артём Н. -> debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:42:17 +0400:
>> >> >> >> То, что в нем объектов нет, это хорошо.
>> >> >> АН> Это вопрос для чего.
>> >> >> Практически для всего. Я тоже в свое время радостно ломанулся в
>> >> >> ОО-программирование. Потом поумнел.
>> >> АН> Но это не значит, что ООП не имеет права на жизнь.
>> >> АН> Идея была такой просто и хорошей... :-(
>> >> "Любая задача имеет короткое, изящное и очевидное _неправильное_ решение".
>> АН> Ну это не совсем к теме ООП.
>>
>> >> ООП имеет право на жизнь, и есть задачи, которые на нем решаются хорошо.
>> >> Но этих задач существенно меньше, чем мест, куда его суют не по делу.
>> АН> Да, согласен.
>> АН> Однако, в идеале, неплохо бы иметь одну общую всеобъемлющую концепцию :-)
>> АН> ООП претендует (с переменным успехом) на роль таковой.
>>
>> Машина Тьюринга заняла эту нишу много лет назад, и даже
>> лямбда-исчислению ее не отдала. И ООП не отдаст.
АН> Я про ту концепцию, которую возможно использовать на практике.
Теорема Геделя нам как бы намекает, что такой концепции не существует.
>> А на практике наличие _одной_ всеобъемлющей концепции - это большой
>> минус. Что и наблюдается как с реляционной моделью в базах данных, так
>> и с ООП в архитектуре программ.
АН> Ну, по крайней мере, сейчас в большинстве случаев используется реляционная
АН> модель... Хоть какое-то единообразие.
Хуже того, в большинстве случаев сейчас уже используется XML-обертка над
ORM над реляционной базой. И нет, не шибко единообразная.
>> Хочешь писать хорошие программы - изучи несколько парадигм, и применяй
>> наиболее подходящие к задаче. А не суй где надо и где не надо ту
>> единственную, которую ты знаешь.
АН> Плохо то, что единственной парадигмы, подходящей везде, - нет.
Извини, это в некотором смысле объективный закон. Что-то вроде закона
всемирного тяготения. Не просто нет, а доказуемо не может быть.
>> >> >> Помнится, код, переписанный с C++ на C со старательным выкидыванием всей
>> >> >> объектности, кроме нужной, стал на порядок компактнее, вдвое понятнее, и
>> >> >> давал в разы меньший результат при компиляции.
>> >> >> Tcl - он же функциональный по сути, зачем ему объекты?
>> >> АН> Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как совмещается
>> >> АН> объектный и функциональный подход..? Хотя, библиотеки-то есть...
>> >> Никогда не надо пользоваться тем, что "в принципе не лишнее".
>> >> Пользоваться надо только тем, что тебе действительно нужно, и понимая,
>> >> почему именно оно, а не альтернативы.
>> АН> Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
>> АН> возможно выбрать лучшую из альтернатив, потому что обе они имеют
>> АН> взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
>> АН> них не является лучшей. Во-вторых, иногда просто недостаточно
>> АН> информации для выбора.
>> Я видел только один вариант "недостаточно информации для выбора" -
>> незнание альтернатив.
АН> Нет, почему же?
АН> Незнание всех характеристик альтернатив, незнание того, как поведёт
АН> себя данная альтернатива, незнание того насколько сильнее одна
АН> характеристика влияет на абстрактное "качество" системы, чем
АН> другая. Много что возможно не знать.
Перечисленное тобой либо сводится к незнанию альтернатив (не знаешь как
поведет - ну, попробуй на тестовом примере; если тебе это слишком сложно
или дорого, это значит, что ты знаешь о существовании этой альтернативы,
но не знаешь ее саму), либо к задачам, которые решать не надо
(совершенно не нужно оценивать влияние характеристик на абстрактное
качество системы, если тебе нужно, чтобы система работала - тебе может
быть интересно только несколько _конкретных_ качеств).
>> Важный момент: совершенно не обязательно выбирать
>> лучшую из альтернатив. Если ты не можешь решить, которая из нескольких
>> лучше по описанной причине, это по крайней мере значит, что ни одна из
>> них не будет существенно хуже других. Выбери любую.
АН> Ага. И тут получается проблема "буриданова осла". Принятие решения. :-)
Монетку брось.
>> А если ты недостаточно знаешь о задаче, то значит, выбирать инструмент
>> пока просто рано, надо сперва задачу изучить.
АН> Что тоже не всегда возможно.
Если ты не можешь изучить задачу, то скорее всего, ты ее и решить не
сможешь, и тут уже совершенно пофигу, каким инструментом ты ее не
сможешь решить. Бери любой.
>> >> Я даже скажу, где в tcl/Tk мне не хватает свойства, характерного для
>> >> объектной модели в хорошем ее исполнении. Но оно есть отнюдь не только
>> >> в объектной модели. Мне не хватало возможностей модифицировать Tk'шные
>> >> виджеты. Включая возможность строить свой на базе готовых. Оная
>> >> возможность, кстати, есть в perl/Tk. Но там как раз объектная модель, и
>> >> описание интерфейса в результате стало куда менее читабельным.
>> АН> Т.е., используя Tcl/Tk я не могу, например, взять панельку и
>> АН> построить на её основе свою мегапанельку, которая станет
>> АН> равноправным компонентом? :-)
>> Можешь. Но придется таки залезть в сишный код, если я правильно помню
>> ситуацию.
АН> Т.е., средствами языка Tcl я это сделать не могу? :-(
Сколь я помню, нет. Впрочем, у тебя столько возможностей для изменения
поведения существующих виджетов, что невозможность создать свой с таким
же интерфейсом можно и пережить. Ну, то есть мне на практике пару раз
хотелось, но потом придумывалось _более удобное_ решение с изменением
поведения существующих.
Но в целом да, я считаю такое ограничение недостатком Tk. С другой
стороны, оно, может, и достоинство, ибо нет возможности - нет и
соблазна, а "творчество" таких виджетов обычно, будучи решением НЕ ТОЙ
задачи, контрпродуктивно.
>> >> >> >> А исключения и работа с файлами
>> >> >> >> там есть. Просто она не относится к синтаксису - это вам не PHP :-)
>> >> >> АН> Хм...
>> >> >> Чего хм? error/catch/return/bgerror и
>> >> >> open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
>> >> >> особенно обрати внимание - я не знаю больше ни одного языка со столь
>> >> >> удобным обращением с асинхронными IO-событиями.
>> >> АН> Почему тогда на нём не пишут?
>> >> АН> Исторические причины?
>> >> Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
>> >> fileevent, нужно владеть парадигмой событийно-ориентированного
>> >> программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
>> >> чего худо-бедно хватает для написания стандартно-корявого гуя, а
>> >> парадигмой владеть.
>> АН> В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
>> АН> событийную модель. В чём сложности?
>> В понимании этих предложений программистами. В результате чего они
>> используют некие шаблоны, не понимая, что они делают. И соответственно,
>> как только задача требует шаг влево, шаг вправо - они ее решить уже не
>> могут. Выходят из положения они очень хитро - они выбирают из тех
>> задач, которые они могут решить, ту, которая кажется им больше всего
>> похожей на поставленную. И решают ее вместо поставленной.
АН> А что им остаётся (не защищаю :-) , просто интересуюсь), как людям?
Сменить профессию. На ту, что требует меньше интеллекта.
>> Я это наблюдал, грубо говоря, в виде, когда человек не может, формируя
>> интерфейс типа "wizard", адекватно обработать какую-либо кнопку, кроме
>> "Далее".
АН> В смысле?
В смысле в интерфейсах типа "wizard" обычно бывают кнопки "Далее" и
"Назад", иногда еще "Отмена". Вот у него получался работающим только
мейнстрим - "Далее", "Далее", "Далее", "Готово". Остальное не работало.
Нет, не то чтобы не пыталось. Пыталось. Не получалось. То что-нибудь
в реестре забудет (под виндой дело было), отчего следующая попытка
инсталляции удивляется и падает, то отвалится по ошибке удаления
несозданного файла...
>> Вот ты, например, не видишь, что ООП к асинхронности ни малейшего
>> отношения не имеет. Не предлагает и не запрещает, просто не имеет
>> отношения.
АН> Естественно, может быть асинхронность без ООП (почти в любой парадигме), как и
АН> ООП без асинхронности.
АН> Но вы не так интерпретировали, что я написал: "сейчас ООП и ГУЙ предполагают и
АН> асинхронность, и событийную модель."
АН> Разве это не так?
Нет, не так. Большинство гуевых библиотек предполагают событийную
модель и позволяют кое-какую асинхронность событий (ага, преимущественно
своих собственных, с собственным циклом ожидания-обработки). Что-то
таких, которые позволяют нормальную асинхронность и свою, и не только, я
и не припомню... А ООП к асинхронности и событийной модели совершенно
перпендикулярна, и ничего относительно этого не предполагает.
>> А большинство гуев на практике как раз синхронны, хотя все
>> гуевые библиотеки позволяют асинхронность.
АН> Да ну? Большинство ГУЁв - это windows. Сообщение приходит асинхронно. И даже не
АН> важно, что там оконный цикл. Любые нормальные фреймворк/среда/обёртка над
АН> оконным интерфейсом предполагают использование:
АН> 1. Событийной модели (onClick()).
АН> 2. Асинхронности (те же клики могут делать как угодно, когда угодно и где
АН> угодно, причём onClick() - это, фактически callback, а если вспомнить, что там
АН> ещё есть "GUI-поток", что сразу подразумевает многопоточность).
АН> Где я не прав?
Начиная с фразы "не важно, что там оконный цикл". Ну-ка, сделай мне
программу, у которого обработки графики столько, что ее гуй тянет FPS
едва 30, и обрабатывает при этом 200 входящих UDP-пакетов в секунду.
Без задержек и потерь этих пакетов. Пакеты, естественно, влияют на гуй,
причем данные из одного пакета должны влиять или не влиять одновременно.
В связи с этим влиянием гуй должен перерисовываться не только по клику,
но и по смене данных из сети.
Все решения такого типа, которые я видел, сводились к закатыванию солнца
вручную, в смысле замены штатного гуевого цикла ручным, и неизбежным
глюкам межтредовой синхронизации - или диким тормозам. Только
хаскельная STM позволяет делать это без глюков (но отнюдь не без
закатывания солнца вручную).
Вообще, многопоточность сама по себе ни разу не гарантирует
асинхронности - чтобы процесс был действительно асинхронным, надо еще
суметь его правильно организовать.
А с типичными гуевыми задачами Tk, кстати, прекрасно справляется в одном
потоке. Не забывая ни про событийность, ни даже про асинхронность.
>> А яндексовский imap, как тут
>> обсуждалось в соседнем треде, не умеет работать асинхронно, хотя RFC на
>> IMAP буквально начинается со слов про асинхронность. Ниасилили, видать.
АН> Не в курсе. Возможно в двух словах?
О чем? О том, что IMAP таки подразумевает асинхронность (хотя вроде бы
и не требует ее на уровне MUST) или о том, что у яндекса ее нет? О
втором был параллельный тред, а о первом - возьми RFC и почитай. Он
большой, но тебя интересует только вводная часть.
Reply to: