- 1
хде хруст?
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−6
хде хруст?
Превед, говнокод. Чому нет категории для раста?
Компиляция рустни длиной почти в вечность, для них это плюс, а не минус.
Никогда не любил сей сцайт c быдлогомиксами, но тут broken watch argument. И там есть пару удачных находок.
Лучшая иллюстрация к аргументу xkcd.com/303 (оно компилируется целый рабочий день, а мы пинаем хуи).
И большинство форсеров рустни... сами на нёй ничего не пишут, а только трындят какой это заебатый язык.
Распространённый на форумах типаж пиздабола-кукаретика.
А потом мы перешли на котлин, и всё стало намного дольше.
Отличие котлина от любого другого языка программирования в том, что он медленно компилируется, зато потом в рантайме всё тормозит (как всегда в JVM).
Не от любого другого.
Это прям, слово-в-слово описание Свалки.
https://govnokod.ru/27985#comment761061
Впрочем всё-равно сорта йажи.
Хахаха. Да что вы знаете о «долго»?
Йажа компилируется быстрее крестов. А кресты быстрее дrustни.
Компиляция Гiгетох после перехода на ржавчину могла идти ЧАСАМИ.
При том что рустня изначальна имела в основании крайне шустрый Шланг.
И у неё на шее не висело Сишное легаси, с инклюдами и хедерами.
А была возможность с нуля пилить нормальную мудульную систему.
Тем не менее анскилябры умудрились обделаться даже тут.
Они захотели прям на уровне функций инкрементальность, чтобы смотреть на сишников с высока... и обосрались. Походу до сих пор инкрементальные билды крашатся.
зато есть статический полиморфизм (как концепты) ну и динамический тоже есть
Раст это первый хипстерский язык без вонючего ГЦ , а это уже много
* Перформанс почти как у плюсов
* чек лайфтайма и ссылок в компиляции
* бесплатный API с сями
* крэйт для работы с виндоапи в коплекте
* ключ слово unsafe, и пиши уже как тебе угодно (сырые указатели и пр)
* пакетный менеджер и тесты в комплекте
* неймспейсы и модулми
ну да
тебе небось Java больше нравится...
можешь сделать ffi из раста в эйфорию и течь?
В последнее время популярно асинхронное программирование на корутинах. Никто не хочет проблемы 10K. Никто не хочет десять тыщ тредов, которые висят на медленном сетевом I/O.
Но и ебаться с оверлапами, комплишен портами, кику, асинкио и прочими еполами никому не всралося.
Потому Go сделал горутины, в которых блокированные сисколы заменены на асинхронные и макака может даже не думать про это
В расте вместо этого есть крейт токио (типа торнадо в питоне) где вручную написаны асинхронные версии синхронных колов
так себе решение
* никаких зависимостей от внешнего говна
* статическая типизация всего вообще
* дешевая асинхронщина и параллельность (нету гила)
Реально, чем это хуже скриптоговна?
Банальные декораторы, например. Метаклассы.
Хуёвые дженерики.
Вместо простых и удобных (особенно в контексте скриптушни) классов — какая-то лютая поебень со «структурами», «типами», «интерфейсами», «методами»… Нахуя это всё?
просто не в рантайме навеное
И да, часть из этого можно сделать простым декоратором (которых в «Го» тоже нет, да), но не всё.
(это постирония конечно же, я не против волшебства, иначе не любил бы руби)
это вообще сразу сжечь нахуй
если я в коде проверяю, является ли А наследником Б - А не должен иметь возможности подмухлевать
ХХ:ХХ "Вызов метода pitux с аргументами yayco, gnezdo"
XX:XX "Метод pitux вернул vasilisk"
XX:XX "Доступ к несуществующему полю foo"
Вот ему нужно передавать проверки isinstance классу, который он хранит, потому что он иначе этот класс нигде не будет работать нормально.
А если ты не хочешь ещё и наследоваться от класса, то модифицировать запросы к isinstance придётся.
Держи класс:
Тебе придётся модифицировать запросы к isinstance, чтобы этот код работал:
держу, это классический декоратор, почему в питоне с ним должны быть проблемы там, где в других языках их нет?
И даже в статике всё проверяется!
> питон
https://i.kym-cdn.com/entries/icons/facebook/000/030/710/dd0.jpg
А это просто множественное наследование (хотя и называется оно там миксинами)
Это тоже можно сделать (по сути простой манкипатчинг), да.
> А это просто множественное наследование (хотя и называется оно там миксинами)
Не совсем. Тут вся фишка в том, что классы-потребители миксина не обязаны наследоваться от Action (это вообще протокол), да и сам Action нужен только для статических проверок. Миксин же позволяет добавить в класс какую-то общую функциональность, основывающуюся на фиксированном наборе (возможно, нулевого размера) атрибутов. По сути миксин — это анти-интерфейс: миксин тоже нельзя инстанциировать напрямую, он тоже требует от класса-потомка реализации каких-то методов, но при этом интерфейс содержит только абстрактные методы, а миксин — только реализации.
он показал мне задачу, которая является де-факто декоратором. это не мои паттерны, это его паттерн
> оторая примитивно и обобщённо решается переопределением isinstance в три строки.
которая решается без переопределения вообще в одну: hasattr(x, 'speak') или, если очень нужно, callable(getattr(x, 'speak', None))
но даже если бы она давала бенефит, сама по себе простота не может являться причиной тащить хуйню в язык
Ну понятно: лучше написать ещё триста тысяч классов, чем решить задачу просто и понятно. Зарплата за количество строк сама себя не нафармит!
Thinking With JAWA.
> которая решается без переопределения вообще в одну: hasattr(x, 'speak') или, если очень нужно, callable(getattr(x, 'speak', None))
1. А вот в его случае надо проверять на честный isinstance(). Например, либа требует Foo, а ей надо передать Foo в обёртке.
2. Нахрюк на протоколы сам по себе нелепый: двадцать нужных методов ручками проверять будешь? А если в каждом надо ещё аргументы проверить — вооружишься inspect и пошло-поехало?
> но даже если бы она давала бенефит, сама по себе простота не может являться причиной тащить хуйню в язык
Для скриптушни это не хуйня, это полезная фича.
погоди-погоди: классы-протоколы пишешь ты, я предлагаю дактайпинг
Для прояснения задачи:
Есть внешнаяя либа A, в которой определены:
1. Класс Foo;
2. Функции для его получения get_foo (пример из реальной жизни — либа requests, класс Response и функция requests.get(url, ...));
3. Функции, которые принимают Foo и проверяют isinstance(), например:
Есть класс AccessLogger, который оборачивает объект и логгирует доступ к его полям.
Задача: передать в функцию A.do_govno объект Foo, обёрнутый в AccessLogger:
Как ты собираешься её решать?
Я предлагаю тот вот AccessLogger выше, который является декоратором и и ничем иным, проверять на соответствие нужному не по номинативной линии, а по структурной
> Есть внешнаяя либа A, в которой определены:
Здесь проблема ровно в том, что сидеть надо либо на номинативном, либо на структурном стуле, и припарки "я не тот класс, я этот" в целом от этого не спасут. Решается это в зависимости от контекста либо выдачей пиздюлей автору библиотеки, которая принимает конкретную имплементацию, а не контракт, либо вопросом а нахуя вам вообще логировать что она внутри делает с объектом, который ровно так же идет из третьей библиотеки requests?
В точности для этого и нужны манипуляции с isinstance(), да.
> сидеть надо либо на номинативном, либо на структурном стуле
Кто это сказал?
> и припарки "я не тот класс, я этот" в целом от этого не спасут
Всё прекрасно работает. Я уже приводил в начале обсуждения пример протоколов, которые используют «трюки» с isintance/issubclass для обеспечения работы коллекций.
Благодаря тому, что Гнидо думал вне коробки (ДЖАВЫ), в «Питоне» список одновременно является Iterable, Sized, Sequence, Collections (https://docs.python.org/3/library/collections.abc.html) — и при этом не отнаследован от миллиарда интерфейсов.
Ну и да, вводить отдельный оператор для проверки сабтайпинга, и отдельный — для дактайпинга — это говнище. Текущая обобщённая реализация прекрасно работает, и в дополнение к этому позволяет делать дополнительные приятные вещи, вроде AccessLogger'а.
> Решается это в зависимости от контекста либо выдачей пиздюлей автору библиотеки
Понятно.
> либо вопросом а нахуя вам вообще логировать что она внутри делает с объектом
Ясно.
Итог — задача не решена, бизнес стоит, убытки идут, зато ПАТТЕРНЫ не осквернили.
Да, это сработало бы, если бы либа позволяла передавать в себя стратегию сборки Foo.
> намонкипатчить
Не вижу, чем манкипатчинг превосходит переопределение поведения isinstance().
> протоколы-интерфейсы
Протоколы — это одно из следствий исходной возможности переопределения поведения isinstance(), от которого ты триггернулся. В задаче и её решении я их не применяю.
нее, лучше кое-что другое сделать
угадаешь?
--Джавист-джавист, а как ты логируешь вызовы методов?
--Вручную пишу "log" в начале каждого метода
--Джавист-джавист, а ты слышал про AOP?
--AOP ГОВНО ЕГО НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ
--Но почему?
--ПОТОМУ ЧТО AOP ГОВНО ЕГО НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ
--Но почему?
--ПОТОМУ ЧТО AOP ГОВНО ЕГО НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ
--Но почему?
....
--Джавист-джавист, видал в питоне декораторы?
--Да, прикольно, нам в джаве конечно такого не хватает
Дано:
Теперь мы совершенно бесплатно получаем:
И нам не надо наследоваться от миллиарда интерфейсов (особенно актуально для библиотечных коллекций), не надо никаких «паттернов»: всё просто работает искаропки за счёт переопределения проверки наследования внутри протокола.
В теории ему ничего не мешает выполнять и любые другие переопределённые isintance, как на практике — не знаю.
Во-вторых, рациональные аргументы никому не интересны
https://www.youtube.com/watch?v=QJ7LtnlOobQ
тут есть кое-что и про петухов