Средства и методы разработки

Я говорю про другую типизацию. Не про int или long, и даже не про int или char*. Программа на ООП-языке существует в рамкой некой модели, где есть понятие типа как класса и возможных операций над типами. И существует во-первых возможность выбора операции, диспетчеризации метода, в зависимости от типа самого класса, возможность автоматического преобразования типа, возможность выбора перегруженной функции, во-вторых не все операции применимы для всех типов, не у всех типов есть определённые функции. И попытка совместить несовместимое кончается в одних языках ошибкой компиляции, а в других ошибкой во время исполнения. Последнее намного хуже, т.к. протестировать все возможные пути исполнения программы -- невозможно. Для ПО определённого класса такое поведение недопустимо, для ПО других классов (развлекательная веб-страничка) -- даже не критично. Нужно понимать, что в C++ многомерный язык программирования. По меньшей мере трёхмерный. И есть несколько реально ортогональных пространств понятий. И пространство типов, существующее во время компиляции, и которое только может быть воображаемо во время исполнения -- одно из них. Я про эти типы. Параллельно и независимо существуют данные, которые могут представляться в двух ипостасях, реальной (constexpr), существующей во время компиляции, или мнимой, когда сущность обретается только в момент исполнения. И конечно данные тоже имеют какой-то layout в памяти и связанный с ними тип структуры, но этот не тот тип, а другой из ортогонального измерения. Ещё есть макросы C-процессора, они тоже из своего ортогонального пространства. И не нужно всё мешать в кучу. У голого C нет пространства типов, C -- двухмерный язык программирования. У него есть только пространство типов как layout в памяти, причём оно совсем уж "плоское" -- в отличии от C++ вложенные типы невозможны, пространств имён нет, и разделение возможно только на уровне единицы компиляции. Хотя даже в этом плоском пространстве разные типы (структуры) -- различимы и подсунуть другой тип в функцию, например, не удастся. И что важно, пространство типов в C++ позволяет задавать правила по автоматическому выбору функций на основе типов заданных аргументов, вычислению самих типов в зависимости от других типов или констант, вычислению констант (значений) на основе других значений или типов. На неком уже декларативном языке. Вот здесь -- метапрограммирование. Когда задаётся набор правил и по заданным правилам и входным данным генерируется программа (результат интересно разглядывать на https://cppinsights.io/). А в голом C нужно всё конкретно расписывать руками (императивное программирование). Что естественно легко в простейших случаях и невозможно чуть в более сложных -- становится сложно, объёмно, и в ход идут друге решения. И вот в C#/Java, для сравнения, механизм типов есть, но ограничен на уровне C++ 90-х годов. Полиморфизм ограничен виртуальными функциями (с диспетчеризацией во время исполнения, со спотыканиями оптимизатора на каждом уровне косвенности), есть наследование (причём нет множественного наследования, только интерфейсы). Есть пользовательские преобразования типов. Но сами типы уже неизменны в том виде как написаны программистом, динамическое, в момент компиляции, создание типов, вычисление типов на основе данных или других типов -- невозможно, вообще любые вычисления в пространстве типов -- невозможны. Только так же как в C# нет макропроцессора. Т.е. программа компилируется как написана, никакого метапрограммирования. Я не уверен про Java, может быть там есть бОльшие возможности, знаком с этим языком поверхностно. Но во всяком случае в C#/Java есть понятие различимых типов данных и компилятор может проверить и выдать ошибку о несоответствии, а если код скомпилировался, то скорей может корректно работать. А в скриптовых языках, в Javascript, в Python -- это не так. Там код даже если скомпилируется в байткод, и в JIT-код, то может выдать ошибку будучи запущенным, из-за того, что применили какую-либо непредусмотренную операцию над как бы другим типом, хотя там все типы -- Object, String и integer, условно говоря. И это реальная проблема, как я сказал выше, невозможно протестировать абсолютно все сценарии. Значит любая более-менее сложная программа на скриптовом языке будет изобиловать багами. И самое важное, о них нельзя узнать заранее, как в случае языков со статической типизацией, где такие баги не проходят дальше компилятора. И есть ещё ньюансы, exception safety, например. Пытаясь что-то программировать на питоне можно сталкиваться с постоянно возникающими именно уже в момент исполнения ошибками (вплоть до синтаксических, perl по-моему имеет более "надёжный" компилятор), в частности вызванными чем-то вроде отсутствия записи с данным ключём в словаре и т.п. И после знакомства с C++ совершенно непонятно как так можно писать сколько-нибудь надёжные программы: в C++ я знаю, что если есть функция, то либо она noexcept, и она как-то не сработает и возможно вернёт ошибку, либо она может вызвать исключения, и об этом известно из документации, декларации и т.п. и я могу писать try-catch вокруг. А в питоне любая функция может свалить программу. Конечно, кто-то скажет, что лучше пусть свалит -- заодно и исправишь. А я опять отвечу, что все случаи протестировать невозможно, и проблема возникнет обязательно когда не нужно, а не в тесте. И хуже когда это делают безобидные библиотечные функции. В принципе в perl/tcl похожая ситуация, только натыкаться на проблемные случаи приходится почему-то реже, не знаю почему.