The lonely compiler

Шутка, конечно, но приятно :-)

2008-06-17T17:30:00.004+02:00

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

Я проверил свои знания русского языка и получил пятерку.

Сходи, проверься?

Там еще такие слова были:

Результаты тестирования
8 из 8 - Поздравляем, вы - вымирающий вид россиянина, отлично знающего свой родной русский язык. Вы один из немногих носителей элитарного знания, доступного в наше время единицам (4% от общего числа опрошенных). Второй вариант: вы - выпускник, которого хорошо натаскали на сдачу экзамена по русскому языку. Третий вариант: вы – репетитор. Или просто закончили филологический факультет и пошли работать не по специальности.

Комментированный стандарт: предварительные итоги

2008-05-17T23:24:00.006+02:00

Коллеги и друзья!

Я уже несколько раз писал о своей старой идее выпуска комментированного стандарта C++. Так вот, дело, кажется, сдвинулось с мертвой точки: некоторое время назад мы с коллегами из фирмы Интерстрон (www.interstron.ru) приняли решение о возобновлении этого проекта.

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

Многие в курсе, что сейчас рабочая группа ISO с бюрократической аббревиатурой JTC1/SC22/WG21 готовит новую редакцию стандарта C++. Скорее всего, окончательный текст будет готов к концу этого года, но формальная процедура принятия нового стандарта завершится не раньше, чем еще через год, а то и позже; по крайней мере, так оценивает сроки Страуструп). Нам показалось бессмысленным ждать момента формального принятия, и мы решили взять за основу нашего текста последнюю на настоящий момент версию (от февраля нынешнего года) предварительного стандарта («Working Draft», документ №2521, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf).

Конечно, с формальной точки зрения Working Draft – это не стандарт. Однако, наш опыт работы с предыдущей редакцией стандарта от 1998 года (а тогда мы писали наш компилятор C++ параллельно с процессом стандартизации и вынуждены были оперативно отслеживать изменения, производимые в нем) показывает, что на завершающих этапах серьезных добавлений в текст уже не вносится. Разумеется, мы будем вносить в наш текст последующие изменения, которые появятся в новых драфтах,- вплоть до момента сдачи книги в типографию, насколько это будет в наших силах.

К данному моменту текст предварительного стандарта практически полностью переведен. Это основной итог напряженной работы последнего времени. На следующей неделе мы начинаем активную деятельность по анализу текста: собираемся определить, какие положения стандарта требуют комментирования, в чем должен состоять комментарий и т.д. Следующий этап – собственно комментарии. Да, кроме перевода и комментариев, текст будет включать дополнительные материалы: толковый словарь понятий C++ («Краткий стандарт», или просто «Краткий курс» :-)), обоснование выбранных вариантов перевода технических терминов, синтаксические диаграммы и кое-что еще.

Наконец, о сроках. Мы собираемся выпустить наш перевод в печатном виде ближе к концу года (точнее не скажу, чтобы не сглазить :-)). Технические подробности, связанные с выпуском, и текущие новости я буду сообщать в процессе. Будет ли сделана онлайн-версия перевода и если да, то когда – сейчас решается.

"Редкая профессия" на сайте Интерстрона

2008-04-28T12:37:00.005+02:00

Типа информация. :-)
Моя давняя-давняя статья "Редкая профессия", о том, как мы делали компилятор C++, выложена на сайте фирмы Интерстрон (www.interstron.ru). Статья вышла в конце 1997 года в PC Magazine/Russian Edition, довольно долгое время лежала у них в электронном архиве, но недавно исчезла (наверное, в связи с десятилетним юбилеем :-)) По этой причине я счел естественным опубликовать ее на сайте "своей" фирмы, подправив кое-какие ляпы и опечатки (не все, к сожалению).

С момента выхода статьи я получил на нее довольно много отзывов, как в различных профессиональных форумах, так и в личных письмах. Один раз даже удостоился критики: автор, мол, "ничего не понимает в компиляторах" или что-то в этом роде. Было очень лестно :-). Как ни покажется удивительным, отзывы продолжают приходить и по сей день (даже с утверждениями, что "статья не устарела"!), что послужило дополнительным мотивом ее повторного опубликования.

Прямая ссылка на статью:
http://www.interstron.ru/upload/images/pubs/Redkaya_professiya.pdf
Enjoy! :-)

Да, чуть не забыл. Вопрос к читателям (на сто тысяч):
Если вы смогли одолеть этот довольно длинный текст, то как бы вы отнеслись к появлению статьи под условным заголовком "Редкая профессия: десять лет спустя" - с рассказом о том, что последовало за описанными событиями, и о некоторых других похожих проектах? Не умею устраивать голосование на блоге (да и не хочу заморачиваться, честно говоря), но узнать интегральное мнение было бы очень интересно...

UPD: Оказывается, статья не исчезла, а просто переехала на другое место в связи с редизайном сайта PC Magazine/RE. Прошу прощения за ошибку, и спасибо Олегу Лебедеву за поправку. Вот новая ссылка на статью.

Интервью Б.Страуструпа

2008-04-05T21:46:00.005+02:00

Недавно, 27-го марта, в Dr. Dobb’s Journal было опубликовано очередное интервью Б.Страуструпа. Заметная часть интервью либо повторяет более-менее известные исторические обстоятельства появления C++, либо содержит любопытные (хотя тоже ранее озвученные) взгляды автора этого языка на обучение программированию. Самое же для меня интересное – информация о готовящемся новом стандарте C++ (кодовое наименование C++0x). Вот наиболее важное в вольном пересказе.

Срок

Новый стандарт языка (по плану?) должен быть готов к концу 2008 года, но все процедуры ISO, связанные с его официальным принятием, обычно занимают много времени. Поэтому то, что сейчас известно под именем C++0x, скорее всего, станет C++10.

Стандартная библиотека

Нововведения в стандартной библиотеке хотя и существенны, но, по его мнению, недостаточны. Добавлены потоки (threads), регулярные выражения, хеш-таблицы (которые изначально присутствовали в оригинальной STL, но не были внесены в предыдущий стандарт), "умные" указатели. Много усовершенствований внесено в существующую библиотеку контейнеров. Наконец, в язык добавлен ряд низкоуровневых свойств (новая модель памяти и задачная библиотека - task library),которые, как он говорит, не предоставляют непосредственных выгод для программистов, но скорее призваны служить основой последующих нововведений (которые откладываются до так называемого "C++13"): разделяемая память, пулы потоков (thread pools), распределенное параллельное программирование. С другой стороны, эти новые свойства уже используются в некоторых мощных коммерческих библиотеках.

(Кстати, один очень интересный момент: Страуструп несколько раз на протяжении интервью жалуется на совершенно недостаточное финансирование процесса стандартизации, из-за которого некоторые важные нововведения в стандартной библиотеке так и не были должным образом рассмотрены и из-за этого в новый стандарт уже не попадают. Причем это высказано в достаточно резких выражениях: «the committee has so few resources», «absolutely no funding» и т.п. Это удивительное для меня обстоятельство: ISO, оказывается, недостаточно финансирует свои комитеты!.. А казалось бы: уважаемая международная организация, важность которой никем не подвергается сомнению, работающая эффективно, тщательно и весьма результативно...)

Нововведения в язык

Основной мотив добавления большинства новых свойств - повысить уровень языка введением полезных высокоуровневых абстракций, которые бы способствовали созданию более ясного и хорошо организованного кода без дополнительных затрат по времени выполнения и требуемой памяти (это почти буквальная цитата). К числу таких свойств относятся обобщенные константные выражения (generalized constant expressions), статические утверждения (static assertions), ссылки на r-значения (rvalue references), а также новые возможности задания перечислимых типов.

Отдельно следует упомянуть новый механизм поддержки обобщенного программирования, который называется concepts. (Предвижу очередную вакханалию и произвол в попытках перевести это название на русский; буквальный эквивалент "концепция" или "понятие" звучит слишком общо и малосодержательно. Может быть, концепт? Механизм все равно новый, так пусть и слово новое будет?) Содержательно этот механизм предназначен для преодоления одной из основных проблем, связанных с шаблонами,- полным отсутствием в языке каких-либо средств контроля фактических параметров настроек шаблонов.

От себя замечу, что механизм concepts продвигается в язык уже довольно давно небольшой группой специалистов во главе с самим Страуструпом. Предложение прошло несколько стадий обсуждений в рабочей группе, было выпущено несколько редакций его описания, вышло несколько статей на эту тему. Не уверен точно, но решение о внесении этого механизма в язык уже, кажется, принято. Однако в последнем драфте нового стандарта (февральском) концептов еще нет.

Будущее C++ после принятия нового стандарта

Помимо новых возможностей стандартной библиотеки, которые (вынужденно, см. выше) отложены на будущее, Страуструп упомянул мультиметоды (диспетчируемые по динамическому типу нескольких аргументов, а не только первого), а также эффективную реализацию динамического приведения (dynamic cast).

Друзья, не спрашивайте меня, в чем существо упомянутых нововведений: сам еще толком не знаю. :-) В последующих постах собираюсь постепенно рассказывать о новых языковых свойствах, по мере того, как сам в них буду разбираться (но до новых библиотек руки, боюсь, скоро не дойдут). Одним из первых на очереди - попытка понять, что же такое concepts...

Lisp на "Эльбрусе" (вторая предыстория)

2008-03-10T20:13:00.002+01:00

Очень скоро после того, как я отошел от идеи реализовать на "Эльбрусе" полный Lisp, в журнале "Программирование" (очень неплохой был журнал; он жив и посейчас, но никто о нем, кажется, не знает и не вспоминает...) вышла статья А.Рейтсакаса из Таллина... ровно на ту же самую тему: Lisp на "Эльбрусе"!

В статье описывалась реализация какой-то (не помню) версии Лиспа, причем, насколько можно было судить по статье, она была на порядок серьезнее, проработаннее и качественнее, нежели мой глупый интерпретатор. У него там, собственно, был представлен полный Лисп, и предусматривался режим "настоящей" компиляции - непосредственно в коды "Эльбруса", и еще какие-то аспекты, активно использующие богатые архитектурные возможности этой машины.

Не скрою, я был расстроен и задет. Конечно, все негативные эмоции были направлены на самого себя: ведь мог бы (должен был!) гораздо серьезнее подойти к делу, уж если задумал такое нетривиальное предприятие. И описание Лиспа надо было найти, ведь он же смог!

Конечно, у меня нашлись объяснения. Мы находились совершенно в разных обстоятельствах: Саша работал в Академии Наук Эстонской (тогда еще) ССР, реализация Лиспа была темой его диссертации и, тем самым, основной обязанностью "по службе". Мой же "проект" был полнейшей самодеятельностью, и надеяться, что начальство позволит мне уделять рабочее время теме, хоть и интересной самой по себе, но решительно не относящейся к тематике нашего "ящика", не приходилось.

Некоторое время спустя, когда мы с Сашей познакомились, я "организовал" у своего начальства отзыв на его диссертационную работу, необходимый для его защиты (попросту говоря, написал этот отзыв и попросил подписать). А Саша и после защиты продолжал заниматься той же темой: в скором времени в его переводе вышел двухтомник финских авторов "Мир Лиспа", который и по сей день, кажется, остается почти единственной толковой русскоязычной книгой по этому языку. Ее скан и сейчас можно откопать в Интернете.

И - закон парности событий! - примерно в это же самое время появилась еще одна работа, тематически очень близкая: московский аспирант (как же его имя?- кажется, Володя Лихолип... Если ошибся, прошу извинить - все-таки много лет прошло) реализовал для того же "Эльбруса" язык Плэнер (Planner), довольно часто упоминавшийся тогда в литературе, а ныне, кажется, совершенно забытый. Planner предназначался для программирования ("планирования", отсюда и название) поведения роботов и содержал в себе полный Lisp как подмножество. Помимо этого, в нем, помнится, был целый ряд нетривиальных и очень интересных свойств, делающих его мощным инструментом программирования в сфере искусственного интеллекта и подобных областях.

Реализация Плэнера составляла весьма серьезную программистскую задачу - я вполне мог об этом судить, так как к тому времени появилась книга по этому языку,- и пусть даже язык был реализован не полностью (на своей защите он честно об этом сказал), я был преисполнен глубокого уважения к этому скромному парню.

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

Впоследствии мне еще несколько раз приходилось испытывать подобные чувства: и когда я познакомился с новосибирскими разработчиками PL/I и Ады, и когда В.О. Сафонов из Питера рапортовал о рекордном быстродействии своего Паскаль-компилятора, который обгонял даже "родной" для "Эльбруса" компилятор Эль-76... Я был чужим на этом празднике жизни, занимаясь системным администрированием, поддержкой и обучением пользователей, разрабатывающих для "Эльбруса" "боевые алгоритмы", смысла которых я почти не понимал...

Основной вывод, который я сделал для себя тогда... Да вру, никаких выводов я не сделал. Просто порасстраивался, и продолжал жить дальше. В конце концов, у меня еще все впереди, появится и у меня классная компиляторная работа!.. (десять лет пришлось ждать...)

И в заключение это нехитрой истории (предыстории, не забывайте - настоящая история еще впереди :-)) - рассказ о том, как я все-таки разжился полным описанием Лиспа. Случай короткий и простой, но в то время он произвел на меня очень большое впечталение.

В середине девяностых мы, уже работая в МГУ, активно занимались языком C++, делая компилятор по заказу одной европейской фирмы (см. "Редкая профессия"). Наша работа шла параллельно процессу стандартизации C++ в ISO, и от наших заказчиков мы регулярно получали текущие материалы рабочей группы, занимающейся разработкой этого стандарта - стенограммы обсуждений, принятые технические решения, планы и т.д. И вот у моего шефа, профессора В.А.Сухомлина, возникла идея более тесно и, самое главное, официально участвовать в этом процессе в качестве представителей от России. Основания были более чем весомые: наша команда работала над реализацией языка, основываясь на последних решениях рабочей группы, кроме компилятора, мы разрабатывали тесты на соответствие стандарту - так почему бы нам более активно, с учетом собственного опыта, не участвовать в работе этой группы?

До той поры контакты с рабочими группами ISO по различным языкам формально шли через какой-то отдел НИЦЭВТа - конторы, которая в советское время занималась разработкой ЭВМ Единой Серии. Несмотря на несколько ироническое отношение к характеру и качеству их разработок (все специалисты прекрасно знали и понимали степень "оригинальности" их решений), следует признать, что с чисто промышленной точки зрения эта организация делала очень важное дело, занимаясь масштабным внедрением вычислительной техники во все отрасли народного хозяйства. Да и, кроме того, за ЕС ЭВМ надо признать по крайней мере один большой плюс: унификацию периферийного оборудования, в том числе их интерфейсов. Дисковые и ленточные накопители, дисплеи, графопостроители и другая периферия на "Эльбрусе" вся была ЕСовская. Правда, со смертью обеих этих ветвей отечественной вычислительной индустрии все это потеряло всякий смысл и значение...

Но в советское время НИЦЭВТ процветал, и, конечно, вид их главного здания поражал воображение: исполинский многоэтажный комплекс из стекла и бетона, почти на километр вытянувшийся вдоль Варшавского шоссе, повторяя его изгиб...

Вот в это здание я и отправился однажды холодным зимним днем, чтобы по договоренности между начальством забрать материалы по стандартизации языков программирования: теперь контролировать этот процесс должна была наша лаборатория в МГУ.

...Друзья, это был шок!
Представьте: огромное здание, промерзшее насквозь (отопления то ли не было, то ли не работало), длиннейшие коридоры, перспектива которых терялась в темноте (электричество то ли не работало, то ли его не было :-))... И самое главное: пусто. Людей не было - ни в коридорах, ни в комнатах. А судя по длине коридоров и размерам комнат, они были явно расчитаны на большие коллективы работников... И легко было представить, как, наверное, выглядело это все в лучшие времена: спешащие, переговаривающиеся, озабоченные люди, сознающие важность своей работы, комнаты, полные опытных специалистов, склонившихся над электронными ли платами, распечатками ли операционной системы... В общем, с тех пор дух того времени прочно ассоциируется у меня с этими поистине апокалиптическим видами бывшего флагмана советской вычислительной индустрии...

(Спаведливости ради - и, так сказать, для баланса - должен заметить, что примерно в те же времена один из "конкурентов" НИЦЭВТа, институт, где проектировались, создавались и программировались "Эльбрусы" - ИТМиВТ - выглядел не лучше. Такая же пустота и запустение. Правда, ощущения сбывшегося апокалипсиса не возникало - но и то лишь из-за сравнительно скромных размеров эльбрусовского "гнезда"...)

В нужной мне комнате, ссутулившись под накинутым пальто, спиной ко входу сидел одинокий человек потерянного вида. Узнав о цели моего прихода, он равнодушно кивнул на шкаф, набитый документами, и отвернулся. Через десять минут лихорадочного просмотра бумаг я понял, какое богатство плывет ко мне в руки, и еще через полчаса приготовленная сумка уже раздувалась от текстов стандартов и других материалов ISO...

Быстро попрощавшись с зябнущим хозяином комнаты, я с деловым видом подхватил сумку и вышел, стремясь поскорее покинуть это умирающее место (и страшась: вдруг меня остановят и заставят вернуть награбленное :-)). Надо ли говорить, что среди материалов по C++, в сумке лежало много документов, к этому языку не имеющих никакого отношения. А среди них - рабочий вариант международного стандарта языка Lisp!..

5 инструментов, без которых я не могу работать продуктивно

2008-03-08T21:03:00.024+01:00

У Алены Сагалаевой увидел приглашение поучаствовать в опросе (спасибо, Алена!). Получилось довольно длинно, так как без комментариев обходиться не умею. :-)

Для начала хотел бы сравнить инструменты, которыми я пользовался в процессе разработки компилятора Си++ (десять лет назад), и теми, с которыми работаю сейчас.

                      1998                    2008
Файловый менеджер     Norton Commander        Total Commander
Компилятор            gcc                     C++/C# из VS
Отладчик              gdb                     Отладчик VS
Текстовый редактор    Multi-Edit              Редактор VS
Ведение версий        CVS                     SourceSafe
Интернет-броузер      Netscape                Internet Explorer
Почтовая программа    Netscape Communicator   Gmail
Персональный организатор                      The Journal, Onfolio

Несколько комментариев.

Файловый менеджер
Я довольно консервативен, да и просто не вижу причин менять привычную парадигму манипуляций с файлами/каталогами. Модель с двумя окнами кажется мне удобной и совершенно адекватной подавляющему большинству практических потребностей. Встроенный в винду Windows Explorer, на мое скромное имхо, безумно коряв с эстетической точки зрения и очень неудобен в работе (даже для рядовых пользователей); даже если потратить довольно много времени на его настройку, результат явно неудовлетворителен. Кстати, никакими плагинами к TC не пользуюсь, может, зря – но времени жалко их выбирать, ставить, пробовать, проверять... Единственный недостаток TC – он довольно медленно работает с большим количеством файлов (несколько сот штук) зараз. Впрочем, может быть, это не он виноват, а нижележащая ОС, но мне лень копаться в настройках самой винды...

Компилятор
Отладчик
Редактор
Ведение версий
Visual Studio, по моему мнению,- очень хорошая интегрированная среда, и я не разделяю практически ни одного из критических замечаний о ней, которые мне приходилось слышать. Inellisense и другие удобства, которые некоторые презрительно именуют "свисточками и звоночками", реально помогают мне программировать и существенно облегчают и ускоряют мою работу. К сожалению, для работы с Си++ и в особенности с ASP.NET уровень поддержки со стороны среды заметно слабее, чем для C#. Версию VS не указываю, так как использую несколько на разных компьютерах.

Так как эти четыре средства можно считать за единую интегрированную среду, то у меня остаются свободные позиции. :-) Поэтому я добавлю в свою версию списка еще кое-что.

Интернет-броузер
Я ни разу не фанат ни самого Микрософта, ни его продуктов, но - опять-таки - считаю, что IE - вполне приличный инструмент, и не испытываю серьезных проблем в работе с ним. Да, иногда он тормозит и даже, бывает, слетает, но кто скажет, что другие приборы всегда быстры и супернадежны? Кроме того, мне важно, что с ним интегрирован Onfolio (см.ниже). Да и вообще, чтобы перейти на другой броузер, мне нужны - кроме простого человеческого любопытства - достаточно весомые причины...

Почтовая программа
Плюсы GMail всем известны - быстрота, простота, надежность - у меня ни разу не было проблем вроде пропажи аккаунта или (части) писем. Письма приходят ко мне и от меня к моим адресатам без заметных задержек, что иногда случалось с другими почтовиками. Вполне приличный спам-фильтр. Плюс, конечно, возможность зайти в него отовсюду, где есть связь.

Однако, рискну и здесь высказать точку зрения, отличную от многих слышанных. GMail, как мне кажется, вовсе не идеальная программа по своему дизайну и практическому удобству. В частности, совершенно не разделяю восторгов насчет "ярлыков" (labels): у меня, например, их штук сто (писем очень много, и нужно же их хоть как-то упорядочивать!), в результате список этих ярлыков вытянулся на несколько экранов вниз. Список примитивно-линейный, и никакого другого решения программа не предлагает. (Не говорю уж о том, что под многими ярлыками на самом деле скрываются письма, которые, будь у меня возможность, я бы распихал в различные разделы!) Поиск по письмам, усердно впариваемый как всеобщая панацея, мне приходилось использовать от силы раза три за все годы работы с GMail, и только в одном случае я нашел, что искал.

Совершенно необходима нормальная, универсальная и всем привычная парадигма иерархического хранилища (папки, попросту). Ярлыки очень удобны и полезны - но только как дополнение к папкам. По невнятной инсайдерской информации что-то подобное должно было появиться еще с год назад, но... до сих пор ждем и надеемся.

Отсутствие необходимости удалять ненужные письма, тоже выставляемое как просто-таки потрясающе революционное свойство - на самом деле очень смешная вещь: совершенно непонятно, почему пользователи должны бурно радоваться этому обстоятельству? Мы ведь все периодически убираем наши рабочие комнаты и рабочие компьютеры от ненужных бумаг (файлов), которые имеют обыкновение скапливаться на столах, в тумбочках и на жестких дисках с необыкновенной быстротой? И что будет, если нам вдруг скажут: ребята, теперь у вас в компьютере огроменный жесткий диск (если надо будет, еще один такой же поставим), поэтому операцию "удалить файл" вам теперь использовать нельзя?.. (Кстати, где-то читал, что поначалу кнопки "Удалить" в GMail не было вообще, и ввели ее с большой неохотой только по настоянию пользователей...)

Вообще, рискуя навлечь на себя шквал критики, скажу о некотором сходстве философии авторов GMail и... языка Си (!!!). Как мне кажется, оба эти инструмента создавались (кстати, и тот и другой - двумя друзьями!) согласно очень схожей философии: то, что удобно нам, авторам, будет, разумеется, удобно и всем остальным - как же может быть иначе? Вот и появилась совершенно безумная по дизайну нотация ("понятная, разве что, специалистам по криптографии", как сказано в одной старой книге), к которой, однако, привыкла тесная компания разработчиков UNIX, и почтовая программа, в которой все письма лежат бессистемной кучей, а единственным средством в этой куче разобраться служит "революционный" поиск нужного письма по куску текста из него, который несовершенная наша память успела запомнить...

Могу предположить: наверное, очень не любили Сергей и Ларри убираться в своих комнатах в университетской общаге - и придумывая свой почтовик, перенесли эту нелюбовь в его дизайн. В самом деле: если мы такие, то ведь и все другие ненавидят наводить порядок в своих вещах и делах!..

Персональные организаторы
(Схитрил: в одну позицию запихал сразу две программы, но они того стоят): The Journal и Onfolio.

Очень долго – несколько лет – искал подходящие инструменты для организации персональных данных, перепробовал, наверное, все, что мог найти в известных коллекциях. Уже надежду потерял, но в итоге все-таки нашел и почти счастлив :-) Не сочтите за рекламу (хотя, собсно, почему бы и нет?)

The Journal (http://www.davidrm.com/) – в нем я веду профессиональный дневник (только для себя), сохраняю наиболее важные письма, готовлю тексты для блога, составляю и веду различные рабочие планы и вообще, храню всю текстовую информацию, имеющую отношение к моим проектам. Очень удобная программа: то, что действительно важно, она автоматизирует (например, ведение дневника), второстепенные детали оставляет на усмотрение пользователя. Документы можно организовывать в виде древовидной структуры любой сложности. С точки зрения дизайна программа вполне традиционная и не требует много времени на освоение. Встроенный редактор сделан на движке от Ворда и предоставляет вполне адекватную моим потребностям функциональность, включая хорошую поддержку таблиц. Вполне отрабатывает свои 40 долларов :-).

Onfolio – средство для сбора информации из Интернета. Можно собирать и структурировать ссылки и делать вырезки из страниц сайтов. Есть известное количество программ, предоставляющих аналогичный сервис, но для меня эта - однозначно лучшая. Вырезает куски на редкость адекватно, с полным сохранением оформления, позволяет редактировать вырезанное (правда, редактор все-таки слабоват). Структурируется информация традиционными парадигмами – есть понятие коллекции, в которой можно создавать каталоги, а в них – записи. Коллекция – это просто файл. При вырезании запоминается дата и адрес источника, можно добавлять свои атрибуты (заголовок, описание, цветной флажок). Очень не хватает тегов, средств упорядочения каталогов и цветового выделения заголовков записей. Собранные коллекции (части коллекций) можно экспортировать в виде единого mhtm-файла, который прекрасно отображается броузером. Разумеется, в записях можно хранить не только вырезки, но и произвольные тексты, PDF-документы, фотографии и прочее... Есть фид-агрегатор, но я его не использую. Программа встраивается в IE (в панели Windows Live Toolbar появляются дополнительные кнопочки) и управляется очень просто. Кроме плагина для IE, в комплекте есть и независимый вариант: Onfolio Deskbar.

В свое время я по-честному купил Onfolio и с удовольствием юзал ее года два, но в один прекрасный день фирму-разработчика купил Микрософт, и программа стала бесплатной составной частью Windows Live :-). Ссылку не даю – потерял, а снова искать лень. Программу точно можно найти в недрах микрософтовского сайта, но придется немного покопаться: прямая ссылка из раздела Windows Live не работает, придется искать обходные пути. Но она там точно лежит! :-)

Передаю эстафету (только троим; к сожалению, не все коллеги, предпочтения которых могли бы быть интересны, ведут свои блоги):

Александр Кротов
Дмитрий Гурьев
Сергей Розовик

"Древовидный" C++

2007-11-06T17:14:00.000+01:00

Сергей Прохоренко в комментарии написал:

Вот несколько моих постов в форумах, которые могут быть полезны для Вашей разработки «древовидного» Си++...

Сергей, спасибо за ссылки и развернутые комментарии, а также за идею заголовка для этого поста :-). Практически со всеми соображениями, высказанными Вами, можно согласиться. Хочу только немного прояснить свое, так сказать, профессиональное «позиционирование» (выделения в Ваших цитатах – мои):

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

Хочу подчеркнуть, что структура программы (компилируемые модули, области видимости имен, объекты) и структура модели (подсистемы, элементы) вообще говоря не обязаны совпадать. При разработке сверху вниз следует начинать со структуры модели, на которую затем накладывать структуру программы.

Иными словами, Вы – совершенно справедливо - выделяете два фундаментальных компонента: модель предметной области и (программную) модель, ее реализующую. Ваши примеры касаются обоих компонентов; однако мои интересы все-таки ближе к программным моделям (каждый должен заниматься своим делом :-)); формализация и структурирование предметной области – все-таки весьма специфическая и далекая от меня задача, я пытаюсь что-то делать, скорее, в сфере анализа языков программирования как таковых.

Именно этому – своему проекту, которым я занимаюсь несколько последних месяцев – я хотел бы посвятить ближайшую серию постов (почти уже готовых). Речь там пойдет только и исключительно о том, как половчее представить программу на ЯП в виде дерева (а на самом деле, конечно, графа) и какие преимущества можно из такого представления получить.

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

И последнее замечание.
В некоторых текстах (не у Вас конкретно) чувствуется некая склонность к преувеличению важности для конечных пользователей "древовидного представления" программ. Я уже писал, что скептически отношусь к попыткам полной смены программной парадигмы: мол, синтаксис – гадость и излишество, давайте его выкинем и перейдем на древовидное представление программ (а заодно и обобщим все на свете: чего там, ведь условный оператор и в Си, и в Модуле, и где-там-еще представляется одинаковым деревом... :-)).

Менталитет разработчиков – вещь все-таки довольно деликатная и требует по крайней мере уважительного отношения. Чтобы совершить подобное насилие над привычками программистов, нужно предложить нечто, что было хотя бы таким же простым, удобным и универсальным, как синтаксически организованный программный текст. Чтобы манипулировать деревом, нужна как минимум адекватная поддержка – соответствующие программные инструменты – не говоря уже о том, чтобы такие инструменты сравнились по простоте и удобству с типичными текстовыми редакторами. Конечно, могут возразить, что в принципе манипулировать деревом ненамного сложнее, чем текстом на формальном языке – однако фундаментальное преимущество текста заключается в том, что с ним можно успешно и эффективно работать великим множеством способов - вплоть до листа бумаги.

Поэтому, если говорить о конечных пользователях – программистах, я бы все-таки рассматривал древовидное представление программы как дополнительное средство – для визуализации и навигации, например,- наряду с обычными (продвинутыми) текстовыми редакторами. С другой стороны, любой сколько-нибудь серьезный инструмент для работы с программными текстами (компилятор, например) практически всегда будет основываться на древовидном представлении. Существенно то, что дерево служит сугубо внутренним целям этого инструмента.

(Между прочим, редактор Visual Studio включает элементы «древовидного» подхода – фрагменты текста программы, соответствующие отдельным синтаксическим конструкциям, можно избирательно сворачивать и разворачивать. К сожалению, набор языковых конструкций, управляемых редактором, ограничивается пространствами имен, классами, функциями и комментариями и не распространяется на «внутренности» функций. Скорее всего, нечто подобное и в Эклипсе есть; может, даже и получше, чем в VS?)

Недавняя статья Страуструпа

2007-11-06T15:25:00.000+01:00

Evolving a language in and for the real world: C++ 1991 - 2006
Ссылка: http://www.research.att.com/~bs/hopl-almost-final.pdf
Статья большая, почти 60 страниц.
Написана для очередной конференции по истории языков программирования.

Первые главки статьи повторяют некоторые ранние статьи и его книгу "Дизайн и эволюция С++", но интерес также представляет информация, относящаяся к процессу принятия нового Стандарта C++.

В целом, статья, безусловно, стоит того, чтобы ее внимательно прочитать.

Собственно, сама статья – не новость, и в некоторых блогах ее комментировали еще летом; см, например, здесь. Но, кажется, никто не заметил (или просто не счел интересной?) короткую, но поистине замечательную фразу (выделения мои):

C++'s success in real-world use also led to influences that are less beneficial. The frequent use of ugly and irregular C++ style of syntax in modern languages is not something I'm proud of. It is, however, an excellent indicator of C++ influence - nobody would come up with such syntax from first principles.

Удивительно видеть такую трезвую и недвусмысленную оценку «большого стиля» C++ от самого создателя этого языка! И одновременно, с чувством глубокого удовлетворения наблюдать такой классный пинок тем, кто копирует «ugly and irregular style of syntax» из примитивно понятых «маркетинговых» соображений... Все ведь понимают, в чей огород этот камень.

P.S. Возможно, в иных обстоятельствах не так бы это зацепило, но как раз сейчас борюсь (в очередной раз...) с этим нерегулярным синтаксисом и семантическими трудностями, которые - как ни покажется странным - порождаются именно этим синтаксисом...

XML как замена всему :-)

2007-11-05T12:26:00.000+01:00

А вообще, конечно же, синтаксис надо давить.
Без синтаксиса лучше.
По этой причине Лисп и стоит выше всех прочих, вместе взятых
(Из комментариев)

- Авек плезир! - отозвался Фагот, - но почему же
с вами одним? Все примут горячее участие!
(«Мастер и Маргарита»)

А почему же только Лисп? См. второй эпиграф.
А почему только синтаксис? Почему не задавить заодно и семантику? :-)

Ну, разумеется, рядом с Лиспом по степени, так сказать, отсутствия синтаксиса, поставить почти нечего. В самом деле, если отвлечься от лексических соглашений и немногих технических деталей вроде спецификации параметров или точечной записи, синтаксис Лиспа описывется всего тремя тривиальными правилами :

Program ::= List
List ::= '(' { Element } ')'
Element ::= List | Atom

Весь язык, собственно говоря, «перетек» в семантику – в правила интерпретации списков, которые (правила) определяются в зависимости от первого элемента.

Насколько это упрощает/усложняет программирование и чтение Лисп-программ – давайте не будем касаться этого вопроса. Сейчас мне хочется просто отметить интересное сходство Лиспа и... XML.

В самом деле, XML ведь тоже (опять-таки, если не брать во внимание второстепенные технические детали), предельно прост:

XMLDocument ::= Element
Element ::= StartTag { Content } EndTag
Content ::= Element | NonstructuredText

Те же три (и очень похожие!) правила. (Правда, в StartTag еще и атрибуты можно задавать, но это та деталь, которой хочется пренебречь для элегантности сравнения... :-))

У XML, в отличие от Лиспа, нет собственной семантики – это всего лишь язык разметки. Смысл XML-документу придают агенты, его воспринимающие – либо люди, либо программы, с ним работающие. Но отсутствие семантики парадоксальным образом оборачивается невиданным расширением сфер использования: с помощью XML можно описать практически все на свете; главное – договориться, как именно описывать и как понимать/интерпретировать такое XML-описание. Для первого служат DTD, Schema или различные неформальные соглашения, для второго – шаблоны XSLT плюс смежные технологии, а также стандартизованные программные интерфейсы – DOM, SAX и подобные.

Вообще-то писать на эту тему можно очень много, но сейчас я хочу только лишь указать на проект Superx++ (http://xplusplus.sourceforge.net/), интересный как раз попыткой предложить XML как замену синтаксиса всеми нами любимого языка C++.

Собственно, смысл проекта достаточно прост: предлагается нотация, полностью заменяющая синтаксис C++ эквивалентными XML-конструкциями. Правда, более внимательное чтение примеров не подтверждает полной замены: автор не решился «xml-изировать» язык целиком и синтаксис выражений оставил в исходном виде. Более того, в какой-то момент он, похоже, испугался собственного радикализма и предложил некий «промежуточный» вариант под названием shortx, в котором язык переведен в XML-нотацию только частично...

Вот, полюбуйтесь: объявление класса в XML-нотации. Исходное, «плюсовое» объявление легко восстановить.

<class name="XTree">
  <scope type="public">
    <func name="GetSize" type="int">
      <return>
        <eval member="Size" object="this">
      </return>
    </func>
    <var name="Size" type="int">200</var>
  </scope>
</class>

Отметим, что (само)уверенности автору не занимать: одна из его первых статей на эту тему называется так: x++: The World's First Full XML-Based Programming Language Released!

(Сначала язык назывался X++, но это имя оказалось занято более «авторитетными» компаниями, и автору пришлось сменить его на superx++.)

Что касается собственно проекта Superx++, то его реализация не вышла из беты, а с 2004 года он, кажется, не развивается; по правде говоря, трудно представить себе какое-то реальное практическое применение такого парадоксального подхода... В общем, любопытна только идея как таковая, а также некоторые технические подробности; в частности, такая.

Для superx++ автор сделал интерпретатор, причем написал его на плюсах. А почему не попытаться применить для этой же цели XSLT? Это выглядело бы логично: ведь он как бы хочет по максимуму использовать преимущества XML-технологий? Понятно, что автор хотел сделать эффективный инструмент, так как надеялся найти практическое применение своему проекту (даже фирму специально для этого сделал), но мне кажется, исследователькая ценность проекта от такого выбора только бы возросла, при этом совершенно неважно, в какой мере это ему бы в итоге удалось. Даже отрицательный результат здесь был бы очень интересен; по крайней мере, мы бы лучше себе представляли границы применимости шаблонов XSLT. Я, например, давно хочу эти границы применимости почувствовать...

UPDATE: совершенно случайно вдруг увидел старую статью В.Турчина:

Рефал как язык для обработки xml-документов
Валентин Турчин

Опубликовано в журнале "Компьютерра" №25 от 02 июля 2001 года
Ссылка: http://www.computerra.ru/2001/402/10900/

Там, помимо вопросов обработки XML-документов средствами Рефала, обсуждается и вариант XML-нотации для этого языка...

Простота и сложность: завершение

2007-10-31T12:32:00.000+01:00

Коллеги, я бы хотел постепенно завершить дискуссию «Простота и сложность». Во-первых, все самое главное, кажется, уже сказано, и повторять соображения еще раз не стоило бы – как мне, так и моим комментаторам. Во-вторых, хочется постепенно перейти к темам, обозначенным в самом первом моем посте (и вообще, приблизиться к компиляторной тематике :-)), и потому нужен некий перерыв, чтобы собраться с мыслями.

Конечно, отвечать на комментарии было бы логично в соответствующем разделе. Но развернутый ответ там не напишешь: получается слишком длинно и «некрасиво», потому приходится делать отдельный пост.

Прежде всего, должен извиниться за безграмотность.
Вот что мне написали в комментариях:

> Си: линейная последовательность функций. Си-функция не может хранить собственный контекст между своими вызовами (это «stateless»-компонент), поэтому для обеспечения сколько-нибудь нетривиального взаимодействия приходится активно использовать глобальные переменные.

То есть как так? А как же static-переменные внутри функций? Они же инициализируются один раз при первом вызове функции, а затем сохраняют своё значение между вызовами функций:

Виноват, совсем забыл про локальные статики. Каюсь. Насчет того, что функции – это stateless-компоненты, дурака свалял. Вообще, весь процитированный абзац выглядит не слишком логичным: взаимодействие функций никак не может быть связано с их собственными контекстами; каждый такой контекст служит как раз для сохранения значений между вызовам самой этой функции и недоступен другим.

Кроме того, и к самой теме поста – «какая модульность мне нужна» - этот пассаж не имеет особого отношения. Функции в Си если и могут быть названы модулями, то разве только совсем уж «кончеными» фанатами Си. :-)

Править основной текст после появления справедливых комментариев – не слишком корректно, потому ограничусь этим ответом.

Комментарии AVP и мои комментарии на комментарии :-)

Да, в Обероне есть модули. Очень хорошее средство; где-то я уже писал, что считаю модульность (не путать с возможностью раздельной компиляции компонент!) исключительно важным свойством языка, которое не менее (а иногда и более) существенно, нежели, скажем, поддержка ООП.

С тем, что модульность иногда важнее ООП, согласен. Но не понимаю, чем Вам раздельная компиляция "не угодила"? :)

Да почему же не угодила? Нормальное средство для Си и подобных языков, естественно вытекающее из линейной структуры программ и практических потребностей разработки. Другое дело, что это вполне, так сказать, «безыдейное» средство: грубо говоря, разрезать программу на части можно почти произвольным образом (в языке нет явных правил оформления этих частей) и положить их в разные места, сказав, что эти части будут компилироваться раздельно. Кроме того, этого явно недостаточно; об этом, собственно, и был предыдущий пост.

Возможно, здесь просто терминологическое расхождение (иногда раздельной (separate) компиляцией называют то, что - в терминологии Вирта - называется независимой (independent) компиляцией).

Ну, примерно так. Мне бы хотелось, чтобы в языке были развитые средства структурирования программ (та самая модульность), а уж техническая возможность компилировать структурные компоненты программы по отдельности подразумевалась бы как естественное следствие этой модульности. Собственно, примерно как в Аде. Модуль (пакет, подпрограмма, задача) – это языковое понятие; раздельная компиляция – больше требование к среде программирования: - к компилятору, линкеру и т.д.

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

Но вот достаточно ли простого набора одинаковых сущностей (и опять, как и в Си, линейного), чтобы адекватно отражать многообразные отношения между частями создаваемой системы?

Почему это набор модулей линейный, как список функций в Си? Между модулями существуют отношения экспорта/импорта, благодаря которым (1) они образуют иерархическую расширяемую структуру (даг), (2) корректный порядок инициализации модулей гарантирован.

Конечно, линейный. Отношения импорта/экспорта сами по себе не дают нового качества. Функции в Си характеризуются такими же по сути отношениями импорта/экспорта: каждая функция экспортирует свое имя и импортирует имена всех доступных функций и глобалов. Оберон-модули как таковые не образуют расширяемую иерархическую структуру: такую структуру образуют расширяемые типы внутри модулей. Структура Оберон-программы, скорее, маскирует, скрывает расширяемую иерархию типов. Иными словами, сейчас Оберон-модули – это однородный набор контейнеров, по которым распределено дерево типов.

Если вывести типы из-под «власти» модулей и сделать сами эти типы модулями (записи, собственно, и так являются концептуально вполне самостоятельными сущностями, потому это выглядит, на мой взгляд, очень естественно и логично), то общая структура программы станет более ясной и адекватной задаче, реашемой этой программой. Примерно так и сделано в Зонноне.

Так, да не совсем: расширяемые записи (аналог классов в более распространенных языках) не являются средством структурирования программы в целом.

Слишком категорично сказано, вызывает сомнение.

Да вроде не слишком и категорично? Оберон-программа – это же набор одинаковых модулей-синглтонов, ведь так? То обстоятельство, что внутри этих модулей, так сказать, «кипит жизнь» в виде расширяемых записей и связанных с ними («примкнувших к ним» :-)) процедур, не меняет этой общей картины? Снаружи – линейный набор контейнеров, внутри конетейнеров – расширяемые типы, смесь «обычных» и связанных процедур и прочего...

Особенно, если вовремя вспомнить об обероновской программной шине или (на тему того, что модули как-то ограничивают записи) инсталлируемых каталогах объектов (например, в BlackBox).

Я, честно говоря, не очень осведомлен насчет решений, воплощенных в Блэкбоксе, но подозреваю, что каталоги объектов – это, судя по названию, средство, помогающее программисту увидеть, какие же типы содержатся в модулях программы и каковы отношения между этими типами. Иными словами, если я прав, то Блэкбокс как раз пытается преодолеть тот недостаток Оберона, о котором я и говорю.

А мне думается, что обероновское решение, дублированное в Аде, вводит принципиально другую (новую, если сравнивать с Си/Си++) архитектуру ПО: "тэгированную" (типизированную) память.

Наверное, можно сказать и так, но я не вижу здесь особенной разницы. Почему плюсовая архитектура не вводит эти типизированную память? По-моему, вводит. Кроме того, в моем посте речь шла, скорее, о средствах и возможностях структурирования программ (о модульности в широком смысле), а не об ООП-подходах.

Поэтому, между прочим, на обоих языках программировать объектно оказалось, попросту говоря, крайне неудобно.

А что значит программировать объектно? Возьмем в качестве примера (абстрактную) современную графическую ОС, основанную на обмене сообщениями. Ее объектная ориентированность вроде бы не подлежит сомнению. И на каком языке ее лучше программировать: на Си++ с его first-class классами :) или Обероне с его расширяемыми записями и проверкой динамического типа всего за одно сравнение? Можно даже сказать, что обероновская программная шина представляет собой простейшую реализацию схемы двойной диспетчеризации.

Честно говоря, я бы уклонился от общей дискуссии об ООП; наверное, я не чувствую себя для этого достаточно подготовленным (это все-таки не совсем компиляторная тема :-)). Пишу «объектно» вполне уверенно, а вот рассуждать и дискутировать... Извините.

А насчет удобства и неудобства – я имел в виду сугубо практические аспекты, через которые я проходил в свое время в Аде, пытаясь на основе примеров из какой-то статьи написать что-то свое в том же стиле. Кроме того, у меня есть сходные свидетельсва людей, которые пытались делать то же, но уже в рамках своей работы. Повторяю, речь идет о попытках проектировать конкретные программы на основе объектной парадигмы, оперируя конструкциями конкретного языка.

Надеюсь, из сказанного примерно понятно, чего мне недостает в Обероне.

Если я правильно понял, в Обероне Вам в основном недостает (1) более разнообразной (специалированной) модульности и (2) классов.

Примерно так. Только я не стал бы разделять эти два пункта. Мне представляется, что «класс» в том виде, как он есть в том же Си++, должен иметь статус полноправного (специализированного) модуля, наряду с другими.

Честно говоря, с первым согласиться легче. :)
Второе, по видимости, движение в том же направлении (по Мейеру, класс = тип + модуль), но вызывает большее сомнение: как уживутся "две женщины на одной кухне" (класс и модуль :) ).

Что значит «уживутся»? Они друг другу никак не мешают, скорее необорот, помогают и дополняют, и вместо Вашего образа двух женщин на одной кухне я бы предложил, скажем, двух рабочих, несущих что-то тяжелое. Любой из них в одиночку груз даже не поднимет, а вместе они его не просто подняли, но даже и перенесли и поставили куда надо...

Ведь тот же Си++, где классы являются объектами первого рода, - язык определенно не модульный.

Конечно, не модульный, но не потому, что там классы, а потому, что он прямой потомок Си и сохранил всю его архаику. Классы в этом смысле – только добавка. Важная, принципиальная, фундаментальная – но только в том, что касается ООП. В плане же модульности плюсы, к сожалению, ничего к Си не добавили. В конце концов, ведь известный слоган «Си с классами» в применении к плюсам именно об этом.

Не могли бы Вы подкинуть немного "инсайдерской" информации и ответить на давно мучающий меня вопрос? :)

Почему в Обероне нет шаблонов - понятно. Но почему в нем не прижились даже "облегченные" дженерики, предлагавщиеся в середине 90-х Шиперским?

Я задавал когда-то подобный вопрос Гуткнехту, но, к сожалению, не понял ответа (вероятно, помешал языковой барьер).

Вряд ли я могу что-то сказать определенное. Основная цель Вирта, как я понимаю,- оставить в языке только фундаментальные, сущностные свойства. Между прочим, в этом смысле, я скорее бы понял, если бы он ввел в язык как раз полноценные шаблоны – все-таки generic programming вполне можно считать одной из фундаментальных программных парадигм. (Правда, при создании Оберона это было, мягко говоря, не очевидно.) А что говорить об облегченных дженериках, если он перечислимые типы и цикл for удалил?..

Я несколько раз говорил с Виртом насчет generic programming (пытался рассказать ему, о чем, собственно, читаю лекции в ETH :-)), но особого интереса не почувствовал. Он когда-то общался с Александром Степановым, и мне показалось, что и тот не смог объяснить ему, чем важны и хороши дженерики... Кроме того, у Вирта, если я правильно ощутил, есть какое-то неприятие Степанова лично. Впрочем, не уверен, могу ошибаться. Возможно, он просто не считает GP столь уж важным подходом и потому относится не слишком серьезно и к его создателю.