Исправление seiken, (текущая версия) :
и не понимаю, почему в 2021 году это ещё не переписали на ООП языке
кто это будет оплачивать? Вот ты, если такой прогрессивный, почему не возьмешь, и не перепишешь? И потом, почему ты думаешь, что от того, что перепишут на ООП ЯП подобные проблемы исчезнут. На том же C++ можно наколбасить, во-первых, в анти-ООП стиле, и во-вторых, со всеми теми же проблемами с памятью, и получится еще более сложный для анализа код.
и заодно не перевели на нормальное именование переменных. Что такое hd и почему я должен долго лазить по коду, чтобы это узнать?
это «заодно» никак не зависит от используемого ЯП. И на ООП языке можно тоже использовать схемы именования «из 70х». К тому же, найдутся критики из другого лагеря: что за MyVerySelfexplanatoryVariableName? кто пустил дурачков жабистов в наш код?
Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?
в смысле ООП, думаю все просто: в таком низкоуровневом и околосистемном коде (в отличие от более разнообразного мира прикладного ПО) количество сущностей ограничено, все они по-технарски специфические, давно изучены, и соотв. абстракции давно уже существуют в терминах простого процедурного ЯП. Введение новых абстракций ООП не даст таких преимуществ, как в прикладном софте, в котором сущности из очень разных предметных областей, и многие есть модель реальных сущностей за пределами IT.
Зато появится дополнительная зависимость: еще один компилятор (даже если это только фронтенд), еще больше сложности в поддержке и портировании. И дополнительные телодвижения ради обеспечения совместимости с кодом на C, даже если эти телодвижения минимальны среди всех остальных ЯП.
А преимущества где?
Исходная версия seiken, :
и не понимаю, почему в 2021 году это ещё не переписали на ООП языке
кто это будет оплачивать? Вот ты, если такой прогрессивный, почему не возьмешь, и не перепишешь? И потом, почему ты думаешь, что от того, что перепишут на ООП ЯП подобные проблемы исчезнут. На том же C++ можно наколбасить, во-первых, в анти-ООП стиле, и во-вторых, со всеми теми же проблемами с памятью, и получится еще более сложный для анализа код.
и заодно не перевели на нормальное именование переменных. Что такое hd и почему я должен долго лазить по коду, чтобы это узнать?
это «заодно» никак не зависит от используемого ЯП. И на ООП языке можно тоже использовать схемы именования «из 70х».
Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?
в смысле ООП, думаю все просто: в таком низкоуровневом и околосистемном коде (в отличие от более разнообразного мира прикладного ПО) количество сущностей ограничено, все они по-технарски специфические, давно изучены, и соотв. абстракции давно уже существуют в терминах простого процедурного ЯП. Введение новых абстракций ООП не даст таких преимуществ, как в прикладном софте, в котором сущности из очень разных предметных областей, и многие есть модель реальных сущностей за пределами IT.
Зато появится дополнительная зависимость: еще один компилятор (даже если это только фронтенд), еще больше сложности в поддержке и портировании. И дополнительные телодвижения ради обеспечения совместимости с кодом на C, даже если эти телодвижения минимальны среди всех остальных ЯП.
А преимущества где?