September 25, 2006

Истинное лицо блога

Hugh очень точно подметил суть блогов и блогосферы вообще. И действительно, лично я сейчас не читаю блоги, я "просматриваю их содержание" при помощи RSS. И только если что-то заслуживает внимания - ссылка открывается в браузере.

На сегодняшний день блоги и всё с ними связанное генерируют столько информации, что ознакомиться с ней полностью невозможно. Особенно следует учесть тот факт, что каждый конкретный блог предоставляет своё видение проблемы и, чтобы увидеть проблему целиком, надо выяснить мнение нескольких людей.

На мой взгляд RSS-ленты это единственная возможность узнать как можно больше мнений по конкретному вопросу и при этом оставить время на осмысление полученной информации, ну и, конечно, на выполнение своих должностных обязанностей :-). Поэтому Hugh был совершенно прав, что поместил RSS-icon в центр картинки. И это вовсе не плохо, а совсем даже наоборот.

tags: , ,


September 15, 2006

Why Johnny can't code

Статья Дэвида Брина(лучше смотреть через IE) о его сыне вызвала широкий резонанс. В ней говорится о том, что на данный момент ни одна из современных платформ не предоставляет пользователю простого языка программирования, такого как Бейсик. Простого и удобного. Настолько простого, что примеры программ на нём могли печатать в школьных учебниках. И настолько удобного, что школьники могли исполнять эти примеры и видеть как работает компьтер. Да, есть поставляемые с *nix системами GCC, есть .Net Framework, содержащий компиляторы, который входит в Windows. Но все они не являются "простым языком программирования".

Да, Бейсик уже давно не актуален. Но давайте вспомним, с чего всё начиналось. Наверняка у каждого, кто сейчас близок к IT был в детстве ZX-Spectrum, с Бейсиком в качестве оболочки и кассетным магнитофоном для загрузки программ(в том числе игр). Программирование начиналось с робких попыток двигать курсор по экрану и изменять цвет вывода. Теперь, конечно, всё это кажется ребячеством, но тогда это было настоящее программирование.

По мнению Девида, проблема гораздо глубже. Сейчас всем предлагается изучать объектно-ориентированное программирование, использовать новейшие технологические достижения в этой области: новые языки, новые среды. И уже мало кто задумывается, что же происходит ниже этого уровня. Сейчас людей учат полагаться на машину и использовать возможности, предоставляемые другими людьми. Раньше обучение начиналось с объяснения, что такое компьютер и как он работает на уровне процессора, машинные команды, бесконечные нули и единицы. Потом ассемблер. И только после этого более высокоуровневые языки.

Сейчас всё иначе (по крайней мере в Америке, по словам автора). Да и у нас в России я стал зачмечать, что есть люди, которые сначала изучали С++, а потом перешли на Java и C#, а есть такие, кто изначально обучался более позднему языку без понимания того, что же происходит на нижних уровнях.

С одной стороны это хорошо: новые технологии, новые горизонты, но нельзя забывать корни, чтобы не получилось как в рассказе Азимова.


September 14, 2006

Виртуальные методы

Oldnewthing размышляет на тему виртуальных методов.

Техническая сторона вопроса понятна. В данном случае речь идёт о философской стороне. Всё сводится к тому, что автор класса, объявляющего виртуальные методы, никак не может влиять на классы-наследники и их поведение, но может зависеть от них. Хорошо когда ты сам автор и базового и дочернего классов. Но в случае написания очередной библиотеки, в конце концов придётся оставить что-то на доработку пользователям, то есть публиковать точки расширения (extensibility points).

Есть несколько различных подходов к решению проблемы. Самый прстой - запретить публичные виртуальные методы. Подход хорош, но как же быть с расширяемостью? Через callbacks? Может быть. Кстати, в скриптовых ОО языках, таких как Python и Ruby все методы по умолчанию являются виртуальными. Там ситуация ещё сложнее :-) и данный подход не применим в принципе.

Для расширяемости можно предложить и другие варианты. Например, те же callback'и или, в случае с .net, events. Но и здесь возможны способы, когда плохой пользователь всё испортит.

Можно использовать COM-подход: наследование интерфейса, а не реализации. Создаётся интерфейс и какое-то количество его реализаций. Эти реализации пишутся автором, то есть тут не может быть разговора о неправильном использовании виртаульных методов. Конкретные реализации должны быть окончательными (final в Java или sealed в С#), а значит, запрещать наследование (к сожалению не в каждом языке есть такая возможность). А вот создавать новые реализации данного интерфейса -- сколько угодно. Вроде бы всё хорошо. Создатель класса не полагается на кривую реализацию пользователя.

Но не тут-то было! В любом из приведённых решений пользователь может очень просто всё испортить. Достаточно просто в методе выполнить совсем не те действия, которые от него ожидаются. То есть, по сути, нарушить контракт. И тогда уж ничего не поделаешь. Получается что всё зависит от "чистоплотности" пользоватлеля, который решился на расширение функциональности класса через предоставляемые extensibility points. А расширяемость просто необходима в некоторых случаях. Совсем другое дело, что иногда её можно избежать.

tags: ,


This page is powered by Blogger. Isn't yours?