Как стать автором
Обновить

Комментарии 123

Добрый день, а на чем делали сам сайт? Самописный или какой-то движок готовый?

Айтинити, ядро Друпала + обвес, чтобы можно было нормально работать обычным людям и верстальщикам. Давнишняя история.

Спасибо, я уж грешным делом подумал что-то опенсорсное

Опенсорсное, но не раскрученное, если будет интерес, предоставлю исходники.

Как по мне так ужасно не удобно справа листинг глав.

Просто он не сильно важен (внизу есть ссылки на следующую, предыдущую лекции), а если слева, то много на себя внимания берет. Если окно браузера сузить, то меню вообще сложится, чтобы никак не отвлекать от основного текста.

В том и дело, что как раз он и отвлекает. Уже как бы стандарт де-факто о расположение списка страниц слева. Какое бы online мануал не взять. Будь то pdf, документация на API или список классов к какой-нибудь библиотеки. Или даже список файлов в проекте хоть IDE хоть приложения типа CAD.

К списку справа я уже привык, а то, что основной текст прижимается к левому краю экрана, пока привыкнуть не могу)

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

Мой опыт с растом на виндовс: Дальше установки не ушел :)))

1) не было для powershell сертификатов c доступом уровня "секюрити" для успешного окончания установки rust (версия виндовс - энтерпрайз 10)

2) после этого, в конце rust установка падал из за какого то "mvc" от новой "VSC"

на этом плюнул

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

А к нему докер образ не идёт случайно?

  1. C сертификатами ни на Windows 10 Pro ни на 11 Pro проблем не испытывал. А зачем вы вообще powershell пользуетесь для этого? загрузили https://static.rust-lang.org/rustup/dist/i686-pc-windows-gnu/rustup-init.exe и запускаете из обычной командной строки

  2. По хорошему, лучше иметь VS Studio установленным на машине - редакции Community будет вполне достаточно. Наверно можно какой-то отдельный маленький рантайм поставить - но я лично так не пробовал, у меня есть студия (и 2019 и 2022)

Я даже не ставил себе Community версию, там достаточно иметь VS Build Tools. Вообще, у меня нет трудностей ставить тулчейн под Windows, единственное, кто мне палки в колёса вставляет, так это антивирус.

а точно VS Build Tools должно хватить - спасибо за уточнение! А антивирус очень странно - ни виндос Дефендер ни Касперский мне ни разу не мешали, причем последний стоит в достаточно злой конфигурации (рабочий копм)

Это сраный бдительный МакАфи, у него какие-то странные правила, на которые срабатывает переименовывание файлов. Баг репорт не мой, там их парочка таких.

Понял. Спасибо за инфу!

Там на самом деле от студии нужен только линкер. И ничто не мешает вместо тулчейна stable-x86_64-pc-windows-msvc поставить себе stable-x86_64-pc-windows-gnu (stable-gnu для краткости)

Или так, да - согласен

а меня установщик заставил скачивать вижуал студио плюс windows11sdk(не убрал галочку). Короче минус 10 гигов памяти

не понимаю почему люди минусуют за факты. Лучше бы шли на гитхаб и решали проблемы и зависимости с установщиком )

Rust вообще и Rust Book в частности гораздо легче «заходят» если есть опыт программирования на нормальных компилируемых языках со статической типизацией, особенно с C-подобным синтаксисом. Тогда и не будет «случайно проставленных точек с запятыми», и многие куски документации будут просто как напоминалочка, что такое вообще бывает.
Ну как сказать, у меня вот обширный опыт на С++, хелоуворлды на rust с циклами и арифметикой без проблем, но как только попытался что-то более сложное — наследования нет, виртуальных методов нет, вместо коллбеков и каррирования — делай вася агрегирование доп. классов с методами и тд и тп.
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).

Изучать я Rust однозначно буду и дальше. Но больна.
виртуальных методов нет

dyn trait же

наследования нет, виртуальных методов нет

И то и другое есть. Чего нет, так это классов. Вместо этого ООП представленно через трейты. Сходство только внешнее.

Как раз-таки классы есть (структуры их успешно заменяют), как и интерфейсы (трейты). Нету именно наследования классов.

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

Начал читать, имея только шапочное знакомство с Rust - глаза зацепились за фрагмент в "Плюсы Rust", "... и без сборщика мусора" (как будто это что-то хорошее :) ). Тут вероятно было бы уместно упомнятуть "строгий контроль использования памяти, не опирающийся на сборщик мусора". В C++ нет сборщика мусора (кстати, часть языка, позволявшая интеграцию сборщика мусора, существовала некоторое время в стандарте - убрали), но нет и строго контроля, легко выстрелить в ногу. В D есть строгий контороль, но есть и сборщик мусора. В дизайне Rust сознательно отказались от сборщика мусора, что имеет далекоидущие последствия из-за более сложных мер по обеспечению строгого контроля.

Спасибо за информацию. Про сборщик мусора, предположу, что идут параллели с Go.

В го, как раз таки, сборщик есть и все присущие ему проблемы - тоже. Но есть и костыль, который называется Arenas

Было бы классно иметь возможность скачать курс в виде PDF файла и читать офлайн в дороге и тд..

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

Rust Book аболютно адекватен. Просто сам язык немного необычен. Он очень сильно заточен на борьбу с проблемами предыдущих поколений языков, и, если читатель не налетал многократно на все те грабли, вполне возможно, что ему такой фокус будет плохо заходить.

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

Не спорю, адекватен, но для новичков не самый лучший старт. Глава вторая:

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

Тут сразу на новичка вываливается: использование библиотек, мутабельность, объект строки, заимствование, result.

Знания приносят страх.

Ну, тут от бэкграунда зависит. Те, кто хоть немного знаком c С++, или даже Java - ЭТОТ код сразу поймут даже без объяснений.

use std::io сразу ассоциируется с using namespace std; #include "<iostream>, к примеру, ну и так далее.

Вот попытка "слегка" это модифицировать - тут да, могут уже возникнуть вопросы. Но далее уже и объясняется по тексту, что и как.

Напротив, именно такой подход новичкам и нужен. Сначала даётся программа, потом объясняется каждая её строчка, со ссылками на будущие главы. Можно начать с готового примера и "играться" с ним — менять часть строк, смотреть что получилось...


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

Вы описали две крайне противоположные ситуации. Истина где-то посередине. Нужно давать последовательную теоретическую базу одновременно закрепляя её практикой.

Не для любого языка это возможно.

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

Он может быть сколь угодно предпочтительным, но если язык требует чтобы код был написан в функции main — вам придётся либо начинать объяснять его с понятия функции (что странно), либо дать изучающему язык "заготовку" с этой функцией и обещанием вернуться к функциям позже.


У вас просто нет варианта "ничего не говорить про main".

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

Вопрос-то не с пониманием функции, а с тем в каком порядке что рассказывать.

Да никак не рассказывать. Функция - понятно из математики за 5-й класс. Переменные - тем более. Просто провести аналогию и не упарываться по объяснениям пока не придёт время)

В математике функции возвращают значение. В программировании они что-то делают (особенно main). Тяжело тут аналогию провести, особенно просто…


Опять-таки, переменные в математике неизменяемые, а в программировании изменяемые придумали. И ведь этого не умолчать, не оставить на потом — это ж самые азы, если только вы не ФП рассказываете.

На Хабре есть статья про то, в какой последовательности читать растбук по главам:

https://habr.com/ru/post/537790/

Да, я на неё сослался в статье. Именно в том и суть, что человек потерял кучу времени и нервов, только из-за текущей последовательности материала. Поэтому есть куда стремиться при создании обучающих материалов.

Ну, мне например не нравится как там подается инфа о разбиении на модули.

Рассказ идёт с тех модулей, которые практически никому не нужны - которые внутри того же файла, не знаю как они точно называются.

А как происходит объявление и доступ к файлам модулей - почти вскользь. Реально полезная инфа может быть подчерпнута только из пары примеров кода про файловую иерархию в конце той главы или методом тыка.

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

Ну самое важное в модулях - это рассказать об областях видимости и что и как с этим делать. А где это лежит - это одна строчка объяснений, что можно mod { } заменить на mod "имя", и тогда все будет искаться в файле "имя". И все (по крайней мере, в актуальной версии Rust).

upd: я сейчас нагуглил растбук: и либо это другой растбук; либо, с того времени как я его смотрел раньше, эта часть значительно улучшилась.

Defining Modules to Control Scope and Privacy

Ваша реплика читается так: если человек не способен учиться на своих ошибках (иначе, откуда многочисленные самострелы?), то Rust легко попадёт ему в подсознание. Странное утверждение, мне кажется.

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

Хм, а где в биноминальной куче нужен unsafe?

Но ведь replace — это безопасная функция?

Не знаю ??‍♂️: внутри у неё unsafe.

Но снаружи-то unsafe нет!

То есть, если unsafe спрятать внутрь, то как бы и не считается?

Если он не нарушает языковых инвариантов — то да, для того его и придумывали как бы. Если это библиотечный код — два раза да. Если это стандартная библиотека — тем более.

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

То есть, если unsafe спрятать внутрь, то как бы и не считается?

Никого ведь не беспокоит, что где-то внутри условной JVM есть нативный код, который всякого натворить может?.. На джаве пишут принимая как факт, что сборка мусора работает корректно и всяких сишных UB не случится.


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

В JVM можно без native реализовать большое разнообразие структур данных, в Rust без unsafe спектр возможного гораздо уже.

Совсем без native у вас прежде всего не получится JVM сделать. А выше в комментариях именно такого сорта жалоба — видите ли, mem::replace решили не интринсиком компилятора делать, а через unsafe реализовать посмели!

В проекте на условном Java можно весь native оставить на уровне JVM и принять политическое решение: для большей безопасности и переносимости, мы запрещаем код с native. В Java ME, если верно помню, вообще native не было.

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

Просто не надо кричать на каждом углу, что Rust даёт какие-то особенные гарантии безопасности. Тогда и претензий к Rust не будет.

Вы сейчас уже куда-то ушли, изначально тут обсуждалась реализация биноминальной кучи через mem::replace.


Так вот — вы согласны что это безопасный Rust, или всё ещё считаете реализацию mem::replace сложнее JVM?

В обсуждаемом коде mem::replaceиспользуется, чтобы изменить ссылку. В Java это обычное безопасное присваивание `x = y`.

Присваивание и в Rust делается через оператор =. Суть replace в том, что она ещё и возвращает старое значение.

Да, но в условном Java, можно написать: `old = x; x = new; return old` - всё вполне себе safe. В Rust приходится это делать unsafe операцией, которая нарушает гарантии на корректность операций с памятью.

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

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

Разумеется, когда Rust дизайнили — об этом подумали. Именно потому mem::replace находится в стандартной библиотеке.

Ok. Больше мне нечего сказать. Если Вы считаете это красивым и верным подходом к дизайну ЯП, то кто я, чтобы омрачать Ваш праздник жизни? Наслаждайтесь! Эволюция и экономика нас рассудят.

Сложно забыть о том, о чём не знаешь. То есть, мне не нужно знать про этот Unsafe, чтобы писать всякие нетривиальные структурки данных на Java, а в Rust unsafe для таких структурок обязателен

Этот unsafe может оказаться под капотом других классов, которые вы используете, т.е. по вашему мнению это такой же плохой дизайн, как и mem::replace

Я могу писать сами алгоритмы и структуры данных полностью сам, без использования сторонних классов, то есть, без подкапотных Unsafe. Библиотечные классы мне понадобятся для ввода/вывода, и в них может быть Unsafe. Но это работа на уровне OS, в которой Unsafe вполне приемлем.

Да вообще вся std так или иначе обращается к ОС (память выделить, тред запустить, файл открыть-прочитать-записать) — выходит, по вашей логике на Rust ничего нельзя написать без unsafe?

Одно дело unsafe для реализации чего-то действительно системного. Другое дело unsafe для реализации простейших структур данных. ??‍♂️

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

Это тоже спорно. (:


Ограничения раста проще понять вдоволь потоптавшись по граблям С или С++. Иначе может быть непонятно ради чего это всё.

Мало кто учил тот же Си, начав с Ассемблера, чтобы потоптаться по граблям Ассемблера, и понять, ради чего это всё. Проблема в том, что у опытного программиста возникают вопросы к выразительности Rust. Точно так же, как у программистов на Ассесблере возникли вопросы к Си. А новичок воспримет это всё как данность.

Это, конечно, исключительно мой личный опыт, но с С++ на раст переключился относительно легко. Был, конечно, период привыкания, но без особых страданий.

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

В целом, стримы Jon Gjengset'а на ютубе - пока лучшее, что я видел. А Fault Lore (блог автора Rustonomicon'а) - самое жутко-прекрасное, что я читал.

Хочу заметить, что сложный для изучения не потому, что сложный, а потому, что мало кто уделяет внимания базовым вещам в обучении языка. Я приводил в статье ссылку на курс на educative.io, там всё достаточно просто изложено, почти на уровне обычных курсов по Питону.

Вы знаете, я несколько лет учу Раст, при весьма хорошем бэкграунде как в Си так и в Питоне, и я могу сказать, что Rust - очень сложный для изучения язык. При том, что есть иллюзия простоты (которая потом хорошо поддерживается компилятором для человека, который знает эту сложность), но попытка понять что такое place expression и кто является владельцем place expression начинает взрывать мозг по мере попыток думать об этом. Неявные заимствования, сравнение unsized значений, появление эфимерных ссылок в момент создания указателей...

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

потерянные годы. зачем?

для абстрактных, но малоприменяемых знаний был же универ

Ну, я мог вместо изучения Rust'а пройти все части Ведьмака и Киберпанк. Это было бы засчитано за потерянные годы?

Rust - это отдушина здравого смысла и манифестация Касталии (из игры в биссер). Наконец-таки в индустрии кто-то что-то делает на совесть не срезая углы.

А ещё бонусом открывается возможность написать любую программу, которую хочешь. Даже если это рендеринг шрифтов в opengl в реальном времени 144 раза в секунду. Этой возможности мне очень сильно не хватает в питоне, где "нарисовать картинку" просто, а показать её на экране - big deal, с нюансами.

А ещё вдумчивое чтение документации по Расту открывает многие аспекты современных компьютеров. Например, если бы не Rust, я бы никогда не разобрался с linux memory model, потому что оно слишком странно написано; а в рамках примитивов Rust (окей, окей, С++ с фэнсервисом) - куда разумнее и лучше.

При этом копание в Rust не оставляет PTSD как, например, ходьба по сишным граблям с type aliasing.

Вот подмена понятий не нужна. Все написано на С, и если ты эту модель понимаешь, то понимаешь мир, иначе никакой язык тебя не спасет (ассемблер как второй вариант).

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

Этакий черный квадрат Малевича. Идеал ничего.

У современного Си модель памяти соответствует С++.

Речь про https://en.cppreference.com/w/cpp/atomic/memory_order

Старинный "обычный" C никакого acquire/release не поддерживает.

Какой то странный дерейл.

С эмбедщиками пить не советую.

При чём тут эмбеддщики? Вы когда последний раз видели компьютер с одним процессором? Уже давно 2-4-6-8-12-24-32-48-64-128-256 ядер. И вот там-то модель памяти становится критически важной, потому что ошибка с режимом доступа к памяти приводит к фантастическим глюкам, включая прыжки в будущее (потому что спекулятивное исполнение).

А "sequential на всё" превращает ваш компьютер в тыкву по производительности.

Дерейл на какой то невиданный "режим доступа к памяти" и ирония в том, что раст то как раз "sequential на всё". Удачи.

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

а это все из очередной попытки писать АБСОЛЮТНУЮ МАШИНУ абсолютно переносимый код

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

А что не так с абсолютно переносимым кодом и почему вдруг это недостаток?

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

А чего это он недостижимый-то?


И даже если так, почему приближение к нему рассматривается как что-то плохое?

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

А про бэкграунд в питоне - why not? Есть жирнючие ценные проекты на нём написанные, которые нужно сопровождать. Если же учесть, что у меня основная работа вообще вокруг ансибла с testinfra строится, то что мне использовать, кроме питона? Писать модули на перле, маме на зло?

писать то можно, хвастаться не стоит =)

получается как в резюме писать про успешное окончание дет.сада

Моё резюме касается только меня и людей, которые мне будут деньги платить. Вы, вероятнее всего, считаете, что питон - это детский сад, и все благородные доны должны писать на coq (haskell, whatever). Но я подозреваю, что тщательно написанный на самом вами любимом языке программирования код окажется в большой неприятной заднице, потому что вендор железки, с которой вы хотите работать, срал на стандарты и обновления, и надо использовать netmiko, которую (увы, увы!) на coq никто не портировал. Либо лично изобретать тайминги слипов после отправки команд по устаревшей версии ssh, отсутствующей во всех современных ОС.

Вы, вероятнее всего, считаете, что питон — это детский сад, и все благородные доны должны писать на coq (haskell, whatever)

Вангую, что Siemargl признаёт только С++.

Нет, просто я бейсик и фокал не пишу в резюме =)

До Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.

Модель памяти Linux описана в терминах работы железа. Не очень понятно, что именно в этом описании "странно".

Ну, и, наконец, рендеринг шрифтов 144 раза в секунду на OpenGL от языка не зависит: шейдеры будут с одинаковой сокростью работать. От языка зависит сложность составлерия и загрузки этих шейдеров. Но, вроде, на Python это не сложно сделать. Не уверен, что сложнее, чем в Rust.

До Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.

И они всем практически мертвы, на практике не используются (еще Эйфелль). Экстраполяция очевидна

НЛО прилетело и опубликовало эту надпись здесь

Эта наука учитывает модель вычислителя, не совсем соответствующую реальному компьютеру, что создаёт значительный оверхед (а то и глупости, типа i30 и u31 в OCaml).

Шрифты рендерятся в процессоре, а не в видеокарте, видеокарта их отображает.

И я очень хочу посмотреть как вы это будете делать на питоне без массивной коллекции so-файлов, выполняющих реальную работу.

Спасибо большое, что пишете про опечатки, я это ценю и сразу исправляю.

Очень даже не плохо) я не такой педант чтобы как-то критиковать ) вполне удобно, как обучение 50.50 , но вот как шпаргалка очень не плохо, добавил себе в закладки.

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

Положение корпуса не имеет значения, только расположение колеса относительно камня и коэффициент трения.

Не имеет? Окей ?

Зачем вы минусуете человека? Сделайте чертеж, приведите обоснование. И никогда нельзя быть на 100% уверенным что вы правы. А расположите робота перед камнем сверху (если вы таскали землю на тележке, то её можно было и толкать и тянуть) А что, если коэффициент трения действительно высокий, а что если там типа шестеренки на зубчатом механизме. А что, если... В общем можно продолжать и продолжать.

Во-первых, я его не минусовал. Когда я пришел писать ответ, минус у него был. А у меня плюс. Но к обоим этим событиям я не имею никакого отношения.

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

Хорошо, что я ошибся. Просто хочу, чтобы все были чуть добрее.

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

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


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

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

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


Точка приложения усилий к камню на картинке видна так же хорошо как и наклон робота.

Камень опирается на две точки: на гору и на руки робота. Робот опирается об гору и об камень. Почему что-то из этого должно вращаться?

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

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

Можно, но так как изображено на картинке — не получится.

И всё же, почему этот треугольник не жёсткий?

А причём тут вообще этот треугольник?

Вы правы, это я нарисовал не проснувшись толком. Вот как я вижу ситуацию: йа картинко
Каждая вершина треугольника зафиксирована (у нас же ничего не проскальзывает), рёбра жёсткие (робот крепкий, камень тоже не разваливается, точки опоры не разъезжаются). Система выглядит стабильной. Что тут не так?

Камень не "приклеен" к поверхности, поэтому вы нарисовали не треугольник — а трёхзвенную ломаную, которая случайно оказалось замкнутой. В следующий момент она разомкнётся.

В каком месте или местах разомкнётся? Не приклеен — проскальзывает? Если катится, то робот не перемещает свои руки по камню на соответствующее расстояние? Почему для следующего момента нельзя нарисовать полностью аналогичную картину? Какое вообще отношение форма робота и его центр масс имеют к тому, что произойдёт в следующий момент?

Если принять, что на картинке запечатлен момент, когда камень катится с горы, и как раз начинает опрокидывать робота - тогда все ОК! :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории