Что происходит с популярностью Go?

Был синтетический пример с LinkedList, но тебе как раз ставили клизму и поэтому ты этот пример упустил.

Примеров кода не было. Тем более примеров кода на двух языках демонстрирующих подобное сравнение.

И как это связано с отсутствием шаблонов в ява 1 ?

Напрямую.

Как именно?

Меня удивляет тупость людей, которые упускают из вида

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

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

typedef struct {
    char Name[50];
} User;

Толи дело с таким…

Разговор был об определении.

Меня удивляет тупость людей, которые упускают из вида, что в форумных срачах все ходы записаны.

Был вопрос «что предлагал пользователю первый Go, если пользователь хотел реализовать свой разреженный вектор?»

На что вы спросили «Вы говорите про массив, большинство элементов которого равны ноль-значениям?»

А я вам ответил, что нет, речь идет о векторе, в котором отсутствующих значений нет. Физически.

Т.е. я вам сразу сказал что мне нужно. Тут не было никакого спора об определениях.

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

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

Вы уточнили общее определение подробностями нужной вам реализации.

Всё ещё не споря с вами я сказал, что map тоже не обязан хранить ноль-значения и тут ваши медикаменты не сработали.

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

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

Это хз что.

Значительная часть того, что вы говорите - это хз что.

Таки да.

Таки лечиться вам надо.

Будет, потому что это часть подмножества Си, поддерживаемая в C++. Но от этого данная конструкция не становится C++ной. Она как была Си-шной, так и осталась.

Вы ещё и теорию множеств не изучали? Всё подмножество C языка C++ входит в язык C++ и каждый элемент подмножество C языка C++ принадлежит множеству языка C++.

Если эта конструкция позволяет мне заменить int a[10] на std::array<int, 10> a и избавиться от кучи унаследованных из Си проблем, то вполне себе заменяет.

Вас послушать, так и в Java нет массивов, а есть лишь ArrayList. std::array<int, 10> - всего лишь альтернатива массиву и самим массивом не является. Это контейнер, а не массив. Называть это массивом лишь потому, что там мелькает слово array могут лишь альтернативно одарённые.

Вы еще говорили, что Пайка взяли в Google чтобы он делал Go. А еще спутали проблемы с Rust-ом Cloudflare с проблемами CrowdStrike. Т.е. у вас каша в голове и путаница в показаниях.

Это у вас каша в голове, потому что вы путаете принципиальные в данной беседе вещи с несущественными оговорками.

Ну уж извините, в сортах Go-шного говна мне разбираться незачем. А вот факт того, что Go-шники много лет жрали sort.Ints, sort.Strings и пр., да еще и говорили «не надо нам усложнять язык дженериками» очень показателен.

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

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

Где у авторов Go сказано, что они его делали якобы для идиотов? Вас в детстве не научили, что врать не хорошо, а тупить плохо?

Был синтетический пример с LinkedList, но тебе как раз ставили клизму и поэтому ты этот пример упустил.

Примеров кода не было. Тем более примеров кода на двух языках демонстрирующих подобное сравнение.

Требования к коду описаны словами. В Java такой код невозможен. В Go такой код тривиален. Кстати, как там клизма, помогла?

Требования к коду описаны словами.

А теперь смотрим на то, что писал я:

если бы были примеры кода

Примеры кода были? Нет, вы это только что сами признали.

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

Вы уточнили общее определение подробностями нужной вам реализации.

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

Так вот еще раз вам повторю, что для определения понятия разреженный вектор совершенно неважна его реализация.

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

Всё подмножество C языка C++ входит в язык C++ и каждый элемент подмножество C языка C++ принадлежит множеству языка C++.

Из этого не следует, что к C++у нужно предъявлять претензии по поводу того, что C++ унаследовал из Си. Вы доколупались к Си-шным массивам. Вот у авторов Си про них и спрашивайте.

std::array<int, 10> - всего лишь альтернатива массиву и самим массивом не является. Это контейнер, а не массив.

Ну это же в корне меняет дело. Не массив, а контейнер. Ну OK. Дальше что? Я лишился возможности использовать std::array вместо Си-шного массива?

Это у вас каша в голове

Фактические ошибки совершаете вы, а каша у меня? Ну бывает, чё.

Вашему C++ говну до Go как до Луны раком.

Сейчас бы цитату где бы я что-то говорил про превосходство C++ над Go.

Вот то, что в Go нет средств защиты от data races, тогда как в Rust есть – это было. По этому критерию для меня Rust лучше Go. Но вот C++ с Go я здесь не сравнивал вообще.

Где у авторов Go сказано, что они его делали якобы для идиотов?

Ну давайте еще раз поднимем цитаты, это не сложно.

Мои слова:

Если вспомнить, что его авторы писали в 2009-2010-х годах, то Go появился прежде всего потому, что в Google было большое количество обычных людей, для которых даже Java (не говоря уже про C++) была слишкамсложна.

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

В них термин «идиот» даже не применяется.

А вот цитата от одного из авторов Go, любезно предоставленная тов.kaldeon:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

И вот что интересно (нет на самом деле, а вполне ожидаемо): я свои слова цитатами подтверждаю. Тогда как вы делаете какие-то голословные выпады и сливаетесь когда вас просят привести хоть какие-то пруфы. Например, вот здесь я просил:

В интернете пишут, что Go начали делать в 2007-ом. Первая версия доступная для широкой публики, появилась в 2009-ом (по крайней мере я об этом языке тогда узнал). Релиз Go 1.0 состоялся в 2012-ом.

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

Требования к коду описаны словами.

А теперь смотрим на то, что писал я:

если бы были примеры кода

Примеры кода были? Нет, вы это только что сами признали.

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

Примеры какого кода вы хотите получить?

Любого, лишь бы они позволяли трактовать слова собеседника однозначно.

Тут местную публику от map/filter/reduce десятилетиями ломало

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

Как бы все ходы записаны

Вы уже говорили, не повторяйтесь. В вашей истории болезни тоже всё записано.

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

Абсолютно плевать что вам нужно. Я у вас уточнял именно определение.

Из этого не следует, что к C++у нужно предъявлять претензии по поводу того, что C++ унаследовал из Си. Вы доколупались к Си-шным массивам. Вот у авторов Си про них и спрашивайте.

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

Ну это же в корне меняет дело. Не массив, а контейнер. Ну OK. Дальше что? Я лишился возможности использовать std::array вместо Си-шного массива?

Вы просто снова протупили в разговоре, где речь шла именно о массивах.

Фактические ошибки совершаете вы, а каша у меня? Ну бывает, чё.

Ну вот буквально пару строк выше как раз таки ваша каша из массивов и контейнеров в одном флаконе.

Сейчас бы цитату где бы я что-то говорил про превосходство C++ над Go.

О шаблонах вы уже забыли, санитары снова по голове ударили?

Ну давайте еще раз поднимем цитаты, это не сложно.

Вот вам цитата: у Go репутация языка «для дебилов»

Будте конкретнее, объясните что вам тут не нравится.

Все шиворот-навыворот. Тип поля за именем стоит, но без разделителя.

Действительно, спасибо за замечание. Следует поправить моё утверждение: «Тут местную публику от map/filter/reduce десятилетиями ломало и продолжает ломать».

Что до вопроса вашего, то map/filter/reduce повышает ясность кода, путём явного выделения разных этапов обработки данных, и даёт выход на трандьюсеры, которые ускоряют работу путём удаления лишних преобразований, неявный паралелизм и т.п. Таким образом код выглядит понятнее и работает быстрее.

Это конечно дело вкуса. Но мне это не нравится.

Любого, лишь бы они позволяли трактовать слова собеседника однозначно.

Что неоднозначного вы нашли в том, что я описал словами?

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

Ну да, Томпсон не смог удержаться шоб доисторическую сишечку в гошечку не добавить..

Понятно зачем это нужно в функциональном ЯП, там по-другому никак.

Вообще-то это всё в лиспе изначально появилось. Наряду с циклами по счётчику.

А когда это в скриптуху тянут,

Все хотят повысить выразительность. Чего скиптам мимо проходить?

перл сложный

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

Не опечятка. Но твоя реакция позабавила.

Абсолютно плевать что вам нужно.

Кому плевать, вам? Да пофиг на вас. Вопрос был в том, какие возможности давали первые версии Go для реализации разреженного вектора.

Был пример чего-то, реализованого на уровне языка, а не стандартной библиотеки, так же как map в Go реализован именно на уровне языка.

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

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

Только вот решение Страуструпа паразитировать на хорошей совместимости с Си с течением времени выглядит оправданным. Не смотря на все его недостатки.

В том числе и потому, что C++ дает возможности средствами языка делать замену тому, что не нравится.

Вот в С++ можно сделать свой std::array. Или std::map.

А в Go можно сделать свой map, который бы выглядел точно так же, как стандартный? А канал? А свою конструкцию select?

Вы просто снова протупили в разговоре, где речь шла именно о массивах.

Вы на вопрос ответьте: имеющаяся в вашей голове разница между «массивом» и «контейнером» как-то мешает мне в C++ном коде использовать std::array вместо Си-шного массива?

Да или нет?

О шаблонах вы уже забыли, санитары снова по голове ударили?

О каких таких шаблонах? Давайте точную цитату, а то с вашей неспособностью в пруфы веры вам нет.

Вот вам цитата: у Go репутация языка «для дебилов»

Из того, что сейчас у Go репутация языка для дебилов (благодаря вашей помощи) вовсе не следует, что Go делали как язык для идиотов. А ведь именно такое утверждение вы мне пытались приписать.

Это же ваш вопрос:

Где у авторов Go сказано, что они его делали якобы для идиотов?

Из него следует что я что-то подобное говорил. Только вот я не говорил. А вы опять не смогли в пруфы. И опять проигнорировали просьбу предоставить пруфы для еще одного вашего обвинения.

Что неоднозначного вы нашли в том, что я описал словами?

Чуть меньше, чем все:

В Java есть интерфейсы List и Deque. Класс LinkedList реализует оба эти интерфейса и если тебя всегда устраивает эта реализация, ты можешь сделать coupling на неё. Но допустим тебе принесли стороннюю библиотеку с другой реализацией интерфейсов List и Deque в одном классе. Как его инжектить в твой код, то есть как всё таки сделать decoupling? Иными словами как использовать dependency injection с такими классами, сразу реализующими несколько интерфейсов которые тебе нужны одновременно?

Покажите хотя бы на примере кода из Go как это должно выглядеть по вашему.

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

В перле только синтаксис упоротый,

Этого достаточно.

сильно ограничивает творчество

А это иногда — весомый плюс. Вы будете ругаться, мне самому противно, но такова жизнь. Я сам за лисп топлю в этой особой олимпиаде, но измеряя WTF/s для разных языков программирования, питон и Go будут в самом-самом низу шкалы. Когда читаешь чужой код — это ровно то, что нужно.

Все хотят повысить выразительность.

Так с ней и сложность тоже растёт. На императивные абстракции со всяким ООП наслаивается ещё и функциональные паттерны. Голова пухнет же.

Голова пухнет же.

Так я ж с этого и начал «от map/filter/reduce десятилетиями ломало, бо на привычный for(int i = 0; i<n; i++) совсем не похоже».

Кроме того тут уместно упомянуть классическое выступление «Simple Made Easy» - Rich Hickey (2011).

Покажите хотя бы на примере кода из Go как это должно выглядеть по вашему.

Какой же вы глупый зануда:

package main

import "fmt"

type A interface {
	bar()
}

type B interface {
	baz()
}

type C interface {
	A
	B
}

// normally in a 3rd party library that doesn't know interface C
type dumb struct{}

func (a dumb) bar() {
	fmt.Println("bar")
}

func (a dumb) baz() {
	fmt.Println("baz")
}

func main() {
	foo(dumb{})
}

// emulates injection
func foo(c C) {
	c.bar()
	c.baz()
}

Ну и где здесь место для LinkedList, List и Deque?

Можно предположить, что List – это A, а Deque – это B. Проблема в чем?

Ну и где здесь место для LinkedList, List и Deque?

Совсем дурной?

Можно предположить, что List – это A, а Deque – это B. Проблема в чем?

В том, что инжектить и использовать нужно одну стороннюю реализацию двух интерфейсов A и B. В Go можно завести свой общий интерфейс C и инжектить через него. В Java так нельзя, потому что про общий интерфейс сторонняя реализация знать не обязана.

пихали богомерзскую венгерскую нотация в качестве костыля

и тут же рядом у вас sort.Sort - костыль в виде заглавной буквы названия публичной функции…

Те кто пишут C/C++, могут писать даже C/C++/C# - буквы же одинаковые в названиях языка :) Эксперты сразу выставляют уровень знания таких индивидуумов как «ознакомительный»: что-то где-то слышал и мимо проходил.

и тут же рядом у вас sort.Sort - костыль в виде заглавной буквы названия публичной функции…

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

Те кто пишут C/C++, могут писать даже C/C++/C# - буквы же одинаковые в названиях языка :)

Крепко же тебя костылём по затылку огрели. Сочуствую.

Совсем дурной?

Вы даже на простой вопрос ответить не можете?

В Java так нельзя, потому что про общий интерфейс сторонняя реализация знать не обязана.

Почему вы не можете в Java сделать обертку над чужим классом, которая будет реализовывать нужный вам интерфейс и делегировать вызовы в объект чужого типа?

interface A {
    public void bar();
}

interface B {
    public void baz();
}

class ForeignClass implements A {
    public void bar() { System.out.println("ForeignClass.bar()"); }
    public void myBaz() { System.out.println("ForeignClass.myBaz()"); }
}

abstract class MyWrapper implements A, B {
}

class WrapperForForeignClass extends MyWrapper {
    ForeignClass realObj;
    
    WrapperForForeignClass(ForeignClass theRealObj) { realObj = theRealObj; }
    
    public void bar() { realObj.bar(); }
    public void baz() { realObj.myBaz(); }
}

public class Main
{
    static void useBar(A what) { what.bar(); }
    static void useBaz(B what) { what.baz(); }
    static void useBoth(MyWrapper what) {
        what.bar();
        what.baz();
    }
    
	public static void main(String[] args) {
	    var obj = new ForeignClass();
	    var wrapper = new WrapperForForeignClass(obj);
	    
	    useBar(wrapper);
	    useBaz(wrapper);
	    useBoth(wrapper);
	}
}

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

Ну да, ну да. Когда от регистра одного символа меняется смысл – это не костыль, это мегафича.

Я думаю, я понял о каком кейсе рассуждает человек, но наверное надо подождать пока он сам поймёт.

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

Вы правы в общем касательно когнитивной нагрузки. Для Perl, созданном филологом, есть принцип «hot-path» - наиболее популярные действия требуют минимум средств, что даёт ускорение в написании кода. Тут как в русском языке: в целом слова длинные, но если перейти на мат, то получается короче и даже иногда яснее для человека :)

Ну да, ну да. Когда от регистра одного символа меняется смысл – это не костыль, это мегафича.

Обычная фича. Не вижу тут никаких костылей. Удобнее public private protected в Java. Вы ещё назовите правило во многих человеческих языках начинать предложения и имена собсвенные с большой буквы костылём.

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

А можно поподробнее, что бы вы хотели добавить? Не то, чтобы в Питоне часто хотелось бы такое делать, но вообще возможность есть.

Вы даже на простой вопрос ответить не можете?

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

Почему вы не можете в Java сделать обертку над чужим классом, которая будет реализовывать нужный вам интерфейс и делегировать вызовы в объект чужого типа?

Могу даже ещё проще, чем в вашем кривом примере с неверным определением ForeignClass. Обёртка получает экземпляр ForeignClass как Object в конструкторе. Конструктор проверяет реализует ли полученный объект оба интерфейса A и B. Далее конструктор кастит и сохраняет референс на полученный объект в соответствующих полях типов A и B. Затем соответствующие методы этих интерфейсов в самой обёртке дёргают те же самы методы этих двух полей. Вот только это костыль, который нарушает кучу всего и вообще неудобен и небезопасен. А в Go никаких обёрток и приведений типов городить не надо.

Вы с dependency injection в Spring никогда не работали?

Могу даже ещё проще, чем в вашем кривом примере с неверным определением ForeignClass.

Мой пример «кривой» только потому, что вы не можете ни в пруфы, ни в конкретные примеры. Приходится домысливать за вас.

Конструктор проверяет реализует ли полученный объект оба интерфейса A и B. Далее конструктор кастит и сохраняет референс на полученный объект в соответствующих полях типов A и B. Затем соответствующие методы этих интерфейсов в самой обёртке дёргают те же самы методы этих двух полей.

o_O

Вот только это костыль, который нарушает кучу всего и вообще неудобен и небезопасен.

Вот этот весь трах с инспекцией Object-а и двумя полями-ссылками для A и B – это реально костыль. Впрочем, то, что в корпоративной Java у народа давно какой-то культ всякой херни, для меня не новость.

Вы с dependency injection в Spring никогда не работали?

Нет.

Что происходит с популярностью Go?

она упала

Мой пример «кривой» только потому, что вы не можете ни в пруфы, ни в конкретные примеры. Приходится домысливать за вас.

Вы не только глупы, но и русский язык для вас не родной?

o_O

Вам снова ставят клизму? Сочуствую.

Вот этот весь трах с инспекцией Object-а и двумя полями-ссылками для A и B – это реально костыль.

Разумеется. Любая обёртка вокруг ForeignClass implements A, B - это костыль и я сам это сказал.

Впрочем, то, что в корпоративной Java у народа давно какой-то культ всякой херни, для меня не новость.

Ну сделайте инжекшен в некорпоративной джаве.

Нет.

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

Вы не только глупы, но и русский язык для вас не родной?

А вы на русском языке проигнорировали просьбы привести пруфы для ваших заблуждений выше, например, вот здесь? Или это было на каком-то другом языке?

Вы за свои слова ответить не можете.

Любая обёртка вокруг ForeignClass implements A, B

Вообще-то ForeignClass у меня реализует только A, но не B. В этом я и видел ваше условие. Но т.к. в код вы не можете (как и в пруфы), то приходится додумывать о чем вы бредите.

А можно поподробнее, что бы вы хотели добавить?

Можно я? Хочу стрелки a → f() эквиваленто f(a), или в более сложном случае a → f(x) → g(y) превращается в g(f(a,x),y).

А вы на русском языке проигнорировали просьбы…

Аргумент в стила «а у вас негров линчуют». Мы же сейчас не об этом.

Вообще-то ForeignClass у меня реализует только A, но не B. В этом я и видел ваше условие.

Именно поэтому я сильно засомневался, а является ли русский язык родным для вас.

Но т.к. в код вы не можете (как и в пруфы), то приходится додумывать о чем вы бредите.

Вам даже додумывать не нужно было. В моём изначальном примере были интерфейсы List<T> и Deque<T> и их общая реализация LinkedList<T>. Вопрос заключался в том, как инжектить любую реализацию этих интерфейсов в одном классе, а не только LinkedList<T>. Нужно быть олигофреном, чтобы не понять о чём я там говорил. Нужно быть ещё большим олигофреном, чтобы продолжать тупить даже после соотвествующего примера кода на Go.

Определить новый оператор, прямо так - да, нельзя.

ИИшка мне следующее предложила:

funcs = [mul2, to_str, add_ex]
result = reduce(lambda acc, f: f(acc), funcs, 10)

Можно и так:

class Pipe:
    def __init__(self, value):
        self.value = value

    def __or__(self, func):
        return Pipe(func(self.value))

    def get(self):
        return self.value

def mul2(x): return x * 2
def to_str(x): return str(x)
def add_ex(x): return x + "!"

result = (Pipe(10) | mul2 | to_str | add_ex).get()
print(result)  # "20!"

Есть библиотеки fancy и pipe, где что-то подобное уже реализовано. Синтаксис, как по мне, так себе, но пайпы организовать можно.

ПС. И хорошо, что нет именно такой возможности. А то сиди потом, разбирайся, что эта новая закорючка означает.

Определить новый оператор, прямо так - да, нельзя.

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

А то сиди потом, разбирайся, что эта новая закорючка означает.

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

Какие макросы в скриптовом языке? Он выполняет команды одна за одной.

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

Не уверен, что (пере-)определять операторы, всегда хорошая идея. Особенно в Питоне.

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

Какие макросы в скриптовом языке? Он выполняет команды одна за одной.

Настоящие. Т.е. как в лиспе. Т.е. клеить строки и вызвать eval не считается.

можно делать

Все полные по Тьюрингу языки эквиваелентны по Тьюрингу. Толку то? Хочется, чтобы было удобно и быстро.

Хочется, чтобы было удобно и быстро.

У каждого своё понимание быстро и удобно. Мне удобно, когда wtf как можно меньше.

Настоящие. Т.е. как в лиспе.

Я тут подумал. Макросы противоречат дзену питона, а именно: «Явное лучше, чем неявное». Так что в питоне такое не появится. Только если хипстеры разработку интерпретатора захватят. Как по мне, это сделает язык хуже - исчезнет простота и превратится это в хрен-пойми-что.

Всё подмножество C языка C++ входит в язык C++ и каждый элемент подмножество C языка C++ принадлежит множеству языка C++.

Из этого не следует, что к C++у нужно предъявлять претензии по поводу того, что C++ унаследовал из Си.

А сверху ещё можно полирнуть тем, что тезис не верен - не всё подмножество C языка C++ входит в язык C++.