Отсутствие мемасиков убило GoTo
"Чистая архитектура: Искусство разработки программного обеспечения" Робер Мартин
Подробнее
Объявление вредным В 1968 году Дейкстра написал редактору журнала САСМ письмо под заголовком Go То Statement Considered Harmful («О вреде оператора Go То»|)\ которое было опубликовано в мартовском выпуске. В статье он обосновал свою позицию в отношении трех управляющих структур2. И мир программирования запылал. Тогда у нас не было Интернета, поэтому люди не могли публиковать злобные мемы на Дейкстру и затопить его недружественными сообщениями. Но они могли писать — и писали — письма редакторам многих популярных журналов. Не все письма были корректными. Некоторые из них были резко отрицательными; другие выражали решительную поддержку. И эта битва продолжалась почти десять лет. В конце концов спор утих по одной простой причине: Дейкстра победил. По мере развития языков программирования инструкция goto все больше сдавала свои позиции, пока, наконец, не исчезла. Большинство современных языков программирования не имеют инструкции goto, а некоторые, такие как LISP, никогда ее не имели.
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
только не надо было ему Роше предавать
А лисп как был никому не нужен, так и остался. Поправка: никому вне академических интересов и исследований. Продакшн-код на нем никто в здравом уме не пишет.
На функциональщине отлично пишутся самые обычные алгоритмы, а не только специфические.
Более того, я считаю, что, если имеется возможность отделения момента сохранения информации от прочей логики, то эту логику следует писать в функциональном стиле.
Функциональный подход в React-redux вытекает из его концепции естественным образом.
В JS нет ничего ущербного. Всё те примеры "странного поведения", которые постоянно мусолят в интернет, на практике не встречаются. JS действительно позволяет "выстрелить в ногу" из-за динамической типизации и проглатывания ошибок. Но с эти борются путем использования всяких надстроек над языком типа TypeScript, а никак не функциональным стилем.
Под функциональной лапшой Вы видимо подразумеваете "лапшу из callback'ов" асинхронных вызовов, раз упоминаете в этом же предложении async/await. Это вообще из другой плоскости предмет, и ФП тут не причем! К тому же вовсе не обязательно оформлять код в виде лапши анонимных функций. Всегда можно выписать функции по отдельности и дать им имена.
В действительности функциональный стиль подразумевает:
во-первых, "чистые" функции. Т.е. для одних и тех же параметров функция всегда возвращает одинаковый результат;
во-вторых, все переменные инициализируются единожды. По сути, в ФП нет переменных, это скорее псевдонимы для выражений;
в-третьих, все объекты иммутабельны. Т.е. операция над объектом не модифицирует объект, а возвращает новый объект.
> JS действительно позволяет "выстрелить в ногу" из-за динамической типизации и проглатывания ошибок
> путем использования всяких надстроек над языком типа TypeScript
Ты просто на ноль поделил. Если на языке невозможно писать без надстроек - то это как раз таки ущербный язык.
Не надо мне рассказывать про функциональный стиль, пожалуйста. Я прекрасно понимаю, что это такое. Действительно полезная вещь в функциональщине ровно одна - чистые функции. Все остальное крайне ситуативно и способствует созданию неоптимального кода. Что до лапши из каллбеков - это прямое следствие корявой асинхронности и навязанного функционального подхода. Никогда не замечал, что это все подозрительно напоминает лиспы? Вот то-то и оно.
Плохо Вы понимаете, что такое функциональный стиль, раз мешаете его с явлением асинхронности.
Я отлично понимаю, что такое функциональный стиль. А еще я понимаю, что технологии обычно ходят рука об руку, и мое утверждение остается в силе: функциональный стиль в js - попытка хоть как-то обойти его дефективность.
Есть очень занятный пример - сервис по продаже авиабилетов гугла. Они его перекупили у какой-то компании вместе с клиентской базой, и лиспофаги постоянно били себя пяткой в грудь - мол вот, лисп в продакшне, скоро все остальные отправятся дворы мести. На самом деле, как мне поведал один знакомый из гугла, это скобчатое говно поддерживать невозможно и оно тупо тормозит, поэтому когда надо внести какие-то изменения в этот божественный лиспокод, то они просто кусками переписывают его на C++. Дело было много лет назад, так что может быть уже и переписали.
Тормоза программ как правило вызваны не парадигмой программирования или особенностями языка, а неверными архитектурными решениями. Сортировка пузырьком на Python исполняться раз 100 медленней, чем на Си. Но правильным способом ускорения здесь будет не замена языка, а замена алгоритма.
Еще как показателен. Функциональный подход с его иммутабельностью выглядит красиво, но порождает дичайший оверхед по памяти и использованию процессора.
> Тормоза программ как правило вызваны не парадигмой программирования или особенностями языка
Неудачно спроектированные языки способствуют написанию говнокода. Пуризм и элитизм любителей фп способствуют написанию неподдерживаемого и неэффективного кода.
> На Lisp'е вполне можно писать в императивном стиле.
Тогда вопрос его нужности по сравнению с другими языками встает еще более остро.
Слушай, я вижу, что ты разбираешься в теме, но тебе, наверное, не встречалось еще кода львов толстых, написанного на всяких функциональщинах. Вопрос лично тебе. Ты упоминал про реакт, ты фронтендер, или так, пописываешь иногда? Хочу уточнить не для троллинга, а потому что наши предметные области могут просто не пересекаться.
К функциональному программированию пришел не по зову моды, а в ходе профессионального развития. Я не являюсь фанатичным адептом этой парадигмы, однако вижу много областей, где уместно было бы гармонично ее употребить.
Что касается иммутабельности: Она действительно порождает некоторый оверхед. Однако надо понимать следующее:
1. Иммутабельные объекты не копируются полностью. Допустим у нас есть массив на N элементов. Нам нужен такой же массив, но с измененным k-ым элементом. Это не значит, что будут скопированы все N элементов. В действительности будет модифицирован объем памяти размером log N.
2. Иммутабельные структуры не могут образовывать циклические зависимости, поэтому необходимость в сложном сборщике мусора, который может обнаруживать и удалять "подвешенные" острова памяти, отпадает. Достаточно тривиального подсчета ссылок.
3. При правильном использовании сравнение огромных структур данных превращается в простое моментальное сравнение ссылок на эти структуры.
Что касается элитизма любителей ФП: это не проблема ФП, это неизбежный спутник слабо распространенных новшеств.
Когда-то все программисты были "иной кастой", потому что были малочисленны. Просто ФП не мейнстрим, вот ФП-программисты и зазнаются.
Всю жизнь старался держаться подальше от веб-параши, но тут в последний год приспичило написать одну веб-приложуху. И я просто охренел от того говна, которого там понаворотили за последние годы. Сломано и дефективно буквально все, а что не сломано - еще нормально не поддерживается браузерами. Но это платформы. А язык - по факту js без альтернатив, потому что использование js со всякими тайпскриптами и прочими реактами превращает отладку в треш, угар и содомию.
Короче, еще раз. Мой поинт в том, что ФП не нужно в виде отдельного языка и нужно в виде элементов в других языках, поскольку никаких особых задач не решает само по себе, которые нельзя было бы решить на императивных языках.
Или можно проще (допустим, не все функции освобождения переваривают NULL)?
Вариант из моего комментария сверху оперирует с одной меткой, хотя после перехода надо проверять несколько условий.
Пример: https://github.com/pi-kvm/ustreamer/blob/master/src/http/static.c
Что интересно, в академической среде goto не хейтят совсем. Видел код, написанный не программистами а как раз всякими докторами/академиками - там goto в полный рост. Если считаете, что академики для прода не пишут, ваш любимый mp3 и его реализации как раз они самые и писали.
последний раз пользовался лет пятнадцать назад.
Но если "академическая среда" -- это искусственная лингвистика, то да, другое дело. Но там они вообще ничего не хейтят, это не тот уровень отношения к предмету.
> любой программист из индустрии охуеет
Программист охуеет прежде всего от предметной области. Сможет только предложить архитектуру, разработать спецфреймворк и обучить физиков необходимым азам, а дальше только отпускать их.
Проблема в том что этот говнокод нужно поддерживать, сопровождать, использовать повторно. А он годами любовно укладывается слоями в мощные копролитовые напластования.
PRINT "General Kenobi..."
15 PROBLEM?
20 GOTO 10
While True
Continue While
Problem?
End While
Конечно, можно было не париться с Continue,
но вам видимо хотелось иметь problem в середине текста программы
While True
End While
Problem?
И такой момент, я не уверен, что компилятор не скажет, что код problem не достижим, я это компилировать не буду, а вы проверьтесь у психиатра.
То есть, я хотел сказать go to jopa!
один из самых пожалуй жесткий костылей, но востребованный и по сей день, grpc php например весь напичкан goto и ничо, норм работает