Оно на 8051-м ядре? Ну вот зачем насиловать труп, скажите? Есть уже вполне адекватные как по цене, так и по периферии/энергопотреблению ARM-ы, под которые существует нормальный инструментарий.
Там не нужен классовое ООП (то, что Вы называете «нормальный»), ибо там тайпклассы — инструмент в разы, если не на порядок мощнее классики.
хотя бы наследование структур
Нет и вводить не собираются. Это нужно разве что при написании обёрток к классике, ибо при АлгТД+тайпклассах код пишется иначе. Если Вы не знакомы с парадигмой, то объяснить с лёту я не смогу — просто начните писать что-то на rust'е (или haskell'е) и Вы удивитесь никчёмности классового (да и прототипного) ООП.
Да потому что всех (кроме отъявленных мазохистов) запарило писать код на C, в котором нормального тайпчекера нет и приходится использовать void* на каждый чих. С другой стороны, непонятно почему нельзя писать под AVR на том же хацкелле.
Дело не в масштабности, а в корректности. К хацкеллу приделать и использовать с ним SMT solver несколько проще (e.g. Liquid Haskell) чем в случае с C (Frama-C).
Одно дело программка на 1к строк и совсем другое на 10к, согласись. Вряд ли ты будешь прикручивать в первом случае Frama-C.
И да, есть полумёртвые Cyclone и D, если совсем припекает.
Никак не относится. Пишешь удобный борщеязычок (eDSL), который генерирует оптимизированный C-код, который в свою очередь компилируется на нужной платформе.
Можно имитировать наследование GameState от State через реализацию Deref. А вот от fow.is_tile_visible(pos) даже в ООП языках с множественным наследованием не избавился бы, ибо закон Деметры
Это нужно разве что при написании обёрток к классике
Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу. Тогда он идет в задницу и я продолжая работать на универсальном С++. Так рассуждает любой вменяемый программер.
Если это замена С, то вопросов не имею.
Вы удивитесь никчёмности классового (да и прототипного) ООП
Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах. Может какие-то либы есть готовые?
Когда у тебя зайдет речь о большой системе, ты поймёшь преимущество «классики». В твоих трейтах и АлгТД ты запутаешься со временем. trait'ы и отдельная реализация вынуждают разбивать систему на большее число компонент, чем требует логика предметной области. Открытые АлгТД удобны в одних ситуациях и неудобны(от слова совсем) в других.
Все это проверено на относительно большом проекте java + scala. Так же есть опыт работы с F#.
Так вот. По мере развития проекта ты или тонешь в сложности или приходишь к тому, что на «высоком» уровне у тебя таки «классика», а вот под капотом вся эта, условно, «функциональна»
По мере развития проекта ты или тонешь в сложности или приходишь к тому, что на «высоком» уровне у тебя таки «классика», а вот под капотом вся эта, условно, «функциональна»
На «высоком» уровне, чем «классика» отличается от «функциональщины»? Интерфейсы или трейты - большой разнцы нет. Или у вас на «высоком» уровне было именно наследование классов?
Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу.
Что-то логику не уловил. Ржавчина это замена крестам, о какой «поддерживать» идёт речь? Если Вам надо поддерживать кучу дерьма на крестах, то нефиг сюда ржавого тянуть, вот и всё.
Если это замена С, то вопросов не имею.
Это не замена си, ибо он отлично с ним уживается.
Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах.
Если речь идёт о представлении html в виде DOM, то тут классовое ООП подходит лучше именно из-за наследования (тут нет ничего удивительного, ибо DOM это объектная модель, она под классы отлично ложится, так что во всяких servo имитируют наследование.
Трейты(скаловские) использовались, да. Часто как раз для миксирования. Я бы не назвал это функциональным подходом.
Классика была в том смысле, что были классические иерархии, с наследованием классов(использовалось все это, конечно, через интерфейсы, но это тоже классика).
case class'ы(АлгТД) на «высоком уровне» использовались только там, где были удобны для выражения понятий предметной области, там, где вероятность появления нового варианта стремилась к нулю. И тут я бы не стал называть это уходом от классики, поскольку в проекте на чистой яве было бы что-то похожее, просто с менее удобным синтаксисом. На том же котлине(правда на практике я его не трогал) это выражалось бы вполне сносно, а в нём ФП и АлгТД нет.
В общем, я таки люблю scala больше java, но само по себе ФП ООП не заменяет, они используются на разных уровнях. Т.е. ФП может убрать ООП там, где оно не нужно и приводит к увеличению, а не уменьшению сложности. Но не везде. Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют. А множественное наследование можно убрать, да, заменив примесями.
Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют.
Да никто и не отказывался. АлгТД+тайпклассы на высоком уровне — тот же классовый ООП, только в профиль, как уже заметил tailgunner. А на низком уровне не совсем понятно, почему нужно отказываться от преимуществ таймпклассов? Реализовал нужный трейт для своего типа и он уже отлично вписывается в существующую систему. В итоге меньше адаптеров и т.д., т.е. упрощение, а не усложнение.
И вообще, мы как-то бурно взялись обсуждать отдельно классику и тайпклассы, что было бы неплохо, если бы был аналог крестов, но с лайфтаймами и рабочими концептами, причём протянутыми через библиотеки.
А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает? В случае шаблонов вполне сработает operator < или свой компаратор(см. стандартные алгоритмы и контейнеры в STL). В случае иерархии, вполне можно сделать метод cmp или ему подобный, если он так уж нужен.
Ага, т.е. если там будет не <, а какой-то конкретный метод, то сведётся к шаблонизированной функции? Отличное ООП получается.
Шаблон там исключительно из-за того, что Rc сам параметризован по типу. А то, что ты показал на rust - костыль, т.к. rust не умеет в перегруженные функции. Вот попробуй минимальными усилиями изобразить аналог:
А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает?
Я тыкнул в рандомное место, так что пример действительно не лучший. Однако перед bool operator<(Rc<T> a, Rc<T> b); есть солидное преимущество: оно ложится в строгую систему типов, которая пока (до введения и широкого применения концептов) в крестах отсутствует. Т.е. это именно Ord, а не просто абстрактный ad hoc полиморфизм (перегрузка).
Поэтому я и говорю:
... взялись обсуждать отдельно классику и тайпклассы, ... крестов, но с лайфтаймами и рабочими концептами, причём протянутыми через библиотеки.
есть солидное преимущество: оно ложится в строгую систему типов,
Все правильно - давайте ограничение называть преимуществом, ну нет у нас перегрузки, даже по одному жалкому параметру. Нет у нас наследования. Зато без всего этого у нас есть «солидное преимущество» (с).
Лалка. А ничего, что через трейты без проблем реализуется мультидиспетчеризация и даже диспетчеризация по возвращаемому значению? Рядом с этим перегрузка функций просто унылая недоделка.