> А.А.Шалыто
Дальше не читал.

А для Ъ?

Типа одних сорцов мало. Надо, дескать, проектную документацию и вообще заморочиться нипадецки. Гранты выбил себе там товарищ, как я понял.

«Как это у него получилось, что он конечные автоматы изобрёл?» (q) Internet

По ссылке клевая цитата:

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

Дальше не читал, извини =(

> По ссылке клевая цитата:
Я не удивлен. По словам автора статьи, он не написал ни одной программы и гордится этим.

Можно цитату, если не трудно =)

Вот еще цитата, не буду ее никак комментировать:

«Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало»

Вычитал в ЖЖ одного студента из ИТМО. Сейчас вряд ли найду.

На самом деле проектная документация не нужна. Любая GPL программа должна поставляться с двумя-тремя заtarенными программистами, дабы они на пальцах объяснили любому желающему поковыряться в исходном коде что и как там работает.

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

> с двумя-тремя заtarенными программистами

Чем затаривать программиста? :)

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

Местным школьницам

Джаббер в профиле.

Поколению пепси код читаь нельзя.
Только инструкции на освежителе воздуха.

поколение пепси ничего больше инструкций и не осилило

Древний боян, откуда вы его только выкопали.

ох, как же эти все университетские статеечки местных одаренных писак похожи друг на друга, независимо от названия вуза. в этом и заключается вся их «наука» — пачкать бумагу.

>Поколению пепси код читаь нельзя.

Только инструкции на освежителе воздуха.

«Свой код, написанный без комментариев, через полгода становится чужим», не помню кто, но правильно.

Отсутствие документации - самая крупная ошибка автора. Код большинства открытых проектов действительно нифига не читаем - даже элементарный комментариев нет. Спасают только ctags и cscope

ХЗ к какому поколению я отношусь, но отсутствие документации вызывает антипатию к автору, хотя при необходимости я могу залезть в исходники и вытащить что мне нужно - из bash, perl и python легко, из c/c++ сложнее.

А ты пишешь комментариий? В глаза, в глаза смотреть!!

> «Свой код, написанный без комментариев, через полгода становится чужим», не помню кто, но правильно.

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

> «Свой код, написанный без комментариев, через полгода становится чужим»

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

>Теоретически ООП должно спасать от этого, ибо интерфейсы классов очень наглядны.

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

> «Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало»

Ну тут я с ним вобщем-то согласен. Нет, программ таких много, конечно, но если в %, то где-то только 1% наверное получится...

В остальном КГ/АМ.

Какой замечательный тред-детектор школоты.

мало этому профессору кода, есть ГОСТ 19.402-78Б сиречь 13-й документ, описание программы. так что предлагаю организовать еще вдобавок движение за открытый нормоконтроль

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

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

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

Похоже, никаких подвижек с 2003 года.

как открыть то, чего не существует?

«Как это у него получилось, что он конечные автоматы изобрёл?» (q) Internet

Их кто только не изобретал. Да же я. :) А потом попалась книжка Теория и практика построения компиляторов...
Какой удар от классика (С).

> Что это у них там за кружок самодеятельности? Проектную документацию на ПО особо не чем верифицировать, в отличии от проектной документации на инженерные системы

И как же там *верифицируют* *документацию*? не схему, не разводку, а именно *документацию*?

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

> «Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало»

Хых, он просто не видел, что обычно в проприетарном мире кропают :-)

один выдающийся программист (участник двух финалов командных чемпионатов мира по программированию, проводимых организацией «Association for Computing Machinery» — АСМ)

Доставило неимоверно. Особенно в купе с этим:

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

Собственно их ложных посылок и вылупился этот высер.

>Чем затаривать программиста? :)

Сначала в SquashFS, а потом в tar.lzma же! :)

>Да же я.

КЛБ

Какой нажористый текст!

«Запрещённая книга» Commentary on Unix: With Source Code оказывается обладает целыми 6 изданиями.

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

А вот это нафиг, не для того люди себе мозги ломают чтобы потом всю жизнь нищебродствовать.

А вообще документированный код стоит больших денег. Халявное ПО есть - харя треснет ещё и халявную документацию делать. На чём тогда зарабатывать?

>Доставило неимоверно. Особенно в купе с этим:

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

Про ассемблер и брейнфак и не говорю. На си сложнее, но тоже можно. Из серии x++ = ++x + x++.

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

Не надо контекст кромсать.

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

Поэтому я и вытащил твою цитату, которая объединяет обе приведённые тобой :)

Потому что он хренов олимпиадник и опыта чтения чужого кода у него просто нет.

Не обязательно. Кстати, я не подразумевал, что запутанный код - единственный вариант, возможно что прав ты. Но - возможно. Я же считаю, что код в 6 строк для достаточно хитрой задачи БЫЛ запутанным.

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

> По словам автора статьи, он не написал ни одной программы и гордится этим.

Понятно, в биореактор таких мыслителей.

Я же считаю, что код в 6 строк для достаточно хитрой задачи БЫЛ запутанным.

Если эти 6 строк кода действительно содержали в себе алгоритм решения задачи о ханойской башне, то длина их была явно символов в 500-1000. Понятное дело, что читать такое - затруднительно :)

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

И как же там *верифицируют* *документацию*? не схему, не разводку, а именно *документацию*?

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

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

Собственно их ложных посылок и вылупился этот высер.

Так точно. Непонятного кода в проекте нужно минимум и он таки да, должен быть документирован.

Полное впечатление, что ООП зачастую используется для обфускац

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

При наличии качественной проектной документации программист не сможет «управлять» менеджерами

Угу сюрприз его ожидает в том, что для разработки «качественной» документации нужно затратить сил не меньше, чем реализовать проект без документации.

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

На практике, как мне кажется, еще чаще бывает так: дом строят, стоят, уже 16 этаж доделывают. А потом вспоминают, ох епт, мы же фундамент залить забыли. Разница в том, что человеку очень просто качественно оценивать физические объекты и очень сложно идеальные. Конечно, точный расчет вообще избавляет от ошибок качественной оценки, но для софта пока в основном качественные оценки и применимы.