Со всеми этими выкладками мы приблизились к пониманию того, что в коде в начале статьи нет никакой “магии”, “фокусов”, “интуиции”, “подбора” и прочих грязных хаков, а есть лишь чистая математика, во всей своей первозданной красоте. Для меня главным выводом из этой истории стала новость о том, что преобразование float в int и наоборот путем переинтерпретации одного и того же набора бит – это не ошибка программиста и не “хак”, а вполне себе иногда разумная операция.

Ошибаетесь. В этом коде есть чудовищный и катастрофический хак, который просто обязательно надо было упомянуть. А именно, нарушение правила strict aliasing-а при разадресации указателя. Все беды в коде возникают оттого, что кто-то проникся «элегантным решением», не разобравшись во всех деталях, а потом начинает применять его к месту и не к месту.

Эту и другие темы я разбирал в своем докладе на конференции C++ Russia. Кому интересно, можете заглянуть.

Есть такая беда, в университетах порой учат, что ООП — единственно правоверный подход, серебряная пуля в мире программирования. А потом выпускник сталкивается с Rust. И не знает даже, откуда начинать его понимать.

Концепция работы в Rust, по моему скромному мнению, самая адекватная из ООПшных. Есть структуры данных (в том числе они же — дескрипторы объектов реального мира. Структуры можно вкладывать друг в друга для получения более сложных структур.

struct Point {
    x: i32,
    y: i32,
}
struct Size {
    width: i32,
    height: i32,
}
struct Rect {
    origin: Point,
    size: Size,
}

Есть описание поведения структур, их характерные черты. (кстати, сообщество уже определилось, как переводить traits?). Их могут наследовать более глобальные описания.

trait HasArea {
    fn area(&self) -> i32;
}
impl HasArea for Rect {
    fn area(&self) -> i32 {
       self.size.width * self.size.height
    }
}

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

А если смотреть глобально — случаи бывают разные. Где-то ООП с классами удобно, где-то старый добрый императивный подход, где-то функциональный, бывает, что нужен какой-то дикий гибрид.

Например, моё мнение: не нужно городить ООП поверх файловой системы. Ну, хорошо, File — это нормально. А вот функции типа mkdir, touch, stat, rename — не ложатся на парадигму никак. Поэтому люди выдумывают синглтоны, непонятные классы, FileManager и прочую ересь. Но зачем плодить лишние сущности, когда можно всё оставить, как есть (ну, может, сделать кроссплатформенные обёртки).

Очень большая боль ниже спины в ООП — различного рода оповещения. Для их реализации создаётся огород классов в 5-10. Хотя в функциональном программировании всё уже давно придумано. Почему не используем, если язык позволяет? Скорее всего, потому, что не научили…

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

Круто! Спасибо! По поводу предложений для названия: «GoLIDE», «GoJ»
Ещё бы IDE для Rust, было бы вообще супер!

Этой игре очень не хватает Z уровней — возможности закопаться вглубь, или построить что-то в несколько этажей.

Оказывается есть анализатор, гораздо лучше вашего.
https://npo-echelon.ru/production/65/10920