Какие знания необходимы программисту - часть 2

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

Физические основы

Здесь "физические", от слова "физика" :-) Имеется ввиду наука физика. Наука великая
и странная, нужно нам из неё немного, а именно кое-что, связанное с электрическими цепями, а также электронными компонентами.

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

Архитектура компьютерных систем

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

• "фон Неймановская" архитектура построения компьютера (использование двоичных чисел, код и данные хранятся вместе, концепция "хранимой программы")
• Не-фон Неймановские архитектуры (гарвардская)
  
• Микропроцессор (оп-коды, регистры, устройство с "электронной" или "физической" точки зрения)
  
• Шина данных (с "электронной" точки зрения)

Операционные системы

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

• Предназначение ОС
  
• Процессы и потоки
• Управление памятью
• Ввод/вывод
• Файловые системы
• Безопасность
• Структура операционных систем (монолитные ОС, ОС с микроядром, виртуализация)
  

Сети

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

• Физические основы (каналы, пропускная способность каналов, виды каналов, виды волн)
• Семиуровневая модель OSI
• Безопасность в сетях

Базы данных

• Типы баз данных
• Реляционная алгебра
• Реляционное исчисление
• Проектирование баз данных (функциональные зависимости, нормализация)
• Защита данных
• Объектно-ориентированные базы данных
• Структуры хранения и методы доступа к данным
  

Криптография

• Симметричные и асимметричные методы
  
• Хэш-функции
• Стойкость
• Криптографические протоколы
  

Основы программирования

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

• Язык ассемблера - основы (смысл не в том, чтобы знать какой-то конкретный ассемблер, а в том чтобы знать что это такое, и как именно согласуется ассемблер с "физическими" основами компьютеров)
• Парадигмы программирования (процедурное, объектно-ориентированное, функциональное, логическое, аспектно-ориентированное, DSL, метапрограммирование)
• Основные концепции, достоинства и недостатки каждой из парадигм
• Основы проектирования (объектно-ориентированный анализ, и тому подобное)
• Компиляторы и интерпретаторы (разница, преимущества и недостатки)
  

Вы знаете, я сам удивился, но я больше не знаю что написать в "обязательный" список. Я только что сидел и перебирал в голове разные, как мне кажется полезные, темы, типа "Design Patterns", рефакторинга, юнит-тестирования, автоматизации, разных других "best-practices". Но не хочу это писать в список. Список представляет собой некий минимум, который как мне кажется неплохо было бы иметь, но это именно минимум.

Обсуждение

В завершение хочу высказать несколько мыслей по изложенному списку.

• Как относиться к этому списку?
  
• Если кто-то знает все темы изложенные в списке, то это ещё не значит что он хороший программист.
  
• Если же кто-то НЕ знает всех тем, изложенных в списке, то он вполне даже может быть хорошим программистом.
• Как же так? Выходит этот список бессмысленный? Если не важно знаешь ты темы из него или нет?
  
  Дело в том, что реальная жизнь существенно сложнее любых списков. Наша ежедневная работа требует от нас выполнения некоторого ограниченного (у одних более, у других менее) набора задач. И то, насколько мы справляемся с конкретным набором задач, зависит от многих причин - от самих задач и нашего умения решать именно эти задачи, от нашего опыта в решении этих задач, от нашего настроения и физического состояния, от того играет ли музыка за столом у коллеги и так далее. Списки, подобные моему влияют всего лишь на одну из составляющих успеха, а вовсе не на все.
  
  
• На какую именно составляющую влияют такие списки? Зачем в список включено "Х"? Ведь никогда в жизни этим не придётся воспользоваться в реальном программировании!
• Я согласен, что очень многими вещами из списка в реальной жизни большинству людей заниматься не придётся. Немногие пишут компиляторы, операционные системы или проектируют новые компьютеры.
• Тем не менее, как мне кажется, существует так называемый "закон дырявых абстракций" (The law of leaky abstractions"). Идея тут такая. "Абстрагированием" мы называем процесс удаления деталей из представления некоторого процесса. Мы, особенно программисты, постоянно строим один уровень абстракции над другим. Например, операционная система предоставляет нам API, который является абстракцией над всем, что реально делает ОС. Так вот "закон дырявых абстракций" говорит нам о том что "Все нетривиальные абстракции, являются, в некоторой степени, дырявыми". То есть рано или поздно мы, программисты, столкнёмся с тем что находимся там, внизу. Вот именно в этот момент нам и понадобится "X" - для того чтобы понять что же именно происходит. Тут может возникнуть ещё один вопрос - а до какого же уровня все нужно учить? Ведь можно попытаться копнуть ещё глубже, а потом ещё? Это на самом деле сложный вопрос, я не буду отвечать на него здесь. Он заслуживает отдельного размышления.
• Ты сам-то знаешь все о чем в списке понаписал?
• Нет, к моему большому огорчению знаю не все. А кое-что знал раньше, но успешно забыл.
• В список не включено 'Y', а без 'Y' невозможно представить себе программиста!
• Вполне вероятно. Я запросто мог что-то пропустить, а чему-то не придать достаточного значения. С удовольствием узнаю Ваше мнение по этому поводу. Добро пожаловать в комментарии!
  

Что в имени тебе моем?

Данный пост представляет собой кросс-пост отсюда и является ответом на вопрос в RSDN.

Вопрос:

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

Люди и Роли

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

В итоге, в каждой компании, в которой хотят ввести такие роли/должности их вводят по принципу:

1. Какими методологиями пользовался/что изучал человек, который придумывает роли
2. Собственное понимание/перевод соответствующих английских терминов
   

Некоторые термины, тем не менее, имеют чёткое определение, которое дано им международными организациями. Например, что такое project, project management, определяется документом PMBOK (Project Management Body Of Knowledge), который можно назвать стандартным.

По этому документу:

Project — Временное предприятие, предназначенное для создания уникальных продуктов или услуг.
Здесь временное означает, что у проекта есть четко определенные начало и конец.
Уникальные продукты или услуги — означает что, то что будет создано, каким-то существенным образом отличается от того что уже есть.

Project Management — Использование знаний, навыков, методов, средств и технологий при выполнении проекта с целью достижения или превышения ожиданий участников проекта.

Project Manager — человек, осуществляющий project management.

Почти что как у Лема

«СЕПУЛЬКИ — важный элемент цивилизации ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКАРИИ».
Я последовал этому совету и прочёл:
«СЕПУЛЬКАРИИ — устройства для сепуления (см.)».
Я поискал «Сепуление»; там значилось:
«СЕПУЛЕНИЕ — занятие ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКИ».
Лем С. Звёздные дневники Ийона Тихого. Путешествие четырнадцатое.

В задачи Project Manager входит (опять же по PMBOK):

1. Создание и исполнение плана проекта
   
2. Создание календарного плана и контроль времени
   
3. Управление ресурсами проекта (людьми, оборудованием, помещениями)
   
4. Создание и управление бюджетом проекта (как денежным, так и временным)
   
5. Установка и поддержание стандартов качества
   
6. Взаимодействие с другими отделами компании, а также с контактами вне компании
   
7. Оценка и управление рисками проекта

Тем не менее, необходимо помнить, что в каждой конкретной организации сложилось свое понимание каждого термина, в том числе и для таких как "project management".

Личный взгляд

В моей голове тоже есть понимание того что означают все эти должности, и это понимание я здесь сейчас изложу.

• Project manager/руководитель проекта — мое понимание совпадает с тем, что изложено в PMBOK (приведено выше)
  Данная роль является "начальственной" в бюрократическом смысле слова. В конечном итоге, если не удается договориться,
  последнее слово всегда остаётся за руководителем проекта.
  
• Product Manager
  Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек, представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:
  
  
  1. Исследование рынка
  2. Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
  3. Исследование конкурентов (иногда этим занимаются специально выделенные люди)
  4. Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
  5. Выработка списка "features" продукта
  6. Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
  7. Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
  8. План развития продукта (RoadMap)
  9. Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
  10. Взаимодействие с высшим руководством компании, если таковое необходимо
  11. Взаимодействие с отделом продаж и совместная выработка стратегии продаж
      
  
  Все вышеизложенное взято из определений "product manager" в MSF, курсов Pragmatic Marketing,
  а также из собственного опыта и возможно ещё откуда-то (ну то есть в голове есть, а откуда взялось — не помню).
  
  Данная роль не является "начальственной", то есть product-manager-ы не могут никому приказать — их голос совещательный.
  
  
• Program Manager
  Это странная сущность, существование которой кажется мне не очень оправданным. В моей картине мира вполне можно обойтись без неё. Тем не менее, она существует и, по всей видимости, введена была в Microsoft
  ещё очень давно. Про эту роль есть два неплохих рассказа:
  
  
  1. Элдар Мусаев "Про маразм и Program Management"
  2. Steven Sinofsky — бывший руководитель группы разработки MS Office
     
  
  Данная роль не является "начальственной", то есть program manager-ы не могут никому приказать — их голос совещательный.
  
  
• Team Leader
  Team Leader — это руководитель небольшой группы программистов. Подчеркну TeamLeader — это начальник, в бюрократическом смысле этого слова. То есть он может приказать. И пусть никого не смущает слово leader. Под небольшой группой понимается группа в 1-5 человек (ну понятно что цифры приблизительные).
  
  
• Technical Leader
  Данная роль предполагает, что человек обладает некоторыми очень глубокими знаниями в каком-то техническом вопросе или теме — более глубокими чем все остальные. Это — "эксперт" в какой-то области. Областью может быть все что угодно: C++, ADSI или очень глубокое знание системы контроля за исходными текстами, использующейся в компании.
  В любом случае эта роль оказывается у человека в результате его "репутации" — в какой-то момент все понимают что этот человек действительно эксперт. Эта роль не является начальником в бюрократическом смысле этого слова, то есть никто не обязан подчиняться technical leader-у.
  
  
• Analyst
  Данная роль отвечает за исследование "процессов" для заказчика. Часто эта роль оказывается близкой к роли Product Manager, особенно если нужна разработка для какого-то одного конкретного заказчика.
  Также как и product manager-ы аналитики занимаются:
  
  
  1. Выявлением нужной заказчикам функциональности
  2. Составлением спецификаций и приоритезацией "features" продукта
  3. [иногда] Оценкой применимости тех или иных средств для реализации нужной функциональности (в MS, насколько я понимаю — это как раз часть деятельности Program Manager-ов)
     
  
  Данная роль не является "начальственной", то есть аналитики не могут никому приказать — их голос совещательный.
  
  
• Architect
  
  "I am the Architect"(C)Matrix Reloaded. Честно говоря я затрудняюсь здесь дать точное определение.
  Очень часто — это не роль, а состояние души
  
  Данная роль не является "начальственной", то есть архитекторы не могут никому приказать — их голос совещательный.

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

Несколько ссылок

1. Project Management Institute — авторы PMBOK
   
2. Российский портал управления проектами pmprofy — у них есть глоссарий с определениями

Какие знания необходимы программисту - часть 1

Очень часто на различных программистских форумах, да и просто в разговорах возникает вопрос: а что должен знать и уметь программист для того чтобы быть достойным высокого звания программиста ;-) Ну естественно тут у каждого свое мнение. Один скажет мол главное иметь голову на плечах, а остальное само приложится. Другой же скажет что без знания MFC и шагу ступить нельзя, третий скажет что знать надо то, чем пользуешься, четвертый расскажет, что если не понимаешь что несколько if-else - это на самом деле система линейных уравнений, но тебе и к компьютеру подходить не стоит, ну и так далее.

У меня тоже свое мнение есть :-) Хочу только сразу сказать, я не буду рассуждать про голову на плечах. Голова, она для любой профессии нужна. Тем не менее некоторый набор базовых знаний, как мне кажется, программистам необходим. Вот этот набор, вернее то, каким он мне видится я и хочу описать. Замечу, что я пытаюсь описать знания, которые совершенно необходимо каждому программисту, независимо от того, какие именно программы и в какой предметной области он или она пишет. (Да тут есть некоторая размытость - ведь не дано точного определения программиста. Нужно ли обладать знаниями о которых я буду говорить в дальнейшем бухгалтеру, который пишет макрос в Excel? А является ли программистом художник, рисующий Flash-анимацию? Как это часто уже бывало в этом блоге, оставляю ответ на "программистскую интуицию" и здравый смысл. Возможно этот вопрос - кого считать программистом- это тема отдельного поста? )


Математические основы

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

• системы счисления (общие принципы, двоичные, восьмеричные и т.п. числа)
  
• способы представления чисел (всевозможные "дополнения до", представление вещественных чисел, числа со знаком и без)
  
• математическая логика (исчисление высказываний, логические операции, правила де-Моргана, булева алгебра)
  
• анализ алгоритмов (O(n), анализ сложности, NP-полнота)
• комбинаторика (перестановки, сочетания, размещения)
• теория вероятностей (мера, нормальное распределение, дисперсия)
• линейная алгебра (векторы, матрицы, системы линейных уравнений)
• теория множеств (множества, пересечения множеств , объединения множеств, мощность)
• основы алгебры (бинарные отношения, изоморфизмы, группы, кольца, поля)
• теория чисел (факториал, простые числа, делимость)
• основы теории графов
  

Алгоритмы и структуры данных

Тоже сложная тема. Зачем нам знать алгоритм сортировки если есть qsort? (вместо qsort
подставить свой алгоритм) . Как можно не знать сортировки? А сколько раз в жизни тебе пришлось руками написать сортировку? Все эти и подобные им вопросы сразу же возникают, когда вспоминаешь про алгоритмы и структуры данных.

• Структуры данных
• стек
• очередь
• списки
• хэш-таблицы
• деревья
  
  
• Алгоритмы
• сортировка :-) (быстрая, вставками, пирамидальная, "пузырьком" :-) )
• поиск подстроки, сопоставление с образцом (алгоритм Кнута-Морриса-Пратта)
• алгоритмы на графах (поиск кратчайшего пути, алгоритм Дейкстры)

Теория автоматов и формальных языков

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

• конечные автоматы
• автоматы с магазинной памятью
  
• грамматики (КС-грамматики, LL и LR грамматики)
• регулярные языки
• формы представления языков (форма Хомского, формы Бэкуса-Наура)
• машины Тьюринга
• рекурсивные функции

Устал. А до конца ещё далеко. Посему обзываю все что успел написать первой частью :-) и выкладываю.

Feedburner

С недавних пор я перевёл все RSS фиды на FeedBurner. Поэтому просьба к тем, кто подписан не через feedburner - переподпишитесь пожалуйста. Так что вот:

• Сам блог: http://feeds.feedburner.com/lktalks
• Комментарии: http://feeds.feedburner.com/lktalks-comments

P.S. Если подписаться на фид комментариев, то можно отслеживать комментарии к старым постам блога

Quick and Dirty?

Есть такой специальный вид исправления ошибок, название которого (если исключить вопросительный знак) вынесено в заголовок. "Quick and dirty fix" - это такое исправление или решение, которое исправляет проблему в каком-то частном, узком конкретном случае, а не решает её целиком. Примеров подобных решений каждый программист может найти в своей практике множество. Предполагается, что такое вот временное решение будет существовать недолго, а как только появится возможность будет заменено на "правильное". Последнее иногда случается, а иногда нет - как повезёт.

Вот только "quick and dirty" бывают не только исправления проблем в условиях сжатых сроков. Иногда "quick and dirty" бывают сами решения. Ну просто нужно что-то сделать, а времени остаётся мало, и вещи делаются как попало, так, как тому кто их делает кажется в данный момент быстрее. И вот такие-то вещи как раз почти всегда остаются в коде навсегда.

Два подхода

Вообще, есть два подхода к написанию программ.

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

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

• Код программы написан в "понятном" стиле
  "Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям."М.Фаулер
  
  
• Программа содержит в себе только необходимые элементы, ничего лишнего, "устаревшего", не использующегося и так далее
  
  
• Код в программе подчиняется принципу DRY (DO NOT REPEAT YOURSELF), то есть каждая часть функциональности существует в единственном экземпляре, нет раскопированных кусков кода, которые делают одно и тоже
  
  
• Все материалы, относящееся к данной версии программы, находится в системе контроля версий:
• исходный код
• картинки
• документация - как пользовательская, так и техническая, включая документы по архитектуре и так далее
• и так далее
  
  
• Связи между независимыми компонентами программы минимизированы
  
  
• Любую версию программы (в том числе и предыдущие) можно построить при помощи запуска одного скрипта
  

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

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

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

Эта аргументация вполне понятна. Но, как и любая аргументация, она имеет границы применимости. Дело в том, что аргументация смотрит вперёд на один ближайший выпуск продукта. И с точки зрения этого ближайшего выпуска, она оптимизирует время так, чтобы ближайший выпуск состоялся вовремя.

А что если посмотреть вперёд? Будут ведь и ещё выпуски? Сколько их будет? Рассмотрим пример. Допустим, что для создания работающей автоматизированной процедуры построения продукта требуется 1 неделя (5 рабочих дней). После этого для сборки продукта будет требоваться 2 часа - время работы процедуры. Допустим также, что для того, чтобы собрать продукт руками опытному разработчику, знакомому с процедурой сборки требуется 1 день. Ясно, что в критериях измерения только "к ближайшему выпуску" предпочтение следует отдавать "ручному варианту". А что если впереди планируется ещё 10 выпусков? Давайте считать. Отлаженная процедура займёт 20 часов ( то есть три дня). "Ручная" же сборка займёт 10 дней. Заметим, при этом, что сборка обычно не происходит один раз - обязательно обнаруживается та или иная ошибка, продукт пересобирается и так далее. В "ручном" режиме это каждый раз трата одного дня.

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

Все зависит от критериев

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

P.S. Если мы в будущее смотрим, но времени у нас на "правильное" программирование не хватает - то это называется неправильным планированием. Тот, кто был ответственен за планирование не до конца все просчитал и не заложил больше времени.

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

Intentional Software

Все ведь знают имя Charles Simonyi? Билл Гейтс называет его "одним из величайших программистов всех времён". В его честь венгерская нотация получила название венгерской (поскольку сам Simonyi родом из Будапешта, Венгрия и это именно он привнёс тот способ именования переменных в программе, который теперь известен как венгерская нотация). Он работал во всемирно известном исследовательском центре Xerox в Palo Alto (Xerox PARC). В то время (Simonyi пришёл в PARC в 1972 году) был разработан легендарный, опередивший свое время персональный компьютер Alto, обладавший поразительными возможностями: графическим пользовательским интерфейсом, сетевым интерефейсом (Ethernet), мышью:
А также, специально для Alto, под руководством Simonyi, был разработан совершенно невиданный для того времени текстовый процессор под названием Bravo. Bravo предложил совершенно новую концепцию текстового редактора - концепцию, при которой пользователь видел на экране компьютера ровно то, что оказывалось распечатанным на принтере. Эта концепция получила название Wysiwyg - "What you see is what you get!". По сути, он изменил индустрию программного обеспечения для пользователя, введя уровень абстракции между ними и текстовым редактором.

После работы в Xerox PARC Simonyi работал в Microsoft и занимался Microsoft Office. В настоящее время он основал собственную компанию и снова хочет изменить мир.

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

Именно ради построения таких методов Simonyi ушёл из Microsoft и основал на собственные деньги компанию. Работа на самом деле началась чуть раньше, когда он ещё работал в Microsoft Research, но условия ухода из MS запрещали использование уже написанного кода а разрешали только использовать идеи, поэтому весь код пришлось переписывать заново.

Идея Simonyi состоит в том, чтобы полностью изменить мир программирования. По его представлению, в будущем программы будут писать не программисты, а эксперты в конкретной предметной области, причём пользуясь терминологией и конструкциями, принятыми не в в программировании, а в данной предметной области. Сама программ будет записываться как некоторое "дерево намерений" (intentional tree), которое в свою очередь будет транслироваться в код, например на С++. При желании изменить программу, необходимо будет изменить дерево намерений, и пересоздать код на C++.

Вообще, если честно все это жутко похоже на популярную сейчас концепцию DSL - domain specific languages, с той разницей что Simonyi утверждает что его intentional programming будет существенно шире, что бы это не значило. Сейчас компания, насколько я понимаю, не имеет ни готового продукта, ни каких-либо клиентов, а живёт только за счёт миллионов её создателя (заработанных, естественно в Microsoft).

Тем не менее по поводу всего этого была поднята довольно большая шумиха поскольку
в недавнем выпуск Technology Review была опубликована большая статья, откуда я собственно и узнал про существование Intentional Software.

Идея выглядит привлекательной, но уж больно сомнительной, с точки зрения практического её выполнения:

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

Создатель языка С++, Бьярн Страуструп, в одном из своих последних интервью сказал:

"Software developers have neutralized the astounding performance of modern computer hardware by adding layer upon layer of overelaborate [software] abstractions."

Может быть он прав?