Артём Н. -> 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 АН> выбрасывается всё, кроме формочек. Остаётся библиотека АН> (относительно независимо), редактор форм и компилятор. :-) Тормоза - потому что типичная межтредовая синхронизация либо ненадежна, либо медленна. Ибо глобальна. >> Вообще, многопоточность сама по себе ни разу не гарантирует >> асинхронности - чтобы процесс был действительно асинхронным, надо еще >> суметь его правильно организовать. АН> Но предполагает асинхронность. Даже, если таковая не совсем корректно АН> используется (например, с большим количеством блокировок). Да, предполагает. Если б она еще предлагала хорошие решения... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk7et1ir....@wizzle.ran.pp.ru