On 06.07.2012 00:07, Artem Chuprina wrote: > Артём Н. -> [email protected] @ 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, нужно владеть парадигмой событийно-ориентированного > >> >> >> программирования. Не вычитать в экзамплах пару шаблонов для > виджетов, > >> >> >> чего худо-бедно хватает для написания стандартно-корявого гуя, а > >> >> >> парадигмой владеть. > >> >> АН> В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и > >> >> АН> событийную модель. В чём сложности? > >> >> В понимании этих предложений программистами. В результате чего они > >> >> используют некие шаблоны, не понимая, что они делают. И > соответственно, > >> >> как только задача требует шаг влево, шаг вправо - они ее решить уже не > >> >> могут. Выходят из положения они очень хитро - они выбирают из тех > >> >> задач, которые они могут решить, ту, которая кажется им больше всего > >> >> похожей на поставленную. И решают ее вместо поставленной. > >> АН> А что им остаётся (не защищаю :-) , просто интересуюсь), как людям? > >> Сменить профессию. На ту, что требует меньше интеллекта. > АН> И зарплата тоже упадёт... И что им делать? Я представил себя... :-( > Видишь ли, рано или поздно мы все умрем. Иии? Кстати, учитывая успехи медицины... > Программист - далеко не самая высокооплачиваемая > профессия. И какую профессию вы им предлагаете? :-D >> Нет, не то чтобы не пыталось. Пыталось. Не получалось. То что-нибудь > >> в реестре забудет (под виндой дело было) > АН> Не удивительно. > > >> отчего следующая попытка > >> инсталляции удивляется и падает, то отвалится по ошибке удаления > >> несозданного файла... > АН> Мда... > Я даже понимаю, почему. Есть такая, гм, парадигма программирования - > example-based. Это когда кодер идет на какой-нибудь ixbt или в msdn > (это в лучшем случае, может и на хабрахабр пойти), вбивает там в поиск > слова, которые показались ему ключевыми, в результатах поиска находит > примеры функций и копипастит в свою программу. Иногда даже удачно > переименовывая переменные... Хм... Но, в принципе, использование примеров - правильно. Все пользуются. А просто скопипастить функцию не получится. Ведь надо понимать хотя бы то, что она делает, ведь так? > Так вот, если перестать утрировать, то видел я те примеры. В них обычно > даже отслеживается, когда вызов обсуждаемой функции возвращает ошибку. > Но никогда не делается попытки восстановления из такой ошибочной > ситуации. По понятным, опять же, причинам - пример-то на функцию, а не > на борьбу с проблемами окружения, в котором она вызвана. Ну это же ни о чём не говорит (в некоторых примерах вообще обработка ошибок отсутствует)? > Но в результате кодер, который программирует на примерах, не умеет > сделать с ошибкой ничего, кроме как вывалиться. Если ошибка нештатная, может, это и правильно: завершиться с информативным сообщением. А, если штатная, ведь код возврата, исключение или errno, он в состоянии обработать? > >> >> Вот ты, например, не видишь, что ООП к асинхронности ни > малейшего > >> >> отношения не имеет. Не предлагает и не запрещает, просто не > имеет > >> >> отношения. > >> АН> Естественно, может быть асинхронность без ООП (почти в любой > парадигме), как и > >> АН> ООП без асинхронности. > >> АН> Но вы не так интерпретировали, что я написал: "сейчас ООП и ГУЙ > предполагают и > >> АН> асинхронность, и событийную модель." > >> АН> Разве это не так? > >> Нет, не так. Большинство гуевых библиотек предполагают событийную > >> модель и позволяют кое-какую асинхронность событий (ага, преимущественно > >> своих собственных, с собственным циклом ожидания-обработки). Что-то > >> таких, которые позволяют нормальную асинхронность и свою, и не только, я > >> и не припомню... А ООП к асинхронности и событийной модели совершенно > >> перпендикулярна, и ничего относительно этого не предполагает. > АН> Вы выдернули из контекста. ООП в рамках обёртки над оконными > АН> функциями. Сами объекты предполагают событийную модель. > > Так нет. Сами объекты как раз не предполагают. Конкретные методы > _приспособлены для_. А _предполагает_ не объект, а событийная > парадигма. В свою очередь, перпендикулярная объектности. ОО > событийно-ориентированный гуй - это просто прямая сумма ОО и СО > парадигм, а не единая объектно-событийная парадигма. На практике в области обёрток, сейчас имеется, как правило, эта сумма. И, вообще, мне кажется, что объекты так и просят, чтобы к ним приделали события. :-) > В смысле, от их > сложения никакого дополнительного профита не получается. Минусов, > впрочем, тоже. Не знаю... Профит - использование объектов. И отсутствие сотни колбэков, в которых легко запутаться, упрощение кодирования. > >> Все решения такого типа, которые я видел, сводились к закатыванию солнца > >> вручную, в смысле замены штатного гуевого цикла ручным, и неизбежным > >> глюкам межтредовой синхронизации - или диким тормозам. > АН> И я менял. :-) Почему обязательно тормоза? Просто из RAD > АН> выбрасывается всё, кроме формочек. Остаётся библиотека > АН> (относительно независимо), редактор форм и компилятор. :-) > Тормоза - потому что типичная межтредовая синхронизация либо ненадежна, > либо медленна. Ибо глобальна. "Типичная" - это какая? Почему должны быть тормоза? Кажется, наоборот. 1. Есть поток для интерфейса и рабочий. В этом случае, интерфейсный поток читает состояние рабочего по низко приоритетному таймеру или запросу пользователя. В задачах, где требуется своевременное отображение, состояние интерфейса изменяет рабочий поток. Время тратится на обращение к объектам синхронизации и переключение контекста. Не знаю точно, но наверное, это оптимальнее, чем вызывать функцию расчёта в цикле единственного потока... Да, конечно, вызов функции менее накладен (всего лишь обращение к стеку и по адресу). Но, во-первых, нельзя задать приоритет потоку, система не может спланировать кому и сколько времени предоставлять, реакция на пользовательский ввод будет не такой своевременной (ведь в это время может выполняться функция расчёта), что приведёт к тормозам, где-то надо будет хранить данные функции, а логика наверняка усложнится. Во-вторых, на многоядерных/процессорных системах... 2. Есть несколько рабочих потоков. Задача распараллелена. Потоки выполняются независимо и проходят точки синхронизации. Где тормоза? Где ненадёжность? 3. Есть несколько потоков: одни спят и ожидают, какой-то один-два независимых работают... Я не вижу ни отсутствия надёжности, ни медлительности. Где? И пример - тот же апач. Вариант без потоков? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
