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