Роберт Мартин: "Будущее программирования" / Robert Martin: "The Future of Programming"

Публикация № 975789

Программирование - Теория программирования

85
Перевод-транскрибация выступления.

 

C++, Objective-C и история чудесного возрождения

Что с нами не так?

В прошлое, чтобы понять настоящее

Новая эра : вниз по водопаду и попытка вернуться к Agile

Инженеры и бизнес. Риски и ответственность.

Выбор будущего

 


Роберт Мартин - автор книг "Чистый код", "Чистая архитектура", ряда других книг по разработке ПО, один из авторов Agile-манифеста. YouTube подбросил мне в список рекомендаций его интереснейшее выступление "Будущее программирования".

После поисков в сети не нашел перевода и даже транскрибации на английском. Наткнулся только на просьбы сделать перевод на нескольких форумах и решил, что выступление этого действительно достойно. Это интересный экскурс в историю от зарождения индустрии до наших дней. И да, оно больше про историю и настоящее, чем про будущее. Название обманывает ))  Перевод не дословный, поэтому рекомендую по возможности посмотреть и само выступление: https://www.youtube.com/watch?v=ecIWPzGEbFc.

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

Ряд вопросов покажется чуждым для разработки на платформе 1С, но есть и те, что имеют к нам непосредственное отношение.

В общем читайте или слушайте и делайте выводы сами.


 

 

C++, Objective-C и история чудесного возрождения

 

Среди вас наверняка есть люди, знакомые с языком Objective-C. Он был создан больше 36 лет назад в 1980 году Брэдом Коксом. Зачем он это сделал? Он просто хотел улучшить язык C. Точно также как Бьёрн Страуструп, который создал C++ в том же самом 1980 году.  

Брэд Кокс был программистом на Smalltalk , но он был вынужден программировать на C. Ему это не нравилось. Поэтому он написал небольшой препроцессор для C, который делал его хоть немного похожим на Smalltalk, и назвал это Objective-C. Бьёрн Страуструп был программистом на Simula, но он был вынужден программировать на C. Ему это не нравилось. Поэтому он написал небольшой препроцессор для C, который делал его хоть немного похожим на Simula, и назвал это "C with Classes".  Потом какой-то парень пришел к нему и сказал, что это неподходящее имя, и тогда язык был переименован в C++. Оба языка были созданы с одной целью, в одно время и развивались параллельно.

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

 

Но потом произошло кое-что странное... Бьёрн Страуструп написал книгу...

Большинство программистов на C и на производных от него языках знают книгу Кернигана и Ритчи "Язык программирования Си". Если вы программист на C, то у вас должна быть эта красивая белая книга с бумажным переплетом и большой голубой буквой "C" на обложке. В ней около 150 страниц и если вы ее откроете, то увидите очень приятный шрифт, хорошо структурированный текст. Нумерация глав у нее начинается с нуля, а не единицы. Нумерация с нуля была хорошим маркетинговым ходом. В итоге каждый гик знает об этом факте и этой книге.  

Так вот, в 1986 Бьёрн Страуструп опубликовал книгу "Язык программирования С++". Она была не белой, а бордовой. Вместо голубой буквы "С" на обложке у нее на обложке была золотая буква "С". И рядом с ней еще два плюса. Но у нее был точно такой же бумажный переплет и тот же самый форм-фактор. Вы открывали её и видели тот же самый шрифт, такую же разметку и таким же образом структурированный текст. Она была написана похожим языком. А главное, нумерация глав в ней также начиналась с нуля вместо единицы. И все программисты сказали : "О!  Это же новый Си!". И они все бросили Objective-C и ушли в C++. Компания Брэда Кокса, пытавшаяся продавать Objective-C, была слита в канализацию.

 

И это должен был быть конец. Objective-C должен был умереть в этот момент. Если бы не один поворот судьбы.  Этим поворотом стал успех компании Apple в начале двухтысячных. Apple продавала компьютеры Макинтош в 1983 году, а до этого компьютеры Apple 2. У нее были миллиарды долларов и один молодой человек по имени Стив Джобс тогда решил, что его компании нужен хороший управляющий. Он немного поискал вокруг и нашел худшую кандидатуру для этого - человека по имени Джон Скалли. Скалли до этого был вице-президентом Пепси Колы. Вам наверное кажется странной идея позвать такого человека для управления Хай-Тек компанией, но аналогичная мысль не пришла тогда в голову Стива Джобса. Выбор Скалли оказался фатальным, этот человек утянул компанию вниз. Но Скалли был достаточно грамотен как политик, чтобы перед этим уволить Стива Джобса из его же собственной компании.

И Стив Джобс уйдя из Apple с несколькими миллиардами долларов в своём кармане сказал "Я ещё покажу этим парням". Он основал новую компанию Next и стал производить железо, намереваясь конкурировать и уделать этих гадов из Apple. А в это время на улице ходила толпа никому не нужных парней с плакатами "Буду программировать на Objective-C за еду". И Джобс нанял этих парней для создания операционной системы для Next.

Компьютеры от Next не снискали популярности. Я знаю только одну компанию, которая купила один из них и это компания, которой я сейчас владею. Но дальше снова был крутой поворот. Спустя несколько лет компания Apple избавилась от Скалли и обратилась к Стиву с просьбой : "пожалуйста, вернись к нам, похоже, что теперь мы не обойдемся без тебя". И Джобс сказал: "Хорошо, я вернусь, но тогда я прихвачу с собой всю мою команду". Так в Apple появилась целая куча программистов на Objective-C и написанная на нём операционная система для Next. Затем они стали работать над iPad.

Так язык полностью возродился. К сожалению.

 

 

Что с нами не так?

 

Теперь собственно вопрос. Почему мы, программисты, никогда не довольны нашими языками? Никогда!  Сколько сейчас языков? Сотни и сотни и завтра появятся еще сотни. Сколько языков появилось за последние пять лет?  Swift, Golang, Dart... и еще целая куча. И сколько еще нам будет нужно ближайшие годы?

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

 

-  Босс, у меня есть новый язык программирования, он намного лучше!

-  Почему?

-  Потому что он новый!

-  Ох, не знаю куплюсь ли я на это в этот раз...

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

-  Ну хорошо, работай на нём.

-  Босс, у меня есть новый язык программирования, он намного лучше!

-  …...

 

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

 

А теперь я прошу сесть всех мужчин. Только мужчин. Дамы, пожалуйста стойте :

 

 

Что не так в этих картинках?  

Как так получилось, что в нашей индустрии настолько доминируют мужчины? Ведь так было не всегда. На заре программирования доля женщин в индустрии составляла примерно половину. Не ровно 50%, но около 50%. И даже когда я рос, когда я был молодым программистом, в первой компании, где я работал примерно треть программистов составляли женщины. И это были не юные 20-летки. Им было по 30, 40, 45 лет. Это были зрелые люди. Почти все программисты были зрелыми людьми. Тогда, будучи 18-летним ребенком мне казалось, что я окружен старцами. И значительная их часть была женщинами.

Через десять лет после этого (я уже работал на другую компанию) у нас было намного больше программистов и почти всем из нас было от 20 до 29 лет. Нас было около 50 программистов и среди нас было всего 2 или 3 женщины.

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

 

 

В прошлое, чтобы понять настоящее

 

Мы начнем с изучения истории, с 1936 года. А вот здесь я, нарисованный синей стрелкой. Я родился в 1952, всего несколько лет от точки отсчета.

 

Точкой отсчета мы возьмем 1936 год по одной важной причине. Алан Тьюринг в этом году оказался пожалуй первым человеком на свете, написавшим код, который вы и я могли бы распознать как программный код. Он исполнялся электронным компьютером, использовал бинарное представление инструкций и в то же время вы или я могли бы посмотреть на него и сказать : "да, это программный код". И в этом же году он написал публикацию "О вычислимых числах с приложением к проблеме разрешимости"  (в ней он формализовал понятие алгоритма и ввёл понятие, известное теперь как "Машина Тьюринга").  Это удивительная публикация.

 

Есть ещё такой парень, Чарльз Петцольд  (Charles Petzolde). Он известен как автор целой кучи книг для Microsoft. Но он также написал книгу "Читаем Тьюринга"(The Annotated Turing). Он взял публикацию Тьюринга , разобрал её на маленькие кусочки и затем заботливо окружил каждый из этих кусочков историей, объяснениями и шаг за шагом прошел по исходной публикации, рассказывая, о чем именно говорил Тьюринг и почему. Прекрасная работа, она настолько хороша, что я читал её дважды.  Рекомендую вам прочитать обе эти публикации - и Тьюринга и книгу Петцольда.

Итак, Тьюринг, представил в 1936 году концепцию, в которой мы с вами можем узнать "компьютер". Он также изобрел другие вещи - подпрограммы,  макросы, переменные, бинарный код.

К 1939 году Тьюринг работал над дешифраторами и несколько машин, которые он использовал для взлома шифров, использовали реле. Они выглядели вот так :

 

 

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

 

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

 

1945 год. После окончания войны была создана машина ACE  (Automatic Computing Engine)   - один из первых компьютеров в мире.

На фотографии за компьютером сидит не Алан Тьюринг, а настоящая женщина, обратите на это внимание. ACE - это машина, которую помог спроектировать Тьюринг. Он разработал набор инструкций, ширину слова, саму концепцию этой машины.  

 

ACE могла складывать, но не вычитать. Чтобы выполнить операцию вычитания необходимо было инвертировать биты, выполнить побитовый сдвиг и затем сложить. На самом деле Тьюринг даже не хотел вводить операцию сложения. Он считал, что достаточно побитовых операций И, ИЛИ, НЕ, с помощью них уже можно было выполнять сложение. Но разработчики оборудования посчитали, что это замедлит вычисления и добавили операцию сложения.

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

Компьютер ACE использовал в качестве памяти "линии задержки" на основе ртути. Только представьте себе это. Трубка с жидкой ртутью, с одной стороны находится динамик, а с другой специальный микрофон. Звук с высокой частотой отправлялся из динамика в трубу со ртутью, принимался на другой стороне микрофоном и отправлялся обратно на динамик.  Это была циклическая, замкнутая память, позволяющая хранить 1024 бит в каждой ртутной трубке.  В распоряжении у ACE было 22 таких трубки. Порцией данных было вращающееся в трубках слово длинной 22 бита, по биту в каждой трубке. Это всё, что было у них в распоряжении.

 

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

Но уже это позволило Тьюрингу сделать большой шаг вперед. Зеленый квадрат на рисунке ниже - это устройство вывода, которое он использовал. Он мог читать вывод компьютера глядя прямо на саму физическую память компьютера как на экран. Он видел нули и единицы, наборы битов, проводил с ними операции. Представлял ими символы используя base32, биты при этом были переставлены в обратном порядке по сравнению с современным представлением base32.

 

 

1945 был также тем годом когда были изобретены программный стек и подпрограммы. Тьюринг предложил использовать стек для хранения адреса возврата из подпрограммы, что было действительно новаторской идеей для того времени. Были изобретены числа с плавающей точкой, умещавшиеся в слово из 22-ух бит.  Для этого пришлось написать библиотеку подпрограмм для работы с такими числами.

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

 

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

 

  

 

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

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

В 1945 году количество компьютеров было порядка O(1). Возможно больше одного, например около четырех, но не больше. Количество программистов было того же порядка - их были единицы. Это было 74 года назад. 

 

1950-ые года. Память на электронно-лучевых трубках, которая могла хранить тысячу бит стоила тысячи долларов. Стоимость памяти была больше 10 долларов за 1 бит. И тогда был изобретен другой тип памяти - память на магнитных сердечниках (core memory). Посмотрите на эти круглые металлические кольца на картинке. Мы намагничивали их пропуская электический ток через проходящие сквозь них провода. После намагничивания кольца, можно было определить факт того, что оно намагничено путем пропускания тока через провод в противоположном направлении. Если кольцо содержало заряд, то оно вызывало ток в другом проводе и этот ток можно было считать. Как и в случае электнонно-лучевых трубок бит данных, хранимый кольцом, при считывании также уничтожался и его требовалось перезаписать.

 

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

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

 

 

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

Например условный оператор в строке 703 говорит, что если (IA + IB + IC) отрицательно, то переход выполняется к строке с меткой 777, если результат равен нулю то переход выполняется также на 777, а если положительно, то переход выполняется к строке 704.

Обратите внимание на отсутствие отступов в коде. Мы тогда еще не придумали отступы. Код пробивался на перфокартах - выбивались квадраты на месте заглавных букв и цифр.

 

 

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

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

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

Наконец приходили вы, забирали результаты, разворачивали их изучали и…. обнаруживали, что забыли запятую. И начинался отсчет следующих 24 часов. Такова была жизнь программиста в то время. И чтобы хоть как-то справиться с этим мы писали по 5-6 программ за раз. У программистов всегда была такая очередь из программ.

 

1956 год. Появился LISP.  Он был создан Джоном Маккарти для работ по искусственному интеллекту. И этот язык до сих пор отказывается умирать. Мы пытаемся убить его раз за разом, он он возвращается.  Я бьюсь об заклад, мы все закончим тем, что будем программировать на LISP ))  Потому что остальные языки умирают, а LISP всё время выживает.

И к слову сказать это первый язык для функционального программирования. А ведь мы только недавно начали понимать всю важность функционального программирования.  Много лет спустя.

 

 

Между 1954 и 1960 годом IBM продала 140 компьютеров с Фортраном и Лиспом внутри.  

 

 

Таким образом количество компьютеров в 1960 году стало порядка 100. От 100 до 900, но порядок был таким. А что можно сказать о программистах? Их из было порядка 1000. Потому что в то время на один компьютер приходилось 10-15 программистов.

 

 

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

Кто же становился программистами в то время? Программистов набирали из инженеров, ученых и математиков. У них были ученые степени. Они имели опыт в своей области и они редко были молоды. Обычно их возраст был 30, 40 , 50 лет. Это были зрелые люди. Они понимали что такое проект, что такое расписание и сроки, они не нуждались в куче менеджмента над собой. Это были люди, которым компании доверяли.

 

 

А потом появился транзистор. Он был меньше ламп, потреблял меньше энергии, был надежнее и проще в производстве. За короткое время транзисторы завоевали рынок, к 1965 году было произведено 10 000 компьютеров модели 1401.

  

 

Это была очень интересная модель компьютера - это была десятичная машина. В IBM приняли решение что всё следует привести к "десятичному" виду. На нижнем уровне операции по прежнему выполнялись в двоичном виде но имели десятичное представление. Разработчики IBM довели эту идею до того, что покупая модель 1401 с памятью 4K вы получали ровно 4000 байт. Не 4096, а ровно 4000. Адресное пространство было "десятичное".

 

Они сдавали эту машину в аренду по цене 2500 $ в месяц, что сегодня равнялось бы 20 000$. Высокая цена на аренду заставила многие компании задуматься над их покупкой вместо аренды.

И к 1965 году количество компьютеров было уже порядка 10 000 , а количество программистов порядка 100 000. Скорее всего их было 200 000 или 300 000. А ведь прошло меньше 20 лет с тех пор, как Тьюринг написал первую строчку кода.  

 

  

 

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

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

 

1966 год. IBM производит по 1 000 машин модели 360 каждый месяц. Я работал на одной из таких машин. Я работал на 360 Model 30 и на 360 Model 40. Первая имела 16 KB внутренней памяти, вторая 64 KB. Это был огромный объем памяти. Я помню когда у нас появился первый Мегабайт. Видите вон там синий ящик размером примерно с холодильник? Так выглядел Мегабайт. Он сдавался в аренду за десятки тысяч долларов в месяц. Если бы вы захотели купить его, он бы стоил десятки миллионов долларов. Это было дорогущее оборудование.

 

Тысячи и тысячи этих машин были выпущены из IBM , это возможно был самый успешный продукт IBM, который принёс им миллиарды долларов.

Это также был год, когда был создан первый объектно-ориентированный язык Simula-67. Он был создан Оле-Йоханом Далем и Кристеном Нюгором в городе Осло. Мы уже имели функциональное программирование и теперь получили объектно ориентированное программирование.

 

А в 1968 году Дейкстра написал свою знаменитую публикацию, где была обозначена вредоносность оператора GoTo и это было начало революции структурного программирования.

За эти 10 лет мы сделали три главных шага в нашей индустрии - функциональное, структурное и объектно-ориентированное программирование. Они все были сделаны в это время, этими профессионалами.  

 

А вот и Кен Томпсон и Деннис Ритчи. Тот же самый 1968 год. Мы всё ещё в 22 годах от появления первых строк кода. Эти ребята сидят в подвале AT&T и создают язык С и Unix. И это были дисциплинированные математики.

 

1970 год. Компания DEC (Digital Equipment Corporation) создает компьютер PDP8 и это был не единственный мини-компьютер того времени. Это была эра, когда все выпускали мини-компьютеры. 50 000 этих PDP8 было лишь вершиной айсберга.

 

Количество компьютеров было порядка 100 000 , а количество программистов порядка 1 000 000. Миллионы программистов спустя 25 лет с первых строк кода. Снова произошло десятикратное увеличение количества программистов за 5 лет.

  

 

Кто были все эти люди?

 

 

 

 

 

Новая эра : вниз по водопаду и попытка вернуться к Agile

 

Вот один из них. Это я. Мне 19 лет и это был возраст, когда я получил свою первую работу как программист. Бог мой, я уже был нанят, чтобы писать на COBOL.

  

 

К 1970 году десятки тысяч выпускников CS и EE  (Сomputer Science и Electrical Engineering) начали заканчивать школы. Компьютерные курсы можно было пройти в колледжах. В среде выпускников попасть в индустрию ИТ считалось престижным. Конечно в этом они были правы. И эти десятки тысяч выпускников, устремившиеся в ИТ имели кое-что общее. Мы все были юными. И почти все мы были мужчинами. Именно здесь произошел сдвиг. Доминирование мужчин в ИТ началось здесь. Я помню себя в ВУЗе, как я прикасался к компьютеру, телетайпу, подключенному к компьютеру в Технологическом Институте. Почти все кто был рядом были парнями, всего одна или две девчонки.  

Когда я пришел на свою первую работу у нас было около 24 программистов и половина из них были женщинами. Это было то место, где я программировал на Коболе. А 10 лет спустя у моего работодателя было 50 программистов. И всего три женщины. Я даже помню их имена, чего не скажешь о всех мужчинах из тех пяти десятков. Подавляющее большинство из нас было мужчинами. Точнее говоря мальчиками.

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

 

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

 

Моя первая работа как программиста давала всего лишь 6 900 долларов в год, 570 в месяц.  Но для возраста 19 лет это была куча денег. Я даже мог купить машину. Я даже мог съехать от родителей. Это было круто.

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

  

 

Какой подход к разработке они использовали? 

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

 

Мы знаем что разработчики программ для Шаттла работали итерациями длинной в 6 недель. Да, по нынешним меркам это долго, но всё же это интересный факт. Они закрывали каждый цикл разработки каждые 6 недель. Мы знаем что программисты для марсианской капсулы писали юнит-тесты на разработанные модули с утра и добивались их прохождения к вечеру. Это было чем-то похоже на TDD.

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

В 1970 году Уинстон Ройс разработал водопад просто как модель  со словами "эй, это не работает". Но похоже что эти слова никто не услышал. Его картинка была взята на вооружение, украдена прямо из его оригинальной публикации и путем копирования-вставки разошлась по документам того времени. Водопад стал процессом, применяемым по умолчанию.

 

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

Посмотрите на график - экспоненциальный рост. Количество программистов удваивается каждые 5 лет. Мы начинали всего с нескольких, а сейчас их сотни миллионов. И важное следствие из этого - половина программистов имеет менее 5 лет опыта.

 

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

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

 

Что еще поменялось помимо “демографической картины” в отрасли? Поменялось железо. Подумайте о разнице между ACE и моим ноутбуком. Даже нет, подумайте о разнице между PDP 8 и моим ноутбуком. PDP 8 мог исполнять полмиллиона инструкций в секунду. Мой ноутбук сейчас в 10 000 раз быстрее!  PDP 8 имел  4 KБ внутренней памяти. Мой ноутбук - 16 Гигабайт и это кажется немного по сегодняшним меркам. PDP 8 имел диск 32 KБ , а ноутбук сейчас 1 Терабайт SSD.  Триллион транзисторов в моем смартфоне… Что если бы он работал на триллионе вакуумных ламп? Какого размера небоскреб мог бы вместить триллион ламп? Это было бы самое большое здание в мире. На него бы работала бы сеть ядерных реакторов и стоил бы он 50 триллионов долларов. Вся экономика того мира лежит в моей руке ))  А мы сейчас производим их миллионными тиражами чтобы можно было расписаться в Инстаграме. Почувствуйте масштаб изменений в течение жизни одного человека.

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

 

Что НЕ изменилось? Вам это не понравится.

Не изменились программы. Вы бы смогли узнать код, который Тьюринг написал для компьютера ACE. Да, он бы вам не понравился, но вы бы смогли его понять. Вы бы смогли разобрать код на Fortran. Вам бы он тоже не понравился. Но вы бы смогли прочитать его и даже написать его. 

Я мог бы взять человека из 1968 года, например программиста для PDP, перенести его в будущее, посадить перед моим ноутбуком и показать ему Intellij IDEA. Ему бы потребовалось около 24 часов чтобы оправиться от шока, но потом  он смог бы начать писать код. Я бы показал ему Java и он немного помявшись сказал бы:  "Нуу ладно, Джава так Джава, интересно. Intellij IDEA хороший инструмент, хотя язык Java так себе. ООП? Это та штука с которой я работал в 1967 году, верно?". Никакой революции не произошло.  

Я мог бы взять вас и перенести в 1968 год.  Посадить перед PDP8 с телетайпом и показать как редактировать код на бумажной ленте. И вам бы потребовалось 24 часа чтобы оправиться от разочарования. Но вы смогли бы писать код. Потому что код - это присваивание, условные операторы и циклы. Ничего более. Так было и так будет - это и есть суть кода, как бы мы им не жонглировали.

 

Если мы и сделали какие-то подвижки в разработке программного обеспечения с 1945 года - это в понимании того, что не следует делать.

  • Структурное программирование  - это о том, что не следует делать. Не использовать опасный GoTo.
  • Функциональное программирование : не используйте присваивание.
  • Объектно ориентированное программирование : не используйте указатели на функции.

Что мы узнали за последние 74 года - это больше о том, что не следует делать, чем о том что нужно делать. Искусство написания программ остается в грубом приближении тем же самым, каким оно было в 1945 году, хотя и с налётом современности.

 

Что же мы должны были поменять? Уровень профессионализма, который мы потеряли из-за потока юных программистов. И уровень дисциплины, большой недостаток которой мы до сих пор испытываем. Старой гвардии, поддерживавшей дисциплину, больше не было в отрасли. Даже первая волна программистов-карьеристов уже шагнула за свои 40 лет. В 1995 году мы уже видели необходимость изменений.

   

 

И тогда Джеймс Греннинг, присутствующий здесь, я, Кен Швабер, Майк Бидл, Кэнт Бэк, Вард Канингем, создатель Crystal Алистер Клокберн и еще несколько человек стали осознавать, что эта эра водопада, в которой мы жили, должна измениться. И мы встретились в месте под названием Сноубёрд, чтобы создать Agile-манифест.

К слову я возвращался в это место несколько лет назад, один из моих клиентов сказал "Было бы круто побывать в этой комнате". Я ответил ему, что даже не помню где она находится, но он уговорил менять подняться на вершину горы и да, мы нашли эту комнату. Мы даже написали на доске то, что писали тогда, в 2001 году. После этого я сфотографировал её. Это настоящая фотография из той самой комнаты.

 

 

А вот эта картинка под текстам - это работа Варда Канингема. Вы можете рассмотреть на ней Мартина Фаулера с безумной бородой, вон там стою я и точно где-то там стоит Джеймс .

 

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

 

 

Инженеры и бизнес. Риски и ответственность.

 

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

Экстремальное программирование - это то направление Agile, которое больше всего воплощает дисциплину. Оно включает в себя TDD, рефакторинг, приемочное тестирование, подход Simple Design.

     

 

Дисциплина гарантирует, что вы будете следовать этическим принципам и принципам морали.  Например "Я буду писать тесты" - это принцип.

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

   

 

Бизнес понимает что такое дисциплина. Любой бизнес понимает что это такое и вы не можете вести бизнес без этого. И поэтому бизнесу действительно понравился Scrum за его простоту, очевидность и дисциплину, которую он предлагает. У вас есть спринты, события, планирование. Это важно для бизнеса. И бизнес подумал: да, это круто нам нужны люди, сертифицированные в этом направлении.

Но бизнес не понимает нас как программистов. Он не понимает парное программирование, он не понимает Test Driven Development, не понимает рефакторинг. Это просто выходит за рамки его экспертизы. И не должно входить! Эти практики принадлежат нам, нашей отрасли.

    

 

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

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

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

 

 

 

Выбор будущего

 

К сожалению, не все из нас с этим согласны. Часть "программистов" считают, что нам не нужны эти практики и недавно мы увидели публикации типа "TDD умерло" , "TDD, я сдаюсь", "Парное программирование? Нет!"

 

 

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

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

 

   

 

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

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

 

   

 

Где все программисты? Вы отправляетесь на Agile конференцию, а там совсем немного программистов, там не поднимают технических вопросов. Бывают попытки сделать это, но они тонут в менеджерах от бизнеса и проджект-менеджерах. Техническое мастерство превратилось в маргинальное сопротивление. Была группа людей, говорившая "подождите, у нас тут тоже право голоса, мы должны поговорить с этими людьми из нового Agile и как то объединиться". Но этого не случилось.

Здесь есть доля иронии. Ведь слова Кента Бэка, сказанные им в Сноубёрде, о целях движения были такими :  "Agile - это лекарство от разделения бизнеса и программирования". И с точки зрения движения эта цель провалена. За исключением отдельных личностей и отдельных офисов, где эту цель удается достичь. Но само движение разделилось.

 

Что же нам нужно изменить в этот раз, спустя 15 лет?

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

 

 

 

Кому то в любом случае придется быть первыми. Потому что есть большая проблема.

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

Кто нибудь знает сколько строк кода в современной машине? 10 миллионов строк кода. Зная, как создаются программы, это вас не пугает? Конечно не все они управляют двигателем, большая часть сидит в GPS и развлекательных устройствах. Но в современной машине дроссель управляется программным обеспечением. Есть софт, управляющий тормозами и акселераторами. Машина моей жены корректирует поворот руля, если она неправильно паркуется. Сколько людей убивает ПО в автомобилях? Тысячи. Много примеров когда машина таким образом теряла управляемость и разбивалась. Мы убиваем людей. Мы пришли в этот бизнес не для того, чтобы убивать людей, но так получается. И будет только хуже. Наша цивилизация всё больше полагается на нас. Хотя она пока этого не понимает, да и мы тоже.

 

Сколько из вас видели как СEO североамериканской Volkswagen давал показания перед конгрессом, обвиняя пару разработчиков программного обеспечения в том, что они подделали результаты тестов? "Ооо, это была пара  программистов, которые с чего-то накосячили".

А знаете в чем дело? Это действительно была пара программистов. Может быть даже больше. Это они написали тот код, обманывающий тесты. Некоторые программисты так делают :

Если РежимТестирования Тогда

     Сообщить("Все хорошо"); // никакого намека на модули форм в типовых конфигурациях, все совпадения случайны
     Возврат;

КонецЕсли;

 

Я даже думаю, что они осознавали, что делают. И в этом проблема. И будет день, когда кто-то из нас напишет программу, которая приведет к интересным газетным заголовкам. Что это может быть за программа? Да что угодно, от софта управляющего самолетом, до софта управляющего футбольным стадионом. Это просто вопрос времени.

Тогда политики начнут делать то, что должны. Они укажут своими пальцами прямо на нас и зададут вопрос "как вы это допустили?" Они не укажут на менеджеров, потому что менеджеры скажут:  “Это не мы, это разработчики написали такой софт, мы не знаем почему они так поступили”. И тоже укажут пальцами на нас.  И наш ответ "О, мой начальник заставил меня написать такой алгоритм" не прокатит. "О, начальник поставил мне дедлайн". Простите, но нет. Это не сработает.

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

 

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

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

И это конец моей речи.

 

85

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. DimDiemon 77 14.01.19 15:30 Сейчас в теме
За одну только эту фразу можно поставить 10 плюсов:
"Agile - это то, что дисциплинированные профессионалы используют в дикой природе"
ILM; artbear; Natain14; Vladimir Litvinenko; +4 Ответить
36. capitan 1221 27.02.19 14:19 Сейчас в теме
(1)Не читал эту статью, но написал об этом здесь еще в прошлом году)

33. capitan 1076 22.11.18 17:45 Сейчас в теме
(31)а кто вам сказал, что я не проникся аджайлом ? наоборот я сказал что команда единомышленников всегда идет по аджайлу даже если он нем и не слышали
это как яблоки падали на землю и до Ньютона и после, но уже осмысленно )


Автору большое спасибо за перевод. титанический труд.
и огромный плюс от меня
2. Gureev 14.01.19 15:54 Сейчас в теме
Возможно мы можем этого избежать? Как? Сделав это первыми. Первыми начав регулировать нашу индустрию, как это давно сделали другие отрасли. Создав принципы и этику. Установить базовый уровень морали и дисциплины и отказываться опускаться ниже. Иногда это значит сказать вашему боссу "нет", как это может например сделать врач, давший профессиональную клятву.


Бред. Бабло побеждает все. А врачи регулярно за бабло класть хотели на любые клятвы.

Менеджеры скажут: “Это не мы, это разработчики написали такой софт, мы не знаем почему они так поступили”. И тоже укажут пальцами на нас. И наш ответ "О, мой начальник заставил меня написать такой алгоритм" не прокатит. "О, начальник поставил мне дедлайн". Простите, но нет. Это не сработает.

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


Программисты сейчас могут писать все что угодно, могут реализовать любую больную фантазию, любого больного менеджера. Вопрос только в бюджете.
manlak; wowik; mivari; oninfostart; Fox-trot; Silenser; +6 Ответить
4. Vladimir Litvinenko 14.01.19 16:24 Сейчас в теме
(2) Вполне вероятно, что в задачах внутреннего учета в компаниях ситуация и не изменится никогда. Этот "идеализм" относится больше к программированию на языках общего назначения, а не к разработке в системах для управленческого учета или системах для организации чёрного учета в компаниях. Потому что на этих языках действительно начинают создаваться вещи, от которых зависят жизни, даже в тех случаях, когда об этом не особо задумываются. И кстати приводится живой пример, когда именно на программистов указывали пальцем менеджеры. С программистов больших денег не взять и поэтому отвечать деньгами всё равно будут управленцы. Но лес рубят - щепки летят. Мартин опасается, что программисты попадут под раздачу и отрасль начнет регулироваться очень жестко.

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


Вообще хотел вырезать эту часть выступления при публикации. Очень уж она далека от наших задач при разработке на 1С. Но тогда это был бы не полноценный перевод.


А врачи регулярно за бабло класть хотели на любые клятвы.

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

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

Поэтому всегда будут те, кто оперируют, лечат зубы и ставят диагнозы точно также, как большая часть из нас программирует )) Но мы же постараемся их избегать, верно? ))
fxmike; Ignatov_mu; w.r.; +3 Ответить
5. acanta 60 14.01.19 17:58 Сейчас в теме
(4)
С программистов больших денег не взять и поэтому отвечать деньгами всё равно будут управленцы.

Именно так.
https://news.rambler.ru/articles/37391734-5-russkih-hakerov-arestovannyh-za-rubezhom/
Женщины не готовы рисковать собственной семьей и детьми ради чужих карьер и доходов в отличие от мужчин.
3. JohnGalt 16 14.01.19 16:12 Сейчас в теме
Политики и менеджеры могут обвинить кого угодно. Создателей атомной бомбы, оружия, наркотиков. И исполнители есть разные.Конечно, разрабы Volkswagen должны были бы отказаться выполнять задачу. Я думаю, они скорее всего, отказались бы, если бы знали, что про это скажет их СEO, как их подставит, а а себя попытается снять ответственность. Так очень часто делают "эффективные менеджеры", которые ссылаются на инструкции, противоречащие друг другу. Выполнил - виноват, не выполнил - тоже виноват. Ведь подразумевали другое, а что подразумевают политики или менеджеры это из области экстрасенсов.
6. tsukanov 54 14.01.19 19:18 Сейчас в теме
Структурное программирование - это о том, что не следует делать. Не использовать опасный GoTo.
Функциональное программирование : не используйте присваивание.
Объектно ориентированное программирование : не используйте указатели на функции


Не ожидал такую чепуху тут встретить
pro1c@inbox.ru; Асов; +2 Ответить
7. Vladimir Litvinenko 14.01.19 19:31 Сейчас в теме
(6)
Под нежелательными указателями на функции наверное имеется ввиду их практика применения в языке C. Использование ссылок на функции для эмуляции полиморфизма вместо таблиц виртуальных методов. Передача в качестве параметров методов ссылок на функции, вместо объекта, имплементирующего интерфейс или унаследованного от общего класса. Примерно как в языке 1С используется оператор "Выполнить" и имя метода в качестве параметра других процедур и функций.

Здесь есть еще один доклад, где он подробно подобные веди рассматривает : SOLID Principles of Object Oriented and Agile Design

Про GoTo он прав. В школе еще этому учили, когда говорили о преимуществах процедурного программирования перед линейным и чем они отличаются друг от друга.

По поводу функционального программирования ничего сказать не могу - не знаком с ним. Было бы интересно Ваше мнение на этот счет услышать.
10. tsukanov 54 14.01.19 19:44 Сейчас в теме
(7) Про указатели я знаю только одну беду - арифметика на указателях. Что в них еще плохого без понятия.
В опп языках они (без арифметики) обычно есть.
Ну и ооп вообще в целом о другом. Оно про инкапсуляцию и интерфейсы (ну и ряд других мелочей). Указатели этому никак не противоречат.
Что он хотел этим сказать непонятно, да.

Структурное программирование не про GOTO. Оно по сути про конкретную теорему: https://ru.wikipedia.org/wiki/Теорема_Бёма_—_Якопини
А этой теореме противоречит многое в современных языках. Более того мне известен всего один структурный язык.

ФП - в основном про алгебраические типы, чистые функции и гарантии. Отсутствие присваивания - это следствие, а не суть.
Например на Лиспе можно нарушить принципы ФП обычным замыканием без всякого присваивания.
pro1c@inbox.ru; Vladimir Litvinenko; +2 Ответить
16. Vladimir Litvinenko 14.01.19 20:29 Сейчас в теме
(10) Спасибо за ссылку. Интересно.
8. tsukanov 54 14.01.19 19:31 Сейчас в теме
Половина статьи - неплохой обзор истории (хотя мне непонятно как можно было не упомянуть Шеннона и Фон Неймана)
Вторая половина - самолюбование, вода и булшит.

Я так понимаю структура спича поставлена таким образом типа Мартин поставил себя рядом с великими мужами.
Удивительный чувак.
pro1c@inbox.ru; Dnki; FreeArcher; CyberCerber; +4 Ответить
9. Vladimir Litvinenko 14.01.19 19:37 Сейчас в теме
(8) Возможно это недостаток моего перевода? Посмотрите оригинальное видео, пожалуйста. У меня не создалось такого впечатления. Он просто говорит через призму своего опыта как и каждый из нас.

Хотя может у него есть право и на большее. За ним стоит ставший классикой SOLID и много всего интересного ))
11. tsukanov 54 14.01.19 19:48 Сейчас в теме
(9) В том то и дело что он говорит как каждый из нас ) Таких любителей потрындеть и пописать книги тысячи. Вот он упоминает Дейкстру... Почитайте "Дисциплина программирования". Быстро увидите разницу.
12. Vladimir Litvinenko 14.01.19 19:53 Сейчас в теме
(11) Ваша позиция понятна. Попробую почитать. Но не уверен, что как 1С-ник с небольшим опытом ООП смогу быстро увидеть разницу )) Тысячи Робертов Мартинов - это конечно интересно ))
13. tsukanov 54 14.01.19 20:07 Сейчас в теме
(12) А что сделал Мартин? Вижу как его пиарят, но достижения его мне неизвестны.
Книги пробовал читать. Были интересные мысли, но не более.
Почитайте "Стиль, разработка, эффективность, отладка и испытание программ" 1981 года.
Далеко ушел Мартин от нее?
Артано; +1 Ответить
14. Vladimir Litvinenko 14.01.19 20:16 Сейчас в теме
(13) Тогда уж Дональда Кнута. Все остальные после него - нахлебники и балаболы )) И вообще всё это придумал Черчилль в 18-ом году.
Мне и про SOLID интересно почитать, хотя этот тот же GRASP и ничего нового.
Кстати и в выступлении про это говорится - разработка ПО не поменялась за десятилетия )) Без какого либо притязания на уникальные знания и достижения.

Ох, холивар, холивар.
Артано; +1 Ответить
15. tsukanov 54 14.01.19 20:19 Сейчас в теме
(14) Ну Кнут все же несколько о другом писал. И как бы Мартин с Кнутом тоже разные весовые категории совсем.
17. tsukanov 54 14.01.19 20:30 Сейчас в теме
(14)
Мне и про SOLID интересно почитать, хотя этот тот же GRASP и ничего нового.
Кстати и в выступлении про это говорится - разработка ПО не поменялась за десятилетия )) Без какого либо притязания на уникальные знания и достижения.

Ох, холивар, холивар.


Да нет никакого холивара ) У вас есть свое мнение, у меня свое. Вы высказываетесь, я высказываюсь.
Это же норм? Баланс. Диалог.

Кстати и в выступлении про это говорится - разработка ПО не поменялась за десятилетия )) Без какого либо притязания на уникальные знания и достижения.

Ну пусть будет так )
30. Артано 654 17.01.19 03:48 Сейчас в теме
(13) Мартин - популяризатор поведенческих моделей хороших программистов в дикой природе. Как человек выросший на Дейкстре, Кернигане с Ритчи и Страуструпе, могу подтвердить что Мартин просто обобщил, приправил местами перчиком и изложил в стиле "Как писать хорошие программы. Для чайников", известные уже десятки лет подходы и принципы. Хотя в докладе он сам это упоминает несколько раз. Мол мопед не мой, я просто разместил объяву.

P.S. Буквально вчера как раз говорил с коллегой на эту тему и высказал примерно такую мысль: "мы стоим на плечах титанов, создавших всё чем мы сейчас пользуемся. Но зачастую даже не понимаем как это работает"
34. Dnki 17.02.19 22:22 Сейчас в теме
(8)
Половина статьи - неплохой обзор истории...

Согласен. Почти.
Я старый программист. Не такой, конечно, как автор ("Я родился в 1952"). Но я тоже "работал на 360 Model 30" (наших ЕС ЭВМ). И я счастлив, что эволюция произошла на моих глазах. Стоп! Вот здесь останавливаюсь и пытаюсь понять: а насколько существенна эта эволюция? Что изменилось?
"Не изменились программы". Точно! Эта мысль часто меня просто съедала! Как и пишет автор, произошли Стало
18. kalyaka 493 14.01.19 23:14 Сейчас в теме
Вы не можете прийти к бизнесу и спросить "нормально будет, если мы займемся рефакторингом"? Так вы просто перекладываете на менеджеров риски, которые должны быть нашими. Это мы - те, кто знает, что код должен быть протестирован. Это мы - те, кто знает, что код должен подвергаться рефакторингу. Это мы знаем как делать программное обеспечение. И мы должны нести риски за это.
Понравилась мысль. Действительно, чем "грузить" бизнес правильными практиками, нужно просто закладывать их в работу. Нужно добавить новую фичу? Проведите вначале рефакторинг, а потом добавляйте. Требования бизнеса идут непрекращающимся потоком? Организуйте процесс непрерывной поставки по технологии DevOps и радуйтесь, что рутина автоматизирована и можно просто программировать (и за это еще и платят! :)).
igee12; mivari; Iscarimet; acanta; Vladimir Litvinenko; +5 Ответить
19. neikist 15.01.19 00:49 Сейчас в теме
Спасибо. Редкий случай когда ИС приятно почитать. Хотя у меня впечатление что вторую часть уже где то читал, хотя первую (историческую) совершенно точно нет.
Vladimir Litvinenko; +1 Ответить
20. HAMMER_59 169 15.01.19 08:19 Сейчас в теме
Наконец-то отличная статья инфостарта, реально уже надоели развлекательные статьи от одного автора, а скорее группы авторов подписывающихся одним псевдонимом.

"И да, оно больше про историю и настоящее, чем про будущее"
А зачем изучают историю, сейчас я не программированию пишу, а в целом, столько ресурсов вливают, думаете, что очень хотят узнать что было?
По мне так очень актуальная статья в контексте 1С. Чем была 1С 15 лет назад, две маленькие книжечки по встроенному языку, да и конфигурации даже ПУБ многим сейчас покажутся смешными.
manlak; artbear; Shmell; Yimaida; Vlad33k; Darklight; Cерый; +7 Ответить
21. Darklight 19 15.01.19 09:53 Сейчас в теме
Статья стенограмма выступления интересна своим экскурсом в историю. Вторая часть - одна вода - ни к чему меня не сподвигла!
Тема "Будущее программирования" вообще не раскрыта (но об этом честно предупредил переводчик в преамбуле к тексту - так что к нему без претензий).
Но почитать было интересно! Спасибо за перевод.
22. HAMMER_59 169 15.01.19 12:56 Сейчас в теме
Не моё, но процитирую: "Если прочитал книгу и ничего не понял, ну так, наверно, автор дурак".
Сразу еще вспомнил высказывание одной из сотрудниц, после перехода с Бух77 на Бух 3: "Программу тупенькую поставили"
23. Shmell 253 15.01.19 18:12 Сейчас в теме
24. mvxyz 115 15.01.19 20:18 Сейчас в теме
Спасибо за перевод! Интересное выступление. Прочитал с большим удовольствием.
Vladimir Litvinenko; +1 Ответить
25. kalyaka 493 15.01.19 20:48 Сейчас в теме
Женщины зарекомендовали себя как очень ответственные и дисциплинированные - именно такие качества были востребованы на заре компьютерной эры. Смотрите на фото:
- «Гарвардские вычислители» за работой. Фото ок. 1890 года.
- «Вычислительная комната» Лётно-исследовательского центра им. Армстронга. США, 1949 год.
С приходом мощных компьютеров потребовалось много чего создавать нового и нужно было быть достаточно безответственным и рискованным, чтобы ввязываться в проекты вероятность провала которых была пугающе велика. А тут как раз
молодым парням не хватало дисциплины у них была энергия. Они могли работать сумасшедшее количество часов в день над поставленной задачей. Они были гиперсфокусированы, правда иногда на неправильных вещах ))
- вот этого по мнению Мартина стало не хватать женщинам для успешной работы в ИТ.
26. w.r. 360 16.01.19 12:54 Сейчас в теме
Основной посыл - раньше были и девушки красивее и трава зеленее. Конечно, качество разработки упало по сравнению с 70ми. Но. Лучше я закажу еду с кривого приложения смартфона, чем буду делать заказ по телефону, как в 70х
27. Vladimir Litvinenko 16.01.19 13:40 Сейчас в теме
(26) Есть истории про то как удается совмещать современное железо и технологии разработки : https://infostart.ru/public/979464. Хотя это банки. Им вообще надежность более важна, чем суши-точкам )) Мне кстати совсем не хотелось бы оказаться в том прошлом, которое здесь описано. Проблемы в разработке были куда больше и трава точно не была зеленее.

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

В технологиях точно также. Чувствую, что сам такой же - по верхам прохожусь и верхоглядством ограничиваюсь, а их всё больше становится. И может быть это не изменится ))
29. w.r. 360 16.01.19 14:13 Сейчас в теме
(27) это еще один посыл - железо стало намного производительнее, а разработка не сдвинулась с места. С другой стороны железные технологии тоже не особо сдвинулись с места. Увеличение мощности достигалось в основном уменьшением транзистора и увеличением количества транзисторов на единицу площади. Так что тут по большому счету, мне кажется, примерный паритет между софтом и железом
Vladimir Litvinenko; +1 Ответить
32. o.nikolaev 191 13.02.19 22:23 Сейчас в теме
(27) Ох уж эти банки. И их "надежность". Пересекался в разное время с разработчиками из банков разной степени крупности. И почти каждый раз всплывали истории типа - пожар на складе ракет в Дальневосточном округе, и в рапорте указано: "несколько ракет улетели в неизвестном направлении". Только в данном случае, вместо ракет - нолики в табличках остатков на счетах.
28. sergathome 16.01.19 13:58 Сейчас в теме
Спасибо, прочитал с удовольствием. Согласен только с одним - надо с этим что-то делать. Самоорганизация - буллшит. Реально - отменить ас-из и унифицировать ответственность на законодательном уровне.
31. Vyatcheslav 13 21.01.19 12:01 Сейчас в теме
спасибо, интересный взгляд.

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


- а вот это золотые слова.
33. o.nikolaev 191 13.02.19 22:26 Сейчас в теме
Отличный источник и замечательный перевод. По мне так столь сложная тема как "будущее программирования" "раскрыта" вполне прилично. На большее только Ванга может отважилась бы, да и та косячила часто, чоуш.
35. Dnki 17.02.19 23:45 Сейчас в теме
Не получилось до конца написать, повторю сообщение.
tsukanov писал:
Половина статьи - неплохой обзор истории...

Согласен. Почти. Весь этот исторический экскурс я вижу в подчеркивании следующей мысли: а что изменилось с той поры?
Я старый программист. Не такой, конечно, как Мартин ("Я родился в 1952"). Но я тоже "работал на 360 Model 30" (наших ЕС ЭВМ). И я счастлив, что эволюция произошла на моих глазах. Стоп! Вот здесь я останавливаюсь и пытаюсь понять: а насколько существенна эта эволюция? Что изменилось? Именно в программировании.
"Не изменились программы". Точно! Эта мысль часто меня просто съедала! Как и пишет автор, в N-ой степени изменилась аппаратная часть, на перфокартах стало писать удобнее (раньше для исправления "забытой запятой" оператор перепечатывал всю строку, теперь нажмет "Insert"), сократилась очередь за получением результата с 24 часов до минут. Но сама программа, как была буковками на перфокартах, или на экране, так осталась ими. Автор перечислил много языков высокого уровня (ЯВУ). Вот их появление и было прорывом. До них код заносили прямо в память кнопками на пульте. Потом на языке ассемблера. ЯВУ сделала общение с "электронным мозгом" "почти человеческим". Наверное, ученый мир тогда испытывал эйфорию! Компьютеры скоро заговорят! В фантастике 70-х задавали им вопросы. И!, словами их обучали, т.е. "закладывали" в них программы. Те, в ответ, излагали умные слова, могли даже обидеться. Ученые всерьез обсуждали тему возможного бунта роботов (буду писать "роботов", а не "компьютеров". Так пишется в https://ru.wikipedia.org/wiki/Три_закона_роботехники).
И, что имеем!? Понадобилось более 40 лет, чтобы сказать "Здравствуй, Сири!". И мы все понимаем, что это просто "ввод-вывод", а никак не обучение робота.

Мои выводы таковы:
* Со времен рождения слова "кибернетика" буковки стали красивее, но не сильно понятней. И т.к. современные компьютеры их вмещают много, читаемость программ катастрофически падает квадратично их размеру и количеству процедур (и уродливому стилю "процедура ради процедуры", бо так требует "структурный подход"). Кто не согласен - полистайте "1С УПП".
* Клиент-серверное программирование добило основную парадигму ЯВУ - программист думает об обработке данных, а не аппаратуре по их хранению и передаче.
* Будущему поколению еще только предстоит создать принципиально новые средства программирования. Точнее их форму. Мне представляется, они будут визуальными, объемными (долой перфокарты!). Программы будут вносить в ЭВМ не кнопочками, это точно!

P.S.
А вот вторую часть статьи и я не понял.Точнее, перскока с языков на управленческие методы. Вроде: "вся молодежь-балбесы. Да еще и мальчуганы. Вот их и нужно организовывать".
tsukanov; A_Max; igee12; +3 Ответить
37. pro1c@inbox.ru 174 28.02.19 13:29 Сейчас в теме
Очень много воды и плач Ярославны.
38. ILM 236 03.03.19 16:37 Сейчас в теме
В последнее время меня не покидает мысль, что программирование является самым "разрушительным" изобретением человечества. Мы просто до конца не осознаем к чему приводят результаты нашего труда. Легкость получения цифр позволяет "эффективным" менеджерам забыть о людях и процессах, а видеть только результаты, но не в глубь явлений, систем и причин.
Оставьте свое сообщение