Программирование превращается в помойку.Я в этом твёрдо уверен. Мы стоим на краю пропасти, а возможно — и вовсе, уже спрыгнули. Думаете ли вы также? Чувствуете ли это?.. В любом случае, я должен объясниться. Дело в том, что программирование становиться грязным. Грязным в том смысле, что противоположен смыслу элегантности. Запутанные, и в то же время пустые в сути — вот каковы программы нашего века.
Попытки радикальной унификации пришли на смену аналогичным попыткам радикальной спецификации, столь популярным в прошлом веке. Видимо, напуганные хакерской изощрённостью, мы теперь не замечаем изощрённой глупости наших собственных программ. И если у хакеров было оправдание — они писали «эфективный» код, то у нас — оправдания нет. Все наши потуги нацелены на избавление от сложности, но, что иронично, они лишь делают всё сложней, добавляя всё новые и новые «универсальные» решения.
Некоторые скажут, что эта запутанность присуща лишь частным случаям, и не является фундаментальной проблемой программирования. Глупость такой позиции очевидна: если бы это было так, то эти «частные случаи» не наблюдались бы постоянно. Более того, центральная проблема программирования — «Как во всём этом не запутаться?».
Есть много ответов, от «программирование — крайне сложная задача сама по себе», до «большие программы требуют взаимодействия программистов, а это трудно», однако, в большинстве своём — они уже хорошо известны. Я опишу более редкий взгляд, особо характерный для нашего времени: виновата прибыль, замечу, не малая, которую приносит программирование. Она приводит к вовлечённости в программирование самого разного рода «непрограммистов». Все эти бедные люди, по определению никогда не интересовавшиеся программированием, зачастую вынужденны принимать существенные решения в нашей области. Теперь очевидна и проблема, и путь её решения: будьте отзывчивей, помогайте «непрограммистам» принимать верные решения. Однако, и тут можно ошибиться: не пытайтесь объяснить всё — «непрограммистам» необходим лишь системный взгляд.Подводя итог, важно помнить, что ответ на вопрос, достигло ли программирование совершенства или нет, зависит только от нашего мужества и воображения.
Комментарии (182)
Almet
04.01.2018 22:08Все зависит от программиста. «Недопрограммисты» долго не живут. Совершенный код невозможно написать ввиду неоднозначности подхода.
AKVeresov Автор
04.01.2018 22:58В том то и дело, что не всё зависит от программиста. Как я и написал, много «непрограммистов» вовлечено в программирование (не недо-, а именно не-).
И в самом деле, совершенный код многие понимают по-разному, однако, если, например, положить совершенным надёжный и понятный код, который без потери понятности и надёжности приемлемо оптимизирован — думаю (скорее надеюсь), такой код писать можно.
Naglec
04.01.2018 23:28Я дико извиняюсь, что перехожу на личности, но с высоты какого опыта студент размышляет о том, что много «непрограммистов» вовлечено в программирование? И что программирование «превращается в помойку» в целом? Ви таки за чистоту расы?
Графомания какая-то.AKVeresov Автор
04.01.2018 23:30Я работаю. Друзья и родственники, в массе, тоже программисты.
Naglec
04.01.2018 23:36+3А я спросил не насчет работы. Я спросил с высоты какого опыта.
Размышлять в стиле данной статьи может только совершенно зеленый «программист», а этот вот запашок «илитарности» вызывает только жалость к автору.
Программист — это человек, который пишет программы. Для одних задач нужна одна квалификации и одни решения, для других — другая квалификация и другие решения.AKVeresov Автор
05.01.2018 00:02Программист — это человек, который пишет программы. Для одних задач нужна одна квалификации и одни решения, для других — другая квалификация и другие решения.
Согласен, однако программы не должны быть неправильными. Можете списать на юношеский максимализм или идеализированное отношение к жизни.yarric
05.01.2018 11:07Какой критерий "правильности" программы? Если речь идёт об оптимальности, то оптимальности в вакууме не бывает, она всегда по какому-то одному критерию и часто — в ущерб другому: добро пожаловать в инжиниринг.
FadeToBlack
05.01.2018 08:32+1Товарищ, я видел студентов 19-ти лет с квалификацией повыше вашей. Студенты они только по возрасту, не по развитию. Человек нашел проблему, понял ее суть и причину, изложил ее. Важен ли возраст? Я скажу — да! Потому что с возрастом люди не становятся умнее, они лишь приобретают знания, которые позволяют им использовать свой интеллект, который есть у человека с рождения. Некоторые становятся глупее, пытаясь знаниями заменить интеллект. Обычно такие такие люди «знают», что студент не может быть опытным. А впрочем, расскажите, чего добились вы, когда вам было 17?
lair
05.01.2018 11:09… и какова причина проблемы, мне интересно?
EvilGenius18
04.01.2018 22:36«Как во всём этом не запутаться?».
С помощью google и stackoverflow решаются все возникшие проблемы.
А появление множества продвинутых библиотек и framework`ов (например Vue.js и Electron) позволило программистам практически в одиночку создавать комплексные работоспособные приложения, отлаженные тестерами и аккуратно упакованные бандлерами.
Так и не понятно, почему программирование превращается в помойку то?
С каждым годом все инструменты и языки оптимизируются все больше и больше, а новые инструменты (например те, которые уже упомянул выше) дают возможности, о которых в прошлом даже мечтать не приходилосьAKVeresov Автор
04.01.2018 22:52Потому что такой подход только ещё больше путает программистов. Считается нормой не понимать свою программу полностью. Это же ведёт к тому, что ПО сейчас крайне не надёжно. О чём говорить, если многие пользователи заранее ожидают краха системы. Ни в одной другой сфере инженерии такого увидеть нельзя — в других сферах корректность работы гарантируется — например, в архитектуре. Почти никто не ходит по улицам, ожидая, что здания вокруг начнут рушиться. Но много кто ожидает этого от программ.
EvilGenius18
04.01.2018 23:00Но это сравнивать не совсем корректно.
— Архитектурное здание строют 500 специалистов, которые разбираются во всех своих инструментах
— Google тоже строют 500 специалистов, которые разбираются во всех своих инструментах
Ни то ни другое не рушится. И то и другое безопасно.
А если вы имели ввиду небольшие программы, построенные 1-5 новичками, то и сравнивать это нужно не с архитектурным проектом, разве не так?AKVeresov Автор
04.01.2018 23:02Наиболее это заметно в ОС (вспомните шутки про Windows, например). На самом деле, у Google тоже ошибки совсем не редкость, просто их влияние не столь заметно — перезагрузил страницу — и готово.
EvilGenius18
04.01.2018 23:05Возможных переменных в функционировании ОС в сотни раз больше, чем в каком-либо небольшом инженерном проекте.
ОС настолько сложна в построении и функционировании, что ее корректно будет сравнивать только с инженерными проектами вроде ИТЕР или адронного коллайдера, если вы хотите сделать ее настолько же надежнойAKVeresov Автор
04.01.2018 23:11Речь ведь не о сравнении программирования и архитектуры. Я и сам думаю, что программирование сложней, но речь не об этом, а о том, что наличие ошибок недопустимо. Можно сказать, что при постройке здания на кону жизни людей, а в программировании — нет, но все мы знаем истории про «серийных программистов» и «ошибки на миллионы».
lair
04.01.2018 23:16наличие ошибок недопустимо
Эээ… нет? Почему?
AKVeresov Автор
04.01.2018 23:19Упрощённо:
«Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ? 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека.
Как тебе спится, Джон — серийный программист?»
из "Плохой код убивает".lair
04.01.2018 23:23Демагогия же. Давайте заодно запретим опаздывающие поезда, светофоры и так далее.
Просто представьте, что с плохим программистом Джоном пользователь тратит пятнадцать минут на обход проблемы и еще 45 минут на работу. Час. Для выполнения задачи, которая без программы делается четыре.
Вы все еще считаете Джона убийцей?
AKVeresov Автор
04.01.2018 23:25Да, ведь он мог потратить ещё, скажем, месяц, и не допустить этой ошибки. Это схоже с концепцией «вежливой математики», суть которой в том, что если вы можете потратить час, сэкономив минуту хотя бы шестидесяти своим читателям — вы должны это сделать.
lair
04.01.2018 23:28Да, ведь он мог потратить ещё, скажем, месяц, и не допустить этой ошибки.
Или год. Или пять. Никогда же не знаешь.
И сколько, бишь, времени будет потеряно пользователями за это ожидание?
AKVeresov Автор
04.01.2018 23:32Дело в том, что это время известно. Программы (не все) можно доказать.
lair
04.01.2018 23:34Дело в том, что это время известно.
Далеко не всегда. Я вот регулярно чиню баги, уходящие корнями в непредсказуемое легаси.
Программы (не все) можно доказать.
Насколько больше времени уходит на разработку полностью доказуемой программы?
AKVeresov Автор
04.01.2018 23:39Прошу прошения, я писал о времени доказательства.
Не намного, особенно если повторно использовать доказательства (т.е. уже доказанные программы). Почитайте «Дисциплину программирования» Дейкстры. Ещё можно по верификации почитать, например Ю.Г.Карпова «Model checking: верификация параллельных и распределённых программных систем». Ещё «Параллельные взаимодействующие процессы» Хоара.lair
04.01.2018 23:40Прошу прошения, я писал о времени доказательства.
Поясните?
Не намного, особенно если повторно использовать доказательства (т.е. уже доказанные программы).
В моей области разработки нет уже доказанных программ. Вернемся к вопросу: так насколько больше времени уходит на разработку полностью доказуемой программы?
Naglec
04.01.2018 23:44+1«доказанный»/«верифицированный» .NET — это было бы сильно…
lair
04.01.2018 23:47Ну да. Вообще, если взять современные мейнстримные языки с виртуальной машиной или интерпретатором — там хотя бы один "доказанный" будет?
AKVeresov Автор
05.01.2018 00:00Языки сами по себе нельзя доказать — они — постановка задачи. Доказать можно соответствие их семантики тем действиям, что производят программы, написанные на них, при запуске с помощью транслятора и машины, т.е. корректность транслятора и машины.
lair
05.01.2018 00:03Я же специально сказал: с виртуальной машиной и/или интерпретатором. Иными словами, меня волнует "доказанность" среды выполнения.
Или вот возьмите все три (уже две) мейнстримных ОС для телефонов. Хотя бы одна из них гарантированно корректна?
AKVeresov Автор
04.01.2018 23:57-1Доказательства не похожи на дебаг, в них всё под контролем, а значит выполняется по плану (хотя про предопределённость времени доказательства я замахнулся). А сколько у вас займёт разработка всех тех программ, что вы используете в программе включая библиотеки? Если предположить, что они уже доказаны (иначе мы не можем их считать верными), то на доказательство прикладной программы лишь чуть больше времени. Дело в том, что вы ведь и так предполагаете правильность программ, которые используете при разработке — вы смотрите в документации описания работы тех или иных функций. При доказательстве надо будет делать тоже самое, но более формально, не допуская недопонимания. Время разработки измениться несущественно, как я думаю. Наверное на несколько процентов, ведь мы и так, по сути, продумываем нашу программу в доказательном ключе. Мало кто просто пишет кусок кода — «авось заработает».
lair
05.01.2018 00:02Если предположить, что они уже доказаны (иначе мы не можем их считать верными)
Это уже неверное предположение. Мы считаем их достаточно надежными, но они не доказаны. И в них регулярно находятся ошибки.
Дело в том, что вы ведь и так предполагаете правильность программ
Да, предполагаю. Но это не значит, что они гарантированно правильные.
Время разработки измениться несущественно, как я думаю.
Программист, который писал программу, в которой есть ошибки, тоже думал, что в ней нет ошибок.
AKVeresov Автор
05.01.2018 00:10Ну, раз они лишь «достаточно надёжны», напишите их сами. Тоже самое вынужден буду делать я, потребуйте вы доказать их. Ваше предположение о правильности схоже с моим предположением о доказательстве. Если учитывать построение доказательств всего существующего в программировании, то и сравнивать его надо с написанием всего, а не только конкретной задачи.
lair
05.01.2018 00:17Ну, раз они лишь «достаточно надёжны», напишите их сами.
… и сколько времени у меня на это уйдет?
Nick_mentat
05.01.2018 11:22-2Поддерживаю требование писать самому всё что не устраивает. Если бы люди получали на вход данные с гарантией правильности, то не нужна была бы тонна проверок. Простейшие обращения без проверок занимают в 100 раз меньше времени. Если бы все программисты писали идеальный код в расчёте на идеальные данные — полагая что правильность всех используемых инструментов доказана математически, то они бы писали более быстрые и простые для понимания библиотеки, которые будут Доказаны. На их базе — быстрые фреймворки и так далее. Я Доказанную нейросетку, написанную с нуля, могу на ноутбуке 9летней давности запустить с той же скоростью как на современном кластере какой-нибудь супермодный навороченный фреймворк. Все эти программисты которые плодят и распространяют свой перегруженный код — они в итоге крадут моё вычислительное время, ведь я мог бы сэкономить дни и даже месяцы!
Но к сожалению, для доказанного программирования желательно всем людям в мире перейти на одну платформу. А всем программистам — писать на одном языке. Но к сожалению, ни второе, ни тем более первое уже недостижимые вещи. Так что приходится выкручиваться с тем, что имеем — недоказанные ненадёжные алгоритмы, которые лежат в основе недоказанных и ненадёжных программ. По хорошему, под каждым сколько-нибудь большим проектом должно стоять как минимум #YMMV
И пока единственный способ борьбы — не используя библиотеки писать код с нуля. Что очень пейнфул. Но надо.michael_vostrikov
05.01.2018 12:11Если бы люди получали на вход данные с гарантией правильности, то не нужна была бы тонна проверок.
Как без проверок гарантировать правильность?
staticlab
05.01.2018 12:16Поддерживаю требование писать самому всё что не устраивает.
И за чей счёт будет этот банкет?
Если бы люди получали на вход данные с гарантией правильности, то не нужна была бы тонна проверок.
Да, но правильность внешних данных гарантировать нельзя. В формочке на сайте магазина нужно проверить, что клиент не забыл указать свой адрес, а браузер не может быть уверен, что ему вместо CSS не придёт злохакерская строка, которая вызовет переполнение буфера.
По хорошему, под каждым сколько-нибудь большим проектом должно стоять как минимум #YMMV
В лицензионном соглашении так и написано: "Работа программы не гарантируется. Пользуйтесь на свой страх и риск."
И пока единственный способ борьбы — не используя библиотеки писать код с нуля. Что очень пейнфул. Но надо.
И где гарантия, что ваш код, который вы будете писать год или больше, будет работать лучше библиотечного?
Nick_mentat
05.01.2018 14:40-1Как без проверок гарантировать правильность?
Цельной архитектурой.
Да, но правильность внешних данных гарантировать нельзя.
Я согласен, что всё что приходит от пользователя — это небезопасно и неизвестно. Однако в программах большая часть данных течёт через интерфейсы и входы методов, куда данные должен положить программист, а не пользователь. И он как раз должен проследить чтобы эти данные во всех многочисленных внутренних связях передавались идеально. В конце концов, даже самые базовые обращения к физической памяти, которые в идеале должна ОС разруливать, всё равно идёт через тонну лишних (никогда не срабатывающих на хорошем коде) проверок.
И где гарантия, что ваш код, который вы будете писать год или больше, будет работать лучше библиотечного?
Априори гарантией служит только уверенность программиста в своих силах. А уже потом можно сравнить и убедиться, что создатели модных библиотек тоже иногда говнокодят.michael_vostrikov
05.01.2018 14:52Цельной архитектурой
Допустим, я отправляю запрос на удаление вашего аккаунта с некоторого сайта. Опишите архитектуру без проверок, которая не позволит мне это сделать.
mikaakim
05.01.2018 10:20Мало кто просто пишет кусок кода — «авось заработает».
Ой, таких много)))) К сожалению…
RPG18
05.01.2018 01:45Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения.
Дейкстра.
staticlab
05.01.2018 10:51+1Скажите, пожалуйста, сколько программ в написали за свою жизнь и сколько из них вы формально доказали?
Harrix
05.01.2018 11:26Под доказательством программы вы что понимаете? Математическое обоснование, что программа найдет правильное решение?
Harrix
05.01.2018 21:05Кстати, автор так нигде (или я пропустил) не написал методику доказательства правильности программы. Например, я могу понять что такое математическое доказательство работоспособности (правильности) алгоритма. Но как доказать правильность программы, которая пишется по данному алгоритму (я имею ввиду точное доказательство, а не приблизительное). Есть алгоритм быстрой сортировки. Как доказать, что в коде программы, которая реализует быструю сортировку, нет ошибок?
Naglec
05.01.2018 21:10В коде может и не быть, а вот в компиляторе, ОС, драйверах, железе — сколько угодно.
Harrix
05.01.2018 21:19Как хотя бы в коде доказать это? У нас на кафедре в универе ходила такая полушутка: «В любой программе всегда четное количество ошибок».
Naglec
05.01.2018 21:24Harrix
05.01.2018 21:27К сожалению, это всё портит: «Доказательство может быть автоматизировано полностью лишь для очень небольшого круга простых теорий, поэтому важное значение получает его автоматическая проверка и для этого преобразование к проверяемому виду.
Для поддержания строгости при проверке доказательства верификатором следует проверить ещё и верификатор, для чего нужен ещё один верификатор и так далее. Получившуюся бесконечную цепь верификаторов можно было бы свернуть, построив верифицирующий себя верификатор, обладающий способностью развернуться до применимого на практике.»Naglec
05.01.2018 21:30Ну, это к автору.
В догонку можно про суперкомпиляцию почитать. Но, по мне так, это попытка переложить оптимизацию за счет рассмотрения частных случаев входных параметров на компилятор вместо программиста. Не взлетело, в общем.
0xd34df00d
05.01.2018 22:01Формулируете требования к алгоритму, выражаете их, тайпчекер или отдельный прувер убеждается, что требования выражаются.
Harrix
05.01.2018 22:04Тогда тестирование подойдет под ваше определение доказательства. Сформулировали требования к алгоритму, чтобы он проходил тесты. Прувер проверяет тесты. Отсуюда получается, что софта, который доказан, очень много. Но по мнению противоположной стороны доказанного софта почти нет.
0xd34df00d
06.01.2018 22:16Ну да, для этого софта доказано, что он проходит данные конкретные тесты. Обычно имеется в виду всё-таки не совсем это.
0xd34df00d
05.01.2018 20:05+1А мог бы потратить ещё месяц и написать другую программу, которая будет экономить три часа в другой задаче.
Закон убывающей полезности, все дела.
vikarti
05.01.2018 07:49Не рушится? У Google там много всего
Простой пример из того что недавно с Google Play Books было. В веб-версии внезапно перестал работать поиск в купленных книгах. Смотрю через Dev Tools — запросы (во всех браузерах сразу) почему то начинают улетать на домен в .ru вместо .com и соответственно ошибка. Почему — не понятно. Пишу в поддержку (по Play Books она таки отвечает) — советы из серии перезагрузите компьютер. Через несколько дней заработало. Почему? Отчего? не ясно.
Тот же Play Books но уже загруженные руками epub'ы — изредка сайт просто говорит что ошибка обработки и все. При этом ВСЕ другие приложения которые умеют читать epub — успешно читают этот файл. Это ошибка Google или нет? (А если учесть что валидатор все же дает ошибки на этот epub?).
А фокусы из серии — если вы открывали (на любом устройстве включая веб-версию) купленную книгу то она перемещается в начало списка книг везде в Play Books а если загруженную — то перемещается в начало списка только в мобильных приложения но НЕ в веб-версии. Это баг или так намеренно сделано? С точки зрения пользователя — выглядит багом, в справке про эту особенность — ни слова.
lair
04.01.2018 23:08Вы готовы ждать новых программ столько же, сколько ждут новых зданий?
AKVeresov Автор
04.01.2018 23:11Да, если они будут абсолютно корректно работать.
lair
04.01.2018 23:16+1(… здания, знаете ли, тоже не "абсолютно корректны": я вот смотрю на свою комнату, в которой нет ни одного прямого угла, и сильно печалюсь)
Окей, ждите ваших корректно работающих программ. Ваше право. А я — не хочу. И те люди, которые ожидают от программ падений, понимают, что они получают взамен.
wsf
05.01.2018 02:31Простите, а на вмк мгу теорию алгоритмов преподают? После курса ТА обычно такой максимализм отшибает :)
Nick_mentat
05.01.2018 11:32-2Абсолютно корректные программы не выгодны бизнесу — их потом не надо поддерживать, и программист становится ненужным. У меня есть теория что именно поэтому все идеальные программы больше не разрабатывают. Под хр их ещё много было — они выпускались на дисках, издатель следил за тем чтобы программа удовлетворяла базовым требованиям надёжности. Но теперь в век интернета — все просто льют фигню, которая вообще может ОС тебе снести при абсолютно точно воспроизведённом мануале. А старые, идеальные программы, никто не переписывает под новые ОС и новый стандарт html. Более того, сейчас некоторые классные штуки вообще не найти нигде, даже файлов установщиков на те, соответствующие времени системы. Корпорации давят. У них численное преимущество(
lair
05.01.2018 11:38+1Абсолютно корректные программы не выгодны бизнесу — их потом не надо поддерживать, и программист становится ненужным.
Неа. Даже абсолютно корректную программу надо развивать, поэтому программист нужен. При этом отсутствие необходимости в поддержке — это гигантский маркетинговый аргумент. Так что нет.
Nick_mentat
05.01.2018 16:34-2Ага. Точно так же как и оригинальные звёздные войны нуждаются в перемонтаже каждые 5-6 лет, с добавлением блэкджека и CGI пацюков. Иначе ведь, никто смотреть не будет. Маркетинг…
lair
05.01.2018 16:37Ага. Точно так же как и оригинальные звёздные войны нуждаются в перемонтаже каждые 5-6 лет,
Нет, не точно так же. Вы действительно считаете, что можно сделать LOB-систему, которая не будет нуждаться в развитии?
vdshat
05.01.2018 19:21Контрпример из жизни, у заказчика народ на поддержке тратит уйму времени на тривиальные операции, которые можно и нужно автоматизировать. Спрашиваем: че за?! Ответ простой: если это автоматизировать, то нужен будет один человек вместо отдела, а я как начальник отдела буду избыточной единицей — зачем мне терять деньги? Приводим ему кучу аргументов как можно развить бизнес и не потерять деньги. Ответ ожидаемый: все это действительно здорово, но зачем, если и так можно зарабытывать. Идем дальше к его начальнику и мягко обрисовываем картину и перспективы. Он: круто, если зам посчитает нужным, то мы внедрим. А заму и так хорошо. Не всегда руководство готово на смену стратегии да и тактики, пока человек сам не созреет его трудно в чем-то переубедить даже с маркетинговыми аргументами, а если у него есть личная заинтересованность, то — невозможно.
В одной австрийской фирме по укладке спец покрытий на ангары была таблица личной заинтересованности руководства клиентов в процентах от стоимости проекта железный аргумент к заключению контрактаlair
05.01.2018 19:25Если людям не нужна автоматизация, то им не нужна автоматизация. Ничего не поделаешь.
Только это контрпример к "давайте писать ПО лучше", потому что ПО "лучше" им тоже не нужно.
staticlab
05.01.2018 12:34+1Кстати, почему вы пишете свои комментарии на сайте, правильность работы которого не доказана, из браузера, правильность работы которого не доказана, в операционной системе, правильность работы которой не доказана, запущенной на процессоре, правильность работы которого не доказана? Вам следовало бы подождать, когда сделают формально корректный программно-аппаратный комплекс, не так ли?
FadeToBlack
05.01.2018 08:39Перефразирую: А вы готовы ждать новых зданий столько, сколько ждут сейчас новых программ? Здания строят за месяцы (даже огромные небоскребы), но на большие программы уходят десятилетия.
lair
05.01.2018 11:07Здания строят за месяцы (даже огромные небоскребы)
Хмм… La Sagrada Familia, постройка начата в 1882, не закончена до сих пор. Центр Помпиду, постройка начата в апреле 1972, открылся в феврале 1977. The Shard, постройка начата в мае 2009, закончена в ноябре 2012. Это только wall-clock-time, информации о человекогодах найти не удалось. И это без учета времени собственно проектирования (для Бобура добавьте еще два года, для The Shard — лет пять).
(Нет, я в курсе про Mini Sky City, но это же префаб)
но на большие программы уходят десятилетия.
А можно пример такой современной мейнстримной программы?
FadeToBlack
05.01.2018 11:30-1Мейнстрим? Т.е. я говорю о небоскребах, а вы хотите, чтобы я вам рассказал про дачный домик, который два узбека за неделю возвели?
> начата в 1882
> феврале 1977
т.е. вы считате, что крайние случаи из позапрошлого века можно считать аргументами, а здание из префабов (читай на фреймворках) не очень-то и аргумент?
lair
05.01.2018 11:37Т.е. я говорю о небоскребах, а вы хотите, чтобы я вам рассказал про дачный домик, который два узбека за неделю возвели?
Сейчас небоскребы — это мейнстрим.
т.е. вы считате, что крайние случаи из позапрошлого века можно считать аргументами
Они не "крайние" (ну, кроме Sagrada Familia, но она там и правда чтобы посмеяться), они вполне реалистичные. Что важно — они все по индивидуальному проекту, как и большая часть современной бизнес-разработки.
а здание из префабов (читай на фреймворках) не очень-то и аргумент?
Да нет, просто когда вы берете здание из префабов, то сравнивать его надо с проектом на фреймворках. За те человекочасы, которые были потрачены на это здание, на фреймворках пишется настолько же типовой работающий проект.
Nick_mentat
05.01.2018 11:43410 дней ушло на постройку емпайр-стейт билдинг. И это с использованием технологий более чем 80-летней давности.
По современным меркам, единожды созданная программа потом допиливается командой до конца жизни проекта. Т.е. если взять программы из тех что до сих пор используются, написанные в 2016, 2010, 2000 и в 1989 — то все они «поддерживаются» — целая толпа программистов, в несколько раз большая чем команда первых создателей сидят и исправляют постоянно возникающие косяки, лишь изредка дописывая новый функционал. Т.е. по сути все эти программы до сих пор разрабатываются, и в среде программистов это почему-то считается нормой — требовать деньги за 80% работы, которые навсегда остаются 80%, сколько бы они над ней не работали. Хотя и попадаются приятные исключения, когда человек несёт ответственность за свою продукцию, так что готов выпустить её на дисках и гарантировать что диск состарится раньше, чем программа на нём даст сбой.lair
05.01.2018 11:51410 дней ушло на постройку емпайр-стейт билдинг. И это с использованием технологий более чем 80-летней давности.
Спасибо, кэп. Время планирования учли? В человекочасы перевели?
в среде программистов это почему-то считается нормой — требовать деньги за 80% работы, которые навсегда остаются 80%, сколько бы они над ней не работали
… в среде заказчиков считается нормой требовать программу за 80% срока при наличии 50% требований. При чем эти 50% всегда остаются 50%.
Паритет.
Программы с фиксированными требованиями разрабатываются за фиксированное время.
lair
05.01.2018 11:53Я за весь свой опыт работы программистом никогда не работал на проекте, который был бы в режиме "только багфикс". Всегда, всегда добавлялись новые фичи (иногда требующие радикального изменения ядра).
wing_pin
05.01.2018 14:12+2А вы знаете сколько тратится человекочасов на поддержку емпайр-стейт билдинг в хорошем состоянии ежедневно?
RPG18
05.01.2018 00:57корректность работы гарантируется — например, в архитектуре.
Нет. Могу привести список всяких торговых центров, аквапарков которые упали.
Считается нормой не понимать свою программу полностью. Это же ведёт к тому, что ПО сейчас крайне не надёжно.
Это произошло не вчера и не год назад. The Mythical Man-Month: Essays on Software Engineering выпущена в 1975; The Art of Software Testing в 1979. Мы с вами еще не родились, а программирование уже стало превращаться в помойку.
Если же говорим о качестве ПО, то в code complete(1993) все описано. Качественное ПО это дорого и долго. А теперь спросите вашего заказчика, готов ли он дать столько времени и денег.
sshikov
05.01.2018 09:23Мы с вами еще не родились, а программирование уже стало превращаться в помойку.
Вот только не надо обобщать! :) Лично я в 1978 уже зарабатывал деньги программированием. И могу совершенно спокойно и на основании своего опыта заявить, что байки про превращение программирования в помойку — чушь собачья. Буквально на пальцах, что было и чего не было в 70-х:
- во-первых, машины конечно стали неизмеримо мощнее. На М-222 у меня компилятор Алгол-60 не мог скомпилировать программу из примерно 300 строк, пришлось разбивать на модули, выводить результат на перфокарты, которые не читались, потому что сбоила читалка…
- В 1980 написал первую программу, которая была внедрена на куче предприятий, порядка 4000 строк ассемблера S/360. Ушло пара месяцев. Сегодня я такое в принципе способен написать за пару дней.
- системы версионирования де-факто не существовали. Никто почти не думал о том, что код нужно развивать. Появились в жизни лет на 10 позже.
- работа командой над кодом большого проекта была уделом таких, как Брукс. Сегодня скажем сотня человек на проекте — это далеко не предел, и это совсем не ОС.
На самом деле, тут можно было бы долго перечислять то хорошее, что с тех пор произошло, но думаю не стоит. Суть тут простая — за это время произошли изменения, которые позволяют в итоге создавать проекты, которые 40 лет назад были невозможны вообще. Просто тогда программисты "от сохи", как выражались мои коллеги — это были инженеры, а сегодня это кто угодно. Просто не надо мешать это в одну кучу.
А теперь спросите вашего заказчика, готов ли он дать столько времени и денег.
А вот это — чистая правда. Качество как правило такое, какое устраивает заказчика, и за какое он готов заплатить. Высокое качество — достижимо. А условный фейсбук с его отстойным мобильным приложением, полным багов — последствие того, что никого не накажут за баги в нем.
redfs
06.01.2018 23:12The Mythical Man-Month: Essays on Software Engineering выпущена в 1975; The Art of Software Testing в 1979… Если же говорим о качестве ПО, то в code complete(1993) все описано.
Хочу добавить к вашему списку Program Style, Design, Efficiency, Debugging, and Testing (Dennie Van Tassel, 1978). В переводе на русский было два издания 1981 и 1985.
Кстати, я почти уверен, что автор статьи эту книгу не читал. Для интересующихся нашёл цитатник из неё, для быстрого ознакомления.
redfs
04.01.2018 23:08С помощью google и stackoverflow решаются все возникшие проблемы
Все чаще мне встречаются программисты, решающие все возникающие проблемы с помощью google и stackoverflow. Утешает только одно — в google и stackoverflow решения этих проблем не сами по себе появляются.
revinsys
05.01.2018 01:00Как по мне, то сейчас больше беда в опытности программиста, а не наборе технологий, «унификаций» и как там было еще? Из-за увеличения мощности девайсов, кто то совсем забывает про оптимизацию своих приложений (чаще это новички и Junior'ы) в следствии если я не обладатель топового железа, данное приложение может повесить мне девайс и/или просто не запустится (сам не раз писал такой «удачный код»))).
Программирование развивается а с ним и инструменты позволяющие продуктивнее и качественнее писать код.
Вспомнить про JavaScript, когда подключали тонну скриптов друг за другом что-бы они заводились правильно, когда сейчас можно использовать какой нибудь gulp/webpack/etc. При этом ни кто вам не мешает написать чистый JS код без фреймворков и сборщиков. А как изменился web с появлением webkit, google-v8? а как изменится с появлением WebAssembler? и это только веб.
Грязным в том смысле, что противоположен смыслу элегантности. Запутанные, и в то же время пустые в сути — вот каковы программы нашего века.
Для моей бабушки кнопочный телефон запутанный и пустой по сути, а дочка с сенсорным справляется на ура и она совсем не понимает как может быть телефон с «диском»?
Таковы реалии нашего века)Naglec
05.01.2018 01:08Никто не забывает про оптимизацию. Просто заказчик не готов за нее платить.
FadeToBlack
05.01.2018 08:55-1Просто не нужно оптимизировать то, что не тормозит. Никогда не видел программиста (даже в зеркале), который заранее на 100% будет уверен в том, что будет тормозить, а что нет. Если сайт работает, клиенты довольны — там нечего оптимизировать.
Jef239
06.01.2018 06:39Для кнопочного телефона — надо уметь читать или наизусть запоминать сложные последовательности. Для сенсорного, как выяснилось на опыте, умение читать не нужно.
К сожалению, нету третьего варианта — телефона с большим цветным экраном и кнопками. Но, похоже, тут 50 на 50 — и большой экран понятней и нажимать на него проще, чем понять многофункциональные кнопки.
Error1024
05.01.2018 02:28Я согласен с автором в части того что программирование действительно стало помойкой, бесконечные фреймворки, лишние абстракции — ради абстракций, необъятность архитектуры, и т.д.
Черт, вчерашние уязвимости процессоров — из этой серии, цпу стали настолько сложными, что нахождение очередной такой уязвимости — дело времени.FadeToBlack
05.01.2018 08:51Все сферы жизни человека содержат эту фундаментальную проблему — проблему помойки. Посмотрите на товары народного потребления, которые продают в магазинах: у вас лишь иллюзия выбора. В магазине у вас всегда есть выбор из 10 открывалок для консервных банок, из которых работает только одна, но для того, чтобы выяснить это вам, поверьте, быстрее и выгоднее (для психики) купить их все. Это обойдется вам примерно в 1000 раз дешевле, чем попробовать 10 различных фреймворков и выбрать лучший.
P.S. Открывалки (и другие товары) из IKEA почти всегда работают.lair
05.01.2018 11:11Посмотрите на товары народного потребления, которые продают в магазинах: у вас лишь иллюзия выбора
Эээ… серьезно? В какие-то грустные магазины вы ходите.
FadeToBlack
05.01.2018 11:16Я хожу в разные магазины, везде картина одна и та же. Может быть расскажите, в какие магазины ходить, чтобы избавиться от этого? Может быть расскажете, где покупать качественную технику за приемлемую цену, чтобы она не ломалась через месяц? Расскажите, как вы решаете эту проблему.
lair
05.01.2018 11:25+1Расскажите, как вы решаете эту проблему.
Внимательным чтением обзоров в интернете.
Вон, в том году купили дешевую немецкую (если не вообще китайскую) вафельницу, прекрасно работает. Понятно, что KitchenAid — лучше, но он и дороже (не неподъемно), и места больше занимает: вот вам и выбор, кстати.
С эспрессо-машинами все еще лучше — даже в одном классе (полуавтоматов) есть три подкласса, суммарный разброс цен раз в шесть, если не десять, причем классы перекрываются по ценам. Купили первую машину два года назад, не подает даже намеков на старение.
Ну и можно продолжать.
FadeToBlack
05.01.2018 11:38-1> Внимательным чтением обзоров в интернете.
Которые только 10 лет назад писались людьми с квалификацией. Сейчас каждый считает себя умным, написаны сотни обзоров, но среди этого хлама отыскать истину практически невозможно.
Хорошо, если у вас есть время, чтобы читать обзоры. Мне давно уже проще купить что-то самое дешевое и понять, что мне нужно от этой техники, не надеясь, что оно долго проработает. Несколько раз критануло, и техника служила долго, а все другие разы заканчивались преосмыслением требований и приобретением действительно подходящей и надежной техники. Я не считаю этот способ оптимальным с точки зрения потребления ресурсов, но современное устройство мира вынуждает меня поступать так. Я бы хотел, чтобы на рынке было не 1000, а 5-10 моделей вещи, которая служит для одинаковой цели, и выбирал уже не исходя из того, сломается вещь или нет, а исходя уже из эстетических соображений.lair
05.01.2018 11:42+1Которые только 10 лет назад писались людьми с квалификацией. Сейчас каждый считает себя умным, написаны сотни обзоров, но среди этого хлама отыскать истину практически невозможно.
Какая нужна квалификация, чтобы написать обзор на вафельницу? А обзоры на эспрессо-машины пишут люди, которые ими пользуются и обслуживают.
Хорошо, если у вас есть время, чтобы читать обзоры. Мне давно уже проще купить что-то самое дешевое и понять, что мне нужно от этой техники, не надеясь, что оно долго проработает.
Ну так это же и есть тот самый выбор: вы выбираете купить дешевое вместо чтения обзоров.
все другие разы заканчивались преосмыслением требований
Переосмысление требований — это тоже ваш выбор, а не проблема техники. И спасибо существующему выбору, что вы можете переосмыслять требования, а не "бери то, что есть".
Я бы хотел, чтобы на рынке было не 1000, а 5-10 моделей вещи, которая служит для одинаковой цели, и выбирал уже не исходя из того, сломается вещь или нет, а исходя уже из эстетических соображений.
… тем самым лишая людей, которым все равно, сломается ли вещь через месяц, возможности выбора. Я не уверен, что они скажут вам спасибо.
FadeToBlack
05.01.2018 12:09-3Какая нужна квалификация, чтобы написать обзор на вафельницу?
Повара-кондитера, как минимум. Хрена с два вы поймете, что ваша вафельница печет неправильные вафли, если делаете это впервые, но под градусом эйфории от того, что у вас что-то получилось, обязательно побежите писать обзор или отзыв. Все так теперь делают.
Однажды в магазине к моей жене подошел мэнэджэр (искажение слова умышленное), который сказал, что вот этот утюг просто отличный, потому что у него там вот-такие-то характеристики. А она спросила — гладил ли он хоть раз свою одежду хоть каким-нибудь утюгом. Так вот. Нихрена он не гладил. И такие же люди пишут эти обзоры.
Ну так это же и есть тот самый выбор: вы выбираете купить дешевое вместо чтения обзоров.
Только у наших внуков, боюсь, такого выбора уже не будет. Мы живем в кредит, который придется отдавать нашим потомкам. Бессмысленная трата ресурсов и энергии — вот девиз наших дней. Такой же тратой является написание этих бесконечных фреймворков, которые делают одно и то же, только содержат разные баги.
тем самым лишая людей, которым все равно, сломается ли вещь через месяц
слишком толсто
lair
05.01.2018 12:17+1Повара-кондитера, как минимум.
Вы это серьезно? Ни один повар-кондитер никогда не подойдет к вафельнице такого класса, ибо ему это низачем не надо. Единственный пользователь этой вафельницы на моей кухне — не повар-кондитер. А Стелла Паркс, автор рецепта, печет на Cuisinart, который дороже почти в четыре раза.
Хрена с два вы поймете, что ваша вафельница печет неправильные вафли
Что такое "неправильные вафли"? Вы понимаете, да, что вафли на выходе из вафельницы зависят много от чего, а не только от вафельницы?
но под градусом эйфории от того, что у вас что-то получилось, обязательно побежите писать обзор или отзыв
Знаете, до сих пор не бежал, и не планирую пока.
Бессмысленная трата ресурсов и энергии — вот девиз наших дней.
Это говорит человек, который покупает вместо чтения обзоров?
слишком толсто
Это жизнь. Вы сначала жалуетесь о том, что выбора нет, а потом предлагаете выбор уменьшить. Спасибо, нет.
FadeToBlack
05.01.2018 12:44-2Вы понимаете, да, что вафли на выходе из вафельницы зависят много от чего, а не только от вафельницы?
А как вы это собираетесь понять, если не исключите хотя бы один пункт неопределенности? Я имею ввиду, как вы поймете, что вафли кривые от кривизны ваших рук, а не от девайса? Именно поэтому повар-кондитер должен подойти хоть раз к такой вафельнице со своими прямыми руками.
Знаете, до сих пор не бежал, и не планирую пока.
точно, мы же тут с вами заняты великим делом
Это говорит человек, который покупает вместо чтения обзоров?
вот видите, какой я плохой. но я понимаю сущность процесса, и понимаю, что мир не изменится от того, что я буду поступать по-другому. потому что этому миру плевать на меня, на себя и на вас. Потому что люди только по отдельности умные, добрые, а в толпе — тупое быдло, которое неспособно принимать мудрых решений.
Это жизнь. Вы сначала жалуетесь о том, что выбора нет, а потом предлагаете выбор уменьшить. Спасибо, нет.Вот именно, что я хочу, чтобы был выбор. Но чтобы был качественный выбор, а не количественный
lair
05.01.2018 12:50Я имею ввиду, как вы поймете, что вафли кривые от кривизны ваших рук, а не от девайса?
Экспериментальным образом и анализом.
Именно поэтому повар-кондитер должен подойти хоть раз к такой вафельнице со своими прямыми руками.
Он не подходил, а обзоры нормальные есть, и вафельница работает как ожидается. Удивительное дело.
вот видите, какой я плохой. но я понимаю сущность процесса, и понимаю, что мир не изменится от того, что я буду поступать по-другому
Занятно. Я вот, напротив, считаю, что если я буду поступать "по-другому", то мир изменится в лучшую сторону. А вот если я не начну поступать "по-другому", то не изменится.
Вот именно, что я хочу, чтобы был выбор. Но чтобы был качественный выбор, а не количественный
Наличие дешевых вещей — тоже качественный выбор.
eGGshke
05.01.2018 04:26виновата прибыль, замечу, не малая, которую приносит программирование. Она приводит к вовлечённости в программирование самого разного рода «непрограммистов». Все эти бедные люди, по определению никогда не интересовавшиеся программированием, зачастую вынужденны принимать существенные решения в нашей области.
Мне вот эта часть жуть как интересна. Можно раскрыть мысль? Я правильно понимаю что любой не богатый человек — по определению не может стать программистом?FadeToBlack
05.01.2018 08:45Мысль простая: за программирование хорошо платят. И поэтому в эту область приходят те люди, которые хотят просто заработать денег. Они делают свою работу не очень хорошо, не задумываются об архитектуре, оптимизации и других вещах. Они производят хлам, который еле-как работает. Но и за это все равно платят, потому что программирование — это сложно и для тех, кто не умеет, и для тех, кто умеет давно и долго.
lair
05.01.2018 11:15Но и за это все равно платят, потому что программирование — это сложно и для тех, кто не умеет, и для тех, кто умеет давно и долго.
Ну то есть вы хотите сказать, что и люди, которые хотят просто заработать денег, и те, которые программируют ради чего-то другого, все равно производят код одинакового качества?
FadeToBlack
05.01.2018 11:18-1Я этого не говорил. Просто те, кто умеет, как правило, выбирают задачи по своим умениям, а значит такой сложности, что скучать не приходится.
lair
05.01.2018 11:26Тогда не понятно, зачем же платят тем, кто пришел просто заработать денег.
Просто те, кто умеет, как правило, выбирают задачи по своим умениям, а значит такой сложности, что скучать не приходится.
Ха!
FadeToBlack
05.01.2018 12:13-2> Тогда не понятно, зачем же платят тем, кто пришел просто заработать денег.
А как вы сможете их отличить? Он же абсолютно так же сидит на стуле, нажимает какие-то кнопки, а на собеседовании расскажет вам о том, как ему нравится работать, узнавать новое, что он каждый день читает книжки по программированию. Это же вы захотите от него услышать?lair
05.01.2018 12:18+1А как вы сможете их отличить?
А мне не надо их отличать, мне нужен результат. Если платят, значит результат устраивает, не так ли?
FadeToBlack
05.01.2018 12:45-3Вот именно, незачем. Поэтому большинство разработанных программ — говно, о чем и хотел сказать автор.
kuftachev
05.01.2018 04:46Не понимаю, чего минусуют автора. Что, никто не напивался на праздники?
FadeToBlack
05.01.2018 08:42Потому что автор абсолютно прав. Никто не любит горькой правды, никто не верит, что кто-то в свои 17 может быть разумным. К тому же… не нужно быть опытным, чтобы понимать эту проблему. Достаточно посмотреть один день, как на самом деле работают программисты.
lair
05.01.2018 11:18+3Потому что автор абсолютно прав.
Эммм.
центральная проблема программирования — «Как во всём этом не запутаться?».
Есть много ответов [...] более редкий взгляд [...]: виновата прибыльSRSLY?
FadeToBlack
05.01.2018 11:24-2Где там противоречие? На мой взгляд, все логично. Гонка за прибылью загоняет программистов так, что не остается времени на обдумывание — быстрее, быстрее, быстрее… И как тут во всем этом не запутаться? Да просто делаем, а потом думаем, а потом будь, что будет. Я не утверждаю, что это плохо. Просто это то, как сейчас выглядит разработка: все делают одно и то же, причем плохо. Изобилие фреймворков, но ни один из них не работает как следует.
lair
05.01.2018 11:28Где там противоречие? На мой взгляд, все логично
"виновата прибыль" не может быть ответом на вопрос "как не запутаться". И даже "помогайте «непрограммистам» принимать верные решения" не может быть ответом на этот вопрос, потому что чтобы помочь кому-то принять верное решение, нужно сначала самому знать верное решение, а для этого уже надо самому не запутаться.
Просто это то, как сейчас выглядит разработка: все делают одно и то же, причем плохо.
Ну, вы за всех бы не говорили, все-таки?
FadeToBlack
05.01.2018 12:21-1Вы очень хорошо умеете закруглять мысли, производя короткое замыкание логики.
Ну, вы за всех бы не говорили, все-таки?
ну а чем вы объясните огромное количество фреймворков?
lair
05.01.2018 12:22+1ну а чем вы объясните огромное количество фреймворков?
Тем, что людей не устраивают существующие, и они думают, что могут написать лучше.
AKVeresov Автор
05.01.2018 12:24И даже «помогайте «непрограммистам» принимать верные решения» не может быть ответом на этот вопрос, потому что чтобы помочь кому-то принять верное решение, нужно сначала самому знать верное решение, а для этого уже надо самому не запутаться.
Про это я и написал, что программирование само по себе сложное, а особенно — при взаимодействии программистов. Просто, на мой взгляд, эти проблемы уже достаточно известны. Дальнейшее рассуждение исходит из того, что с проблемой с этих точек зрения мы справились (хотя это не так сейчас). Однако, я думаю это не единственные проблемы программирования и привёл ещё одну, которая также вносит запутанности. Как я писал, некоторые «непрограммисты» вынужденны принимать существенные решения в нашей области, а значит могут вносить хаос и неразбериху — то есть запутанность.lair
05.01.2018 12:28Как я писал, некоторые «непрограммисты» вынужденны принимать существенные решения в нашей области, а значит могут вносить хаос и неразбериху — то есть запутанность.
Программирование существует для того, чтобы решать задачи… непрограммистов. Поэтому именно они будут принимать решения о том, что должно быть сделано. А дальше в дело вступает хорошо известный конвеер из анализа-дизайна-разработки-тестирования-обслуживания.
И все это настолько же не ново, насколько "проблема взаимодействия программистов". Из того, что лично я читал, это описано уже четырнадцать лет назад у МакКоннела, и я глубоко уверен, что он не первый.
poznawatel
05.01.2018 09:48У программирования был шанс — Unix way
Мне до слез обидно, что он не был использован программистами.Error1024
05.01.2018 12:01+1Простите, но текущий UNIX way — набор костылей, запускаешь утилиту, она делает что-то и отдает результат, преобразуя его в текстовой вид, другая утилита которая должна продолжить работать над данными парсит вывод предидущей, преобразуя обратно в бинарный вид, тратя на это время и нагревая атмосферу…
Да можно и по другому, но в настоящее время оно работает именно так.FadeToBlack
05.01.2018 12:17Никто же не говорит, что внутри программы надо делать так же. Да и не об этом. А о наборе изолированных атомарных библиотек, которые делают ровно одно дело. Кстати, в книжках по программированию пишут обычно KISS, DRY, и прочее. Но философия, к сожалению, не передается через книги.
lair
05.01.2018 12:19+1А о наборе изолированных атомарных библиотек, которые делают ровно одно дело.
Как вы гарантируете, что одно дело (например, чтение файла с диска) делает ровно одна библиотека на рынке? Монополией?
FadeToBlack
05.01.2018 12:29-2Законодательно. Были же в мире такие хорошие вещи, как срок за спекуляцию и тунеядство. Нормально же относились к этому. Потому что это логично и естественно. Так же нормально нужно относиться и к бережливому отношению к природе, а значит к запрету на создание лишних сущностей. Но я опять же не говорю, что это возможно без существования текущего мироустройства. Чтобы понять простоту, нужно пройти путь от простого к сложному и обратно.
Naglec
05.01.2018 12:31+3Кто нормально относился к сроку за спекуляцию и тунеядство?
FadeToBlack
05.01.2018 12:52-2Те, у кого не было с этим проблем.
Разве это нормально, когда одни работают, а другие просто пользуются?lair
05.01.2018 12:53+2Да, это нормально, если это устраивает тех, кто работает. Почему, собственно, кто-то должен мне запрещать, как мне распоряжаться своими доходами?
0xd34df00d
05.01.2018 21:58Предположим, что я год ударно поработал, заработал много денег, и потом пять лет сижу и живу на эти деньги, пописывая стихи, опенсорс или просто почёсывая пузо. Меня надо сажать?
lair
05.01.2018 12:31Законодательно
Не просто монополия, а законодательно закрепленная монополия. Еще лучше. Вы там где-то выше говориле о выборе — так вот, вы понимаете, что его не будет? А будет только одно существующее решение со всеми его недостатками?
Были же в мире такие хорошие вещи, как срок за спекуляцию и тунеядство. Нормально же относились к этому. Потому что это логично и естественно.
Для меня не логично и не естественно. Вот, скажем, в какой-то момент за тунеядство можно было бы привлечь как БОРЗ мою жену. Что в этом нормального?
AKVeresov Автор
05.01.2018 12:39Согласен. Монополия одного «универсального» решения — плохо, как я и писал. Слишком уж сильно некоторые решения различаются с системной точки зрения. Однако, FadeToBlack и не писал об одном решении. Он написал, что не надо порождать лишние, то есть, в моём понимании, пытающиеся реализовать в целом один функционал, и имеющие одинаковую, по сути, структуру.
lair
05.01.2018 12:41Он написал, что не надо порождать лишние, то есть, в моём понимании, пытающиеся реализовать в целом один функционал, и имеющие одинаковую, по сути, структуру.
Вот есть два модуля, написанные разными людьми, оба реализуют HTTP-клиент. Оба работают, набор фич перекрывается на 90%, отличается публичный интерфейс. Какой из них лишний и почему?
FadeToBlack
05.01.2018 12:57Один из них точно лишний. Все равно какой.
lair
05.01.2018 12:58+1Круто, то есть какой-то из потребителей останется без нужных ему 10% функциональности. Откуда ему ее взять?
FadeToBlack
05.01.2018 12:56-2А будет только одно существующее решение со всеми его недостатками?
Да, будет одно нормальное решение, так как тысячи человек вылижут каждую строчку этого решения.
там где-то выше говориле о выборе — так вот, вы понимаете, что его не будет?
А зачем выбор, если вам предлагают идеальное решение?
lair
05.01.2018 12:57+1Да, будет одно нормальное решение, так как тысячи человек вылижут каждую строчку этого решения.
Это если вам удастся договориться, чтобы у этих тысяч человек было одинаковое видение, куда и как лизать.
А зачем выбор, если вам предлагают идеальное решение?
Не бывает идеальных решений. Бывают хорошие компромисы.
Harrix
05.01.2018 19:28Когда вы найдете ответ на вопрос: «Почему на Земле не существует один единственный идеальный вид живых существ, а их превеликое множество», то тогда поймете, почему в программировании не может быть идеального решения, и почему это, наоборот, плохо.
FadeToBlack
05.01.2018 19:53Когда вы поймете, чем выпуск продуктов отличается от эволюции, естественного и искусственного отбора, вы поймете, почему надо что-то менять
Harrix
05.01.2018 20:49Развитие программных продуктов (а также еще много чего, что производит человечество) подчиняется законам эволюции с естественным и искусственным отбором. Не без отличий от эволюции живых организмов, но тут тоже есть своя эволюция со схожими законами. Посмотрите, что такое меметика, которую предложил Ричард Докинз.
0xd34df00d
05.01.2018 21:59Предположим, я только учусь программировать, и я хочу написать ещё одну библиотеку для чтения файлов. Или для парсинга жпегов. Неважно. Меня уже надо сажать?
Предположим, я её выложил на гитхаб. Ну а почему бы и нет, в конце концов? Меня уже надо сажать?
Предположим, я использую эту библиотеку в другом проекте. Меня уже надо сажать?
Предположим, Вася использует эту же библиотеку (понравилась она ему). Его надо сажать?
Когда наказывать-то?staticlab
05.01.2018 22:03Да, разумеется. Должна быть одна библиотека, один фреймворк, один язык, один народ, один рейх, один фюрер...
(сарказм, если что)
symbix
05.01.2018 11:25Автор, скажите, сколько строк отлаженного кода примерно в день вы пишете? Да, одни 10 строк стоят иных 10000, и это плохая метрика, но, тем не менее. Ведь нетривиальные алгоритмы — это 1-2% работы, все остальное — банальности. А ваши рассуждения если и применимы — то для тех самых нетривиальных 1-2%. Хороший программист в хорошей форме пишет порядка 1-2k "банальных" sloc за рабочий день. Сколько времени вы это будете "доказывать"?
FadeToBlack
05.01.2018 12:25-2Если бы человечество занялось проблемой системно, через десяток лет вообще не нужно было бы писать банальности, а каждая строчка программы была бы доказана. Не было бы десятка платформ, процессоров, сотен одинаковых библиотек. Была бы одна операционная система для всего, ну OpenSource. Все к этому и придет когда-нибудь.
lair
05.01.2018 12:29+1Ну то есть все-таки монополия, да?
Давайте вернемся к этому вопросу после того, как на планете будет (а) один стандарт электричества и (б) один стандарт дорожного движения.
FadeToBlack
05.01.2018 12:49-2Ну то есть все-таки монополия, да?
OpenSource
Давайте вернемся к этому вопросу после того, как на планете будет (а) один стандарт электричества и (б) один стандарт дорожного движения.
А давайте улетим, и не будем возвращаться на эту планету?
lair
05.01.2018 12:52OpenSource
Какого типа? Со свободой форка или свободой внесения изменений?
FadeToBlack
05.01.2018 12:59В согласованности со здравым смыслом.
lair
05.01.2018 13:07+1Здравый смысл как раз говорит нам за свободу форка. Но тогда не будет монополии.
AKVeresov Автор
05.01.2018 12:34Вряд ли когда-то будет одна ОС — слишком специфичны бывают их задачи. То же самое и про платформы.
symbix
05.01.2018 13:12Вы про инфраструктурщину, это ерунда, тут и так все реюзают готовый код.
90% программирования — это бизнес-задачи.
AKVeresov Автор
05.01.2018 12:32Производительность программиста измеряется не в строках кода (их мы скорее тратим, чем производим), а в реализуемом функционале.
Мало, раз уж они банальны.lair
05.01.2018 12:36Мало, раз уж они банальны.
А можно конкретные какие-то цифры? Я даже могу ради этого достать какой-нибудь пример кода.
(Заодно бы и посмотрел, как выглядит процесс формального доказательства работоспособности программы)
AKVeresov Автор
05.01.2018 12:43Сам я ещё имею слишком мало опыта, что бы производить доказательства больших программ, могу сказать, что тут, в разделе «Отчёт о состоянии», приведён практический пример идеи доказанной (и крупной) программы.
lair
05.01.2018 12:48Сам я ещё имею слишком мало опыта, что бы производить доказательства больших программ
Тогда на основании чего вы говорите о том, сколько времени вам потребуется?
тут, в разделе «Отчёт о состоянии», приведён практический пример идеи доказанной (и крупной) программы.
Я несколько раз проглядел, но так и не нашел там ни одной конкретной цифры "сколько человекодней на это ушло".
AKVeresov Автор
05.01.2018 13:21На основании своего опыта, а также приобретённого через разговоры, лекции и книги. Также как и все.
Я думаю, конкретные числа не столь важны. Этот пример я привёл как показатель того, что это возможно, причём оправданно. Если говорить о времени — точно не помню время разработки, но оно составило несколько лет.lair
05.01.2018 13:28На основании своего опыта, а также приобретённого через разговоры, лекции и книги.
Подождите, вы же только что сказали, что у вас слишком мало опыта.
Я думаю, конкретные числа не столь важны.
Они как раз очень важны.
Этот пример я привёл как показатель того, что это возможно, причём оправданно.
А как вы делаете вывод, что это оправдано?
AKVeresov Автор
05.01.2018 13:52Подождите, вы же только что сказали, что у вас слишком мало опыта.
Что не исключает его существование.
А как вы делаете вывод, что это оправдано?
Исходя из широкой (пусть локальной и временной) распространённости этой системы, а также того, что идеи, заложенные в ней, присутствуют (более того, активно используются) в наши дни.lair
05.01.2018 14:03Что не исключает его существование.
Вы уж определитесь. Либо у вас достаточно опыта, чтобы оценивать время, необходимое на доказательство конкретного кода (и тогда вы должны мочь производить такое доказательство), либо недостаточно.
Исходя из широкой (пусть локальной и временной) распространённости этой системы,
Не может быть "широкой локальной и временной распространенности".
Ну и да, современные ОС намного более распространены. Значит ли это, что их модель разработки более оправдана?
а также того, что идеи, заложенные в ней, присутствуют (более того, активно используются) в наши дни.
Это значит, что идеи были удачными. Это ничего не говорит об оправданности выбранной модели разработки.
michael_vostrikov
05.01.2018 13:03Вот вам банальная задача.
Есть некий сервис с библиотекой музыкальных треков. У него есть API для поиска по названию, автору, итд. Он предоставляет информацию о темпе трека (beats per minute).
Есть другой сервис тоже с библиотекой треков, но у него нет информации о темпе.
Задача: найти трек из второго сервиса в первом и определить bpm, либо сообщить что трек не найден.
Допустим, программа для некоторых введенных пользователем данных нашла трек и вернула какое-то значение bpm. Как вы докажете правильность ее работы?
Допустим, программа для некоторых введенных пользователем данных не нашла трек и сообщила об этом. Как вы докажете правильность ее работы?
Можете писать любой псевдокод алгоритма поиска и допускать, что вспомогательные компоненты уже доказаны.AKVeresov Автор
05.01.2018 13:46Допустим, программа для некоторых введенных пользователем данных нашла трек и вернула какое-то значение bpm. Как вы докажете правильность ее работы?
Исходя из кода программы. Нельзя доказать программу, проверяя её на частных случаях.
Допустим, программа для некоторых введенных пользователем данных не нашла трек и сообщила об этом. Как вы докажете правильность ее работы?
Опять таки, о чём это?
Вы просите написать программу, реализующую этот функционал?
Тогда, для начала, определим интерфейсы и саму задачу более формально:
Пусть есть функции exist2(user_data) и exist1(user_data), возвращающие true исключительно если во второй и, соответственно, первой системе найдена аудиозапись по заданным данным (предполагая их существование, опираюсь на вашу фразу «У него есть API для поиска по названию, автору, итд.»).
Далее, пусть есть функция bpm1(user_data), возвращающая bpm аудиозаписи найденной по заданным данным.
Тогда наша задача формулируется очевидным образом:
При верных exist2(user_data) и exist1(user_data) вернуть bpm1(user_data),
иначе — вернуть сообщение об ошибке.
Формулировка сама по себе и является решением (это вытекает из семантики условной конструкции и оператора логического И).
То есть:
if (exist2(user_data) && exist1(user_data)) { return bpm1(user_data); } else { /* Возвращаем сообщение об ошибке, например 0 (так как bpm не равен нулю, неоднозначности не возникнет) */ return 0; }michael_vostrikov
05.01.2018 14:06Да не, user_data для exist1 это данные из exist2.
Ок, и как вы докажете, что exist1 нашла именно тот трек, который нужен, а не скажем более быстрый ремикс? И как вы докажете, что если она не нашла, то совершенно точно такого трека в библиотеке нет, например что он не занесен туда с немного другим названием? Ведь если это так, значит программа работает неправильно.
lair
05.01.2018 14:07… я правильно понимаю, что "доказательство" сводится к тому, что "мы тут написали &&, следовательно, будет работать"? И заодно: это доказательство делается и верифицируется исключительно человеком?
(я сейчас серьезно, я пока вообще не понимаю, как работает обещаемое вами "доказательное программирование")
Формулировка сама по себе и является решением
Маленький нюанс: за время, прошедшее между вызовами
existиbpm, песню удалили из системы. Каково будет поведение программы в этом случае?
Sinatr
05.01.2018 13:57+1Программирование превращается в помойку.
Это ваше мнение, которое сложилось под влиянием некоторых факторов в некотором окружении. У каждого, как вы понимаете, будет свое. Делится такого рода мыслями, не вводя читателя в курс — почему — сами видите к чему приводит. А могла бы получится отличная статья (о трудностях обучения в условиях экономического кризиса? о невзгодах на пути начинающего программиста?...) и вас, возможно, даже поддержали бы.
Я в этом твёрдо уверен
достигло ли программирование совершенства
Нет конечно же. Совершенство недостижимо, как и бесконечность. Но вы, как один из программистов, можете способствовать этому. Станьте одним из «великих» и сделайте весомый вклад, в чем проблема?
Я, например, стараюсь писать «красивые» программы, насколько мне позволяют мои опыт, знания и время. Но если времени впритык, то считаю, что быстрое (уродливое) решение с большим техническим долгом является наиболее верным. Тоесть часть моего кода совершенна (для меня тогдашнего), часть — шлак. И это норма.
Есть хорошие программисты, есть плохие. На StackOverflow я и ищу помощи, и помогаю чем могу. Плохой ли я программист? Виновен ли в ваших проблемах? Как понять? В статье почему-то про это ни слова.
Nick_mentat
05.01.2018 17:05-2А не хотите ли принять участие в разработке IT технологий с нуля? Я просто тоже несколько недоволен ситуацией в программировании, потому хочу попытаться предложить миру альтернативу — начиная от железа. Я запланировал полный переход на условно «безошибочные» вычислительные машины, с курсом на автономный машинный интеллект. Но с такими косячными подходами никто далеко не уедет. Приходится разбираться ещё с косяками микросхем и базовых компонент. Если мне удастся продвинуть единое издательсво, гарантирующее правильность отработки кодов на определённом типе машин — это станет одним из ударов по недопиленому софту «с поддержкой», и я надеюсь что тогда мне удастся подорвать экономическую сторону этой гигантской аферы, и это заставит программистов по всему миру работать как следует и учить матчасть… Ну, это в перспективе. Пока есть наработки по высокоуровневым языкам общения с машиной (это такие языки программирования, которые на два уровня повыше текущих высокоуровневых), и 15 патентов на производство процессоров и жестких дисков (к сожалению, пока полный цикл производства не обеспечен, но будет и это). Мне нужны такие люди, которые презирают сложившуюся систему работающих как попало кодов. Вместе — мы сила.
michael_vostrikov
05.01.2018 20:50+1Покажите код, который написали лично вы и в котором нет ошибок. Ошибки в сторонних компонентах не считаются. Что-нибудь сложнее калькулятора, например работа с базой данных с проверкой прав на определенные действия.
vdshat
05.01.2018 20:30На самом деле автором подняты довольно серьезные проблемы, можно сказать даже философские. Да, ввиду молодости прослеживается категоричность, небольшой опыт не дает оформить мысль полностью или раскрыть ее с разных сторон.
Помойка.
Это сравнение, можно сказать, есть эмоциональная реакция на несовершенство окружаещего мира потребления. Да, к сожалению мы наблюдаем кривой, несовершенный код сплошь и рядом, как и кучи ширпотреба с иллюзией выбора. Все чаще встречаются персонажи не прочитавшие ни одной книги по программированию, но худо-бедно говно-кодят покуда архитектура и мощности позволяют. Но потом, как правило случается коллапс. У нас есть один сервис, работающий лет пять, за рефакторинг которого никто не хочет садится. Да, он пока работает, но поддерживать его нереально, т.к. говно-кодер об его поддержке и не думал, хотя формально все бизнес требования соблюдены. В результате синьор-кодера уволили за альтернативность мышления, но помойка осталась.
Непрофессионалы
Категория, к сожалению, касается не только программирования, но в ИТ их с верху до низу. Менеджеры незнающие специфику области, не владеющие элементарными знаниями ни в одной области, кроме амбиций и интриг. Архитекторы незнающие ни процесса разработки ни умеющие писать код, непредставляющие производства в целом, т.к не являются инженерами. HR «специ» не понимающие процесса отбора и найма персонала и т.д. К сожалерию, нами создана среда, в которой социальные паразиты вполне могут жить и жить успешно. Мы с ними, даже, в симбиозе. К сожалению, даже не смотря на жесткий отбор у нас в команде есть люди, которые пишут, т.к. за это платят, меньше, чем за наркотики, но не сажают.
Думаю, на это и хотел обратить внимание автор. И на самом деле стремление улучшить мир — это и есть главная движущая сила прогресса.
P.S. Табличка на дверях отдела автоматизации: Мы увеличиваем производительность труда!michael_vostrikov
05.01.2018 21:01Это сравнение, можно сказать, есть эмоциональная реакция на несовершенство окружающего мира потребления.
Скорее выглядит так, будто автор увидел код какого-то фреймворка с кучей классов и не смог в них разобраться)
Классов много, но необязательно знать как работает каждый. На то она и абстракция.
vdshat
06.01.2018 03:07А может и реакция на ситуацию подобную этой. У нас в команде после долгих поисков решили написать свой фреймворк для визардов (2004 год). Сеньор нарисовал и отдал пользоваться. У всех был ступор: как им пользоваться? Вроде все API то, что нужно, но не работает. Оказалось, что он был настолько абстрактен, что не содержал ни одной реализованной стратегии. Это как раз и наталкивает на мысль, что человек писал не для пользователей.
sbnur
Скорее всего в помойку превращается… (заполнить по своему разумению)
Lure_of_Chaos
Не превращается. Более того, благодаря фреймворкам, задающим жесткую структуру, вместо Божественной Функции мы имеем множество хорошо структурированных классов, в которых методы тривиальны, «взять, трансформировать и передать дальше», а благодаря популяризации элементов ФП мы вместо десятка вложений if-for можем писать понятную и лаконичную цепочку операций. А еще вспомним, что событийная модель (и асинхронность в целом) позволила избавиться от Главного Цикла в пользу Слушателей/Обработчиков. Такое движение не может не радовать.
Ладно, справедливости ради нужно также отметить, что такое потакание программистам влечет увеличение лени, и раз уже не надо экономить такты процессора и байты памяти, то в итоге мы видим, как программы весят гораздо больше при тех же функциях и работают меньше (и позвольте поныть о моде на притягивание веб-технологий туда, где хорошо без них...)
Error1024
Я считаю что поголовное увлечение асинхронностью/событийностью привело к тому что программы стали более нестабильными/недетерминированными.
Если в программе основанной на концепции Главного Цикла, при зависании одной из функций — висла вся программа, и было понятно что «приехали», надо писать разработчику/править сорцы, то с текущей асинхронностью — нередко когда программа вроде и работает, но, то кусок отвалился, то не обновляется, то ui вроде реагирует, но ничего кроме индикации «waiting...» не происходит, и такие странности живут годами, ибо воспроизвести их сложно/невозможно.
lair
Ну то есть вы предпочтете, чтобы программа подвешивала UI, пока делает работу по, скажем, скачиванию файла?
Error1024
Ключевое слово «поголовное», асинхронщина необходимое зло, но надо знать меру.
sbnur
Простите — но почему вы меня уверяете в том, что программирование не помойка — я такое не утверждал.
Могу пояснить свой коммент — скорее всего в помойку превращается место, где появляются такие публикации.