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 я имею представление. Странно... -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
