Изображение с сайта abv24.com
Один из тех людей, с именем которых связано превращение программирования из шаманства в науку, — Эдсгер Дейкстра. Он небезуспешно доказывал, что программирование — высокое искусство и интеллектуальное творчество.
Во всех своих исследованиях Дейкстра придает большое значение простоте и изяществу математических рассуждений. При написании своих работ он создал новый стиль научных и технических сообщений, который можно описать как нечто среднее между журнальными публикациями и дружеской перепиской.
Программирование – не набор пассов и заклинаний, не шаманство, не танцы с бубном, а математическая дисциплина. А всякая дисциплина, если она претендует на нечто большее, чем на внешний эффект, должна строиться на прочном фундаменте. Таким фундаментом для Дейкстры является математическая логика, а точнее – исчисление предикатов.
Сейчас это не кажется чем-то необычным, но в 50-е годы это прозвучало как откровение. Дейкстра понял и убедительно показал, как теория может и должна помочь практике.
Для особо одаренных
Эдсгер Вайб Дейкстра родился в Роттердаме (Голландия) в 1930 году. Его родители были хорошо образованными людьми: отец был химиком, а мать — математиком. В 1942 году в возрасте 12 лет Дейкстра поступил в гимназию Эрасминиум — школу для особо одаренных детей, где преподавался ряд разнообразных предметов, в том числе греческий, латынь, французский, немецкий и английский языки, биология, математика и химия.
Изображение с сайта balto-slavica.com
В 1945 году Дейкстра подумал, что он мог бы изучать право и, возможно, работать в качестве представителя Нидерландов в ООН. Однако, вследствие его успехов в изучении химии, математики и физики, он поступил в университет Лейдена, где решил заняться теоретической физикой. В 1951 году он посещал летнюю школу по программированию в Кембриджском университете.
Дилемма
За год до окончания университета Дейкстра оказался перед дилеммой: продолжить научную карьеру по основной специальности – теоретической физике или все-таки продолжать заниматься программированием:
мне надо было сделать выбор – либо прекратить программировать и стать настоящим респектабельным теоретическим физиком, либо как-то формально завершить мое обучение теоретической физике с минимальными усилиями и стать… кем же? Программистом? Но разве это респектабельная профессия? В конце концов, что такое программирование? В чем должен был состоять тот солидный объем знаний, который позволил бы считать программирование научной дисциплиной?
Однажды Дейкстра постучал в дверь кабинета своего научного руководителя ван Вейнгаардена. Терпеливо выслушав, что беспокоит Дейкстра, ван Вейнгаарден согласился, что в настоящее время есть не так уж много вещей, которые можно было бы отнести к дисциплине программирования, но затем он спокойно продолжал объяснять, что автоматические вычисления машины — не кратковременная мода, за ними будущее, что мы находимся у самых истоков и — как знать? — может быть, именно Дейкстра призван превратить программирование в почетную научную дисциплину. Это был поворотный момент всей жизни Эдсгера Дейкстра, и он как можно быстрее прошел все курсы, требующиеся для получения диплома в области теоретической физики, и начал заниматься программированием.
Дейкстра официально стал «программистом» 1 марта 1952 года и был первым голландцем, начавшим заниматься этим в своей стране. Он начал работать в качестве совместителя в Математическом центре в Амстердаме.
Туманное будущее
Надо сказать, что Дейкстра действительно рисковал выбирая столь экзотическую в те времена профессию. Программистов было мало, а компьютеры и вовсе исчислялись двумя-тремя десятками. Будущее информатики как науки было туманным – многие рассматривали (и надо признать не без оснований) информатику как ветвь прикладной математики.
Однако, ближайшие несколько лет показали – ван Вейнгаарден не ошибся, предложив своему талантливому студенту, а в дальнейшем аспиранту, выбрать программирование: с конца 50-х годов корпорация IBM начала производство компьютеров на транзисторах, что позволило существенно снизить их энергоемкость, массу и стоимость одновременно подняв объемы памяти и производительность. Моментально подтянулись другие компании и компьютеры из военных и научных лабораторий стали доступны банкам, производственным предприятиям, учебным заведениям, больницам, коммунальным службам.
Алгоритм Дейкстры
Многим программистам Дейкстра известен как создатель алгоритма «кратчайшего пути», предложенного им еще в 1952 году, который появился в результате его работы над задачей по оценке производительности компьютера ARCMAC, установленного в Математическом Центре. Этот алгоритм позволяет находить наилучший путь для перемещения между двумя точками.
Ученый также использовал этот алгоритм для решения задачи «О нахождении оптимального пути передачи электрического тока всем существенным элементам цепи, минимизируя при этом расход меди», с которой столкнулись инженеры, разрабатывавшие ARCMAC. Он назвал этот способ «алгоритмом дерева с кратчайшими ветвями».
Изображение с сайта urban-sanjoo.narod.ru
Алгоритм Дейкстры широко применяется и сегодня (например, при планировании автомобильных и авиамаршрутов, при разводке электронных плат, в протоколах маршрутизации). Относится к «жадным» алгоритмам, то есть достаточно эффективен для поиска путей на относительно небольших графах.
ALGOL-60
Порядком намаявшись в начале своей программистской карьеры с машинными кодами и с тем, что для различных моделей компьютеров один и тот же алгоритм нужно было переписывать практически с нуля, Эдсгер Дейкстра не мог не «ухватиться» за языки программирования высокого уровня.
FORTRAN, появившийся в конце 50-х годов Дейкстру не очень привлекал: в FOTRAN-е многое было принесено в жертву главной цели — во чтобы то ни стало реализовать высокоуровневый язык и избавить программиста от «проклятья» двоичных кодов. Появись FORTRAN сегодня, его шансы удержаться, думаю, были бы весьма сомнительными. Но тогда, безусловно, FORTRAN был великим шагом вперед. Однако, Дейкстре все равно FORTRAN не импонировал – ему в этом языке, по-видимому, не хватало того изящества и логичности конструкций, которые Дейкстра привык видеть в математике и логике.
Язык ALGOL-60 описывался стройной и вполне строгой нотацией (т.н. называемая «форма Бэкуса-Наура»), его разработка велась едва ли не в академической среде с присущими последней требованиями четкости, ясности и доказуемости. Критерии были строгими и язык поэтому получился изящный (не случайно такие языки программирования как PL/1, PASCAL и ADA носят явные следы влияния ALGOL-а).
Не мешкая Дейкстра приступил к реализации компилятора и успех в этом направлении подтвердил его давнюю мысль – программировать надо на «нормальных» языках, приспособленных, насколько это возможно, к психологии человека. А машинный код – ну что же, раз без него все равно никуда не деться – его можно и нужно оставить машинам.
Одной из наиболее сложных задач при трансляции языков программирования в те годы была задача компиляции арифметических выражений с учетом приоритетов операций и скобок. Дейкстра убедительно обосновал и упростил предложенный в 1957году Ф.Брауэром и К.Замельзоном алгоритм использования для этой цели двух стеков (тогда обычно говорили «магазин» по аналогии с магазином оружия). Арифметические выражения эффективно транслировались в обратную (или «инверсную») польскую запись очень удобную для генерации объектного кода.
Пример обратной польской записи
Величайшие изобретения прошлого по версии Дейкстры
Одним из величайших изобретений, он считал, является замкнутая подпрограмма, которая воплощает одну из фундаментальных абстракций.
Вторым крупным достижением в области программного обеспечения Дейкстра называл рождение FORTRAN. Это был чрезвычайно смелый проект, который должен оцениваться как успешная методика программирования, но с очень ограниченным числом средств поддержки основной концепции. В наши дни этот язык считают устаревшим. Трагическая судьба FORTRAN — следствие его широкого признания, приковавшего мышление тысяч и тысяч программистов к прошлым ошибкам.
Третьим проектом, о котором упоминает Дейкстра, является LISP. На использованииLISP основаны многие в некотором смысле наиболее изощренные программные продукты. В шутку LISP описывался как «наиболее интеллигентный способ злоупотребления компьютером». Дейкстра считал, что подобная характеристика является большим комплиментом, поскольку она передает всю полноту освобождения: LISP помогает многим из наиболее одаренных программистов мыслить о вещах, ранее считавшихся немыслимыми.
Четвертым проектом был ALGOL-60. В то время как определение LISP до сих пор остается причудливой мешаниной из того, что язык означает, и того, как он работает, знаменитое «Сообщение об алгоритмическом языке ALGOL-60» является плодом подлинных усилий перейти на следующий уровень абстрактности и определить язык программирования способом, не зависящим от его реализации.
Пять обедающих философов
Разработчики первых операционных систем, которые и операционными системами можно назвать с большой натяжкой, работавших в пакетном режиме (когда одному заданию полностью «принадлежали» все ресурсы компьютера) почти не сталкивались с задачей, которая к середине 60-х годов прошлого века стала чрезвычайно актуальной – обеспечение доступа нескольких процессов к общим ресурсам и разделение этих ресурсов между процессами. Без этого нельзя было решить важнейшую задачу – одновременное выполнение нескольких процессов на одном компьютере. В операционных системах, использующих эти алгоритмы, никак не удавалось избежать блокирования процессами друг друга.
Разумеется, такая нестабильность и непредсказуемость поведения основной программы – операционной системы – никого не могла устроить.
Наиболее полно свои мысли по этому поводу Дейкстра изложил в статье «Взаимодействие последовательных процессов». Для решения этой проблемы Дейкстра предложил концепцию «семафора» — специальных целочисленных общих переменных и двух примитивов «P-операция» и «V-операция». Вот как сам Дейкстра описывает эти примитивы:
Эти две последнии операции всегда выполняются над семафорами и представляют единственный способ обращения к семафорам со стороны одновременно действующих процессов. Семафоры являются по существу неотрицательными целыми величинами. Если они используются только для решения задачи взаимного исключения, то область их значений составляют лишь «0» и «1».
V-операция состоит в увеличении значения аргумента (который является семафором) на 1. Такое увеличение обязано быть неделимой операцией. P-операция, напротив, будучи применной к семафору, уменьшает (также неделимым образом) значение последнего на 1. Поскольку семафор, согласно определению, число неотрицательное, то рано или поздно P-операция уменьшит его значение до 0. Процесс, инициировавший P-операцию вынужден будет ждать (т.е. фактически окажется в режиме задержки выполнения) до тех пор пока другой процесс не «сдвинет» значение этого семафора в положительную область, т.е. разблокирует семафор.
Эти концепции и их дальнейшее развитие – например, мьютексы – и сегодня применяются при проектировании и реализации операционных систем.
В эти же годы Эдсгер Дейкстра руководил созданием операционной системы THE (от «Technische Hogeschool Eindhoven») с поддержкой многозадачности. Операционная система была построена в виде иерархии из 6 уровней; при этом более низкие уровни (начиная с 0) служили базой для более высоких (вплоть до 5). На начальных уровнях были реализованы система обработки прерываний, семафоры, переключение контекстов процессов, система управления памятью, диспетчер. На средних уровнях были реализованы взаимодействие с консолью, ввод/вывод, взаимодействие с устройствами; самый верхний уровень предназначался для пользовательских программ. В дальнейшем такая модель организации операционной системы получила широкое распространение.
Для иллюстрации проблемы разделения/блокирования ресурсов и взаимодействия процессов Дейкстра предложил простую и остроумную модель; позже эта модель получила имя «задачи о пяти обедающих философах». В изложении Чарльза Хоара она звучит так:
В давние времена один богатый филантроп пожервовал свой капитал на основание некоего пансиона, чтобы дать пристанище пяти знаменитым философам. У каждого философа была своя комната, где он мог предаваться размышлениям. Была у них и общая столовая с круглым столом, вокруг которого стояли пять стульев, каждый помеченный именем того философа, которому он предназначался… Слева от каждого философа лежала золотая вилка, а в центре стояла большая миска спагетти, содержимое которой постоянно пополнялось.
Изображение с сайта dic.academic.ru
Предполагалось, что большую часть времени философ проводил в размышлениях, а почувствовав голод, шел в столовую, садился на свой стул, брал вилку слева от себя и приступал к еде. Но такова уж сложная природа спагетти, что их не донести до рта без помощи второй вилки. Поэтому философу приходилось брать вилку и справа от себя… Если вилка требовалась другому философу, ему приходилось ждать, пока она освободится.
Структурное программирование
Проникновение компьютеров во все отрасли промышленности, бизнеса, образования, а также сопутствующий этому проникновению рост объема разрабатываемого программного обеспечения вызывал обеспокоенность ведущих специалистов: программы становились все больше, все сложнее, все разнообразнее. Все это не смогло не сказаться на их качестве – оно стремительно падало.
Досадно, если ошибка была в программе начисления заработной платы, но это, в конце-концов дело поправимое. Страшно, если программная ошибка обнаруживалась в системе управления воздушным транспортом. И совсем уж катастрофической была бы ошибка в программе управления работой атомного реактора.
Дейкстра видел причины ошибок в запутанной структуре программ:
Я считаю, что программа никогда не является самоцелью; программа предназнается для того, чтобы вызвать вычисления, а цель вычислений – получить нужный результат… Я утверждаю (хотя и не могу доказать), что легкость и гибкость таких наших суждений существенно зависит от простоты взаимосвязей между программой и вычислениями… Грубо говоря, можно считать желательным, чтобы структура программы отражалась в структуре вычислений.
Он помог программной индустрии стать намного более дисциплинированной, выдвинув тезис, что оператор «go to» является вредным. Это означало, что чем больше в программе операторов go to, тем труднее разобраться в исходном коде программы.
Для обеспечения указанных легкости и гибкости Дейкстра предлагает проектировать и кодировать программы в соответствии с определенной дисциплиной, названной им структурным программированием. Известно (это математический факт известный как теорема Бема-Якопини), что любую программу можно построить с использованием трех конструкций: следования, ветвления и цикла.
Изображение с сайта itandlife.ru
Дейкстра предложил (одновременно, хотя и независимо с Никлаусом Виртом) представлять программу как иерархическую структуру блоков, каждый из которых выполняет небольшую, но завершенную задачу. Это достигается с помощью механизма процедур и функций.
Идеи структурного программирования, поначалу встреченные с недоверием, довольно скоро завоевали признание (особенно, после создания Никлаусом Виртом языка программирования PASCAL). Более того, эта методика остается актуальной и сегодня (достаточно вспомнить такие популярные языки программирования C, PASCAL или BASIC).
О пользе и вреде Goto
Этому вопросу была посвящена одна из статей на «Хабре».
Против:
1. Использование GOTO – плохой тон.
2. Самый плохой тон – возвращение с помощью метки назад.
3. GOTO – избыточный оператор. Его легко можно заменить циклами и условиями.
4. Вирт и Дейкстра говорят, что GOTO это плохо.
5. GOTO аннулирует многие возможности компилятора по оптимизации управляющих структур, из-за чего код становится медленней и объёмней.
За:
1. Группа взаимоисключающих условий.
2. Принцип вселенской причинности – если где-то есть GOTO, значит он там нужен.
3. Выход из множества циклов одновременно.
4. Конечные автоматы (пример кода).
Память
Дейкстра был активным писателем, его перу (он предпочитал авторучку клавиатуре) принадлежит множество книг и статей, самыми известными из которых являются книги «Дисциплина программирования» и «Заметки по структурному программированию», и статья «О вреде оператора GOTO» (GOTO considered harmful) — классические книги по теории структурного программирования.
Дейкстра продолжал работу в Математическом Центре до тех пор, пока в начале 70-х годов не перешел на работу исследователем в корпорацию Burroughs в США. В 1972 году АСМ наградила Дейкстра премией Тьюринга (ACM Turing Award).
В 1974 году AFIPS удостоила его памятной наградой Гарри Гуда (AFIPS Harry Goode Memorial Award). В начале 1980-х годов Дейкстра переехал в Остин, штат Техас. В 1984 году он был назначен деканом факультета компьютерных наук в Техасском университете.Эдсгер Вайб Дейкстра является Почетным Иностранным членом Американской Академии гуманитарных, естественных и технических наук. Он также является членом Голландской королевской Академии наук, действительным членом Британского Компьютерного Общества и, наконец, доктором наук Королевского университета в Белфасте.
Изображение с сайта abv24.com
Не от мира сего
В 1957 году женился. В графе «профессия» анкеты, которую положено заполнять при регистрации брака, он написал «программист» — его заставили переписывать документы, заявив, что такой профессии не существует. В результате, как писал Дейкстра: «Хотите — верьте, хотите — нет, но в графе «профессия» моего свидетельства о браке значится забавная запись «физик-теоретик»!».
В обычной жизни Дейкстра был по-хорошему «чудаковат»: предпочитал простую ручку компьютеру, в его доме не было телевизора, он не пользовался мобильным телефоном, не смотрел кино. Он также любил музыку и был хорошим пианистом.
Когда его коллеги подготовили и издали к 60-летнему юбилею специальный сборник, Дейкстра ответил каждому из них личным благодарственным письмом, написанным от руки (а это, между прочим – 61 адресат). Ученому его уровня и положения полагался секретарь, но Дейкстра отказался от этой привилегии и все предпочитал делать сам.
В августе 2002 года Эдсгер Вибе Дейкстра скончался в своем доме в Нидерландах.
Комментарии (50)
kemiisto
20.06.2016 21:43-1После прочтения «Заметок по структурному программированию», лично для себя ставлю его на особый и почти недостижимый уровень даже среди «отцов-основателей». Излагает ёмко, чётко, по существу. В ином предложении смыслов поболее, чем в многостраничных фолиантах некоторых «писучих товарищей». Пока ничего подобного по уровню, кроме, разве что, ещё «Основ квантовой механики» Дирака, не читал. А уж современные писульки а-ля «Совершенный код» — это вообще откровенное «бумагомарательство». Бумаге, конечно, вроде как, всё ровно, она, как говорят, «терпит», но вот читатель такого точно не заслуживает.
evocatus
20.06.2016 22:28Пользуясь случаем: кроме «Заметок по структурному программированию» что бы вы советовали прочесть?
kemiisto
21.06.2016 00:37+1Ещё неплохая книга есть у Вирта: «Систематическое программирование. Введение». Но мне как-то Дейкстра больше по душе пришёлся. Даже могу сказать, намного больше, но это уже, подозреваю, всего-навсего личные пристрастия. А прямо сейчас медленно и вдумчиво читаю «Языки программирования. Концепции и принципы» за авторством Кауфмана. Ещё не дочитал, но уже могу смело советовать в тех же целях: чтобы приподняться с уровня Мартинов-Макконнеллов по наименованию переменных и оптимальному количеству параметров функции (т.е. по сути, кодирования) на уровень более куда более фундаментальных вещей (т.е. собственно программирования).
lair
20.06.2016 22:37+7А уж современные писульки а-ля «Совершенный код» — это вообще откровенное «бумагомарательство»
Аргументируйте.kemiisto
21.06.2016 00:13-5Аргументировать что? Вы сей опус читали? Там большинство «полезных советов» либо тривиальны донельзя (скажем, советы по наименованию), либо языко-специфичны (скажем, советы по использованию исключений для обработки ошибок и панический страх автора перед функциями с более чем двумя параметрами), либо представляют собой возведение более-менее здравой идеи в идиосинкратический абсолют (функции по 5 строк без параметров). Слишком много воды (аж на 450 страниц!), а реально полезных знаний крупицы. Если бы это всё называлось как-нибудь… ну не знаю «Записки стареющего Java-разработчика» и не пиарилось повсюду, то ладно, но уж чересчур претенциозное название и чересчур много шума из ничего. На фундаментальный труд никак не тянет, словоблудие сплошное по большому счёту. Так чего ради было столько бумаги марать?
lair
21.06.2016 00:54+3Аргументировать что? Вы сей опус читали?
Да, конечны.
Там большинство «полезных советов» либо тривиальны донельзя
Тривиальны для кого?
Ну и да, давайте сравним с высказыванием, из, скажем, "On our inability to do much": "we should remain aware of the fact that the extent to which we can read or write a text is very much dependent on its size". Оно не тривиально?
(скажем, советы по наименованию)
Вы никогда не слышали про две фундаментальных проблемы computer science?
либо языко-специфичны (скажем, советы по использованию исключений для обработки ошибок
И что, они теперь бесполезны? Особенно учитывая, во скольких мейнстримных языках есть исключения, и сколько вокруг них войн.
Если бы это всё называлось как-нибудь… ну не знаю «Записки стареющего Java-разработчика»
Вас не смущает, что первое издание CC вышло за два года до Java?
уж чересчур претенциозное название
А что претенциозного в названии Code Complete?
Так чего ради было столько бумаги марать?
Ради того, чтобы можно было взять, открыть нужный раздел, и найти мнение, подтверждение конкретными исследованиями (а не абстрактным "мне кажется, что").kemiisto
21.06.2016 11:36-5Тривиальны для кого?
Да для любого человека с IQ, достаточным для того, чтобы быть программистом. Я понимаю, что нынче программирование «в тренде», и идут туда не только те, кто могут, а повально все, кому кушать хочется. Так, собственно, необходимость в подобного рода «тривиальщине» и возникает.
Вы никогда не слышали про две фундаментальных проблемы computer science?
Первый раз слышу такое словосочетание. Это что ещё за «мем»? Уж будьте добры, просветите. Вообще, основная проблема в программировании — борьба со сложностью. А вот в computer science? Тут надо, конечно, для начало определиться, а что такое вообще этот Ваш «computer science»? Ну и в любом случае, оставь этот убогий термин нашим «коллегам» из-за океана. Дейкстра, между прочим, ещё когда говорил: «Сomputer Science is no more about computers than astronomy is about telescopes.» :D
И что, они теперь бесполезны?
Нет, конечно. Но, во-первых, как я уже сказал, полезного там на 450 страницах — «кот наплакал». А во-вторых, есть вещи куда более фундаментальные и полезные. Этих всяких Мартинов полезно читать после Дейкстры, а не до, и уж тем более не вместо. Тем временем, труды Дейкстры нынче библиографическая редкость, а «бульварного чтива» от Мартина и прочих — хоть отбавляй.
Вас не смущает, что первое издание CC вышло за два года до Java?
И что это меняет? Нынче же не первое читают, а последнее. А там большинство примеров и многие советы очевидным образом ориентированны на Java (и родственные языки). Так что нет, здесь меня ничего не смущает.
А что претенциозного в названии Code Complete?
В том что это оксюморон, нет? Очевидно недостижимая цель, причём, заметьте, как не переводи: хоть «Законченный код», хоть «Совершенный». Несуществующие сущности. У книги Мартина ещё вменяемое название, но Макконнелла уже, по-моему, занесло.
Ради того, чтобы можно было взять, открыть нужный раздел, и найти мнение, подтверждение конкретными исследованиями (а не абстрактным «мне кажется, что»).
Это мы сейчас за какую книгу то говорим? За Мартина? Что это там за «исследования» такие? :Olair
21.06.2016 11:55+2Да для любого человека с IQ, достаточным для того, чтобы быть программистом.
То есть программистам обучение не нужно, я вас правильно понял?
Первый раз слышу такое словосочетание. Это что ещё за «мем»?
"There are only two hard things in Computer Science: cache invalidation and naming things." (Phil Karlton, по цитатам, оригинал не найден)
Вообще, основная проблема в программировании — борьба со сложностью.
В этом контексте забавно сравнить высказывания МакКоннела ("Managing complexity is the most important technical topic in software development") и Дейкстры ("the art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible").
Нет, конечно.
Вот поэтому книга и существует.
Но, во-первых, как я уже сказал, полезного там на 450 страницах — «кот наплакал».
Если вы его там не нашли, это не значит, что его там нет.
Этих всяких Мартинов полезно читать после Дейкстры, а не до, и уж тем более не вместо.
А кто-то где-то говорил, что надо читать МакКоннела и/или Мартина и/или Фаулера и/или Ханта/Томаса вместо Дейкстры?
труды Дейкстры нынче библиографическая редкость
"Notes on structured programming", как и прочие рукописи Дейкстры, доступны онлайн.
И что это меняет?
То, что ни один стареющй Java-разработчик не принимал участия в написании Code Complete.
А что претенциозного в названии Code Complete?
В том что это оксюморон, нет? Очевидно недостижимая цель
То есть вы проект никогда не сдаете? "Code complete" — это устоявшееся выражение, означающее "программист работу закончил".
Это мы сейчас за какую книгу то говорим?
За Code Complete, очевидно.kemiisto
21.06.2016 12:28-1То есть программистам обучение не нужно, я вас правильно понял?
Нет, не правильно. Определённый уровень интеллекта — лишь достаточный критерий, но не необходимый. Учиться надо, но не по «Чистым кодам».
«There are only two hard things in Computer Science: cache invalidation and naming things.» (Phil Karlton, по цитатам, оригинал не найден)
Мне эту чушь обязательно комментировать? Тоже мне фундаментальные проблемы.
Если вы его там не нашли, это не значит, что его там нет.
А Вы правда нашли во всех 450 страницах, да? Там, как минимум, втрое можно сократить без малейшей потери смыслов.
А кто-то где-то говорил, что надо читать МакКоннела и/или Мартина и/или Фаулера и/или Ханта/Томаса вместо Дейкстры?
Берёте случайный ресурс для программистов и смотрите некий список книг, обязательных к прочтению. С 99% вероятностью что-нибудь из Clean или Complete Code там будет, а трудой Дейкстры — нет. И если и будут упомянуты, то в самом низу списка. Так что почти «все-то» почти «везде-то» это говорят. Просто загуглите «must read computer science books» или что-то типа того, чтобы в этом убедиться. Например, на SO есть закрытый топик, там Дейкстру случайно кто-то упомянул, но это упоминание утонуло в море «чистых совершенных кодов» и прочей биллетристики.
«Code complete»
— это устоявшееся выражение, означающее «программист работу закончил».
Даже по ссылке, что Вы дали, которая, кстати, не отражает, что автор вкладывал в название своей книги, нет консенсуса. Кто-то, так же, как и я, считает, что выражения означает какой-то мифический совершенный завершённый код. Так что, простите, не надо «ла-ля»: нет тут никакого устоявшегося выражения.
За Code Complete, очевидно.
Ну Code Complete в целом лучше, чем Clean Code, да. Там действительно много полезных отсылок к монографиям тех же Дейкстры, Вирта, GoF, и прочих. Вот только я про «мне кажется что» не очень понял. Какая разница: читать оригинал с «мне кажется что», или читать книгу, ссылающуюся на этот оригинал? Отсылка к «мне кажется что» посредством цитирования не делает утверждение менее субъективным. И эта Ваша Computer Science пока ещё слишком молодая наука, так что большинство «исследований» в ней таки находятся на этом самом уровне «мне кажется что» и «я считаю что»: обобщение собственного (в лучшем случае) коллективного опыта, социологические опросы. Зачастую, грош цена таким «исследованиям», зато есть чем список литературы набить для создания эффекта научности, да. :)lair
21.06.2016 13:03+2Учиться надо
Окей, следующий вопрос: вредна ли Code Complete (Pragmatic Programmer, Clean Code, Clean Coder...) при обучении программиста?
Тоже мне фундаментальные проблемы.
Понятно. Я искренне вам завидую, если и та, и другая у вас не встречаются или всегда легко решаются.
(впрочем, исходное высказывание шуточно, если вы вдруг этого не поняли)
Там, как минимум, втрое можно сократить без малейшей потери смыслов.
Это применимо почти к любой литературе, написанной человеком на натуральном языке. Он (натуральный язык), знаете ли, избыточен. Интереса ради, можете попробовать применить то же самое к Notes On Structured Programming, эффект получается занятным.
Берёте случайный ресурс для программистов и смотрите некий список книг, обязательных к прочтению
Меня слабо интересуют "случайные ресурсы для программистов", и я не отвечаю за их высказывания.
Так что, простите, не надо «ла-ля»: нет тут никакого устоявшегося выражения.
То есть вы думаете, автор его придумал из головы? Srsly? Опять-так, если вы чего-то не знаете, это не значит, что его не существует. "A release is called code complete when the development team agrees that no entirely new source code will be added to this release." (Wiki)
Другое дело, что последнее время (ну как, больше десяти лет уже) вообще идет много драк вокруг definition of done, но это уже вопрос процессуальный.
Там действительно много полезных отсылок к монографиям тех же Дейкстры, Вирта, GoF, и прочих
Эм. У Дейкстры есть хотя бы одна монография? В библиографии CC точно ни одной не упоминается. Монография Вирта? Вы про "Algorithms and Data Structures"? Она не цитируется в CC. Ну и да, чем она "фундаментальнее и монографичнее" Ахо-Хопкрофта-Ульмана или Седжвика или Кнута?
Какая разница: читать оригинал с «мне кажется что», или читать книгу, ссылающуюся на этот оригинал?
Так речь не идет о ссылках на "мне кажется что", речь идет о ссылках на конкретные статистические наблюдения за индустрией.
И эта Ваша Computer Science пока ещё слишком молодая наука
О, srsly, ей уже больше полтинника, ее в университетах преподают. Впрочем, я вообще не утверждаю, что это _наука, я считаю, что это дисциплина.kemiisto
21.06.2016 13:18Это применимо почти к любой литературе, написанной человеком на натуральном языке. Он (натуральный язык), знаете ли, избыточен. Интереса ради, можете попробовать применить то же самое к Notes On Structured Programming, эффект получается занятным.
Применимо только в той или иной мере. Бывают такие «песни», из которых «слов не выкинешь». Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы. Вот этого я у всяких Мартинов не вижу: тривиально, тривиально, тривиально, и так далее на 500-1000 страниц. Ску-ко-ти-ща.
То есть вы думаете, автор его придумал из головы?
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete. Переводчики на русский, заметьте, интерпретировали заглавие именно как «Совершенный Код».
У Дейкстры есть хотя бы одна монография?
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография. То, что 3 монографии издали одной книгой не делает их чем-то иным.
Так речь не идет о ссылках на «мне кажется что», речь идет о ссылках на конкретные статистические наблюдения за индустрией.
Вот! Статистические наблюдения за индустрией — это уже куда более конкретный термин, нежели какие-то там исследования. Тут есть сразу два важных слова: статистические и индустрия. Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика». Про второе: а что если индустрия идёт не туда? Что если попытки оптимизации труда программистов если и нашли какой-то минимум, то только локальный? Что если все эти советы несущественны?lair
21.06.2016 13:29+2Каждое отдельное предложение в текстах Дейкстры может казаться тривиальным, но в сумме у него получаются очень даже нетривиальные выводы.
Например, какие из первой главы NoSP, "On our inability to do much" (просто любопытно)? Кстати, учтите, что сам Дейкстра пишет о NoSP: "I felt that they suffered from a marked verbosity".
Я не могу утверждать, что конкретно автор имел ввиду под Code Complete.
Я привел вам ссылку на Wiki. МакКоннел — из MS, у них была вполне конкретная дисциплина (прослеживающаяся в MSDN), в которой Code complete — это фаза общего жизненного цикла приложения.
Ну привет. Упомянутые «Notes on Structured Programming» — вполне себе монография.
Привет-привет. NoSP — не монография. Во-первых, и в самых важных, так считает сам Дейкстра: "these notes have the status of "Letters written to myself" [...] as a document this is very incomplete". Во-вторых, монография "обычно" предполагает объем немного побольше и, что важнее, peer review.
Про первое всё уже сказано и не раз: «Существуют три вида лжи: ложь, наглая ложь и статистика».
И этот человек еще что-то говорит о "the only two hard things". Статистика — это факты, можно спорить с методикой сбора, можно спорить с методикой расчетов или выводами, но опровергать исследование только на основании того, что оно статистическое — глупо.
Про второе: а что если индустрия идёт не туда?
Тогда вам нужны инструменты определения того, что она идет не туда. Ну и да, вы хотите работать в другой индустрии? Тогда да, книги по этой индустрии вам не нужны.
Что если все эти советы несущественны?
Опыт показывает, что советы, описанные у МакКоннела, могут быть тривиальными (для тех, кто уже выяснил это из другого источника или опытным путем), избыточными (если мы работаем в другой среде), но они пока еще не оказывались несущественными — в том смысле, что они имеют влияние на процесс разработки.kemiisto
21.06.2016 13:49NoSP — монография. «Letters written to myself» — это просто формат. Никаких ограничений по объёму на монографии не накладывается, монография — это по сути просто писанина на одну конкретную тему. Ограничения по объёму появляются только в том случае, когда монографии выполняет какую-то необязательную роль, скажем, когда используется в качестве докторской диссертации. Да и peer review, о чём автор прямо упоминает: «Prior to their publication in book form, the „Notes on Structured Programming“ have been distributed privatly» и далее по тексту «спасибки» ревьюверам. Плюсом там ревьювером был как минимум ещё редактора сери Хоара, который, кстати, в предисловии прямо называет работы, вошедшие в книгу монографиями.
Статистика — это факты, можно спорить с методикой сбора, можно спорить с методикой расчетов или выводами, но опровергать исследование только на основании того, что оно статистическое — глупо.
И точно так же глупо верить результатам статистических исследований, не ознакомившись с ними. Вы оригинальные исследования то читали или просто верите автору «на слово»?lair
21.06.2016 14:04+2NoSP — монография [...] Никаких ограничений по объёму на монографии не накладывается, монография — это по сути просто писанина на одну конкретную тему.
Окей, давайте начнем с простого: какое определение монографии вы используете, и где вы его взяли?
Вы оригинальные исследования то читали или просто верите автору «на слово»?
Конечно, верю на слово. В этом, собственно, смысл рецензируемой (и редактируемой) публикации — проверка источников делается рецензентом и техническим редактором. Если я буду идти по каждой ссылке в книге (а не только по интересным мне или по тем, которые нужны для конкретной дискуссии), я никогда читать не закончу.kemiisto
21.06.2016 15:06+1Окей, давайте начнем с простого: какое определение монографии вы используете, и где вы его взяли?
ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам». Никаких ограничений на объём тут быть не может, что называется, по определению: проблема проблеме рознь. Рецензирование, впрочем, тут подразумевается, ибо в современном мире издание вряд ли можно считать научным, если его не рецензировали профильные специалисты. Но, как я уже указывал выше, рецензирование имело место.
Конечно, верю на слово. В этом, собственно, смысл рецензируемой (и редактируемой) публикации — проверка источников делается рецензентом и техническим редактором.
Ну не знаю, не знаю. Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например. Так что таки следует читать как минимум выводы или резюме оригинального исследования. И никакое рецензирование Вас от этой обязанности не освобождает: ссылки на оригинальные исследования Вам, собственно, за этим и даны. Доверяй, но проверяй. А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали. :)
Если я буду идти по каждой ссылке в книге (а не только по интересным мне или по тем, которые нужны для конкретной дискуссии), я никогда читать не закончу.
Зачем ходить по не интересующим Вас ссылкам я, честно говоря, не очень понимаю. А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача. Там всё равно около 1000 страниц читать, эка проблема глазами пробежать десяток другой abstract'ов. :D Конечно, если возникнут сомнения или просто появиться интерес к оригинальному исследованию, его придётся читать. Ну а что делать? Вам ссылки, повторюсь, за этим и даны.lair
21.06.2016 15:16+1ГОСТ 7.60-2003, например, определяет монографию как (стр. 6, п. 3.2.4.3.1.1) «научное или научно-популярное издание, содержащее полное и всестороннее исследование одной проблемы или темы и принадлежащее одному или нескольким авторам».
Агу. С момента "полное и всестороннее исследование" уже смешно?
Но, как я уже указывал выше, рецензирование имело место.
Раз уж пошла такая пьянка, можете указать, откуда именно вы цитируете фразу "Prior to their publication in book form, the „Notes on Structured Programming“ have been distributed privatly", и почему вы считаете, что она означает peer review?
Как по мне, Вы поступаете не совсем правильно: цитирующий автор может запросто (нарочно или нет) исказить смысл цитируемого исследования, некорректно его интерпретировав, например.
… за что его должны побить по рукам рецензент и/или редактор.
А иначе, будь по-вашему, их бы давали только рецензентам, а из публичных копий убирали
А мне их дают для того, чтобы я мог, если мне интересно, пойти и почитать побольше и поподробнее.
А просмотреть хотя бы резюме по интересующим — это не такая и времязатратная задача.
Серьезно? Вы пробовали это проделать для того же МакКоннела?
эка проблема глазами пробежать десяток другой abstract'ов.
Сколько-сколько? Вообще-то, в МакКоннеле 21 страница библиографии (извините, я сейчас не буду проверять, сколько из нее реально цитируется). Кстати, далеко не вся эта литератора доступна в открытом виде.
Вам ссылки, повторюсь, за этим и даны.
Зачем мне даны ссылки, я уже сказал выше.kemiisto
21.06.2016 15:38+1… за что его должны побить по рукам рецензент и/или редактор.
В идеальном мире, да, должны. А в реальном, как говориться, Вам никто ничего не должен. Или, вспоминая актуальный ногомяч, как там было у Аршавина? «Ваши ожидания — это Ваши проблемы.» :) Программисты должны писать чистый код — это из той же оперы.
Серьезно? Вы пробовали это проделать для того же МакКоннела?
Я подобной работой занимаюсь каждый день. Иду к PhD (не в области информационных технологий, но не суть) и каждый божий день приходиться блуждать туда-сюда по куче ссылок и читать как минимум abstract'ы того, что цитируют. Поверьте, мир далеко не идеален. Часто цитируют даже не совсем ту работу (пускай и тех авторов), которую бы стоило процитировать (в том смысле, что утверждения, которое пытаются подкрепить цитированием, в цитируемой работе вообще нет ни в каком виде) :D А иногда вообще цитируют (сразу видно) даже не открывав оригинал: все цитируют, и ты цитируй. И ерунда что эти мифические все цитируют совсем в другом контексте. И рецензенты — тоже люди с теми же слабостями, запросто пропускающие чужие умышленные и неумышленные ошибки. Резюмируя: как минимум резюме/выводы цитируемых работ стоит пробегать глазами, чтобы не попасть впросак.lair
21.06.2016 15:42+1А в реальном, как говориться, Вам никто ничего не должен.
У нас с вами разные "реальные миры".
Программисты должны писать чистый код — это из той же оперы.
Ну, я вот считаю, что я должен писать чистый код.
Я подобной работой занимаюсь каждый день.
Я тоже "подобной работой" в свое время достаточно прозанимался на защитах и рецензировании. Так вот, затраты времени для меня несопоставимы с полученной выгодой.kemiisto
21.06.2016 17:11+1У нас с вами разные «реальные миры».
Такое, конечно, возможно, но что-те не очень верится…
Так вот, затраты времени для меня несопоставимы с полученной выгодой.
Да мне тоже осточертело, но вот прямо сейчас заставить себя отказаться от привычки всё проверять хотя бы «по минимуму» не могу. Когда-то не мог себя приучить к этому, теперь не могу разучиться.
Консенсуса, как я вижу, у нас тут не получилось, но и обмен мнениями — «уже хлеб». :D
lair
21.06.2016 14:12+1Впрочем, для изначальной темы обсуждения достаточно уже и того, что вопрос "полезно ли учиться по МакКоннелу" благополучно забыт, а обсуждаются только и исключительно монографии Дейкстры и статистические исследования. Что наводит на мысль, что с изначальным посылом вы больше не спорите.
kemiisto
21.06.2016 15:11+1А какой там был изначальный посыл? Как бы то ни было, если Вам так интересно, то мой ответ на вопрос: «Полезно ли учиться по МакКоннелу» очевидно: «Нет, так как там особо нечему учиться.» Пробежать глазами стоит, не более. Мартина даже пробегать глазами не стоит.
lair
21.06.2016 15:19+2А какой там был изначальный посыл?
Первоначальный — что ваше утвеждение "Code Complete — откровенное "бумагомарательство" некорректно. Далее мы пришли к вопросу "вредна ли Code Complete (Pragmatic Programmer, Clean Code, Clean Coder...) при обучении программиста?"
«Полезно ли учиться по МакКоннелу» очевидно: «Нет, так как там особо нечему учиться.»
О, а расскажите мне, пожалуйста, откуда начинающему программисту научиться правильному именованию? Документированию кода? Основам рефакторинга?kemiisto
21.06.2016 15:26-1Изначальный посыл был всё-таки про Clean Code, уже потом в качестве ещё одного примера я упомянул Code Complete, а про Pragmatic Programmer я вообще ничего не говорил. Хотя есть стойкое ощущение, что всё это одного поля ягоды, но это скользкая дорожка. Pragmatic Programmer не читал и пока, как следствие, не осуждаю. По второму вопросу, в очередной раз повторю, правильному именованию, документированию кода, основы рефакторинга — это всё существенно только для кодирования. С точки зрения программирования — это «шелуха». А проблема в том, что этой «шелухой» часто подменяют программирование. Впрочем, я уже это говорил в этой теме…
lair
21.06.2016 15:33+2Изначальный посыл был всё-таки про Clean Code
Правда? "А уж современные писульки а-ля «Совершенный код»" Ни слова про "Clean Code".
По второму вопросу, в очередной раз повторю, правильному именованию, документированию кода, основы рефакторинга — это всё существенно только для кодирования. С точки зрения программирования — это «шелуха».
Вот только без этой, как вы выражаетесь, "шелухи" программирования не будет. Все эти навыки — обязательное (хотя и не достаточное) предусловие для становления программиста. В частности, если программирование — это управление сложностью, то правильное именование — обязательное условие управления сложностью (вы не можете адекватно воспринимать программу, в которой нарушено именование).kemiisto
21.06.2016 19:46В самом начале я перепутал название: книга Мартина называется таки «Чистый код», да.
lair
21.06.2016 23:57Это не мешало вам потом все те же самые претензии высказывать Code Complete (я название упомянул сразу же). Кстати, в названии Clean Code тоже нет ничего претенциозного.
И еще раз кстати: а чем, бишь, мартиновские соглашения по именованию "тривиальнее" макконнеловских? Между прочим, прекрасная глава, еще и существенно менее занудная, нежели у МаКоннела.
kemiisto
22.06.2016 19:21Потому что всё то же самое верно и про Code Complete. Она только длиннее, скучнее и с претензией на большую научность.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание, которое считаю достаточно нетривиальным: про длину имён. «The longer the scope of a variable, the longer is its name; variables in very short scopes should have very short names.» А для классов и функций — наоборот.
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?» Возможно, кончено, для меня они кажутся тривиальными, потому что есть опыт работы с большими и достаточно формальными (хоть и не программными) текстами на естественном языке, к которым почти все эти правила точно так же применимы. Имена должны быть содержательными, легко произносимыми, удобными для поиска, никаких шуточек и каламбуров, единственный термин для каждой отдельной концепции, и т.д. и т.п. Ну да, ну да, всё так. Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры. Книжки а-ля «Чистый код» могут написать сотни и тысячи авторов (и, собственно, и пишут), а на тексты уровня «Заметок по структурному программированию» способны единицы.lair
22.06.2016 20:43Потому что всё то же самое верно и про Code Complete
Ну значит тот факт, что вы в начале перепутали название, особого значения не имеет (хотя, конечно, и забавен). И, значит, ваш "изначальный посыл" равноприменим к обеим книгам.
Я не считаю мартиновские соглашения по именованию «тривиальнее» макконнеловских. Я и те, и другие считаю вещью даже не второстепенной и тривиальной. Вот я сейчас глянул с свои заметки по книге Мартина, я себе из всей «воды» про именования «отжал» только одно замечание,
Согласитесь, что это что-то говорит о книге только в контексте ваших знаний на момент, когда вы ее читали?
Я не говорю, что остальные советы вредны или бесполезны, они просто ну донельзя тривиальны. При их прочтения у меня возникает только один вопрос: «А как вообще может в голову придти делать как-то иначе?»
Да легко. Я ежедневно вижу код (разного происхождения), который эти советы игнорирует и нарушает.
Но я повторю свою изначальный тезис: это всё ну уровень Дейкстры.
Ну, с этим тезисом я спорить не буду, особенно учитывая что он восхитительно неоднозначен. Дело, однако же, в том, что из этого тезиса никак не вытекает, что Clean Code или Code Complete — "откровенное "бумагомарательство"". Учебники для школы и для ВУЗа — на разных уровнях, и оба этих уровня — не уровень докторской диссертации… и что? Учебники не нужны?
Я повторю единожды уже заданный вопрос: по каким книгам (предпочтительно, конечно, Дейкстры или "уровня Дейкстры") начинающему программисту научиться правильному именованию?
KlimovDm
21.06.2016 09:32+7«Бумагомарательство» — это, конечно, сказано сильно, хотя если принимать во внимание количество бумаги… :)
Сравнивать Макконнелла и Дейкстру на мой взгляд вообще не совсем корректно, и вот — почему.
Макконнелл — копает. Дейкстра говорит — в каком месте копать.
Дейкстра пишет музыку. Макконнелл — самоучитель игры на фортепиано.
Дейкстра — это Хендрикс, Макконнелл — Мальмстин.
Иными словами — Дейкстра — это стратегия. Макконнелл — тактика.
И то и другое дополняет друг друга. Более того, тактика и стратегия друг без друга — никуда.kemiisto
21.06.2016 11:44Про «бумагомарательство» — это, конечно, утрирование было, или, как нынче модно говорить, «наброс», но, ей богу, на 450 страниц у того же Мартина есть явный перебор «тривиальщины», постоянных повторений и откровенной «воды». А по поводу стратегии и тактики, я где-то даже соглашусь с Вами. Но отметьте, что тактика — это всего лишь инструмент реализации стратегии, т.е. первична то именно стратегия. А теперь простой вопрос: сколько по Вашему мнению программистов ознакомились со стратегией (Дейкстра, Вирт) перед тактикой (Мартин, Макконнелл)? Уже отмеченный выше факт, что труды Дейкстры и Вирт — нынче библиографическая редкость как бы намекает на правильный ответ.
evans2094
21.06.2016 12:31+2Я бы сказал подругому. Один пишет, что нельзя скручивать медь и алюминий без аргументации. Второй объясняет почему именно нельзя (и не только медь и алюминий, медь с железом тоже классную биметаллическую пару организует) и не забывает описать как их можно все-таки скрутить, если очень приперло, с минимальными жертвами для себя и окружающих.
KlimovDm
21.06.2016 13:10Я совсем недавно хотел сыну на ДР подарить хорошую правильную книгу. Подумалось о Дейкстре. Да, вы правы — не нашел. «Тактики» — сколько угодно, а этого нет. Пришлось заказывать на Озоне из категории «печать по требованию».
chaetal
22.06.2016 11:46+1Безотносительно темы спора, чисто по форме… начинаю понимать, почему Alan Kay сказал
I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras.
Не знаю, относится ли это непосредственно к Дейкстре… но к некоторым моментам этой переписки — емким, четким и по существу — вполне… ;)
GreenPeace
21.06.2016 00:41брал вилку слева от себя… приходилось брать вилку и справа от себя… Если вилка требовалась другому философу, ему приходилось ждать, пока она освободится.
Звучит как практическое пособие по созданию Deadlock.
robert_ayrapetyan
21.06.2016 03:20+2Наоборот, на этом примере им были даны пути разрешения этих самых Deadlock-ов.
GreenPeace
22.06.2016 22:43Похоже вы путаете «Deadlock» (взаимная блокировка) с синхронизацией доступа. Пример объясняет как синхронизировать доступ к ресурсу. Но делает он это не правильно, так как нарушен принцип установки взаимоотношений между блокировками. Так, например все философы сначала берут правую вилку. Но понятие правая вилка — относительно и у каждого философа своё. И если так случится что все философы сядут за стол одновременно — то они все возьмут «правые» вилки и будут ждать «левые» — вот тут и случиться Deadlock.
robert_ayrapetyan
23.06.2016 01:43Вообще-то я имел ввиду оригинал задачи (и там именно проблема Deadlock-a описана, как результата неправильной синхронизации доступа, и пути разрешения этой ситуации)
khrundel
21.06.2016 09:09+1Не поверите: этот пример и придуман для того, чтоб продемонстрировать опасности блокировки и способы их избегания. Более того, процитированный текст опускает тот факт, что по условиям философы берут вилки последовательно, так что философ, ожидающий освобождения вилки при этом может держать другую вилку в руке.
javerma
21.06.2016 09:09-3Очень надеюсь, что когда-нибудь люди перестанут считать программирование «великим творчеством». Может быть, до Дейкстры это было так, но он сам всё творчество убил, и слава Дейкстре, ни он, ни Вирт, ни Хоар творчество не воскрешали.
Fedcomp
21.06.2016 09:25+5Очень странный аргумент. Программирование как ремесло подходит только с задачами где все давно решили обсосали и оно проиндексровалось в гугле. Как только доходит до чуть более нетривиального функционала, это уже походит на творчество. Читая некоторые опусы по embedded системам например можно часто наткнуться как автор очень хитро решает проблему нехватки ресурсов/портов и так далее. Чем это не творчество?
javerma
21.06.2016 12:10Вы же не считаете творчеством строительные работы? Там может творчество архитектора где-то когда-то произошло, но на этапе строительства всё должно быть чётенько и по гостам. Такое вот разделение уровней творческости, с поправкой на особенности нематериального мира.
«Таджикам» 21-го века не нужно быть конструктивистами на рабочем месте.kemiisto
21.06.2016 12:35Как раз эти «поправки» на особенности нематериального мира тут и играют определяющую роль. Фантазируй, твори, машина стерпит. В реальном то мире «фантазёрам» обычно очень быстро «прилетает» от матушки-природы. :D Там то правила игры жёсткие и определяются не человеком, а тут ну такой простор для «творчества», такой простор…
kemiisto
21.06.2016 13:03Уточню, что «фантазии» в конечном счёте отольются горькими слезами и при работе с нематериальным миром, вот только не так сразу, как в случае мира материального. В (технический) долг, зачастую, берут одни, а расплачиваются уже другие…
iChaos
21.06.2016 13:46>> Очень надеюсь, что когда-нибудь люди перестанут считать программирование «великим творчеством».
Позвольте ответить цитатой, из одной книги по программированию: ”Программа – это Идея, изложенная программистом на языке программирования".
Таким образом, до тех пор пока задача создания программ будет требовать от программиста интеллектуальных усилий, программирование будет считаться творчеством…javerma
21.06.2016 14:53Не очень понятно, каким определением творчества Вы руководствовались в своём рассуждении.
lair
Мимими. Как из первого утверждения ("алгоритм относится к жадным") вытекает второе ("алгоритм достаточно эффективен")? "Жадность" алгоритма — это всего лишь указание на используемую в нем стратегию, эффективность может быть любой.
Теперь "достаточно эффективен [...] на относительно небольших графах". А на больших — не эффективен? А какой вы знаете более эффективный алгоритм, работающий в тех же допущениях, что и алгоритм Дийкстры?
(ну и да, если речь идет о разнице между оригинальным алгоритмом Дийкстры 1959-года (O(V2)) и современными его реализациями (O(E + V log V)), то утверждение "Алгоритм Дейкстры широко применяется и сегодня" неверно, потому что очевидно, что сегодня применяются современные реализации, а не оригинальная)
andreishe
https://upload.wikimedia.org/wikipedia/commons/8/85/Dijkstra.ogg