Казалось бы, - программа для фотографов

Есть один интересный вопрос, в общем случае ответа на который я не знаю. А именно - "как соотносится качество конечного продукта и качество выбранного разработчиком инструментария?". Здесь нужны некоторые (весьма серьёзные) пояснения.

Во-первых, - "качество". Это что? Чем оно измеряется и, вообще, могут ли быть прямые способы его оценки?

На оба вопроса ответов я не знаю. Точнее, - могу сослаться на пару сотен статей, диссертаций и даже документов, но всё это будет не то.

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

В общем же случае нет ни одного вменяемого опеределения прямой оценки качества (программного продукта, само собой).

Косвенная же оценка может быть одной - продукт качественный, если он реально востребован. Всё.

Кстати, что это значит - "продукт реально востребован"?

Мне кажется, это означает, что, несмотря на имеющиеся у продукта недостатки (он, например, может содержать ошибки - любой нетривиальный хоть в чём-то код их содержит), несмотря на известность многих недостатков и очевидную неизвестность ещё большего их количества (период эксплуатации - это и период самого серьёзного тестирования и эволюции), пользователи выбирают продукт и продолжают выбирать именно его. По каким причинам это делают пользователи - не важно (а  если кто-то думает, что можно так проводить в Японии рекламную компанию автомобиля  "ВАЗ 2110", что все японцы сначала предпочтут эту машину своим хондам-тойотам-сузуки-дайхацу, а потом ещё и будут хранить верность своему предпочтению, этот кто-то очень плохо, некачественно думает, и лучше пусть так больше не делает).

Так вот, - продукт должен быть качественным, чтобы быть востребованным, и должен быть востребованным, чтобы становиться всё более качественным (потому что период эксплуатации - blah-blah-blah, уже было выше).

Вот, например, продукт Adobe Photoshop Lightroom. Продукт "молодой" в знаменитой адобовской линейке (достаточно взглянуть на номера версий - Photoshop 10.0.1 и Lightroom 1.3.1). И уже востребованный практически всеми, для кого цифровая фотография представляет интерес.

Главный архитектор Lightroom, Марк Гамбург (Mark Hamburg) - человек легендарный, титулованный "Архитектор Photoshop", причём титул ему присвоили в команде разработчиков, а не в журнальной статье (а это, согласитесь, огромная разница).

Гамбург знает Lightroom до мельчайшего "винтика", потому что это его детище. Вот в этом интервью (я советую прочесть и его первую часть) он рассказывает об архитектуре Lightroom и использованном инструментарии следующее (это не дословный перевод, само собой):

• 40% функциональности Adobe Photoshop Lightroom реализовано на языке Lua,

• ключевые элементы архитектуры продукта - встраиваемый интерпретатор Lua, СУБД SQLite и унаследованный от проекта Photoshop код конфертера RAW-файлов,

• код модулей сопряжения с операционной системой реализован на С++ или ObjectiveC (в зависимости от платформы)

Итого.

Есть старая-престарая статья Кернигана о том, насколько удобен сверхвысокоуровневый интерпретируемый язык-"клей" (то есть, изначально созданный для одновременного встраивания в приложение и формирования приложения за счёт расширений языка).

Таких языков на сегодня на самом деле совсем немного - разве что кроме Lua вспоминаются многочисленные реализации клонов Lisp (Scheme). О причине, почему Lua, a не Scheme, Гамбург говорит следующее:

"Lua - привлекательный баланс между простотой и мощью. Он мал, быстр, его легко встраивать в приложения. У него очень простая лицензия. Он весьма похож на Scheme, который мне нравится, - но в нём нет синтаксиса, требующего от людей слишком больших усилий (вообще-то, в оригинале - "It’s very much like Scheme language I like—but without a syntax likely to make people go running for the hills.")"

Сказанное о Lua, можно слово в слово повторить о SQLite - она тоже небольшая (да какое там - небольшая, она крохотная для своей функциональности), простая, легко встраивается, её лицензия - Public Domain.

Вот так, собственно говоря, Гамбург и дал Lightroom'ом ответ на вопрос о соотношении качества инструментария и продукта:

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

Примерно так. А Lua и SQLite - действительно замечательные вещи. Я бы даже сказал - уникальные.

Digital Twin для мережевої інфраструктури: технологія завтрашнього дня, що доступна вже сьогодні