Я далек от мысли, что стандартизация программирования — это простое дело. Необходимое — да, и не простое. Но чтобы дойти, надо идти. Начнем с какого-то простого конца.

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

Саморезы классифицируются по назначению – для дерева, для металла, кровельные и т.д. и по размеру. Размеры стандартизованы, например, есть саморезы длиной 25 мм и 32 мм, но нет 27 мм.

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

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

Аналогия вещь не всегда корректная, но все же задам простой вопрос – есть ли что-то простое в программировании, что можно стандартизовать раз и на всегда (или очень надолго)?

Безусловно есть, например: sin (а также cos, tg и т.д.)

Синус (и вся тригонометрия) – это чудесные stateless функции, которые нет никакого смысла программировать заново.

Следующий вопрос: а важно ли мне на каком языке запрограммирован синус?

Ответ: Безусловно нет. Для 99.99% приложений не имеет значения, для очень малого количества приложений имеет значения производительность и там могут быть какие-то особые решения.

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

На каком языке написана эта функция?  А все равно. И вообще функции хранятся в LLVM промежуточном коде и докомпилируются на нужную платформу по требованию. Этакое общественное хранилище open semi-binary кода.

Вопрос: а как же language binding, соглашение о связях?

Естественно, что для каждой единицы хранения хранится не только код, а, как минимум:

• Соглашение о связях (языково-независимое!), которую используют компиляторы, линкеры и другие инструменты
• Информация для верификаторов
• Тесты (для регрессивного тестирования как минимум)
• Документация для разработчика
• Информация для поиска, принадлежность к категориям, теги и прочее

Вопрос: Есть же библиотеки, зачем изобретать что-то новое?

Ответ: как-нибудь я напишу статью: «Libraries considered harmfull»…

А пока несколько простых соображений:

• Если мне нужен синус, то зачем мне в придачу дают косинус? И еще 153 кучки ненужного мне кода? Если мне нужна единица кода, зачем мне дают библиотеку (набор)?
• Под словом «library» скрывается несколько принципиально разных сущностей, например, математическая библиотека принципиально отличается от curl. В первом случае – это набор слабо связанных функций (кусков кода), во втором некий механизм, состоящий из взаимодействующих частей.
• Разработчик библиотеки первого рода (слабо связанной) всегда стоит перед вопросом – что должно быть частью библиотеки и что нет. И на этот вопрос ответить невозможно, так как потребности программ разные. Единственный принципиальный ответ – разобрать библиотеку на составные атомарные части. Тогда вместо библиотека мы получим name space в репозитории.
• А вот библиотеки второго рода – это вообще не библиотеки. Об этом надо говорить отдельно.

Принципиальный вопрос: А стоит ли городить огород? Насколько велик объем того, что можно хранить в таком репозитории?

Ответ: продолжение следует…