post-tree

[amarao]

Интернеты говорят, что во-первых Rc<RefCell> не идиоматично для Rust (деревья правильно держать как банальные вектора, содержащие в себе вектора векторов). Во-вторых, я, в целом, всё правильно сделал.

После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от Enum и бального true/false хватит?

Да, получилось.

fn mktree(source: &[Option<i32>]) -> Tree {

if source.is_empty() || source[0].is_none() {

return None;

}

let tree: Tree = new_tree(source[0].unwrap());

let mut buff = VecDeque::new();

buff.push_back((tree.as_ref().cloned(), false));

for val in source[1..].into_iter() {

let subtree = val.and_then(|val| {

let subtree = new_tree(val);

buff.push_back((subtree.as_ref().cloned(), false));

subtree

});

let (node, is_last) = buff.pop_front().unwrap();

if is_last {

node.unwrap().borrow_mut().right = subtree;

} else {

node.as_ref().unwrap().borrow_mut().left = subtree;

buff.push_front((node.as_ref().cloned(), true));

}

}

tree

}

Что меня смущает? Изобилие as_ref().cloned(). Ща буду думать...

Comments

[paserbyp]

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

[amarao]

Чего? Ты просто хочешь обесценить? Начни с чего-то более почтенного. PL/I?

[paserbyp]

Нет я не хочу обесценить ничего. Кстати, PL/1 - это был тупик развития и это сразу всем стало ясно. Поэтому и решили, что лучше попытаться улучшить ассемблер и тогда возник С, который до сих пор жив и никак не помрет, а ведь давно пора.

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

[amarao]

Я не "всю жизнь учу язык". У меня язык программирования, за который мне деньги платят, это jinja. С примесью питона, и всё завёрнуто я ямл (который параметризируют jinj'ой). И чем дальше я со всем этим вожусь, тем меньше мне он нравится, хоть мне и платят всё больше за это.

Rust - для души. Я им занимаюсь в свободное от работы время (а времени у меня мало). Это невероятная дисциплина ума. В том незначительном объёме, в котором я его использовал для практических задач, я задачи решал, но у меня очень много времени уходило на доучивание кусков, которые я к тому моменту ещё не знал хорошо. Будет с этого практический выхлоп или нет, я не знаю, но язык мне интересен сам по себе, в отрыве от работы.

[paserbyp]

Правильно и тут главный критерий - это за что платят деньги! А платят как раз за С++ или за смесь ежа с гадюкой - питона с ямлом…

Будут ли платить за раст? Конечно будут, пока не напишут другой бред сивой кобылы, за который заплатят больше!

Что касается души, то не продавайте ее дьяволу за бесценок!

[amarao]

Пока что я свою карьеру всегда поворачивал в сторону интересного, а потом оказывалось, что за это больше платят. Если бы я слушался людей и делал то, что нужно бизнесу здесь-и-сейчас, то я сначала бы выучил 1С и был бы гуру виндовых серверов с видеонаблюдением, ip-телефонии и бы мастером chef'а. Но всё это мне не понравилось и я его скипнул. Так же как скипнул "некрасивый" перл с powershell и ровно так же как сейчас меня не особо вдохновляет тераформ.

[paserbyp]

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

[amarao]

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

[ufm]

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

Ты немного заблуждаешься. Платят тебе больше из-за того, что тебе интересно. Я в том смысле - что ты всё делаешь правильно. :)

[amarao]

Ну, я понимаю, что это становится конкурентным преимуществом, но я в целом, смотрю на индустрию - масса тоскливых тенхологий просто не взлетела или умерла. Тот же шеф, от него пахло дурным инжинирингом. Как только я увидел из chef-sdk, 600Мб deb-файл с несколькими завенодоренными копиями erlang'а, мне стало настолько неприятно, что я его скипнул, хотя и были объективные причины учить. Итог - progressive.

Вот сейчас мне так же неприятно от того, куда катится вся это ямло-кодла.

[straktor]

> Точки,
> многоточия,
> двоеточие,
> точка с запятой,
> скобки трёх видов,

это всё есть даже не в С++, а в Си
кстати {} скобки в паскале тоже приняли

> подчеркивание

из Пролога
в C/C++ принято как соглашение во многих код стайлах

> все это говорит о том, что в голове тех кто создавал этот язык - хаос и дурдом ромашка

мнение игнорамуса

[paserbyp]

Я не ищу оправданий в ассемблере и в С, что там делается, мне понятно, когда имеешь дело с регистрами и драйверами для поддержки железа. Но зачем эту фигню тащить в языки высокого уровня. Посмотрите,что произошло с С++? Это настолько мощный язык, что когда ты в С стреляешь себе в ногу, то в С++ тебе отрывает всю ногу да еще и кусок жопы! Поэтому кстати и создали Java, которая более защищенная версия С++, но избавиться от влияния ассемблера и С ну никак не удается!

Что касается тех кто создавал языки для машин фон Неймана, то у них в головах не то, что хаос, а просто обычная импотенция из-за бессилия и тупика куда их загнала архитектура фон Неймана, которой скоро уже исполнится 100 лет и ее давно пора выкинуть на свалку истории, но смогут это сделать нейросети и ИИ? Нам осталось подождать еще совсем немного!

[amarao]

Насчёт "выкинуть на свалку"... Кто-то показал, что нейросети тьюринг-полные? Мне кажется, строго наоборот. Я с трудом себе могу представить зависшую нейросеть, а это означает, что какой-то класс алгоритмов не реализуем на нейросети, что в свою очередь означает, что она не тьюринг-полная.

Алсо, я видел как выглядит "профессиональное" описание картинки для StableDiffusion, и у меня нет ощущения, что получившийся мунспик сильно отличается от лиспа. Особенно, с учётом количества скобочек.

[paserbyp]

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

[amarao]

Тест Тьюринга или показать полноту по Тьюрингу? Так сказать, крайне различные вещи.

[paserbyp]

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

[amarao]

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

[eterevsky]

Рекуррентные нейросети стопудово тьюринг-полные.

[amarao]

Почитал, да. while могут.

[eterevsky]

> Но зачем эту фигню тащить в языки высокого уровня.

Чтобы одновременно выполнить следующие условия:

1. Эффективность: дать возможность писать realtime код, без overhead'а в виде GC и прочего рантайма.

2. Достаточно гибкие абстракции, в частности какой-то вариант generics.

3. Возможность писать относительно безопасный код, хотя бы если следовать определённым правилам.

4. Возможность работать с большим объёмом кода, на уровне сотен тысяч и миллионов строк.

Rust и C++ -- единственные языки, которые удовлетворяют всем этим условиям одновременно.

[paserbyp]

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

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

В далекой юности я столкнулся с языком IPL https://en.wikipedia.org/wiki/Information_Processing_Language и это было подобно взрыву атомной бомбы. На этом языке достаточно было написать несколько команд в одной строке кода и это заменяло тысячи строк ассемблера и сотни строк FORTRAN, ALGOL или PL/1.

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

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

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

[eterevsky]

> как-то гибкость абстракций(как ее измерить?)

В возможности имплементировать generic алгоритмы и контейнеры без runtime оверхэда.

> безопасность кода в С++

С++ относительно безопасен если использовать его идеоматически, с RAII и референсами. Гораздо безопаснее C.

Я не очень понял к чему был разговор про IPL. На C++, также как и скажем на Java, есть много проектов с сотнями тысяч и миллионами строк, и с ними вполне возможно работать, хоть с микросервисами, хоть без.

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

[paserbyp]

…контейнеры с алгоритмами и безопасный идиоматический С++, который настолько безопасный, что непонятно для чего написали Java и Scala?

…сначала надо ответить себе на вопрос зачем было создано структурное программирование, ООП и функциональное программирование, которое закончилось возникновением архитектуры микро сервисов? Когда ответите, тогда и поговорим… кстати, переписать монолитное приложение на микро сервисы, занимает годы и годы! Ну это так к слову…

Когда научат ИИ генерировать и главное сопровождать миллиарды строк кода, все программисты окажутся на улице, как и водители автомобилей и это случиться очень скоро! Ждем-с…

[eterevsky]

У Java и Scala другие trade off'ы. И C++ 90х, на фоне которых создавалась Java был совсем другой.

> …сначала надо ответить себе на вопрос зачем было создано структурное программирование ...

Я хорошо знаю все слова, которые вы пишете, но не вижу в чём ваш пойнт.

[eterevsky]

Чуть подробнее почему Java не подходит: в ней нет настоящих generic'ов, и всё везде хранится по указателям. Дженерики есть на уровне языка, но они не компилируются в специализации и работают поверх объектов. Это означает что в джаве невозможно писать эффективный низкоуровневый код с дженериками, в отличие от C++ и Rust.