PEP 572, процесс принятия которых привел к отставке «великодушного диктатора», предлагают «способ назначения переменных в выражении с использованием обозначения NAME: = expr, чтобы убрать подвыражения и сделать Python более аккуратным и быстрым». Как видно по обсуждению этого решения на форуме Y Combinator, некоторые разработчики считают, что это плохой подход, который отражает личное мнение ван Россума больше, чем передовые практики в отрасли.
6 июля ван Россум написал в публикации на сайте Python, что был ошеломлен количеством отзывов, которые получил в ответ на принятие PEP 572. Этот комментарий был сделан три дня спустя после того как спорные изменения уже вступили в силу.
Здравствуйте, so5team, Вы писали:
S>Выглядит так, что люди попытались воплотить мечты г.Мызыченко в жизнь и попробовали таки скрестить макросы с компайл-тайм рефлексией. Но уперлись в непреодолимые в их условиях сложности.
Очень похоже на то, что они попытались реализовать чрезмерно "либеральные" макросы, избегая вводить разумные ограничения.
Например, использование макросов в ассемблерах всегда было сопряжено с проблемами изменения глобальных макропеременных (нечто вроде сишных #define) от прохода к проходу. Они решаются разными способами — от использования тех значений, что были в момент обработки конкретной конструкции (программист мог создать путаницу, но сам и разгребал ее последствия) до порождения фатальной ошибки при таком изменении. Возможны и промежуточные варианты.
Нечто подобное описывали сотрудники MS в отношении __if_exists/__if_not_exists: поскольку C++ в ряде случаев допускает использование элементов, которые будут определены ниже по тексту, не всегда есть возможность уверенно считать элемент "определенным" или "неопределенным" в конкретной точке, поэтому они забили на это. По мне, так никакой проблемы нет: хочешь удобной условной трансляции — определяй все заранее, хочешь удобной записи — обходись без условной трансляции, или используй #if.
Все это достаточно легко регулируется как умолчаниями, так и явно указанными правилами. А если не скупиться на диагностические сообщения, то никаких экзистенциальных, труднопреодолимых проблем не просматривается.
Re[18]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Marty, Вы писали:
M>>>мне всегда проще было сделать что-то рекурсивно, чем итерационно. ЕМ>>Если алгоритм изначально рекурсивный — неудивительно. M>А если сам алгоритм придумываешь?
Ну, если Вашему мышлению комфортнее воспринимать какой-нибудь перебор элементов списка, как рекурсивный процесс, то Вы принадлежите к абсолютному меньшинству людей — абсолютному большинству естественным представляется итерационный.
Здравствуйте, so5team, Вы писали: S>Никогда с Dart дел не имел, а изучать Dart для того, чтобы поддержать беседу с очередным балаболом и пропагандоном .NET-а в прошлом нет ни времени, ни желания.
Ну почему же "в прошлом". Я и сейчас с большим уважением отношусь к платформе .Net.
А ваше грязнословие по этому поводу как-то бросает тень на вашу (действительно впечатляющую) квалификацию в вопросах С++.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То, что это весьма затратный процесс, особенно при том, что мне нужна хорошая оптимизация кода на выходе, а времени на занятия, не приносящие денег, остается все меньше и меньше.
Вот за это беспокоиться не надо. Достаточно уметь выплёвывать LLVM IR, а хорошую оптимизацию сделают за вас.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
M>>>>мне всегда проще было сделать что-то рекурсивно, чем итерационно. ЕМ>>>Если алгоритм изначально рекурсивный — неудивительно. M>>А если сам алгоритм придумываешь?
ЕМ>Ну, если Вашему мышлению комфортнее воспринимать какой-нибудь перебор элементов списка, как рекурсивный процесс, то Вы принадлежите к абсолютному меньшинству людей — абсолютному большинству естественным представляется итерационный.
Перебор списка — нет. А вот алгоритмы на деревьях так и просятся на рекурсивную реализацию, хотя итерационно тоже можно сделать
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>"Не смог" сюда не подходит — я не захотел его осваивать за пределами полезного мне подмножества. Квалификация позволяла и 35 лет назад освоить его в полном на тот момент объеме, и развлекаться сочинением шаблонов в стиле Александреску. Я ж когда-то делал курсовики и сдавал экзамены по всяким там функциональным пространствам, формальным языкам и подобной математике, и вполне во всем этом разбирался, но вот не нравится оно мне. Не вижу в этом ничего удивительного. Я освоил то подмножество C++, которое позволяет мне эффективно решать задачи, которыми я занимаюсь, не испытывая чрезмерного дискомфорта от того, какими средствами это достигается. По той же причине я не использую, например, Qt там, где нужно показать простое окошко и пару диалогов.
А если бы осилил, то полезное тебе подмножество было бы сильно больше
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Интересно, как бы Вы рассуждали, если бы вместо термина "macro" с самого начала использовался термин "template", а термин "macro" вовсе не вошел бы в обиход?
Наверное, использовали бы термин "template". Но фишка в том, что терминология есть, какая есть. И чтобы понимать друг друга, следует её придерживаться. А если под каждым термином каждый будет подразумевать какие-то свои понятия, то никакого понимания не будет.
В том числе и поэтому тебя просят привести пример использования твоих "макросов", потому что нихрена не понятно, как оно у тебя, предполагается, работает.
ЕМ>Все это достаточно легко регулируется как умолчаниями, так и явно указанными правилами. А если не скупиться на диагностические сообщения, то никаких экзистенциальных, труднопреодолимых проблем не просматривается.
Что нам стоит дом построить — нарисуем, будем жить
Здравствуйте, σ, Вы писали:
σ>>>В некоторых языках, которые лежат в основе C++, было что-то типа закрытого наследования (discriminated/tagged unions), и Строструп был с этим знаком. Но специально не включил это в C++ (наверное по вредительским соображениям).
D>>А это что?
D>>
σ>class B : private A {
σ> // ...
σ>};
σ>
σ>Приватное наследование
А теперь русскими словами...
Спасибо за внимание
Re[26]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Marty, Вы писали:
M>А если бы осилил, то полезное тебе подмножество было бы сильно больше
Количественно — больше, но качественно — не намного полезнее. Если б там просматривались какие-то качественные для меня прорывы, то давно освоил бы.
В большинстве-то случаев все эти трюки не дают радикальных улучшений, позволяя лишь более единообразно записывать то, что раньше делалось вразнобой. То есть, это полезно в первую очередь в групповой разработке, в открытом ПО, или в ПО, которое делает один, продает другому, тот дорабатывает, продает третьему, и т.п. Ничем из этого я не занимаюсь.
Поэтому, повторюсь, "осиливать" технологии, в основе которых лежат трюки, мне тупо эстетически неприятно, и я не вижу смысла заниматься этим до того, как ожидаемый эффект достигнет серьезных (для меня величин).
Вот забавно, кстати: сейчас ведь набирают силу тренды вроде производства белков из насекомых, и многие категорически заявляют, что "не будут есть эту дрянь ни за что", хотя возможности определить фактический источник того белка в своей еде у большинства из них нет. И это считается позицией, вполне заслуживающей уважения — по крайней мере, пока. Однако нежелание таких, как я, погружаться в извращенную кухню трюковых шаблонов лишь потому, что они считается модными, и с их помощью можно сэкономить единицы процентов времени разработки, почему-то объявляется "ретроградством", "ограниченностью", "неспособностью осилить" и т.п. А ведь полностью избавиться от знакомства с "подкапотом" этой кухни невозможно, даже тупо используя готовые конструкции из примеров.
Вот лично Вы как относитесь к пище с "насекомыми" белками?
Здравствуйте, Marty, Вы писали:
M>фишка в том, что терминология есть, какая есть. И чтобы понимать друг друга, следует её придерживаться.
Ну, это как большинство современных русскоязычных программистов, хорошо ориентирующееся в "корутинах", впадает в ступор при виде термина "сопрограмма", который в русском языке использовался еще с 60-х, но потом сошел на нет по причине угасания техник изготовления сопрограмм подручными средствами. Так что терминология, которую отстаивает so5team, сложилась исключительно от нехватки образования и исторической преемственности. Полагаете, это следует приветствовать?
Кроме этого, не забывайте, что я не столько предлагаю ввести в C++ эти "макросы" сейчас, сколько сожалею, что они не были в него введены тридцать лет назад, когда термин "метапрограммирование" еще не примелькался так, как в последние годы.
Re[4]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну, это как большинство современных русскоязычных программистов, хорошо ориентирующееся в "корутинах", впадает в ступор при виде термина "сопрограмма", который в русском языке использовался еще с 60-х, но потом сошел на нет по причине угасания техник изготовления сопрограмм подручными средствами. Так что терминология, которую отстаивает so5team, сложилась исключительно от нехватки образования и исторической преемственности. Полагаете, это следует приветствовать?
Фокус в том, что "короутина" и "сопрограмма" в современных реалиях -- это уже недостаточные и самоописывающиеся термины, т.к. stackful coroutine -- это одно, а stackless coroutine -- совсем другое. И как бы вы не переводили coroutine на русский язык (будь то корутина или сопрограмма) без уточнения термин "coroutine" оказывается неоднозначным.
Ну и я отстаиваю не столько терминологию, сколько принципиальную разность в подходах, когда "макросы" отвечают только за преобразование исходников, не заморачиваясь семантикой, которая скрывается за лексическими/синтаксическими элементами, а "метапрограммы" отвечают именно за преобразование кода с учетом его семантики.
Это ведь не зря разные подходы (по крайней мере когда мы рассматриваем статически-типизированные языки с отдельной стадией компиляции): есть вполне себе понятный водораздел, который определяет где уже есть семантическая информация, а где ее еще нет.
И ваши мечтания о том, что легко устранить этот самый водораздел, выглядят, по меньшей мере, наивно. Вы могли бы придать хоть какой-то вес своим измышлениям, если бы иллюстрировали свои утверждения хоть каким-то кодом. Но вы этого принципиально не делаете, что лично для меня хорошим основанием навесить на вас ярлык звиздун обыкновенный форумный балабол.
ЕМ>Кроме этого, не забывайте, что я не столько предлагаю ввести в C++ эти "макросы" сейчас, сколько сожалею, что они не были в него введены тридцать лет назад, когда термин "метапрограммирование" еще не примелькался так, как в последние годы.
Да, как же плохо, что идиоты из комитета не сделали для г.Музыченко зашибись еще 30 лет назад. Об этом остается разве что сожалеть. Ведь поделать уже ничего и нельзя.
Re[27]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В большинстве-то случаев все эти трюки не дают радикальных улучшений
Шаблоны не дали радикальных улучшений?
variadic templates не дали радикальных улучшений в сравнении с обычными шаблонами?
constexpr/consteval не дал радикальных улучшений?
Может это из-за того, что вы занимаетесь задачами, для которых нужно что-то не сильно выше ассемблера?
ЕМ>То есть, это полезно в первую очередь в групповой разработке
Это не так. Во-первых, новые фичи снижают стоимость реализации тех или иных задач.
Во-вторых, как раз в групповой разработке приходится следить за тем, чтобы сложность применяемых элементов языка соответствовала способностям самых слабых участников группы. И чем больше группа, тем внимательнее за этим нужно следить.
ЕМ>Поэтому, повторюсь, "осиливать" технологии, в основе которых лежат трюки
Само употребление термина "трюк" выглядит неоднозначным. Непонятно что вы под этим понимаете.
Например, есть способы, которые позволяют обратиться к приватному члену класса не будучи другом этого класса.
Как по мне, это трюк -- нечто уникальное и лежащее на грани разумности/дозволенности.
Есть трюк, который позволяет сделать так, что константное выражение в compile-time будет вести себя не как константа. Это вообще чистой воды трюк, который использует дефект(ы) в определении языка (возможно, уже устраненные).
Но мне почему-то кажется, что вы что-то гораздо более простое называете трюками.
Re[28]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, so5team, Вы писали:
ЕМ>>Поэтому, повторюсь, "осиливать" технологии, в основе которых лежат трюки
S>Само употребление термина "трюк" выглядит неоднозначным. Непонятно что вы под этим понимаете.
А для него почти весь С++ — это трюк. Как для дикаря зажигалка.
--
Справедливость выше закона. А человечность выше справедливости.
Re[29]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, rg45, Вы писали:
ЕМ>>>Поэтому, повторюсь, "осиливать" технологии, в основе которых лежат трюки
S>>Само употребление термина "трюк" выглядит неоднозначным. Непонятно что вы под этим понимаете.
R>А для него почти весь С++ — это трюк. Как для дикаря зажигалка.
Есть у меня такое подозрение. Но хочется, чтобы большинству читателей RSDN-а это стало очевидно.
Чтобы слова г.Музыченко о C++ можно было смело множить на коэффициент, близкий к нулю
Здравствуйте, so5team, Вы писали:
S>stackful coroutine -- это одно, а stackless coroutine -- совсем другое. И как бы вы не переводили coroutine на русский язык (будь то корутина или сопрограмма) без уточнения термин "coroutine" оказывается неоднозначным.
И многие ли, видя хоть "coroutine", хоть "сопрограмма" без уточнения, сразу и намертво залипают на частное значение, которое наиболее им мило? Напротив, я часто вижу, как кто-то упоминает "сопрограмму вообще", а другой уточняет, что сказанное применимо только к определенным типам/реализациям.
И я, заметьте, в своих текстах всегда стараюсь как-то оговаривать, что речь идет не о привычных сишных макросах, или макросах внешних, универсальных макропроцессоров, а о некоторых специальных, заточенных именно под особенности C++.
S>принципиальную разность в подходах, когда "макросы" отвечают только за преобразование исходников, не заморачиваясь семантикой, которая скрывается за лексическими/синтаксическими элементами, а "метапрограммы" отвечают именно за преобразование кода с учетом его семантики.
Вот пока Вы с единомышленниками будете это противопоставлять вместо того, чтобы признать очевидную подчиненность терминов, у вас будут получаться исключительно частные решения. Сколь много вы не наворотили бы языковых средств для решения частных задач, всегда найдется задача, для которой существующий синтаксис не годится. И придется или городить костыли, или привлекать внешние средства обработки (которых, внезапно, может не оказаться на очередной платформе).
А можно один раз сделать разумную реализацию макрообработки, где "макрос" [как правило] получает на вход сырую последовательность лексем (а то и вовсе строку абстрактного текста), может сам решить — то ли полностью разбирать ее своими силами, то ли попросить компилятор разобрать хоть отдельные части, хоть всю строку (возможно, дав ему какие-то подсказки по смыслу содержимого), то ли сразу отдать компилятору на разбор, получить от него удобный описатель, и уже по нему принимать решение о порождении тех или иных конструкций.
Если такая реализация будет достаточно удобной и "ортогональной" (то есть, будет позволять комбинировать разные средства/способы, а не выбирать между ними), на ней довольно быстро напишут множество самых разных примочек, как это сейчас принято делать на шаблонах, и самые удачные можно будет включать хоть в стандартную библиотеку, хоть в сам язык. Но все эти примочки можно было бы делать в человеческом виде, а не в подобии машины Тьюринга или математического вида конечного автомата, как это делается на шаблонах.
S>И ваши мечтания о том, что легко устранить этот самый водораздел
Вы так и не поняли сути того, о чем я талдычу уже столько лет. А суть как раз не в устранении водораздела, как такового, а в наведении мостов между берегами. В той модели, которую отстаиваете Вы, мост через реку должен быть только один, а производство должно быть организовано только так, чтоб все двигалось по мосту лишь в одном направлении. Типа, на левом берегу добыли сырье, сделали какое-нибудь предварительное обогащение, перевезли на правый берег, там уже обработали окончательно, и повезли куда-то дальше. А если вдруг кто заикнется, что на левом берегу имеются почти готовые мощности для какой-то промежуточной обработки (которая очень медленно и с большим трудом внедряется на правом), и всего-то нужно организовать обратную перевозку — хоть по тому же мосту, хоть по дополнительному легкому, хоть вообще по понтонному, его тут же объявляют еретиком, покушающимся на Единственно Правильное Направление.
S>Вы могли бы придать хоть какой-то вес своим измышлениям, если бы иллюстрировали свои утверждения хоть каким-то кодом.
Пока не вижу оснований полагать, что код сможет в этом хоть как-то помочь. Если вдруг замечу у кого-то понимание самой идеи в целом, то попробую. Пока вижу лишь возражение в стиле "это не будет работать, поскольку так не положено".
S>лично для меня хорошим основанием навесить на вас ярлык звиздун обыкновенный форумный балабол.
Да и ради бога, лишь бы на здоровье.
S>как же плохо, что идиоты из комитета не сделали для г.Музыченко зашибись еще 30 лет назад.
Ладно Музыченко, он в это дерьмо хоть сумел почти не наступать. А вот народ, барахтающийся в нем по уши, жалко.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>stackful coroutine -- это одно, а stackless coroutine -- совсем другое. И как бы вы не переводили coroutine на русский язык (будь то корутина или сопрограмма) без уточнения термин "coroutine" оказывается неоднозначным.
ЕМ>И многие ли, видя хоть "coroutine", хоть "сопрограмма"
Меня это не волнует. Вы позволили себе упомянуть меня рядом с этим примером, поэтому пришлось указать, что все не так однозначно.
ЕМ>И я, заметьте, в своих текстах всегда стараюсь как-то оговаривать, что речь идет не о привычных сишных макросах, или макросах внешних, универсальных макропроцессоров, а о некоторых специальных, заточенных именно под особенности C++.
Давайте называть вещи своими именами: о некоторых гипотетических, которых кроме вас никто не видел.
S>>принципиальную разность в подходах, когда "макросы" отвечают только за преобразование исходников, не заморачиваясь семантикой, которая скрывается за лексическими/синтаксическими элементами, а "метапрограммы" отвечают именно за преобразование кода с учетом его семантики.
ЕМ>Вот пока Вы с единомышленниками будете это противопоставлять вместо того, чтобы признать очевидную подчиненность терминов
Чтобы признать и "очевидную", и "подчиненность", не говоря уже про "очевидную подчиненность", нужно чтобы кто-то доказал это на практике.
И кто бы это мог быть, а?
ЕМ>А можно один раз сделать разумную реализацию макрообработки
Пусть кто-нибудь сделает. А мы посмотрим.
ЕМ>Если такая реализация будет
Ну вот, это уж ближе к реальности: если такая реализация вообще будет.
ЕМ>достаточно удобной и "ортогональной"
а тут еще один "если", т.е. низкие вероятности еще и перемножаются...
S>>И ваши мечтания о том, что легко устранить этот самый водораздел
ЕМ>В той модели, которую отстаиваете Вы, мост через реку должен быть только один, а производство должно быть организовано только так, чтоб все двигалось по мосту лишь в одном направлении.
Вы не поняли ключевое. Я не отстаиваю эту модель. Всего лишь говорю, что пока что приходится наблюдать именно ее.
А если есть какая-то другая, то хорошо бы на нее взглянуть.
Только вот тот, кто говорит про другую модель, показать ничего не может. Посему продолжаем жить с тем, что есть.
