Re: Несколько вопросов вразброс
05.07.2012 00:32, Artem Chuprina пишет:
> >> Машина Тьюринга заняла эту нишу много лет назад, и даже
> >> лямбда-исчислению ее не отдала. И ООП не отдаст.
> АН> Я про ту концепцию, которую возможно использовать на практике.
> Теорема Геделя нам как бы намекает, что такой концепции не существует.
Теорема Гёделя об этом не говорит (про практику и частности).
Я про концепцию, типа реляционной в БД (на том же месте)...
> >> Хочешь писать хорошие программы - изучи несколько парадигм, и применяй
> >> наиболее подходящие к задаче. А не суй где надо и где не надо ту
> >> единственную, которую ты знаешь.
> АН> Плохо то, что единственной парадигмы, подходящей везде, - нет.
> Извини, это в некотором смысле объективный закон. Что-то вроде закона
> всемирного тяготения. Не просто нет, а доказуемо не может быть.
Ну везде, с некоторыми ограничениями...
>
> >> >> >> Помнится, код, переписанный с C++ на C со старательным выкидыванием всей
> >> >> >> объектности, кроме нужной, стал на порядок компактнее, вдвое понятнее, и
> >> >> >> давал в разы меньший результат при компиляции.
> >> >> >> Tcl - он же функциональный по сути, зачем ему объекты?
> >> >> АН> Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как совмещается
> >> >> АН> объектный и функциональный подход..? Хотя, библиотеки-то есть...
> >> >> Никогда не надо пользоваться тем, что "в принципе не лишнее".
> >> >> Пользоваться надо только тем, что тебе действительно нужно, и понимая,
> >> >> почему именно оно, а не альтернативы.
> >> АН> Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
> >> АН> возможно выбрать лучшую из альтернатив, потому что обе они имеют
> >> АН> взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
> >> АН> них не является лучшей. Во-вторых, иногда просто недостаточно
> >> АН> информации для выбора.
> >> Я видел только один вариант "недостаточно информации для выбора" -
> >> незнание альтернатив.
> АН> Нет, почему же?
> АН> Незнание всех характеристик альтернатив, незнание того, как поведёт
> АН> себя данная альтернатива, незнание того насколько сильнее одна
> АН> характеристика влияет на абстрактное "качество" системы, чем
> АН> другая. Много что возможно не знать.
> Перечисленное тобой либо сводится к незнанию альтернатив (не знаешь как
> поведет - ну, попробуй на тестовом примере; если тебе это слишком сложно
> или дорого, это значит, что ты знаешь о существовании этой альтернативы,
> но не знаешь ее саму), либо к задачам, которые решать не надо
> (совершенно не нужно оценивать влияние характеристик на абстрактное
> качество системы, если тебе нужно, чтобы система работала - тебе может
> быть интересно только несколько _конкретных_ качеств).
В общем случае, да. Но незнание альтернатив почти всегда есть.
> >> Важный момент: совершенно не обязательно выбирать
> >> лучшую из альтернатив. Если ты не можешь решить, которая из нескольких
> >> лучше по описанной причине, это по крайней мере значит, что ни одна из
> >> них не будет существенно хуже других. Выбери любую.
> АН> Ага. И тут получается проблема "буриданова осла". Принятие решения. :-)
> Монетку брось.
Не то...
> >> А если ты недостаточно знаешь о задаче, то значит, выбирать инструмент
> >> пока просто рано, надо сперва задачу изучить.
> АН> Что тоже не всегда возможно.
>
> Если ты не можешь изучить задачу, то скорее всего, ты ее и решить не
> сможешь, и тут уже совершенно пофигу, каким инструментом ты ее не
> сможешь решить. Бери любой.
Вопрос насколько изучить...
> >> >> >> >> А исключения и работа с файлами
> >> >> >> >> там есть. Просто она не относится к синтаксису - это вам не PHP :-)
> >> >> >> АН> Хм...
> >> >> >> Чего хм? error/catch/return/bgerror и
> >> >> >> open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
> >> >> >> особенно обрати внимание - я не знаю больше ни одного языка со столь
> >> >> >> удобным обращением с асинхронными IO-событиями.
> >> >> АН> Почему тогда на нём не пишут?
> >> >> АН> Исторические причины?
> >> >> Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
> >> >> fileevent, нужно владеть парадигмой событийно-ориентированного
> >> >> программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
> >> >> чего худо-бедно хватает для написания стандартно-корявого гуя, а
> >> >> парадигмой владеть.
> >> АН> В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
> >> АН> событийную модель. В чём сложности?
> >> В понимании этих предложений программистами. В результате чего они
> >> используют некие шаблоны, не понимая, что они делают. И соответственно,
> >> как только задача требует шаг влево, шаг вправо - они ее решить уже не
> >> могут. Выходят из положения они очень хитро - они выбирают из тех
> >> задач, которые они могут решить, ту, которая кажется им больше всего
> >> похожей на поставленную. И решают ее вместо поставленной.
> АН> А что им остаётся (не защищаю :-) , просто интересуюсь), как людям?
> Сменить профессию. На ту, что требует меньше интеллекта.
И зарплата тоже упадёт... И что им делать? Я представил себя... :-(
> >> Я это наблюдал, грубо говоря, в виде, когда человек не может, формируя
> >> интерфейс типа "wizard", адекватно обработать какую-либо кнопку, кроме
> >> "Далее".
> АН> В смысле?
>
> В смысле в интерфейсах типа "wizard" обычно бывают кнопки "Далее" и
> "Назад", иногда еще "Отмена". Вот у него получался работающим только
> мейнстрим - "Далее", "Далее", "Далее", "Готово". Остальное не работало.
Зато, он нацелен на развитие и устремлён в будущее. :-D
> Нет, не то чтобы не пыталось. Пыталось. Не получалось. То что-нибудь
> в реестре забудет (под виндой дело было)
Не удивительно.
> отчего следующая попытка
> инсталляции удивляется и падает, то отвалится по ошибке удаления
> несозданного файла...
Мда...
> >> Вот ты, например, не видишь, что ООП к асинхронности ни малейшего
> >> отношения не имеет. Не предлагает и не запрещает, просто не имеет
> >> отношения.
> АН> Естественно, может быть асинхронность без ООП (почти в любой парадигме), как и
> АН> ООП без асинхронности.
> АН> Но вы не так интерпретировали, что я написал: "сейчас ООП и ГУЙ предполагают и
> АН> асинхронность, и событийную модель."
> АН> Разве это не так?
> Нет, не так. Большинство гуевых библиотек предполагают событийную
> модель и позволяют кое-какую асинхронность событий (ага, преимущественно
> своих собственных, с собственным циклом ожидания-обработки). Что-то
> таких, которые позволяют нормальную асинхронность и свою, и не только, я
> и не припомню... А ООП к асинхронности и событийной модели совершенно
> перпендикулярна, и ничего относительно этого не предполагает.
Вы выдернули из контекста. ООП в рамках обёртки над оконными функциями. Сами
объекты предполагают событийную модель.
> >> А большинство гуев на практике как раз синхронны, хотя все
> >> гуевые библиотеки позволяют асинхронность.
> АН> Да ну? Большинство ГУЁв - это windows. Сообщение приходит асинхронно. И даже не
> АН> важно, что там оконный цикл. Любые нормальные фреймворк/среда/обёртка над
> АН> оконным интерфейсом предполагают использование:
> АН> 1. Событийной модели (onClick()).
> АН> 2. Асинхронности (те же клики могут делать как угодно, когда угодно и где
> АН> угодно, причём onClick() - это, фактически callback, а если вспомнить, что там
> АН> ещё есть "GUI-поток", что сразу подразумевает многопоточность).
>
> АН> Где я не прав?
> Начиная с фразы "не важно, что там оконный цикл". Ну-ка, сделай мне
> программу, у которого обработки графики столько, что ее гуй тянет FPS
> едва 30, и обрабатывает при этом 200 входящих UDP-пакетов в секунду.
> Без задержек и потерь этих пакетов. Пакеты, естественно, влияют на гуй,
> причем данные из одного пакета должны влиять или не влиять одновременно.
> В связи с этим влиянием гуй должен перерисовываться не только по клику,
> но и по смене данных из сети.
И..? Это частный случай. Он не говорит о том, что в модели, предлагаемой RAD,
нет асинхронности. Это асинхронная событийная модель. А детали реализации... Ну
и задачи немного другие, да и целевая аудитория, полагаю.
> Все решения такого типа, которые я видел, сводились к закатыванию солнца
> вручную, в смысле замены штатного гуевого цикла ручным, и неизбежным
> глюкам межтредовой синхронизации - или диким тормозам.
И я менял. :-) Почему обязательно тормоза? Просто из RAD выбрасывается всё,
кроме формочек. Остаётся библиотека (относительно независимо), редактор форм и
компилятор. :-)
> Вообще, многопоточность сама по себе ни разу не гарантирует
> асинхронности - чтобы процесс был действительно асинхронным, надо еще
> суметь его правильно организовать.
Но предполагает асинхронность. Даже, если таковая не совсем корректно
используется (например, с большим количеством блокировок).
> >> А яндексовский imap, как тут
> >> обсуждалось в соседнем треде, не умеет работать асинхронно, хотя RFC на
> >> IMAP буквально начинается со слов про асинхронность. Ниасилили, видать.
> АН> Не в курсе. Возможно в двух словах?
>
> О чем? О том, что IMAP таки подразумевает асинхронность (хотя вроде бы
> и не требует ее на уровне MUST) или о том, что у яндекса ее нет? О
> втором был параллельный тред, а о первом - возьми RFC и почитай. Он
> большой, но тебя интересует только вводная часть.
О яндегсе. Про IMAP я имею представление. Странно...
Reply to: