Вот смотрю, знание уже существующих решений позволяет значительно сократить время на разработку. Кто-то будет фичу делать с нуля, а кто-то реализует на основе существующих решений.

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

Насколько вы уделяете внимание знанию не основ а именно знанию библиотек и существующих решений?

Здравствуйте, Shmj, Вы писали:

S>Насколько вы уделяете внимание знанию не основ а именно знанию библиотек и существующих решений?

Уделяю.

Здравствуйте, Shmj, Вы писали:

Ну тут медаль о двух сторон. Для начального нужного функционала найдешь библиотеку, заточишься под нее, а потом заказчик такой «а давайте вот такую финтифлюшку добавим». А найденная библиотека эту финтифлюшку не поддерживает. И начинаются лютые костыли.

Здравствуйте, Hоmunculus, Вы писали:

H>Ну тут медаль о двух сторон. Для начального нужного функционала найдешь библиотеку, заточишься под нее, а потом заказчик такой «а давайте вот такую финтифлюшку добавим». А найденная библиотека эту финтифлюшку не поддерживает. И начинаются лютые костыли.

Пока не вижу минусов. Быстрый выход с тем что есть. Не устраивает библиотека — форк и доработка. Или начать делать своё, но уже с пониманием, что надо получить.

Здравствуйте, Nuzhny, Вы писали:


N>Пока не вижу минусов. Быстрый выход с тем что есть. Не устраивает библиотека — форк и доработка. Или начать делать своё, но уже с пониманием, что надо получить.

Ну, в идеальном мире — да. И форки существуют и время тебе дают

Здравствуйте, Hоmunculus, Вы писали:

H>Ну, в идеальном мире — да. И форки существуют и время тебе дают

Так альтернатива какая? Заказчик разрешает разрабатывать самому весь софт, начиная с ОС и драйверов?

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Hоmunculus, Вы писали:

H>>Ну, в идеальном мире — да. И форки существуют и время тебе дают

N>Так альтернатива какая? Заказчик разрешает разрабатывать самому весь софт, начиная с ОС и драйверов?

Я же сказал — «медаль о двух сторон». Да, с библиотеками удобнее. Но иногда это выливается в жопу. Я не говорил писать ОС, компилятор и IDE с нуля

Здравствуйте, Hоmunculus, Вы писали:

H>Я же сказал — «медаль о двух сторон».

Так какая же отрицательная сторона? Я и написал, что твой минус по факту — это не минус, потому что он наступил бы в любом случае.

Здравствуйте, Nuzhny, Вы писали:

H>>Я же сказал — «медаль о двух сторон».

N>Так какая же отрицательная сторона? Я и написал, что твой минус по факту — это не минус, потому что он наступил бы в любом случае.

Есть минус: чужой алгоритм, протокол, библиотека, программа, ОС, процессор, железо, мир — дыры в безопасности.

Как проводить аудит всего этого хозяйства и как защититься от закладок в них на всех уровнях?

Если это не смущает, то это есть плюс: возникающий баг в них может быть устранён поднятием версии

Здравствуйте, Nuzhny, Вы писали:

H>>Я же сказал — «медаль о двух сторон».

N>Так какая же отрицательная сторона? Я и написал, что твой минус по факту — это не минус, потому что он наступил бы в любом случае.

Минус в том, что завязавшись на библиотеки, вы существенно сужаете пространство возможностей, но ускоряете разработку особенно на старте. И это выстреливает внезапно — багфикс, секурити фикс, новая фича, перформанс, поддержка новых ОС/платформ и тд.
Стоимость обслуживания здесь всегда растет и почти всегда не вашу пользу — чужие зависимости вам не подчиняются. И их как правило много больше, чем кода в вашем приложении. И регулярно это создаёт проблемы.
Одни лицухи могут доставить вагон геморроя.

В своём коде у вас основной минус в том, что большую часть егу нужно писать самому, вы медленнее стартуете проект/фичи, но ядро приложения у вас обычно лучше приспособлено к изменениям.
Мейнтенанс здесь обходится гораздо дешевле — такое работает десятилетиями.

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

Здравствуйте, Pauel, Вы писали:

P>Минус в том, что завязавшись на библиотеки, вы существенно сужаете пространство возможностей, но ускоряете разработку особенно на старте. И это выстреливает внезапно — багфикс, секурити фикс, новая фича, перформанс, поддержка новых ОС/платформ и тд.

Ну так это в две стороны работает: начал писать своё, а потом оказывается, что надо поддерживать ещё другие ОС/платформы, страдает перформанс и т.д. А открытая библиотека силами сообщества или крупного вендора уже всё это умеет.

P>Одни лицухи могут доставить вагон геморроя.

Так можно смотреть на них ДО того, как тащить проект к себе.

P>В своём коде у вас основной минус в том, что большую часть егу нужно писать самому, вы медленнее стартуете проект/фичи, но ядро приложения у вас обычно лучше приспособлено к изменениям.

Ещё есть минус: пишешь своё, пишешь, тратишь время и деньги, а потом не хватает ни времени, ни денег на бизнес-логику и всё летит к чертям.

Альтернатива: берёшь библиотеку, выкатываешь релиз, тестируешь, начинаешь развиваться, получать отзывы и хотелки пользователей, понимаешь, как надо и: либо пишешь своё и правильно, или модифицируешь библиотеку. Рисков при использовании открытых библиотек намного-намного меньше, вероятность факапа ниже. Другое дело, если ты уже в курсе всего, предметная область знакома, все шишки набиты, есть понимание конкурентного преимущества — да, тогда и только тогда можно и нужно писать своё.
С теми же нейросетями умерло много разных фреймворков (Theano умер, MxNet умер, просто Torch умер), даже именитый TensorFlow от Гугла практически умер (версия 1.х), они купили Керас и сделали совсем другой TensorFlow 2.0, который потребовал переписать всё, что было. И то он скорее мёртв, чем жив. Да, в этом случае многие начали писать своё, но по факту прыгать по открытым фреймворкам оказалось выгоднее, чем тратить ресурсы на своё, которое потом умерло. Потому что легче найти специалистов, есть уже документация, есть поддержка и т.д.
Стратегия пляски через готовые библиотеки и в короткой, и в длительной перспективе выгоднее всегда. Своё — всегда большой риск, на кторый стоит идти сознательно и хорошо подготовленным.

N>>Пока не вижу минусов. Быстрый выход с тем что есть. Не устраивает библиотека — форк и доработка. Или начать делать своё, но уже с пониманием, что надо получить.

H>Ну, в идеальном мире — да. И форки существуют и время тебе дают

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

Здравствуйте, Shmj, Вы писали:

S>Насколько вы уделяете внимание знанию не основ а именно знанию библиотек и существующих решений?
Объехать ChatGPT по общей эрудиции — ну, такая себе специальная олимпиада.
Если речь идёт о какой-то специфической предметной области, на изучение которой вы можете потратить 1-3-5 лет, то да — вы будете легко и непринуждённо поправлять любую LLM в ответах на вопросы в рамках этой области.
А когда на вас внезапно сваливается какая-нибудь штука, которой вы либо вообще не занимались, либо занимались этим "давно и неправда", то LLM прекрасно подойдёт.
Потому что альтернатива — учить наизусть вообще все библиотеки, в надежде на то, что это когда-то пригодится — бессмысленна и невыполнима.
Тем более, что эти библиотеки и существующие решения появляются и исчезают ежедневно.
Так что лично я изучаю только то, что мне стало интересно по какой-то конкретной причине.

Здравствуйте, Pauel, Вы писали:

P>Минус в том, что завязавшись на библиотеки, вы существенно сужаете пространство возможностей, но ускоряете разработку особенно на старте. И это выстреливает внезапно — багфикс, секурити фикс, новая фича, перформанс, поддержка новых ОС/платформ и тд.
P>Стоимость обслуживания здесь всегда растет и почти всегда не вашу пользу — чужие зависимости вам не подчиняются. И их как правило много больше, чем кода в вашем приложении. И регулярно это создаёт проблемы.

Как-то странно рассуждать о таких вещах без использования примеров.
Вот если взять мир C/C++...

Есть библиотека Qt. Её использование, конечно же, связано с некоторыми ограничениями.
Или, как альтернатива Qt для специфических применений, Dear ImGUI. С ней так же связан ряд ограничений.

Только вот делать своими силами альтернативы Qt или Dear ImGUI... Так себе идея, мягко говоря.

Или взять libcurl.
Какой-нибудь наивный и излишне самоуверенный вюьноша (вне зависимости от возраста и пола), может решить, что можно самому на коленке собрать простенького самодельного HTTP-клиента. Только вот есть сильное подозрение, что как раз с базфиксами, секурити, новыми фичами, перфомансом, поддержкой новых ОС/платформ как раз у самодельного решения проблем будет больше.

Или, скажем, ffmpeg. Делать для него альтернативу своими силами и повторять, хотя бы частично, то что там реализовано? Попахивает самоубийством.

Тему библиотек, связанных с криптографией, наверное, и вообще затрагивать не стоит.

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

Здравствуйте, so5team, Вы писали:

S>Я это к тому, что примеры библиотек, без которых в той или иной области не обойтись, находятся сходу.
S>А вот с примерами библиотек, которые можно заменить самодельными аналогами уже посложнее.

Обычно наоборот — в проекты обычно тащут вообще всё, что только могут. Такое и в дотнете, и в джаве, и где угодно. Сейчас это в жээсе и питоне, из последнего.

Здравствуйте, Nuzhny, Вы писали:

N>Ну так это в две стороны работает: начал писать своё, а потом оказывается, что надо поддерживать ещё другие ОС/платформы, страдает перформанс и т.д. А открытая библиотека силами сообщества или крупного вендора уже всё это умеет.

Да, бывает и так.

P>>Одни лицухи могут доставить вагон геморроя.
N>Так можно смотреть на них ДО того, как тащить проект к себе.

Интересуют вопросы не "до", а именно что после — смена лицензии у пакета, или изменение статуса с "можно" на "нельзя".


N>Стратегия пляски через готовые библиотеки и в короткой, и в длительной перспективе выгоднее всегда.

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

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

Есть простое объяснение — буде такая библиотека в наличии, любой, сколь угодно большой продукт сведется к одной функции — вызову из той самой библиотеки.

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

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

Здравствуйте, Pauel, Вы писали:

S>>Я это к тому, что примеры библиотек, без которых в той или иной области не обойтись, находятся сходу.
S>>А вот с примерами библиотек, которые можно заменить самодельными аналогами уже посложнее.

P>Обычно наоборот — в проекты обычно тащут вообще всё, что только могут. Такое и в дотнете, и в джаве, и где угодно. Сейчас это в жээсе и питоне, из последнего.

А можно конкретные примеры?

Скажем, в проекте у текущего заказчика (на C++) используется несколько библиотек для работы с JSON: местами C++ REST SDK, местами RapidJSON, местами Glaze. Причины банальные: начали с одного, со временем убедились, что не вывозит, попробовали другое, потом третье. При этом большие куски кода, написанные, скажем на C++ REST SDK, пока не переписывали -- справляется со своей задачей, а времени на рефакторинг нет.

Так же используется две библиотеки для работы с bitset-ами: boost::dynamic_bitset и roaring. Можно было бы, наверное, оставить только один roaring, но местами более простой и менее продвинутый boost::dynamic_bitset более эффективен.

Так же есть несколько вариантов взятых из других библиотек контейнеров (типа hash-map-а из Folly или sparsetable от Google).

Причем переписать своими руками, наверное, без проблем можно было бы разве что boost::dynamic_bitset. На остальное у среднестатистического участника проекта просто не хватило бы квалификации.