Шоу в самом деле «не ахти» и заслуживает троллинга.
Впрочем не знаю мотивы участия в нем других.

Владимир

То, что описано в Ajile manifesto.

Шикарно.
В общем что и требовалось показать, 10 страниц ругани, а о чем речь никто сформулировать не может.

Так уж и быть, покормлю. Agile это:
- рано и часто релизить;
- ломать архитектуру даже в «конце» разработки;
- вместо ТЗ использовать общение с заказчиком и друг с другом;
- не иметь долгосрочного плана, а работать по регулярно меняющимся целям.

Так внезапно это не в вашей (фронт бек) компетенции. Как вы это в двоем решите?

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

Так уж и быть, покормлю. Agile это:

• рано и часто релизить;
• ломать архитектуру даже в «конце» разработки;
• вместо ТЗ использовать общение с заказчиком и друг с другом;
• не иметь долгосрочного плана, а работать по регулярно меняющимся целям.

Херак, херак и в production?

Владимир

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

Владимир

Так в чем разница того о чем ты говоришь (обсуждать проблема когда она возникла) и 15 минутном обсуждении возникших проблем на дейле?

Так в чем разница того о чем ты говоришь (обсуждать проблема когда она возникла) и 15 минутном обсуждении возникших проблем на дейле?

В том, что проблема часто не решается в одну итерацию - и что тогда, ждать следующего дня? Нет, в итоге придется написать/сказать результат, раньше, и в итоге ты придешь все равно к тому же сценарию, который я написал - так зачем лепить лишнюю сущность?

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

Херак, херак и в production?

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

побольше бестолковых конференц-колов сюда добавь, когда висят по 30 человек

Ска, я аж прослезился.

SCRUM этот ваш

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

– Отец, – с холодным достоинством ответил Максим, – чего это ты пургу метёшь, а? Мы ведь это проехали давно. Я тогда был художник-концептуалист, а это был хэппенинг.

Никита глубоко вздохнул дым и закашлялся.

– Говно ты, – сказал он отдышавшись, – а не художник-концептуалист. Ты просто ничего делать не умеешь, … вот всякие названия и придумываешь.

Ты всю суть вырезал. Там было про то, что «ты просто ничего больше делать не умеешь, кроме как треугольники вырезать и писать ххх, вот всякие названия и придумываешь. И на „Вишневом саде“ вы тоже треугольник вырезали и ххх написали, а никакой это не спектакль. И вообще, во всем этом постмодернизме ничего нет, кроме ххх и треугольников».

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

это метапрог.

И во всём этом Скраме тоже ничего нет, кроме стрелочек и треугольничков? :)

Открываем ГОСТ 19.201-78(СТ СЭВ 1627-79).

так это ж ЕСПД. немодно. модно: процесс управления (инжиниринга) требований, на основе CASE-систем и автогенерируемых матриц трассировки по настроенным моделям и метамоделям трассировки. и кстати, если это достаточно автоматизированно никаких отчётов о проделанной работе «закручиваем гайку А1 ключом М2 10 раз по часовой стрелке» писать не надо, всё сразу видно. хотя вообще-то в том же Emacs org-mode clock-in/clock-out нажимается парой клавиш, и чтобы такой отчёт написать, нужно а) иметь хоть какой-то ежедневный план, эти вот agenda и прочий timeboxing b) пару кнопок нажать для отслеживания хронометража (вышел из-за компа – поставил на паузу, пришёл – продолжил) c) немного его причесать.

вообще идеальных планов не бывает, на самом-то деле. если, конечно это не «план Маршала» :)

1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

то есть: медленно и печально.

а как, простите, без ТЗ что-то разрабатывать? это как вообще?

вообще в этом треде полно каких-то предубеждений и предрассудков. типа того, что «или планирование, или аджайл», «скрам со спринтами это никакого планирования», «бюрократия и спецификации вредят процессу разработки» (ага, ну поразрабатывайте без ТЗ, без «бюрократии» вообще, лол)

или вот например: ГОСТ 34 это классическая водопадная, без итераций и переделок, а значит, противостоит аджайлу, например скраму со спринтами. не значит нифига.

ГОСТ 34 — это технология, с отдельными этапами — технологическими стадиями. а SCRUM, XP, ISO 12207, спиральная модель Боэма и прочий ЖЦ типа ISO 15288 — это методологии, то есть метатехнологии, на уровень выше. у них есть методика применения, способ верификации и валидации (корректности применения методики).

если на входе технологии подать говно, технология корректно отработает — сделает из говна говно. неговно она сделать не может — это не задача технологии. это задача метатехнологии, отфильровать говно и остановить конвейер по переработке говна GIGO.

здесь уже появляется управление рисками и системы менеджмента (на основе рисков и процессов). это тоже задача методологии (теперь управления).

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

вопрос в том, что не обязательно это ТЗ сводить к «написанию документов». а потом переделывать когда у заказчика приоритеты изменятся. или когда задача в старой постановке станет невостребованной и не актуальной, и приоритеты и риски изменятся. или когда будет найден новый, более технологичный способ решения (технология, архитектура и т.п.)

есть более общие процессы управления требованиями, управления конфигурацией и изменениями, управления рисками. которым подчиняются конкретные технологии (например, набросать архитектуру по корректному и проработанному ТЗ, набросать тесты и реализацию по API архитектуры и т.п.).

нормальные люди давным-давно пользуются CASE системами, а не занимаются «написанием документов» (и прочей бюрократией, ога). которые давным-давно работают с настраиваемыми в конфигурации моделями процессов, данных, моделей и матриц трассировки, аналитических представлений. и автоматизируют работу аналитика с ТЗ и архитектурой и разработчика требований, с SR-> FR+NFR+SBS и моделями и матрицами трассировки.

и давным-давно пользуются а) захватом требований из текстового файла-анкеты б) генерацией ТЗ по настраиваему шаблону (тот же ГОСТ 34) из CASE в настроенной конфигурации и моделями трассировки в) автогенерируемыми матрицами трассировки, аналитическими представлениями и запросами со БД CASE г) параметрическим синтезом везде, где это возможно (а из-за гибкой структуры таких баз это много где возможно)

вот, например Cradle. CASE-система управления требованиями.

есть решения и про ГОСТ 34 и каскадно-водопадную: GO-34

и про скрам и прочий отжайл: из коробки автоматизация отчётов по планированию в SCRUM остальное поиском, здесь обрати внимание на автогенерацию матриц трассировки, и вообще, про модели трассировки (есть настраиваемые схемы как для SysML и системной инженерии, так и по ГОСТ 34, и вообще там всё полностью настраиваемо)

так что:

а) ГОСТ 34 не обязательно строго каскадно-водопадный, его можно совмещать с тем же SCRUM. когда-то на видном месте на сайте САТУРС висела презентация и типовое решение, как это можно сделать. опять же, на основе автоматизации по настроенными моделям и матрицам трассировки. сейчас что-то сходу не найду, куда-то глубоко закопано.

б) планирование в SCRUM таки есть – это 1)планирование очередного спринта на микроуровне 2) на макроуровне, это разбиение epic user story по отдельным спринтам, итерациям и релизам. опять же, метод освоенного объёма, диаграмма сгорания, покер планирования – ради этого.

другое дело, что почему-то CASE системами «пользоваться немодно», лол. а разводить бюрократию с «написанием документов» идеального ТЗ, идеальной архитектуры, идеально организованного рабочего процесса – это нормально, ога? и далее медленно и печально его утверждать и согласовывать, а потом рвать на жопе волосы в случае рисков и переделок, пересогласований.

ну почему оно так. или из-за врождённого нищебродства у людей денег на CASE системы не хватает. или технологической культуры ими пользоваться, а не разводить бюрократию с «написанием идеального документа».

а потом наблюдаем агонию на 10 тредах по 40 страниц каждый, когда из-за недостатка планирования, из-за недостаточно гибко организованных процессов управления требованиями и рисками, плюс ещё если помножить на макак-недопрограммеров изучающих методом тыка по ходу дела, хоть какой-то прототип рождают мучительно, медленно и печально и мертворожденно.

и имеем очередной метапрог.

... и немедленно выпил

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

И вот тогда-то я ввел свои пресловутые «индивидуальные графики», за которые меня наконец и поперли…
Новогиреево – Реутово
Сказать ли вам, что это были за графики? Ну, это очень просто: на веленевой бумаге, черной тушью, рисуются две оси – одна ось горизонтальная, другая вертикальная. На горизонтальной откладываются последовательно все рабочие дни истекшего месяца, а на вертикальной – количество выпитых граммов, в перерасчете на чистый алкоголь. Учитывалось, конечно, только выпитое на производстве и до него, поскольку выпитое вечером – величина для всех более или менее постоянная и для серьезного исследователя не может представить интереса. Итак, по истечении месяца рабочий подходит ко мне с отчетом: в такой-то день выпито того-то и столько-то, в другой – столько-то и того-то. А я, черной тушью и на веленевой бумаге, изображаю все это красивою диаграммою. Вот, полюбуйтесь, например, это линия комсомольца Виктора Тотошкина: А это Алексей Блиндяев, член КПСС с 1936 г., потрепанный старый хрен: А вот уж это – ваш покорный слуга, экс-бригадир монтажников ПТУСа, автор поэмы «Москва – Петушки»: Ведь правда, интересные линии? Даже для самого поверхностного взгляда – интересные? У одного – Гималаи, Тироль, бакинские промыслы или даже верх кремлевской стены, которую я, впрочем, никогда не видел. У другого – предрассветный бриз на реке Кама, тихий всплеск и бисер фонарной ряби. У третьего – биение гордого сердца, песня о буревестнике и девятый вал. И все это – если видеть только внешнюю форму линии. А тому, кто пытлив (ну вот мне, например), эти линии выбалтывали все, что только можно выболтать о человеке и о человеческом сердце: все его качества, от сексуальных до деловых, все его ущербы, деловые и сексуальные. И степень его уравновешенности, и способность к предательству, и все тайны подсознательного, если только были эти тайны. Душу каждого мудака я теперь рассматривал со вниманием, пристально и в упор. Но не очень долго рассматривал: в один злосчастный день у меня со стола исчезли все мои диаграммы. Оказалось: эта старая шпала, Алексей Блиндяев, член КПСС с 1936 г., в тот день отсылал в управление наше новое соцобязательство, где все мы клялись по случаю предстоящего столетия быть в быту такими же, как на производстве, – и, сдуру ли или спьяну, он в тот же конверт вложил и мои индивидуальные графики.

Метрика - это придуманная манагером формула, по которой считается результат спринта. Плюс пороги этой метрики, когда считается, что команда справилась на отлично/хорошо/плохо.

лигрыл то есть, «литр на грамм на рыло»

В том, что проблема часто не решается в одну итерацию

Окей, давай пойдем дальше (но не глубже, не думай что это какой-то придуманный лишь бы быть пример, все более чем жизненно)

У тебя есть задача фронт1 (ну например, узнать реальный емейл пользователя который зашел через фейсбук) которая связанная с бек1 (достать эту инфу с через АПИ фейсбук). Эта фича нужный шаг перед неким фронт2 (настроить аналитику возврата пользователя после емейл рассылки) - на котором подключается маркетинговый отдел с задачей маркет1 (рассылка емейла) - но тут оказывается что у маркетингового отдела какая-то проблема и задача маркет1 почему-то не реализуемая.

Что в результате? Ты себе спокойно пилишь фронт1, даже не зная что эта таска уже не нужна.

Маркет1 даже не подозревает что существует таска получение емейла.

Ах да, в этот момент еще существует дизайн1 - нарисовать иллюстрацию в емейл. А также дизайн2 - нарисовать «ого, вы уже второй раз на нашем сайте после емейл рассылки, невероятно круто!».

А еще есть таска деньги1 - выделить деньги на какой-то там мейлчимп для рассылки. (Кстати может быть и наоборот, маркет1 все отлично - а вот бек1 не получается сделать, или фронт1)

И вот теперь представь что дейли нет - и ты об этой проблеме (фронте1 не получается реализовать) не сообщил, или сообщил только дизайнеру, или только маркетологу, или только менеджеру, или только тому кто заведует таской «деньги1».

А представь что таска таки реализуется, но как-то сложно, и ты пошел к лиду, а он к СТО и вот вы решаете как это делать, а потом оказывается что с ФБ у вас только 5% пользователей (или еще круче - вы даже сайт еще не релизнули и не знаете будут ли у вас пользователи, или сайт давно в релизе - но нет аналитики). И может быть что те 5% не стоят того чтоб тратить много времени на фронт1 + немного на бек1, маркет1, деньги1.

И это же я привел достаточно простой пример связанных тасок когда ты можешь быть даже не в курсе какие связи вообще существуют. Причет тут пример четкий «либо есть емейл с ФБ либо нет». А представь когда четких границ нет (ну например у вас 30% регистрируются через емейл/пароль, и только 70% через ФБ) - и тут вообще не понятно если у нас нет 70% емейла пользователя нужно ли маркетингу и дизайну и «деньги1» продолжать работать ради 30%

Пока писал еще одну вещь понял, а представь что вы таки сделали фронт1 (но заняло много времени) бек1 маркет1 дизайн1 деньги1

А потом… А потом… оказалось что конверсия возврата через емейл 1%.

А знаешь как бы это было в аджайле? Ты на дейли говоришь «чет трудно с фронт1», а маркетинговый отдел «окей, давай мы сначала сделаем маркет1 для тех пользователей который не с фейсбука, и посмотрим стоит ли оно того вообще». Быстрый релиз, и через неделю вы понимаете что не стоит, и с легкостью выбрасываете не актуальные фронт1, маркет1, дизайн2 таски

У тебя есть задача фронт1 (ну например, узнать реальный емейл пользователя который зашел через фейсбук) которая связанная с бек1 (достать эту инфу с через АПИ фейсбук). Эта фича нужный шаг перед неким фронт2 (настроить аналитику возврата пользователя после емейл рассылки) - на котором подключается маркетинговый отдел с задачей маркет1 (рассылка емейла) - но тут оказывается что у маркетингового отдела какая-то проблема и задача маркет1 почему-то не реализуемая.
И вот теперь представь что дейли нет - и ты об этой проблеме (фронте1 не получается реализовать) не сообщил, или сообщил только дизайнеру, или только маркетологу, или только менеджеру, или только тому кто заведует таской «деньги1».

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

А потом… А потом… оказалось что конверсия возврата через емейл 1%.
А знаешь как бы это было в аджайле? Ты на дейли говоришь «чет трудно с фронт1»

Я тебе скажу, как это происходит конкретно у нас. Кодер получает задачу, оценивает сроки ее выполнения и возможные трудности. Всё, дальше менеджеры сами решают, нужна ли эта задача завтра на таких условиях или нет.

Быстрый релиз, и через неделю вы понимаете что не стоит, и с легкостью выбрасываете не актуальные фронт1, маркет1, дизайн2 таски

Ситуация релиза в продакшн сырого кода для проверки теории - это очень ограниченная часть задач (прототипирование), под которые выделяется неделя, ну максимум две работы - это вполне годный вариант. За пределами этой сферы необходимо возвращаться к написанию качественного и продуманного софта.

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

Так а почему после прототипа не продолжить делать заново прототип (версия 2)? Или ты думаешь что потом все будет работать как часы и 100% быть предсказуемым?

Ну грубо говоря на моем примере выше - сделали прототип чтоб протестить конверсию с емейл рассылки - не зашло (или зашло, не важно) - дальше делаем прототип «Подпишитесь на нас в инсту - мы будет спамить вас каждый час там в ЛС», через неделю делаем «Подпишись на ютуб - будем стримить в 4 часа утра тебе на зло». И так далее.

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

Звучит логично. Не хочешь ли ты рассмотреть аджайл как уменьшение количества менеджеров - и увеличение менеджерского скила в каждом исполнители (кодере, дизайнер и так далее?)

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

Так а почему после прототипа не продолжить делать заново прототип (версия 2)? Или ты думаешь что потом все будет работать как часы и 100% быть предсказуемым?

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

Ну грубо говоря на моем примере выше - сделали прототип чтоб протестить конверсию с емейл рассылки - не зашло (или зашло, не важно) - дальше делаем прототип «Подпишитесь на нас в инсту - мы будет спамить вас каждый час там в ЛС», через неделю делаем «Подпишись на ютуб - будем стримить в 4 часа утра тебе на зло». И так далее.

Это уровень хелло волда, может быть немного выше. Можно спорить о том, нужно ли на такое занятие нанимать программиста, или же школьник за бутылку пива поставит нужный софт и сделает нужные скрипты.

Не хочешь ли ты рассмотреть аджайл как уменьшение количества менеджеров - и увеличение менеджерского скила в каждом исполнители (кодере, дизайнер и так далее?)

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

Давай кодеры будут еще на четверть ставки мыть полы

В планировании мытья полов участие уборщицы не обязательно — менеджер достаточно понимает процесс. В планировании (и перепланировании) создания ПО участие исполнителя желательно, потому что никто лучше него не понимает процесс во всех деталях. Если мы хотим, чтобы планы не сильно расходились с реальностью, конечно.

Я отлично понемаю желание забиться в угол, рычать и писать код, игнорируя все эти бизнес-заморочки — пусть кто-то другой об этом думает (и, конечно, вовремя подтаскивает мешки с деньгами). Вот только способствует ли такая позиция увеличению объема мешков? %)

В планировании мытья полов участие уборщицы не обязательно — менеджер достаточно понимает процесс. В планировании (и перепланировании) создания ПО участие исполнителя желательно, потому что никто лучше него не понимает процесс во всех деталях. Если мы хотим, чтобы планы не сильно расходились с реальностью, конечно.

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

Я думаю все мы знаем чем отличается макака от профи, профи сроки умножает на три, макака нагло врет о том, что работы на пол часа.

Вот как хочешь так и планируй с этим знанием тлять.

Ну так что там с ХРУМ /ранее назывался SCRUM/?

Владимир

Ах, в статье приводится! А ты и ведёшься, как девочка. «В статье» тебе ещё и не такое напишут — учить критически воспринимать получаемую информацию, особенно, если хочешь руководить какими-то процессами, информацию от подчиненных, особенно позитивную.

«О вреде оператора Go To» http://hosting.vspu.ac.ru/~chul/dijkstra/goto/goto.htm

Дейкстра написал эту статью в 1968 году.
В 80-х интернета не было и об этой статье ни кто не знал.
И вот «дураки» использовали процедурное программирование.
До сих пор не могу понять, почему эта «проблема» так популярна /и даже ныне/.

А вообще goto не вреден.
И даже более того жаль, что в VC нет goto Expession.

Владимир

Распушаешь свой хвост перед девчонкой, старый греховодник?

Бесноватый, если бы «молодая особа» не хамила всем, то и комментов моих не было бы.

Владимир

Гордыня имеет признаки, которые необходимо различать.

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

ХРУМ /ранее назывался SCRUM/?

или CКРАМ

До сих пор не могу понять, почему эта «проблема» так популярна /и даже ныне/.

да всё просто: Дейкстра сотоварищи (например, с Хоаром – есть совместная статейка 70, где озвучены основные принципы ООП, только другими словами про ADT и структурное программирование) упарывался по формальной верификации отдельных строчек (на базе предусловий, постусловий и инвариантов), которая потом выродилась в верификацию отдельных методов и правила композиции клиента/сервера класса (терминология из Eiffel) при контрактном программировании.

для верификации из-за большого количества трасс программы при трассировки для прослеживаемости состояния (область определения -> область допустимых значений) размерность этого пространства (ООФxОДЗxКолвоТрассАльтернативныхЛинийВремениДоктораКто) росла нелинейно.

ниасилили. посему ввели всего 5 видов операций: присваивание, вычисление выражения, вызов функции, альтернатива(if..then..else, a=b?c:d), итерация(for,while,until), следование (умножение ; в мононоиде a;b;).

здесь моноид с операцией ‘;’ – строго синхронный. всякую асинхронщину выкинули. goto либо выкинули вообще, либо существенно ограничили, запретив милые трюки типа замыканий, продолжений, octopus stack и сопрограмм. то есть, теперь нельзя переходить в середину функции, в середину if или while, выходить из середины – можно. нельзя вместо call func делать goto func и вручную подменять адрес возврата (например для реализации сопрограмм или замыканий с продолжениями). области видимости данных это вложенные контексты из алгола, никаких static переменных в си или замыканий с продолжениями из других языков (того же алгола с call-by-name семантикой, например).

в итоге облегчили формальную верификацию. плюс теорема Бьёма-Якопини которая говорит что любой алгоритм может быть переделан к структурному виду. и например тот же брейнфак где его набор команд и есть операторов Бьёма-Якопини.

в итоге, чтобы написать теперь простой конечный автомат или Duff device теперь нужно извращаться. ну как же, прогресс же, структуральнейшие лингвисты же.

опростились же аки граф Толстой, ходим в рубище и лопухами подтираемся. замыкания с продолжениями некошерны, хитрые игры со стеком вне закона. а два стека, например как в аде где во втором можно хранить локальные данные переменного размера – вообще хитрая магия. фортрановы переменные в регистрах а не стеке, кстати тоже.

кстати, тому же Толстому тоже почему-то приписывают бред под названием «непротивлению злу насилием». изачальное понятие «ахимса» означала «ненасильственное сопротивление злу», почувствуйте разницу. сопротивляться, но не умножая насилие или не копротивляться ваапче.

А вообще goto не вреден.

ну да, теже конечные автоматы в помощь. и например в современном ООП коде с диспетчеризующимися вирутальными методами – есть скрытый двойной goto неявный через VTable. и с исключениями тоже.

в итоге недетерминированное время вызова отдельного метода может быть из-за всего этого. хотя VTable достаточно эффективный.

ну и инвалидация кеша, например.

А ты можешь также грамотно и подробно ответить здесь Вопросы к зачету? Если хочешь.

Все правильно.
Но вы вот подгадили в отношении меня УЧИТЕЛЬ, а теперь учите порядочности.
Как то не вяжется все.
Научитесь нормально без гадостей вести диалог и будет все Ok!

Что касаемо унижения других, то ни когда себе этого не позволяю, но
если хамовитые направо и налево «раздают всем», то да говорю им об этом.

Владимир

Прочитал еще раз.
На личности ни когда не перехожу /в т.ч. когда троллю/.
Но вот не люблю хамовитых и говорю им «перестань хамить».
Это разве плохо?

Владимир

Нужно подыскать другой термин

Тяп-ляп же.

И в продакшен!

Мне больше нравится «граммо-градус на рыло в час».

Вольна баба в языке, а черт в бабьем кадыке.

Вольна баба в языке, а черт в бабьем кадыке.

Вот напрочь не понимаю для чего в форумах переходят на личности?
Профит в чем?

Владимир

Профит в чем?

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

Народ уже намекнул тебе

Это же ЛОР.
Загляните в любую тему и они процентов на восемьдесят состоят из «намеков» друг другу.

Владимир

Учися вежеству Владимир: где пень - тут челом; где люди - тут мимо; где собаки дерутся - говори: «Бог помощь!»

где собаки дерутся - говори: «Бог помощь!»

В отличии от вас к форумчанам как к собакам не отношусь и ни одному из них «не намекнул».
Но все же жаль, что на ЛОР-е любят «намекнуть».
Впрочем на других форумах «не лучше».

Владимир