amarao | post-tree

Интернеты говорят, что во-первых 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(). Ща буду думать...

Flat | Top-Level Comments Only

From:

straktor

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

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

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

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

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

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

From:

paserbyp

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

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

Edited Date: 2022-12-24 07:20 pm (UTC)

From:

amarao

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

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

From:

paserbyp

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

Edited Date: 2022-12-24 08:18 pm (UTC)

From:

amarao

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

From:

paserbyp

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

Edited Date: 2022-12-24 08:23 pm (UTC)

From:

amarao

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

From:

paserbyp

Аналоговые компьютеры? Ты на них сегодня деньги заработаешь? А завтра? Так что засунь свою машину Тьюринга, сам знаешь куда…

From:

eterevsky

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

From:

amarao

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

From:

eterevsky

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

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

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

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

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

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

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

From:

paserbyp

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

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

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

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

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

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

From:

eterevsky

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

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

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

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

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

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

From:

paserbyp

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

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

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

Edited Date: 2022-12-25 06:59 pm (UTC)

From:

eterevsky

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

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

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

From:

paserbyp

Это потому что оно вам не надо. Для вас главное - это быть востребованным на рынке труда и зарабатывать побольше денег, а то о чем я говорю вам не интересно, так как не приносит никакой прибыли…

From:

eterevsky

Да не, мне интересно. Почти все языки и технологии, благодаря которым я сейчас "востребован на рынке труда" я учил потому что мне было интересно.

Но вы просто почти ничего не говорите по существу.

From:

paserbyp

Просто по существу не говорят.

Что касается рынка труда, то он очень сильно меняется в этой сфере и вся суть этих изменений направлена на увеличение производительности труда, которая приводит к автоматизации и замене ручного труда. Вот и все, что я хотел вам сказать по существу.

From:

eterevsky

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

Edited Date: 2022-12-25 07:08 pm (UTC)

From:

paserbyp

У вас, например, на курсе 100 студентов пишут курсовую работу на Java. Если бы они писали бы ее на C++, то пришлось бы перегружать университетский компьютер каждые 10 минут, а так если упадет одна из 100 JVM, то перезапустить ее как два байта переслать. Еще вопросы будут?

From:

eterevsky

Да, будут. Что вы курите?

И когда вам в последний раз случалось перезагружать компьютер из-за упавшего процесса в юзерспейсе?

From:

paserbyp

Я бросил курить давно, а процесс не падает в юзерспайсе а убивает всех вокруг своего юзерспейса. На С++ такое сделать не возможно?

From:

eterevsky

Самое страшное что может случиться с C++ процессом это segfault, при котором процесс просто убивается.

В случае JVM даже этого не случается. Сам процесс JVM не должен падать, и критическая ошибка -- это просто exception который останавливает работу приложения.

С точки зрения пользователя разницы большой нет. С точки зрения программиста Java защищает от нескольких типов ошибок ценой потери производительности и эффективности использования памяти. Rust совмещает одно с другим.

Edited Date: 2022-12-25 08:37 pm (UTC)

From:

paserbyp

Я неуверен, что вы хорошо знаете о том о чем говорите, особенно о самом страшном, что может случиться с С++. Ну да Бог с вами...

Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++, то я в этом я очень глубоко сомневаюсь и тем более по поводу вашего "смелого" утверждения о "эффективности" использования памяти!

Edited Date: 2022-12-25 08:46 pm (UTC)