Некоторое время назад мне понадобилось процитировать известное письмо Дейкстры 1968 года, и я воспользовался случаем, чтобы таки внимательно прочитать его. В наши дни "споры о `goto`" уже неактуальны, поскольку в большинстве современных языков команды `goto` либо нет вообще, либо используется она редко, и стало быть, обсуждать особо нечего. Однако мне была интересна аргументация. В нашей области масса "фольклорного знания", которое на поверку не всегда оказывается точным (что хорошо показано в книге Боссавита), так что оценить логику Дейкстры с позиции сегодняшнего дня не помешает. Надо сказать, что его формулировки не всегда легко понять, поэтому я решил изложить их несколько более простым языком, потратив немного больше места.
Дзен Nim
21 min
Translation
1. Копирование плохого дизайна — плохой дизайн.
2. Если компилятор не может рассуждать о коде, то и программист не может.
3. Не стой на пути у программиста.
4. Перенеси работу на этап компиляции: программы запускаются гораздо чаще, чем компилируются.
5. Настраиваемое управление памятью.
6. Лаконичный код не мешает читабельности, он ей способствует.
7. (Задействовать метапрограммирование, чтобы оставить язык компактным).
8. Оптимизация это специализация: если вам нужно больше скорости, пишите кастомный код.
9. Должен быть только один язык программирования для всего. Этот язык — Nim.
Спрос рождает предложение: как потребности программистов выливались в языки программирования
10 min
Про развитие программирования уже писано-переписано, и вряд ли можно сказать что-то принципиально новое. Однако полезно время от времени отрываться от текущих задач, окидывать взглядом прошлое и осознавать, как именно всё пришло в текущую точку. Легко воспринимать всё вокруг как данность, но когда разбираешься, понимаешь, по каким причинам что-то возникло. В истории было много витков, на каждом из которых языки программирования давали ответ каким-то запросам своего времени.
Этот пост — «краткое содержание предыдущих серий», где эти витки собраны вместе (конечно, в очень упрощённом виде: в одном тексте все важные нюансы не расписать). А после него, окинув взглядом весь контекст, можно и на текущие задачи посмотреть по-новому. Какие новые запросы человечества видны сейчас, и какими станут новые языки программирования, отвечающие на них? Расскажите в комментариях, через десять лет проверим.
О структурном программировании
2 min
Многие в комментариях к посту об операторе goto высказывали одно и то же мнение, которое звучит примерно так: «За n лет написания программ мне ни разу не понадобился goto, и использовать его в будущем я тоже не собираюсь». И они абсолютно правы, уже давно доказана теорема о структурировании, в которой говорится, что любая простая программа функционально эквивалентна структурированной программе составленной с использованием функций и предикатов исходной программы, а также с использованием дополнительного счетчика. Доказательством является алгоритм составления той самой структурированной программы:
- пронумеровать все узлы схемы, при этом порядок обхода произвольный;
- пронумеровать все дуги схемы следующим образом: выходной дуге схемы припишем номер 0, всем остальным дугам присвоим номер вершины, в которую данная дуга входит;
- для каждого функционального узла исходной программы, имеющего номер i и выходную дугу j, составить новую простую последовательную программу Gi с номером входной дуги i
- для каждого предикатного узла с номером i составить новую простую программу
- построить программу типа while do с do-частью в виде структры, проверяющей значения L.
«Забытые» парадигмы программирования
5 min
Получилось так, что те парадигмы, которые раньше потом и кровью пробивались в свет через орды приверженцев традиционных методов постепенно забываются. Эти парадигмы возникли на заре программирования и то, почему они возникали, какие преимущества они давали и почему используются до сих пор полезно знать любому разработчику.
Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!
Эдсгер Дейкстра: в поисках «кратчайшего пути» к осознанному программированию
11 min
Изображение с сайта abv24.com
Один из тех людей, с именем которых связано превращение программирования из шаманства в науку, — Эдсгер Дейкстра. Он небезуспешно доказывал, что программирование — высокое искусство и интеллектуальное творчество.
Во всех своих исследованиях Дейкстра придает большое значение простоте и изяществу математических рассуждений. При написании своих работ он создал новый стиль научных и технических сообщений, который можно описать как нечто среднее между журнальными публикациями и дружеской перепиской.
Программирование – не набор пассов и заклинаний, не шаманство, не танцы с бубном, а математическая дисциплина. А всякая дисциплина, если она претендует на нечто большее, чем на внешний эффект, должна строиться на прочном фундаменте. Таким фундаментом для Дейкстры является математическая логика, а точнее – исчисление предикатов.
Сейчас это не кажется чем-то необычным, но в 50-е годы это прозвучало как откровение. Дейкстра понял и убедительно показал, как теория может и должна помочь практике.
История языков программирования: Algol — жертва конфликта интересов
9 min
Влияние Algol на ИТ-индустрию
Название языка Algol (ALGOrithmic Language), первая версия которого появилась в 1958 году, подчеркивает то обстоятельство, что он предназначен для записи алгоритмов. Благодаря четкой логической структуре Algol стал стандартным средством записи алгоритмов в научной и технической литературе. Однако он так и не смог полноценно конкурировать с языком Fortran, а с COBOL его и вовсе было трудно сравнивать в силу отсутствия некоторых важных возможностей у Algol – той же обработки текстов например или форматирования ввода/вывода.
«Роды» Algol проходили очень тяжело. Для некоторых его создателей, прямо скажем, – в муках. Ученые и эксперты отрасли никак не могли прийти к единому мнению по многим вопросам.
В результате новый язык скорее вызвал интерес, чем привлек потребителей. Грейс Хоппер охарактеризовала его так: «Похож на большую поэму: простой и ясный с точки зрения математики, но отнюдь не практичный».
Точки выхода или немного о структурном программировании
3 min
Читая Хабрахабр или просматривая чужие исходные коды, мне довольно часто приходится замечать примерно следующий кусок кода, который совершенно одинаково «звучит» на любом языке, на каком бы не был написан:
Здесь приведён кусочек кода на Javascript, но то же самое можно написать на нескольких десятках других языков. Что здесь не так? Только то, что у функции (метода, свойства, процедуры) несколько точек выхода. Если вам интересно почему это плохо, прочитай то что написано под катом.
function(single_document)
{
if (single_document.getElementById("comments") != null)
return;
…
…
…
…
}* This source code was highlighted with Source Code Highlighter.
Здесь приведён кусочек кода на Javascript, но то же самое можно написать на нескольких десятках других языков. Что здесь не так? Только то, что у функции (метода, свойства, процедуры) несколько точек выхода. Если вам интересно почему это плохо, прочитай то что написано под катом.
Существуют только структурная и объектная парадигмы программирования
14 min
Эту статью я подготовил во время дискуссий по поводу паттерна Мост, но тогда не опубликовал. Думал разобрались, так как было упомянута Domain Driven Design, и казалось, что необходимость проектирования и программирования именно в стиле ООП никем не оспариваются. Но все же со временем я столкнулся с непониманием. Это будет чисто историческая теоретическая статья. Конечно, даже без попытки обхвата всей широты темы. Но это так сказать посыл молодому разработчику, который читает по верхам и не может выбрать каких принципов и правил ему придерживаться, что первично, а что вторично.
Заглавие этой темы для многих сейчас может показать очень спорным (и скорее намерено провокационным, но для дела :) ). Но все же мы постараемся это здесь обосновать и понять какими свойствами должна обладать парадигма программирования, чтобы иметь право называться парадигмой.
Единственно прошу, если прочитали по диагонали — комментируйте сдержано.
Заглавие этой темы для многих сейчас может показать очень спорным (и скорее намерено провокационным, но для дела :) ). Но все же мы постараемся это здесь обосновать и понять какими свойствами должна обладать парадигма программирования, чтобы иметь право называться парадигмой.
Единственно прошу, если прочитали по диагонали — комментируйте сдержано.
Я не знаю ООП
12 min
Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.
Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.
И вот несколько вещей, которые вызывают у меня непонимание.
Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.
И вот несколько вещей, которые вызывают у меня непонимание.
Люди не понимают ООП
Medium
15 min
Opinion
Translation
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1
Похоже, многим не нравится объектно-ориентированное программирование. Первое, что приходит в голову, когда слышишь эту трёхбуквенную аббревиатуру — это пример с автомобилем, наследование, геттеры, сеттеры и ObjectFactoryFactorySingleton.
Мне это всегда казалось довольно странным. Мне не только нравится ООП, я ещё и считаю, что часто это лучший/наиболее очевидный способ моделирования задачи. И ниже я расскажу, почему.
Размышления о структурном программировании
Medium
3 min
Review
Изначально я хотел назвать статью как нибудь вызывающе, например, "Как наука может превращаться в религию", "В ловушке искажений смыслов структурного программирования" или "О чем вам забыли рассказать про структурное программирование", но в результате все же оставил текущее название и надеюсь, оно не вызывает раздражения у читателей. И хотя другие заголовки являются более кликбейтными, тем не менее они все же в больше степени отражают смысл статьи, чем нейтральные "размышления".
А поводом к этой статье послужил один из комментариев к предыдущей публикации Управление памятью и разделяемыми ресурсами без ошибок, где написали "было доказано математически". А я сразу вспомнил свое небольшое расследование, когда пытался разобраться в одном из "математических доказательств", про которое нам всем рассказывают еще в школе на уроках информатики.
Все наверно помнят, что любой алгоритм можно представить в виде трех видов алгоритмических конструкций, следование, ветвление и повторения? А иногда еще добавляют, что эту теорему выдвинул и доказал Э. Дейкстра в 70-х гг. прошлого века, в том числе, включая широко распиаренный якобы запрет на использование операторов goto.