Re: Несколько вопросов вразброс
04.07.2012 22:12, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Wed, 04 Jul 2012 20:34:17 +0400:
>
> >> >> >> То, что в нем объектов нет, это хорошо.
> >> >> АН> Это вопрос для чего.
> >> >> Практически для всего. Я тоже в свое время радостно ломанулся в
> >> >> ОО-программирование. Потом поумнел.
> >> АН> Но это не значит, что ООП не имеет права на жизнь.
> >> АН> Идея была такой просто и хорошей... :-(
> >> "Любая задача имеет короткое, изящное и очевидное _неправильное_ решение".
> АН> Ну это не совсем к теме ООП.
>
> >> ООП имеет право на жизнь, и есть задачи, которые на нем решаются хорошо.
> >> Но этих задач существенно меньше, чем мест, куда его суют не по делу.
> АН> Да, согласен.
> АН> Однако, в идеале, неплохо бы иметь одну общую всеобъемлющую концепцию :-)
> АН> ООП претендует (с переменным успехом) на роль таковой.
>
> Машина Тьюринга заняла эту нишу много лет назад, и даже
> лямбда-исчислению ее не отдала. И ООП не отдаст.
Я про ту концепцию, которую возможно использовать на практике.
> А на практике наличие _одной_ всеобъемлющей концепции - это большой
> минус. Что и наблюдается как с реляционной моделью в базах данных, так
> и с ООП в архитектуре программ.
Ну, по крайней мере, сейчас в большинстве случаев используется реляционная
модель... Хоть какое-то единообразие.
> Хочешь писать хорошие программы - изучи несколько парадигм, и применяй
> наиболее подходящие к задаче. А не суй где надо и где не надо ту
> единственную, которую ты знаешь.
Плохо то, что единственной парадигмы, подходящей везде, - нет.
> >> >> Помнится, код, переписанный с C++ на C со старательным выкидыванием всей
> >> >> объектности, кроме нужной, стал на порядок компактнее, вдвое понятнее, и
> >> >> давал в разы меньший результат при компиляции.
> >> >> Tcl - он же функциональный по сути, зачем ему объекты?
> >> АН> Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как совмещается
> >> АН> объектный и функциональный подход..? Хотя, библиотеки-то есть...
> >> Никогда не надо пользоваться тем, что "в принципе не лишнее".
> >> Пользоваться надо только тем, что тебе действительно нужно, и понимая,
> >> почему именно оно, а не альтернативы.
> АН> Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
> АН> возможно выбрать лучшую из альтернатив, потому что обе они имеют
> АН> взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
> АН> них не является лучшей. Во-вторых, иногда просто недостаточно
> АН> информации для выбора.
> Я видел только один вариант "недостаточно информации для выбора" -
> незнание альтернатив.
Нет, почему же?
Незнание всех характеристик альтернатив, незнание того, как поведёт себя данная
альтернатива, незнание того насколько сильнее одна характеристика влияет на
абстрактное "качество" системы, чем другая. Много что возможно не знать.
> Важный момент: совершенно не обязательно выбирать
> лучшую из альтернатив. Если ты не можешь решить, которая из нескольких
> лучше по описанной причине, это по крайней мере значит, что ни одна из
> них не будет существенно хуже других. Выбери любую.
Ага. И тут получается проблема "буриданова осла". Принятие решения. :-)
> А если ты недостаточно знаешь о задаче, то значит, выбирать инструмент
> пока просто рано, надо сперва задачу изучить.
Что тоже не всегда возможно.
> >> Я даже скажу, где в tcl/Tk мне не хватает свойства, характерного для
> >> объектной модели в хорошем ее исполнении. Но оно есть отнюдь не только
> >> в объектной модели. Мне не хватало возможностей модифицировать Tk'шные
> >> виджеты. Включая возможность строить свой на базе готовых. Оная
> >> возможность, кстати, есть в perl/Tk. Но там как раз объектная модель, и
> >> описание интерфейса в результате стало куда менее читабельным.
> АН> Т.е., используя Tcl/Tk я не могу, например, взять панельку и
> АН> построить на её основе свою мегапанельку, которая станет
> АН> равноправным компонентом? :-)
> Можешь. Но придется таки залезть в сишный код, если я правильно помню
> ситуацию.
Т.е., средствами языка Tcl я это сделать не могу? :-(
> >> >> >> А исключения и работа с файлами
> >> >> >> там есть. Просто она не относится к синтаксису - это вам не PHP :-)
> >> >> АН> Хм...
> >> >> Чего хм? error/catch/return/bgerror и
> >> >> open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
> >> >> особенно обрати внимание - я не знаю больше ни одного языка со столь
> >> >> удобным обращением с асинхронными IO-событиями.
> >> АН> Почему тогда на нём не пишут?
> >> АН> Исторические причины?
> >> Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
> >> fileevent, нужно владеть парадигмой событийно-ориентированного
> >> программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
> >> чего худо-бедно хватает для написания стандартно-корявого гуя, а
> >> парадигмой владеть.
> АН> В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
> АН> событийную модель. В чём сложности?
> В понимании этих предложений программистами. В результате чего они
> используют некие шаблоны, не понимая, что они делают. И соответственно,
> как только задача требует шаг влево, шаг вправо - они ее решить уже не
> могут. Выходят из положения они очень хитро - они выбирают из тех
> задач, которые они могут решить, ту, которая кажется им больше всего
> похожей на поставленную. И решают ее вместо поставленной.
А что им остаётся (не защищаю :-) , просто интересуюсь), как людям?
> Я это наблюдал, грубо говоря, в виде, когда человек не может, формируя
> интерфейс типа "wizard", адекватно обработать какую-либо кнопку, кроме
> "Далее".
В смысле?
> Вот ты, например, не видишь, что ООП к асинхронности ни малейшего
> отношения не имеет. Не предлагает и не запрещает, просто не имеет
> отношения.
Естественно, может быть асинхронность без ООП (почти в любой парадигме), как и
ООП без асинхронности.
Но вы не так интерпретировали, что я написал: "сейчас ООП и ГУЙ предполагают и
асинхронность, и событийную модель."
Разве это не так?
> А большинство гуев на практике как раз синхронны, хотя все
> гуевые библиотеки позволяют асинхронность.
Да ну? Большинство ГУЁв - это windows. Сообщение приходит асинхронно. И даже не
важно, что там оконный цикл. Любые нормальные фреймворк/среда/обёртка над
оконным интерфейсом предполагают использование:
1. Событийной модели (onClick()).
2. Асинхронности (те же клики могут делать как угодно, когда угодно и где
угодно, причём onClick() - это, фактически callback, а если вспомнить, что там
ещё есть "GUI-поток", что сразу подразумевает многопоточность).
Где я не прав?
> А яндексовский imap, как тут
> обсуждалось в соседнем треде, не умеет работать асинхронно, хотя RFC на
> IMAP буквально начинается со слов про асинхронность. Ниасилили, видать.
Не в курсе. Возможно в двух словах?
Reply to: