заржавелли
Mar. 21st, 2026 12:34 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123Страдаю с программой на Рже с помошью двух эяев (один сам программу ковыряет, у другого я спрашиваю вопросы для ручных изменений). Я должен сказать, что их правила констанстности - это просто п.здец, без эяя за ними вручную усмотреть невозможно - постоянно какая-то херня ломается. Эяй - и тот иногда попадает только с третьей-четвертой-пятой попытки, и при этом иногда пытается нахерачить какие-то совсем ужасные изменения, от которых его приходится отговаривать вручную.
Более того, у них нельзя иметь несколько ссылок типа shared_ptr (Rc или Arc) на один и тот же объект, и при этом вызывать на нем неконстантные методы с внутренней синхронизацией. Нет, надо чтобы или была ровно одна ссылка, или мутексом синхронизировать вообще доступ к объекту. Вкладывание мутекса в Arc при этом портит свойства автоматического сравнения и их надо вручную заворачивать.
Ну, то есть, на самом деле по-нормальному делать можно, но только в режиме unsafe. Нет, ну я знаю, что на нем в безопасном режиме нельзя даже классические списки делать. Но чтоб запрещать доступ с нескольких ссылок - это вообще-вообще.
Между прочим, превращение Option<i32> в Option<i64> делается хитрым паттерном x.map(|v| v as i64), простого конструктора для этого недостаточно.
Невероятно дебильный, многословный, и уродливый язык. Хотя до джавной кривизны, может, и не совсем дотягивает. А может и дотягивает.
P.S. Я вот тут еще подумал, и на самом деле их критерий для Arc - не только утомительный, но и неправильный. Правильным критерием должно быть что во время доступа к объекту по ссылке эта ссылка не исчезнет.
Более того, у них нельзя иметь несколько ссылок типа shared_ptr (Rc или Arc) на один и тот же объект, и при этом вызывать на нем неконстантные методы с внутренней синхронизацией. Нет, надо чтобы или была ровно одна ссылка, или мутексом синхронизировать вообще доступ к объекту. Вкладывание мутекса в Arc при этом портит свойства автоматического сравнения и их надо вручную заворачивать.
Ну, то есть, на самом деле по-нормальному делать можно, но только в режиме unsafe. Нет, ну я знаю, что на нем в безопасном режиме нельзя даже классические списки делать. Но чтоб запрещать доступ с нескольких ссылок - это вообще-вообще.
Между прочим, превращение Option<i32> в Option<i64> делается хитрым паттерном x.map(|v| v as i64), простого конструктора для этого недостаточно.
Невероятно дебильный, многословный, и уродливый язык. Хотя до джавной кривизны, может, и не совсем дотягивает. А может и дотягивает.
P.S. Я вот тут еще подумал, и на самом деле их критерий для Arc - не только утомительный, но и неправильный. Правильным критерием должно быть что во время доступа к объекту по ссылке эта ссылка не исчезнет.
no subject
Date: 2026-03-21 12:27 pm (UTC)Любой иностранный язык уродлив. Кривизну родного языка мы просто не замечаем.
Ограничения на количество ссылок следуют из принятой идеологии (move semantics и способа управления памятью). Местами громоздко, зато предотвращает появление целого класса багов, которые легко сделать и трудно найти.
Например, у меня в сиплюсплюсном коде был перевод uint64 в байты через union с комментарием, что это неявно зависит от endianess и по-хорошему надо бы переделать. При переводе на ржавчину Клод расписал явно перевод по байтам, потому что иначе никак. Строк кода стало больше, потенциальный баг исчез. Причём такой баг, который сложно найти (у меня, например, нет под рукой big endian процессора).
no subject
Date: 2026-03-21 05:21 pm (UTC)Ну, а в деталях у меня наверное такие претензии:
1. Ненавижу comprehensions и итерацию через подобие пайплайнов, они для меня всегда были сложны для чтения и выглядят раком. Это тот случай, когда краткость за счет понятности. (Тут, возможно, проблема в том, что конкретный код был написан эяем, который любит такой стиль).
2. Вот те самые правила безопасного доступа, за которыми невозможно уследить вручную. Но тут, возможно, надо просто использовать больше unsafe :-)
3. Хорошо, когда в языке есть избыточность, например в Перле можно выразить одно и то же несколькими разными способами. Плохо, когда в языке есть много разных способов, каждый из которых надо использовать в ОТДЕЛЬНОЙ СПЕЦИАЛЬНОЙ СИТУАЦИИ. Я такое неспособен запомнить. Та же проблема имеется в новых стандартах C++, где они придумывают специальную функцию для каждой мелкой хери, но к счастью в C++ эти выдумки пока можно игнорировать. Да-да, обобщительность, но в реальности она практически везде ни в хер не нужна. Такое можно писать только с эяем.
> При переводе на ржавчину Клод расписал явно перевод по байтам, потому что иначе никак
Кстати, это реальное с одной стороны достоинство, с другой стороны проблема: эяй не ленится расписывать вещи, которые вручную каждый раз делать просто лень и утомительно. Почему достоинство - понятно, но проблема - в том, что плодится огромное количество кода, которое делается сложно понимать. Если человека эта ситуация подталкивает на обобщение, абстракцию вынесение общей функциональности в библиотеки и т.д. (с другой стороны, см. ситуацию с отдельной функцией для каждой мелкой хери, но тут нормального человека (а не стандартизатора C++) остановит другая лень), то работящий эяй просто пишет и пишет тонны кода, которые по месту чуть отличаются в деталях.
no subject
Date: 2026-03-21 06:35 pm (UTC)Как откровение воспринимается, когда в первый раз. Если взять два похожих языка, например, Java и C#, и сначала изучать Java, то будет откровение, а потом C# — нуичё, ничего интересного, те же яйца вид сбоку. А если сначала C#, то наоборот.
Мне вот Перл был неинтересен, потому что встретился поздно. Ну язык и язык, регулярные выражения были знакомы по grep-у, интерпретатор из Бейсика, работа с плоскими файлами из связки bash/awk, синтаксис кривоват по сравнению со взрослыми языками. Особенно после написания самодельного корявого языка на lex+yacc.
no subject
Date: 2026-03-22 07:36 am (UTC)В Перле не только регулярные выражения. Он меня как раз впечатлил после awk, в котором тоже регулярные выражения. А вот как раз и синтаксисом. И потом 5-й Перл с его структурами данных - опять откровение. Старый C++ сам по себе был для меня невпечатляющим, откровением он для меня стал с добавлением темплейтов и STL - как Си и Перл в одном флаконе, и компилируемый!
no subject
Date: 2026-03-21 05:24 pm (UTC)no subject
Date: 2026-03-21 06:38 pm (UTC)Правильный критерий - время работы программы целиком. А то можно наоптимизировать скрепку. В моих тестах по этому критерию ржавчина уже догнала C++, так что моё почтение.
no subject
Date: 2026-03-22 07:31 am (UTC)no subject
Date: 2026-03-22 01:56 pm (UTC)Мне всегда казалось, что слухи про то, что на Фортране получается оптимизировать лучше, чем на C/C++, мягко говоря, преувеличены. То есть враньё. Когда-то давно фортрановская математическая библиотека была лучше и компиляторы C/C++ не умели векторизацию делать, но это ж когда было.
А теперь появилась возможность легко проверить. Сейчас попрошу Клода перевести программу, ранее использованную для сравнения C++ и ржавчины, на Fortran и сравню. О результатах доложу.
no subject
Date: 2026-03-22 01:54 am (UTC)no subject
Date: 2026-03-22 07:29 am (UTC)Го - не 30-летней давности, а примерно 15-летней, но представляет себой отрыжку прошлого, вообще 1980-х годов. Ну, не принял Роб Пайк объектно-ориентированного программирования, и вместо того попытался все сделать по-другому.