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