Замечательный комментарий! Который очень хорошо говорит о том, насколько мне трудно донести сою мысль. Я оказался совершенно не понятым.
Я говорю не о каком-то хранилище, куда люди добровольно выставляют свой код (может быть, даже, очень хороший и востребованный) на всеобщее обозрение, а про ресурс, который является базой данных работающего кода (то есть — универсальным репозиторием), с которого постоянно загружается (тиражируется) код. Смысл такого репозитория в том, чтобы:
Задать для всех единую систему координат, чтобы все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах.
Создать базу данных проверенного кода или, как любят иногда здесь выражаться, покрытого тестами.
Указать проблемные места, на доработку которых следует направить силы разработчиков.
Гитхаб, разумеется, во многом, позволяет достигать похожих результатов, но даже этот сайт не является искомым решением, и более концентрируется на п.3.
Подождите! А зачем LLM писать какой-то код? Вам нужно решить задачу. Прикладную. Путь LLM сама сделает то, что Вам нужно. Без посредство какого-то кода.
Вот меня и интересует, почему меняется кейс? Для меня это — краеугольный вопрос разработки: можно ли писать код (и, вообще, создавать ПО) так, чтобы не надо было ничего переписывать? "Вот, в чём вопрос." (с)
Это и есть проблема. Корень проблемы. Хорошо можно сделать только последовательно. Не перескакивая через этапы. (Поэтому поводу, даже, сказка есть. Называется "12 месяцев".))) Все эти гибкие способы разработки они вполне естественны для раскрутки какого программного кода из состояния отельных разрозненных заготовок до полноценного рабочего состояния. А ситуация, когда клиент "вспоминает", что ему нужно что-то ещё, плохая ситуация. Да, такая ситуация является общепринятой. Но это, что называется, увы и ах. А в нормальной ситуации, для хорошего дома всегда возводится прочный фундамент. Для программных систем таким фундаментом является набор базовых библиотек (программная платформа) и проектная документация, где на каждый вопрос по проекту даётся ответ (выбирается способ решения, способ сопряжения и оцениваются риски).
Представим, что чистый код существует. Это значит, что можно в интернете завести сайт, где будет этот самый чистый код храниться. Каждый отдельный алгоритм будет иметь свой уникальный идентификатор. И тогда можно будет формировать свою программу, ссылаясь на это хранилище. Все будут пользоваться общим кодом, а не самописными конструкциями.
Выгодно, это может быть только в одном случае - если вы продаете софт.
Вот компании и продают софт. Для того, чтобы продавать, нужно всегда делать новый. Это может быть и хорошо, если таким образом, методом последовательных приближений делается продукт, который действительно нужен. Но это может быть и плохо, если втюхивается нечто сомнительного качества, а конкуренты медленно затираются, чтобы не было выбора. Каждая компания выбирает сама свой путь.
Чистый код (если, такой код, вообще, может быть написан) не нуждается в поддержке. В нём всё понятно. Он полностью управляем. И, кстати, полностью покрываем тестами. Мы никогда не сможем проверить все возможные входные данные, но мы мы можем проверить важнейшие классы входных данных.
Хорошим примером чистого кода является математика.
Вспомните школьную математику. Вы хотите решить уравнение или исследовать функцию. Вы понимаете. что у функции есть область определения. Если Вы об этом забудете, то Вы рискуете получить несуществующие корни. И при изложении материала, всегда явно указывается, что из чего и как определяется, разбираются пограничные случаи (например, что у нас в нуле, как расшифровывается неопределённость, вроде 0/0)...
Не стоит делать упор на покрытие тестами. Борьбы за надёжность начинается с самого начала работы над приложением, и покрывать тестами нужно уже сами исходные требования, чтобы устранить основные причины возникновения проблем ещё до начала самого кодирования. Это азы тестирования.
На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Архитекторы никогда не будут на первом плане. Всякая архитектура предполагает строго последовательный способ создания любой системы. Водопадная модель! Сначала составляется полный список требований. он закрывается. Затем, по нему делает проект, где для каждого вопроса предлагается решение (ещё только "на бумаге"). И уже когда на все вопросы получены какие-то ответы, начинается, собственно кодирование. В реальности, бизнес навязывает другую модель разработки, когда, вмешательства оказываются возможны на любом этапе. В результате, полученное "здание" приходится снабжать "костылями", поскольку все элементы оказываются довольно далекими от расчётных значений. Предсказать поведение такой "системы" довольно трудно. Если, вообще, возможно.
С точи зрения архитектуры, чистый код — это такой код, который можно один раз написать и растиражировать везде. А у нас вся история программирования — это история разработи и реализации многочисленных библиотек, которые благополучно отправляются на свалку всемирной истории. Было бы качество — мы бы сейчас, могли бы писать на Хабр, например, при помощи приложения, написанного на Turbo Vision. Текстовый режим... У него были преимущества. И в смысле безопасности тоже. Не говоря о том, сколько проблем не надо было решать (там, с HTML/CSS/JavaScript).
Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием.
Подождите! Как это обеспечиваться? Что же такое чистый код? Разве надёжность и чистота — это не две оборотные стороны одной медали?
Допустим, где-то в программе написано:
s = input()
Допустим, выбран язык программирования Python. Здесь приведён пример чистого кода? Я, конечно же, утрирую. Но, однако, продолжим. Что мы вводим? Интересный вопрос! Это строка или число? Мы знаем, что функция input() возвращает символьную строку. Но такая строка может содержать и число! Но мы хотим застраховаться от ошибок. Мы попытаемся написать что-то вроде.
s = input()
try:
i = int(s)
except ValueError:
...
Это уже чистый код?
А если мы захотим получить число с плавающей запятой? Переделывать код? А может быть, можно переделать саму функцию input(), чтобы она сразу возвращала значение нужного типа? А (кстати!) а от чего зависит тип возвращаемого значения? Мы могли бы сразу написать, как в Pascal'е:
i: integer
i = input()
Это как? Ещё чище? И где, и какое тестирование здесь проводить?
Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода.
Давайте, вместо общих слов, возьмём какую-нибудь прикладную задачу и рассмотрим её различные решения и сравним их с тем. что предлагает ИИ. Если ИИ предлагает что-то дельное, то весь этот кипишь вокруг ИИ можно расценивать как проявления страха большого числа людей, к которым, наконец, пришёл оценщик (как этот бычок из детской сказки, который всех считал), и сейчас общество узнает реальную цену разработчикам. Если есть какие-то внятные принципы разработки, то почему мы им все не следуем, и не изучаем прямо в школе? Если же ИИ предлагает какую-то лажу, хотя бы и яркой упаковке (когда, на первый взгляд, всё работает, то есть — работает в принципе), то это означает (опять же!), что обучающая выборка содержит множество артефактов, то есть — общепринятым является суррогатное программирование. Куда ни кинь — всюду клин!
Всё это не означает, что настоящее программирование должно быть дорогим. Но оно обязательно должно рождаться в результате приложения определённых усилий на то, чтобы понять задачу, на то, чтобы увидеть различные варианты реализации, и выбрать из них наилучший (или предложить некую комбинацию решений, когда, в зависимости от контекста, выбирается свой вариант).
А что Вы скажете про анализ кода и рефакторинг? Зачем Вы хотите проанализировать код? Для чего Вам нужен рефакторинг?г
Требования к программистам поменялись из-за изменения бизнес-требований.
Если быть точным, то эти самые бизнес-требования появились. Изначально, ведь, были только научные задачи. А уже потом подтянулся бизнес. А бизнесу нужна скорость выпуска новой продукции. Хорошо проработанное решение мешает создавать новое: зачем делать чт-то новое, если есть хорошо работающее старое?
Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Такие требования были всегда. Поменялись сами программисты, и творчества среди них тоже стало меньше. Раньше программист мог задумываться о собственном языке программирования, собственной СУБД или CRM-системе. А сейчас? Некогда даже задуматься об этом.
Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
В прежние времена, многое приходилось изобретать самому. Обмен информации не был таким быстрым. Многое, просто объективно, со временем попадает в какую-то библиотеку и становится частью словарного запаса любого мало-мальски профессионального программиста. Сегодня надо знать, что какая-то задача уже имеет некое решение, зато это известное решение с известными свойствами. (Но и не забываем слова, сказанные ранее про "серый ящик". Это суть другая. оборотная сторона проблемы.)
Никто не мешает и сегодня называть постоянного «пользователя» библиотек таким же «ламером». Тогда, правда, придётся называть таковыми довольно много людей, включая и особо продвинутую часть сообщества, включающую т.н. «мид(д)лов» и «сеньоров», которые чрезвычайно глубоко знают целые стеки технологий. Но! Многие ли из них, действительно, способны что-то изобрести поперёк хорошо им знакомого подхода? А как же критическое мышление? Надо же уметь видеть и слабые стороны используемых инструментов! Ведь. отсюда берётся и потребность в создании новых инструментов, включая и новые, более понятные и удобные (в заданных отношениях) языки программирования!
Мы все являемся пользователями ОС. Но ОС не предлагает «из коробки» никакого средства (кроме разве что, командной строки и скриптов) для автоматизации.
Вот, смотрите, текст, который я сейчас пишу, я пишу в специальной форме, которая открывается на сайте. Неосторожное движение мышкой или нажатие не на ту клавишу может заставить браузер "дёрнуться" не в ту сторону, и я потеряю свой текст. Чтобы как-то сохранить этот текст у себя, мне приходится его копировать. Но всё могло бы быть и иначе. Я мог бы писать свой текст в приложении самой ОС, по сути, как текстовое поле локальной базы данных, в которой хранились бы все сообщения, когда-либо мною написанные на всех посещаемых мною в разные годы форумах и площадках. Можно было бы реализовать и такое, но чтобы такое сделать, надо выйти за пределы повседневного использования существующих технологий и изобрести новые протоколы передачи данных и, и, вообще, представить себе интернет без сайтов, как таковых, интернет, который ближе к фидо, бибис и гоферу.
Задачей программиста было написание в принципе работающей программы.
Это не так.
Почему появлялись различные языки программирования? Потому, что учёные (а этим тогда занимались учёные) искали способы наиболее ясного выражения вычислительных концепций. Чего, только, стоят алголо-подобные языки (Pascal, Modula, Ada)! Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном. Я бы с интересом посмотрел бы.
Кроме того, некоторые языки сами выросли на определённых концепциях: всё есть список (Лисп), всё есть связка рекурсивных функций (Форт). И, вообще, всё функциональное программирование.
А ещё имеется целая ветвь: доказательное программирование, сигма-программирование (Ю.Л.Ершов этим в Новосибирске занимался)...
Это сейчас царит подход сделать в принципе работающую программу. Гигабайт памяти не жалко. Дали бы старым программам нынешние объёмы памяти (как дисковой, так и оперативной), мы бы, наверное, удивились как они работают, но тогда не пришлось бы писать новые программы, плодить новые ошибки, и снова переписывать (далее — по кругу). Потому ИИ так и "взлетел", потому что сократилось время появления новой версии ПО. В принципе, работает? Да, работает. А теперь, покажите, пожалуйста, полученный таким образом код. Может быть, он, действительно, то, что нам нужно. Тогда его надо вписывать в учебники и делать основой для образовательных курсов. Очень хочется увидеть такой образцовый код. А то нам всякие гуру описывают, каким должен быть хороший ("чистый", "совершенный") код, а его не видно. Был бы такой код, все бы так писали. Как прописи в первом классе. (Хотя, все всё-равно. потом пишут как курица лапой. Особенно те, кто "в аптеке". ) Был бы такой код, можно было бы издать всемирный справочник, что-то вроде, Камке для дифференциальных уравнений, и пользоваться по мере необходимости. Или всё глобально автоматизировать.
В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки?
Во-первых, когда у Вас есть библиотечная функция, то Вы не знаете до конца, как она работает. У Вас не всегда есть её исходный код. Ситуация с чёрным ящиком суть неизвестность. Тут Вы, хотя бы, насторожитесь и постараетесь проверить работу функции. Если у Вас есть исходный код, то, конечно, Вы можете проверить этот код, но надо всегда делать скидку на компилятор. У Вас никогда не будет того самого компилятора. Да и, вообще, на самом деле, у Вас всегда будет ситуация серого ящика, когда о функции, вроде бы, многое известно, но это всё одно собрание гипотез, приходится верить на слово, а полноценное регрессионное тестирование оказывается невозможным.
Помниться, ещё в книге "Софтостроение изнутри" говорилось о безысходном программировании. Вот было бы здорово, если бы приложение печатало бы свой исходный код! Могла бы и отдельная функция печатать. Для этого надо, чтобы сами функции писались на некотором мета-языке, чтобы в коде явным образом фиксировались принятые предположения, базовые (точнее, базисные, в математическом смысле некоего базиса, из которого можно построить полностью всё пространство). Это и есть чистый код. Код, в котором нет никаких умолчаний. Код, который сам себя документирует. Код, который сам управляет своей дальнейшей трансляцией.
Во-вторых, выбор функции обрекает нас на пребывание в заложниках у её реализации. Выбрали функцию сортировки получили свои варианты работы на различных данных. А был бы использован оператор сортировки, то вопрос выбора способа сортировки можно было бы отложить на потом. Можно было бы в ОС хранить несколько различных конфигураций таких управляющих параметров на разные случаи жизни. Не говоря о такой возможности, как выбор плана выполнения приложения в момент запуска.
В этом смысле, ИИ отчасти решает эту проблему, но ИИ, фактически, работает как кривой "костыль", а для чистоты кода нужно системное решение. Ближе всего к такому системному решению находится аспектное программирование, когда код сопровождается якорями-аннотациями, к которым "прикрепляется" дополнительная функциональность, которая при дальнейшей трансформации (трансляции) программы, может стать частью основного кода. Тут, над кодом надо произвести что-то вроде ортогонализации Грамма-Шмидта, чтобы получить эффективный функциональный базис. Для этого надо будет понять, что такое ортогональность в программировании.
Наконец, в-третьих, что, отчасти, продолжает предыдущее рассуждение, засилие библиотек тормозит развитие самих языков программирования. Языки становятся похожими друг на друга, и вопрос сводится, в итоге, только к выбору определённого синтаксиса, уже готового набора инструментов и развитого сообщества. Между тем, было бы удобнее иметь отельные языки для создания пользовательских интерфейсов, для работы с базами данных, для научных вычислений, для организации тестирования, для документирования и написания компиляторов. Отдельные примеры таких специализированных языков, конечно же, существуют, но у нас до сих пор нет единой парадигмы написания программного кода с соответствующей данной парадигме программной экосистемы.
ИИ пытается заполнить эту нишу, но, за неимением указанной парадигмы, всё что делает ИИ, всегда будет в большей степени суррогатом, хотя, может быть, и имеющим яркую оболочку. Но это, как раз, говорит о засилии в индустрии суррогатного кода, создатели которого мало думают об обоснованности принятых ими решений. В этом смысле, библиотечный подход оказывается, по сути, генератором этого самого программного суррогата...
А всё должно быть наоборот: ИИ должен предложить чёткую, надёжную и достаточно полную классификационную схему алгоритмов вместе с автоматическим выводом допустимых вариантов реализации (на уровне низкоуровневых кодов, форматов хранения данных, сетевых протоколов и обобщённых вычислительных архитектур). И тогда можно будет построить некое пространство программных систем и функцию выбора определённой системы в заданных обстоятельствах и ограничениях.
Для того, чтобы написать хорошую статью, нужно изрядно потрудиться. У действующего специалиста всегда есть материал: его собственные разработки. И это всегда интересно узнать о том, кто и как решает практические задачи. Но у такого специалиста может попросту не быть времени. Написать какую-то ерунду (и, тем более, изобразить ИИ-гадание на кофейной гуще) проще простого. Ну... а можно, всё-таки, что-то сделать. Например, написать статью. Можно перестать комментировать всё подряд. И если каждый напишет что-то из своего опыта, то Хабр наполнится чем-то полезным. Давайте! Дерзайте!
(с вызовом) А что случилось в 2020 году?
Если Вы хотите что-то тиражировать, то напильником придётся поработать изрядно.
Замечательный комментарий! Который очень хорошо говорит о том, насколько мне трудно донести сою мысль. Я оказался совершенно не понятым.
Я говорю не о каком-то хранилище, куда люди добровольно выставляют свой код (может быть, даже, очень хороший и востребованный) на всеобщее обозрение, а про ресурс, который является базой данных работающего кода (то есть — универсальным репозиторием), с которого постоянно загружается (тиражируется) код. Смысл такого репозитория в том, чтобы:
Задать для всех единую систему координат, чтобы все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах.
Создать базу данных проверенного кода или, как любят иногда здесь выражаться, покрытого тестами.
Указать проблемные места, на доработку которых следует направить силы разработчиков.
Гитхаб, разумеется, во многом, позволяет достигать похожих результатов, но даже этот сайт не является искомым решением, и более концентрируется на п.3.
Никто никогда ничего не выпилит. Так и останется. А LLM только покроют этот управленческий туман новым слоем абстракций.
Подождите! А зачем LLM писать какой-то код? Вам нужно решить задачу. Прикладную. Путь LLM сама сделает то, что Вам нужно. Без посредство какого-то кода.
Вот меня и интересует, почему меняется кейс? Для меня это — краеугольный вопрос разработки: можно ли писать код (и, вообще, создавать ПО) так, чтобы не надо было ничего переписывать? "Вот, в чём вопрос." (с)
Это и есть проблема. Корень проблемы. Хорошо можно сделать только последовательно. Не перескакивая через этапы. (Поэтому поводу, даже, сказка есть. Называется "12 месяцев".))) Все эти гибкие способы разработки они вполне естественны для раскрутки какого программного кода из состояния отельных разрозненных заготовок до полноценного рабочего состояния. А ситуация, когда клиент "вспоминает", что ему нужно что-то ещё, плохая ситуация. Да, такая ситуация является общепринятой. Но это, что называется, увы и ах. А в нормальной ситуации, для хорошего дома всегда возводится прочный фундамент. Для программных систем таким фундаментом является набор базовых библиотек (программная платформа) и проектная документация, где на каждый вопрос по проекту даётся ответ (выбирается способ решения, способ сопряжения и оцениваются риски).
Представим, что чистый код существует. Это значит, что можно в интернете завести сайт, где будет этот самый чистый код храниться. Каждый отдельный алгоритм будет иметь свой уникальный идентификатор. И тогда можно будет формировать свою программу, ссылаясь на это хранилище. Все будут пользоваться общим кодом, а не самописными конструкциями.
Вот компании и продают софт. Для того, чтобы продавать, нужно всегда делать новый. Это может быть и хорошо, если таким образом, методом последовательных приближений делается продукт, который действительно нужен. Но это может быть и плохо, если втюхивается нечто сомнительного качества, а конкуренты медленно затираются, чтобы не было выбора. Каждая компания выбирает сама свой путь.
Чистый код (если, такой код, вообще, может быть написан) не нуждается в поддержке. В нём всё понятно. Он полностью управляем. И, кстати, полностью покрываем тестами. Мы никогда не сможем проверить все возможные входные данные, но мы мы можем проверить важнейшие классы входных данных.
Хорошим примером чистого кода является математика.
Вспомните школьную математику. Вы хотите решить уравнение или исследовать функцию. Вы понимаете. что у функции есть область определения. Если Вы об этом забудете, то Вы рискуете получить несуществующие корни. И при изложении материала, всегда явно указывается, что из чего и как определяется, разбираются пограничные случаи (например, что у нас в нуле, как расшифровывается неопределённость, вроде 0/0)...
Не стоит делать упор на покрытие тестами. Борьбы за надёжность начинается с самого начала работы над приложением, и покрывать тестами нужно уже сами исходные требования, чтобы устранить основные причины возникновения проблем ещё до начала самого кодирования. Это азы тестирования.
Архитекторы никогда не будут на первом плане. Всякая архитектура предполагает строго последовательный способ создания любой системы. Водопадная модель! Сначала составляется полный список требований. он закрывается. Затем, по нему делает проект, где для каждого вопроса предлагается решение (ещё только "на бумаге"). И уже когда на все вопросы получены какие-то ответы, начинается, собственно кодирование. В реальности, бизнес навязывает другую модель разработки, когда, вмешательства оказываются возможны на любом этапе. В результате, полученное "здание" приходится снабжать "костылями", поскольку все элементы оказываются довольно далекими от расчётных значений. Предсказать поведение такой "системы" довольно трудно. Если, вообще, возможно.
С точи зрения архитектуры, чистый код — это такой код, который можно один раз написать и растиражировать везде. А у нас вся история программирования — это история разработи и реализации многочисленных библиотек, которые благополучно отправляются на свалку всемирной истории. Было бы качество — мы бы сейчас, могли бы писать на Хабр, например, при помощи приложения, написанного на Turbo Vision. Текстовый режим... У него были преимущества. И в смысле безопасности тоже. Не говоря о том, сколько проблем не надо было решать (там, с HTML/CSS/JavaScript).
Подождите! Как это обеспечиваться? Что же такое чистый код? Разве надёжность и чистота — это не две оборотные стороны одной медали?
Допустим, где-то в программе написано:
Допустим, выбран язык программирования Python. Здесь приведён пример чистого кода? Я, конечно же, утрирую. Но, однако, продолжим. Что мы вводим? Интересный вопрос! Это строка или число? Мы знаем, что функция
input()возвращает символьную строку. Но такая строка может содержать и число! Но мы хотим застраховаться от ошибок. Мы попытаемся написать что-то вроде.Это уже чистый код?
А если мы захотим получить число с плавающей запятой? Переделывать код? А может быть, можно переделать саму функцию
input(), чтобы она сразу возвращала значение нужного типа? А (кстати!) а от чего зависит тип возвращаемого значения? Мы могли бы сразу написать, как в Pascal'е:Это как? Ещё чище? И где, и какое тестирование здесь проводить?
Давайте, вместо общих слов, возьмём какую-нибудь прикладную задачу и рассмотрим её различные решения и сравним их с тем. что предлагает ИИ. Если ИИ предлагает что-то дельное, то весь этот кипишь вокруг ИИ можно расценивать как проявления страха большого числа людей, к которым, наконец, пришёл оценщик (как этот бычок из детской сказки, который всех считал), и сейчас общество узнает реальную цену разработчикам. Если есть какие-то внятные принципы разработки, то почему мы им все не следуем, и не изучаем прямо в школе? Если же ИИ предлагает какую-то лажу, хотя бы и яркой упаковке (когда, на первый взгляд, всё работает, то есть — работает в принципе), то это означает (опять же!), что обучающая выборка содержит множество артефактов, то есть — общепринятым является суррогатное программирование. Куда ни кинь — всюду клин!
Всё это не означает, что настоящее программирование должно быть дорогим. Но оно обязательно должно рождаться в результате приложения определённых усилий на то, чтобы понять задачу, на то, чтобы увидеть различные варианты реализации, и выбрать из них наилучший (или предложить некую комбинацию решений, когда, в зависимости от контекста, выбирается свой вариант).
А что Вы скажете про анализ кода и рефакторинг? Зачем Вы хотите проанализировать код? Для чего Вам нужен рефакторинг?г
Если быть точным, то эти самые бизнес-требования появились. Изначально, ведь, были только научные задачи. А уже потом подтянулся бизнес. А бизнесу нужна скорость выпуска новой продукции. Хорошо проработанное решение мешает создавать новое: зачем делать чт-то новое, если есть хорошо работающее старое?
Такие требования были всегда. Поменялись сами программисты, и творчества среди них тоже стало меньше. Раньше программист мог задумываться о собственном языке программирования, собственной СУБД или CRM-системе. А сейчас? Некогда даже задуматься об этом.
В прежние времена, многое приходилось изобретать самому. Обмен информации не был таким быстрым. Многое, просто объективно, со временем попадает в какую-то библиотеку и становится частью словарного запаса любого мало-мальски профессионального программиста. Сегодня надо знать, что какая-то задача уже имеет некое решение, зато это известное решение с известными свойствами. (Но и не забываем слова, сказанные ранее про "серый ящик". Это суть другая. оборотная сторона проблемы.)
Никто не мешает и сегодня называть постоянного «пользователя» библиотек таким же «ламером». Тогда, правда, придётся называть таковыми довольно много людей, включая и особо продвинутую часть сообщества, включающую т.н. «мид(д)лов» и «сеньоров», которые чрезвычайно глубоко знают целые стеки технологий. Но! Многие ли из них, действительно, способны что-то изобрести поперёк хорошо им знакомого подхода? А как же критическое мышление? Надо же уметь видеть и слабые стороны используемых инструментов! Ведь. отсюда берётся и потребность в создании новых инструментов, включая и новые, более понятные и удобные (в заданных отношениях) языки программирования!
Мы все являемся пользователями ОС. Но ОС не предлагает «из коробки» никакого средства (кроме разве что, командной строки и скриптов) для автоматизации.
Вот, смотрите, текст, который я сейчас пишу, я пишу в специальной форме, которая открывается на сайте. Неосторожное движение мышкой или нажатие не на ту клавишу может заставить браузер "дёрнуться" не в ту сторону, и я потеряю свой текст. Чтобы как-то сохранить этот текст у себя, мне приходится его копировать. Но всё могло бы быть и иначе. Я мог бы писать свой текст в приложении самой ОС, по сути, как текстовое поле локальной базы данных, в которой хранились бы все сообщения, когда-либо мною написанные на всех посещаемых мною в разные годы форумах и площадках. Можно было бы реализовать и такое, но чтобы такое сделать, надо выйти за пределы повседневного использования существующих технологий и изобрести новые протоколы передачи данных и, и, вообще, представить себе интернет без сайтов, как таковых, интернет, который ближе к фидо, бибис и гоферу.
Это не так.
Почему появлялись различные языки программирования? Потому, что учёные (а этим тогда занимались учёные) искали способы наиболее ясного выражения вычислительных концепций. Чего, только, стоят алголо-подобные языки (Pascal, Modula, Ada)! Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном. Я бы с интересом посмотрел бы.
Кроме того, некоторые языки сами выросли на определённых концепциях: всё есть список (Лисп), всё есть связка рекурсивных функций (Форт). И, вообще, всё функциональное программирование.
А ещё имеется целая ветвь: доказательное программирование, сигма-программирование (Ю.Л.Ершов этим в Новосибирске занимался)...
Это сейчас царит подход сделать в принципе работающую программу. Гигабайт памяти не жалко. Дали бы старым программам нынешние объёмы памяти (как дисковой, так и оперативной), мы бы, наверное, удивились как они работают, но тогда не пришлось бы писать новые программы, плодить новые ошибки, и снова переписывать (далее — по кругу). Потому ИИ так и "взлетел", потому что сократилось время появления новой версии ПО. В принципе, работает? Да, работает. А теперь, покажите, пожалуйста, полученный таким образом код. Может быть, он, действительно, то, что нам нужно. Тогда его надо вписывать в учебники и делать основой для образовательных курсов. Очень хочется увидеть такой образцовый код. А то нам всякие гуру описывают, каким должен быть хороший ("чистый", "совершенный") код, а его не видно. Был бы такой код, все бы так писали. Как прописи в первом классе. (Хотя, все всё-равно. потом пишут как курица лапой. Особенно те, кто "в аптеке". ) Был бы такой код, можно было бы издать всемирный справочник, что-то вроде, Камке для дифференциальных уравнений, и пользоваться по мере необходимости. Или всё глобально автоматизировать.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки?
Во-первых, когда у Вас есть библиотечная функция, то Вы не знаете до конца, как она работает. У Вас не всегда есть её исходный код. Ситуация с чёрным ящиком суть неизвестность. Тут Вы, хотя бы, насторожитесь и постараетесь проверить работу функции. Если у Вас есть исходный код, то, конечно, Вы можете проверить этот код, но надо всегда делать скидку на компилятор. У Вас никогда не будет того самого компилятора. Да и, вообще, на самом деле, у Вас всегда будет ситуация серого ящика, когда о функции, вроде бы, многое известно, но это всё одно собрание гипотез, приходится верить на слово, а полноценное регрессионное тестирование оказывается невозможным.
Помниться, ещё в книге "Софтостроение изнутри" говорилось о безысходном программировании. Вот было бы здорово, если бы приложение печатало бы свой исходный код! Могла бы и отдельная функция печатать. Для этого надо, чтобы сами функции писались на некотором мета-языке, чтобы в коде явным образом фиксировались принятые предположения, базовые (точнее, базисные, в математическом смысле некоего базиса, из которого можно построить полностью всё пространство). Это и есть чистый код. Код, в котором нет никаких умолчаний. Код, который сам себя документирует. Код, который сам управляет своей дальнейшей трансляцией.
Во-вторых, выбор функции обрекает нас на пребывание в заложниках у её реализации. Выбрали функцию сортировки получили свои варианты работы на различных данных. А был бы использован оператор сортировки, то вопрос выбора способа сортировки можно было бы отложить на потом. Можно было бы в ОС хранить несколько различных конфигураций таких управляющих параметров на разные случаи жизни. Не говоря о такой возможности, как выбор плана выполнения приложения в момент запуска.
В этом смысле, ИИ отчасти решает эту проблему, но ИИ, фактически, работает как кривой "костыль", а для чистоты кода нужно системное решение. Ближе всего к такому системному решению находится аспектное программирование, когда код сопровождается якорями-аннотациями, к которым "прикрепляется" дополнительная функциональность, которая при дальнейшей трансформации (трансляции) программы, может стать частью основного кода. Тут, над кодом надо произвести что-то вроде ортогонализации Грамма-Шмидта, чтобы получить эффективный функциональный базис. Для этого надо будет понять, что такое ортогональность в программировании.
Наконец, в-третьих, что, отчасти, продолжает предыдущее рассуждение, засилие библиотек тормозит развитие самих языков программирования. Языки становятся похожими друг на друга, и вопрос сводится, в итоге, только к выбору определённого синтаксиса, уже готового набора инструментов и развитого сообщества. Между тем, было бы удобнее иметь отельные языки для создания пользовательских интерфейсов, для работы с базами данных, для научных вычислений, для организации тестирования, для документирования и написания компиляторов. Отдельные примеры таких специализированных языков, конечно же, существуют, но у нас до сих пор нет единой парадигмы написания программного кода с соответствующей данной парадигме программной экосистемы.
ИИ пытается заполнить эту нишу, но, за неимением указанной парадигмы, всё что делает ИИ, всегда будет в большей степени суррогатом, хотя, может быть, и имеющим яркую оболочку. Но это, как раз, говорит о засилии в индустрии суррогатного кода, создатели которого мало думают об обоснованности принятых ими решений. В этом смысле, библиотечный подход оказывается, по сути, генератором этого самого программного суррогата...
А всё должно быть наоборот: ИИ должен предложить чёткую, надёжную и достаточно полную классификационную схему алгоритмов вместе с автоматическим выводом допустимых вариантов реализации (на уровне низкоуровневых кодов, форматов хранения данных, сетевых протоколов и обобщённых вычислительных архитектур). И тогда можно будет построить некое пространство программных систем и функцию выбора определённой системы в заданных обстоятельствах и ограничениях.
Для того, чтобы написать хорошую статью, нужно изрядно потрудиться. У действующего специалиста всегда есть материал: его собственные разработки. И это всегда интересно узнать о том, кто и как решает практические задачи. Но у такого специалиста может попросту не быть времени. Написать какую-то ерунду (и, тем более, изобразить ИИ-гадание на кофейной гуще) проще простого. Ну... а можно, всё-таки, что-то сделать. Например, написать статью. Можно перестать комментировать всё подряд. И если каждый напишет что-то из своего опыта, то Хабр наполнится чем-то полезным. Давайте! Дерзайте!
Например, в БД у нас есть заказы, продукция, клиенты, а в приложении опять возникают классы "Заказ", "Клиент", "Продукт" (и т.д. и т.п.).
А с какой версии это стало доступно?
А как выбрать?