Re: Несколько вопросов вразброс
Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 20:49:27 +0400:
>> >> Машина Тьюринга заняла эту нишу много лет назад, и даже
>> >> лямбда-исчислению ее не отдала. И ООП не отдаст.
>> АН> Я про ту концепцию, которую возможно использовать на практике.
>> Теорема Геделя нам как бы намекает, что такой концепции не существует.
АН> Теорема Гёделя об этом не говорит (про практику и частности).
АН> Я про концепцию, типа реляционной в БД (на том же месте)...
Я ж говорю: намекает. На самом деле есть еще теорема Гёделя о полноте,
но опять же стоит глянуть на ее доказательство, чтобы понять, в чем
будет проблема такой концепции. А проблема, собственно, в том, что чем
универсальнее концепция, тем она менее полезна. А чем она менее
универсальна, тем более узкий круг задач она способна решить.
Реляционная концепция оказывается такой похожей на универсальную в
первую очередь потому, что у нас в области обработки данных табличной
природы на практике стоит довольно узкий класс задач, а в области
обработки нетабличных данных пока вообще задачу толком поставить не
могут. В итоге большинство поставленных задач она решает хорошо.
>> >> Хочешь писать хорошие программы - изучи несколько парадигм, и применяй
>> >> наиболее подходящие к задаче. А не суй где надо и где не надо ту
>> >> единственную, которую ты знаешь.
>> АН> Плохо то, что единственной парадигмы, подходящей везде, - нет.
>> Извини, это в некотором смысле объективный закон. Что-то вроде закона
>> всемирного тяготения. Не просто нет, а доказуемо не может быть.
АН> Ну везде, с некоторыми ограничениями...
Все зависит от ограничений ;-) Классическое "автомобиль может быть
любого цвета, если этот цвет черный" - это тоже "с некоторым
ограничением".
>>
>> >> >> >> Помнится, код, переписанный с C++ на C со старательным выкидыванием всей
>> >> >> >> объектности, кроме нужной, стал на порядок компактнее, вдвое понятнее, и
>> >> >> >> давал в разы меньший результат при компиляции.
>> >> >> >> Tcl - он же функциональный по сути, зачем ему объекты?
>> >> >> АН> Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как совмещается
>> >> >> АН> объектный и функциональный подход..? Хотя, библиотеки-то есть...
>> >> >> Никогда не надо пользоваться тем, что "в принципе не лишнее".
>> >> >> Пользоваться надо только тем, что тебе действительно нужно, и понимая,
>> >> >> почему именно оно, а не альтернативы.
>> >> АН> Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
>> >> АН> возможно выбрать лучшую из альтернатив, потому что обе они имеют
>> >> АН> взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
>> >> АН> них не является лучшей. Во-вторых, иногда просто недостаточно
>> >> АН> информации для выбора.
>> >> Я видел только один вариант "недостаточно информации для выбора" -
>> >> незнание альтернатив.
>> АН> Нет, почему же?
>> АН> Незнание всех характеристик альтернатив, незнание того, как поведёт
>> АН> себя данная альтернатива, незнание того насколько сильнее одна
>> АН> характеристика влияет на абстрактное "качество" системы, чем
>> АН> другая. Много что возможно не знать.
>> Перечисленное тобой либо сводится к незнанию альтернатив (не знаешь как
>> поведет - ну, попробуй на тестовом примере; если тебе это слишком сложно
>> или дорого, это значит, что ты знаешь о существовании этой альтернативы,
>> но не знаешь ее саму), либо к задачам, которые решать не надо
>> (совершенно не нужно оценивать влияние характеристик на абстрактное
>> качество системы, если тебе нужно, чтобы система работала - тебе может
>> быть интересно только несколько _конкретных_ качеств).
АН> В общем случае, да. Но незнание альтернатив почти всегда есть.
При наличии образования - отнюдь не почти всегда. Конечно, чтобы
правильно задать вопрос, надо знать половину ответа. Но затем и
образование.
>> >> Важный момент: совершенно не обязательно выбирать
>> >> лучшую из альтернатив. Если ты не можешь решить, которая из нескольких
>> >> лучше по описанной причине, это по крайней мере значит, что ни одна из
>> >> них не будет существенно хуже других. Выбери любую.
>> АН> Ага. И тут получается проблема "буриданова осла". Принятие решения. :-)
>> Монетку брось.
АН> Не то...
KISS!
>> >> А если ты недостаточно знаешь о задаче, то значит, выбирать инструмент
>> >> пока просто рано, надо сперва задачу изучить.
>> АН> Что тоже не всегда возможно.
>>
>> Если ты не можешь изучить задачу, то скорее всего, ты ее и решить не
>> сможешь, и тут уже совершенно пофигу, каким инструментом ты ее не
>> сможешь решить. Бери любой.
АН> Вопрос насколько изучить...
Вот как раз настолько, чтобы появились достаточно четкие критерии, по
которым выбирается инструмент. Или, другой вариант оценки, когда
появилось два-три варианта архитектуры решения и понимание, чем они
хороши и плохи для данной задачи.
Если ты не можешь изучить задачу до этого уровня - ты ее не решишь.
>> >> >> >> >> А исключения и работа с файлами
>> >> >> >> >> там есть. Просто она не относится к синтаксису - это вам не PHP :-)
>> >> >> >> АН> Хм...
>> >> >> >> Чего хм? error/catch/return/bgerror и
>> >> >> >> open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
>> >> >> >> особенно обрати внимание - я не знаю больше ни одного языка со столь
>> >> >> >> удобным обращением с асинхронными IO-событиями.
>> >> >> АН> Почему тогда на нём не пишут?
>> >> >> АН> Исторические причины?
>> >> >> Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
>> >> >> fileevent, нужно владеть парадигмой событийно-ориентированного
>> >> >> программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
>> >> >> чего худо-бедно хватает для написания стандартно-корявого гуя, а
>> >> >> парадигмой владеть.
>> >> АН> В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
>> >> АН> событийную модель. В чём сложности?
>> >> В понимании этих предложений программистами. В результате чего они
>> >> используют некие шаблоны, не понимая, что они делают. И соответственно,
>> >> как только задача требует шаг влево, шаг вправо - они ее решить уже не
>> >> могут. Выходят из положения они очень хитро - они выбирают из тех
>> >> задач, которые они могут решить, ту, которая кажется им больше всего
>> >> похожей на поставленную. И решают ее вместо поставленной.
>> АН> А что им остаётся (не защищаю :-) , просто интересуюсь), как людям?
>> Сменить профессию. На ту, что требует меньше интеллекта.
АН> И зарплата тоже упадёт... И что им делать? Я представил себя... :-(
Видишь ли, рано или поздно мы все умрем. Зарплата, кстати, не
обязательно упадет. Программист - далеко не самая высокооплачиваемая
профессия.
>> >> Я это наблюдал, грубо говоря, в виде, когда человек не может, формируя
>> >> интерфейс типа "wizard", адекватно обработать какую-либо кнопку, кроме
>> >> "Далее".
>> АН> В смысле?
>>
>> В смысле в интерфейсах типа "wizard" обычно бывают кнопки "Далее" и
>> "Назад", иногда еще "Отмена". Вот у него получался работающим только
>> мейнстрим - "Далее", "Далее", "Далее", "Готово". Остальное не работало.
АН> Зато, он нацелен на развитие и устремлён в будущее. :-D
Ах, если бы...
>> Нет, не то чтобы не пыталось. Пыталось. Не получалось. То что-нибудь
>> в реестре забудет (под виндой дело было)
АН> Не удивительно.
>> отчего следующая попытка
>> инсталляции удивляется и падает, то отвалится по ошибке удаления
>> несозданного файла...
АН> Мда...
Я даже понимаю, почему. Есть такая, гм, парадигма программирования -
example-based. Это когда кодер идет на какой-нибудь ixbt или в msdn
(это в лучшем случае, может и на хабрахабр пойти), вбивает там в поиск
слова, которые показались ему ключевыми, в результатах поиска находит
примеры функций и копипастит в свою программу. Иногда даже удачно
переименовывая переменные...
Так вот, если перестать утрировать, то видел я те примеры. В них обычно
даже отслеживается, когда вызов обсуждаемой функции возвращает ошибку.
Но никогда не делается попытки восстановления из такой ошибочной
ситуации. По понятным, опять же, причинам - пример-то на функцию, а не
на борьбу с проблемами окружения, в котором она вызвана.
Но в результате кодер, который программирует на примерах, не умеет
сделать с ошибкой ничего, кроме как вывалиться.
>> >> Вот ты, например, не видишь, что ООП к асинхронности ни малейшего
>> >> отношения не имеет. Не предлагает и не запрещает, просто не имеет
>> >> отношения.
>> АН> Естественно, может быть асинхронность без ООП (почти в любой парадигме), как и
>> АН> ООП без асинхронности.
>> АН> Но вы не так интерпретировали, что я написал: "сейчас ООП и ГУЙ предполагают и
>> АН> асинхронность, и событийную модель."
>> АН> Разве это не так?
>> Нет, не так. Большинство гуевых библиотек предполагают событийную
>> модель и позволяют кое-какую асинхронность событий (ага, преимущественно
>> своих собственных, с собственным циклом ожидания-обработки). Что-то
>> таких, которые позволяют нормальную асинхронность и свою, и не только, я
>> и не припомню... А ООП к асинхронности и событийной модели совершенно
>> перпендикулярна, и ничего относительно этого не предполагает.
АН> Вы выдернули из контекста. ООП в рамках обёртки над оконными
АН> функциями. Сами объекты предполагают событийную модель.
Так нет. Сами объекты как раз не предполагают. Конкретные методы
_приспособлены для_. А _предполагает_ не объект, а событийная
парадигма. В свою очередь, перпендикулярная объектности. ОО
событийно-ориентированный гуй - это просто прямая сумма ОО и СО
парадигм, а не единая объектно-событийная парадигма. В смысле, от их
сложения никакого дополнительного профита не получается. Минусов,
впрочем, тоже.
>> >> А большинство гуев на практике как раз синхронны, хотя все
>> >> гуевые библиотеки позволяют асинхронность.
>> АН> Да ну? Большинство ГУЁв - это windows. Сообщение приходит асинхронно. И даже не
>> АН> важно, что там оконный цикл. Любые нормальные фреймворк/среда/обёртка над
>> АН> оконным интерфейсом предполагают использование:
>> АН> 1. Событийной модели (onClick()).
>> АН> 2. Асинхронности (те же клики могут делать как угодно, когда угодно и где
>> АН> угодно, причём onClick() - это, фактически callback, а если вспомнить, что там
>> АН> ещё есть "GUI-поток", что сразу подразумевает многопоточность).
>>
>> АН> Где я не прав?
>> Начиная с фразы "не важно, что там оконный цикл". Ну-ка, сделай мне
>> программу, у которого обработки графики столько, что ее гуй тянет FPS
>> едва 30, и обрабатывает при этом 200 входящих UDP-пакетов в секунду.
>> Без задержек и потерь этих пакетов. Пакеты, естественно, влияют на гуй,
>> причем данные из одного пакета должны влиять или не влиять одновременно.
>> В связи с этим влиянием гуй должен перерисовываться не только по клику,
>> но и по смене данных из сети.
АН> И..? Это частный случай. Он не говорит о том, что в модели,
АН> предлагаемой RAD, нет асинхронности. Это асинхронная событийная
АН> модель. А детали реализации... Ну и задачи немного другие, да и
АН> целевая аудитория, полагаю.
Событийная модель там как раз синхронная. Ее можно заставить
справляться с асинхронными событиями, но не более того.
>> Все решения такого типа, которые я видел, сводились к закатыванию солнца
>> вручную, в смысле замены штатного гуевого цикла ручным, и неизбежным
>> глюкам межтредовой синхронизации - или диким тормозам.
АН> И я менял. :-) Почему обязательно тормоза? Просто из RAD
АН> выбрасывается всё, кроме формочек. Остаётся библиотека
АН> (относительно независимо), редактор форм и компилятор. :-)
Тормоза - потому что типичная межтредовая синхронизация либо ненадежна,
либо медленна. Ибо глобальна.
>> Вообще, многопоточность сама по себе ни разу не гарантирует
>> асинхронности - чтобы процесс был действительно асинхронным, надо еще
>> суметь его правильно организовать.
АН> Но предполагает асинхронность. Даже, если таковая не совсем корректно
АН> используется (например, с большим количеством блокировок).
Да, предполагает. Если б она еще предлагала хорошие решения...
Reply to: