Что не нужно кодить самостоятельно

    Недавно написал свой велосипед и выложил его на хабре. Вот он: «Простейший Connection pool без DataSource в Java». Статья не из самых удачных, только прошу больше не минусовать. Итак, чтобы не повторять такие ошибки самому и, возможно, предостеречь кого-то от таких ошибок, решил перевести статью «Seven Things You Should Never Code Yourself» достаточно известного в среде open-source деятеля IT-области — Andy Lester'а. Итак, кому интересно, прошу под кат.

    Мы, программисты, любим решать задачи. Мы любим, когда идеи возникают в наших головах, перенаправляются на наши пальцы и тем самым создаются великолепные решения.

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

    Например, если вы столкнетесь с одной из этих семи задач программирования, то почти всегда вам лучше поискать существующее решение, чем пытаться реализовывать что-то самостоятельно:

    1. Парсинг HTML или XML


    Задачей, сложностью которой зачастую пренебрегают, по крайней мере на основе того, сколько раз про него спросили на StackOverflow — является парсинг HTML или XML. Извлечение данных из произвольного HTML выглядит обманчиво просто, но на самом деле эта задача должна решаться применением библиотек. Скажем, вы хотите извлечь URL из тега такого, как

    <img src="foo.jpg">
    

    На самом деле это простое регулярное выражение, которое соответствует шаблону.

    /<img src="(.+?)">/
    

    Строка “” будет выдана в результатах поиска по шаблону и она может быть присвоена строковой переменной. Но будет ли такой код находить нужные значения в тегах, в которых имеются другие атрибуты:

    <img id="bar" src="foo.jpg">
    

    После изменения кода, чтобы он обрабатывал такие случаи, будет ли он рабочим, если кавычки имеют другой вид:

    <img src='foo.jpg'>
    

    или кавычек не будет вовсе:

    <img src=foo.jpg>
    

    Что делать, если тег занимает несколько строк и является самозакрывающимся:

    <img id="bar"
    src="foo.jpg"
    />
    

    И будет ли ваш код знать, игнорировать ли закомментированные теги:

    <!--
    <img src="foo.jpg">
    -->
    

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

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

    2. Парсинг CSV и JSON


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

    # ID, name, city
    1, Queen Elizabeth II, London

    Безусловно, пока вам не придется иметь дело с запятыми, заключенными в двойные кавычки:

    2, J. R. Ewing, "Dallas, Texas"

    Если вы решили проблему с использованием таких двойных кавычек, что будет, если в строке будут встроенные кавычки, которые нужно пропустить:

    3, "Larry \"Bud\" Melman", "New York, New York"

    Вы можете справиться и с этим, пока не придется иметь дело с переводами строк в середине записи.

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

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

    Если чтение структурированных данных неструктурированным методом считается плохой практикой, то идея изменять данные на месте еще хуже. Люди часто говорят что-то вроде «Я хочу изменить все теги с такими-то и такими URL так, чтобы у них появивлся новый атрибут.» Но даже такое, казалось бы, простое дело, как «Я хочу изменить в каждом пятом поле в этом CSV имя Боб на Стив» таит в себе опасность, потому что, как было отмечено выше, вы не сможете считывать запятые должным образом. Чтобы все было правильно, вам необходимо прочитать данные с помощью грамотной библиотеки во внутреннюю структуру, изменить данные, а затем записать измененные данные обратно с помощью той же библиотеки. Ничто не представляет такой риск искажения данных, как если их структура не соответствует вашим ожиданиям.

    3. Проверка Email адресов


    Есть два способа проверки адреса электронной почты. Можно проверить по-простому, сказав, «мне нужно иметь некоторые символы перед знаком @, а затем какие-то символы после него», эту идею реализует регулярное выражение:

    /.+@.+/
    

    Оно, конечно же, не полное, и допускает наличие неверных элементов, но по крайней мере мы имеем знак @ посередине.

    Или вы можете проверить на соответствие правилам RFC 822. Эти правила покрывают все случаи, которые встречаются редко, но все же допустимы. Простое регулярное выражение не выдает такой срез. Вам придется использовать библиотеку, написанную кем-то другим.

    Если вы не собираетесь проверять на соответствие RFC 822, то все, что вы делаете будет использованием правил, которые могут казаться разумными, но могут оказаться и не правильными. Этот подход является компромиссным, но не обманывайте себя, думая что вы охватили все случаи, если в итоге вы не обратились к RFC, или просто используйте библиотеку, написанную кем-то другим.

    (Для дальнейшего обсуждения вопроса валидации электронных адресов, см. Stackoverflow)

    4. Работа с URL


    URL-адреса не столь противны, как адреса электронной почты, но они по-прежнему полны раздражающих мелких правил, которые вы должны помнить. Какие символы должны быть закодированы? Как вы обрабатываете пробелы? Как насчет знаков +? Какие символы могут идти вслед за знаком #?

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

    5. Работа с датой/временем


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

    Будь то для арифметики c датами, сводящейся к вычислению даты, которая настанет по прошествии трех дней от определенной даты, или для валидации строки на входе на соответствие формату даты, используйте существующие библиотеки.

    6. Системы шаблонов


    Это почти обряд посвящения. Младший программист должен создать огромное количество шаблонного текста и придумывает какой-нибудь простенький формат наподобие:

    Dear #user#,
    Thank you for your interest in #product#...

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

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

    7. Фреймворки для логирования


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

    Не является ли библиотека излишеством?


    Перед тем, как относиться с пренебрежением или презрением к идее подключения стороннего модуля, следует обратить пристальное внимание на ваши протесты и возражения. Первое возражение обычно такое: «Зачем мне нужна целая библиотека просто для того чтобы сделать это (проверить эту дату/распарсить этот HTML/и т.д..),» Мой ответ: «А что в этом плохого?» Вы же, скорее всего, не пишете код микроконтроллера для тостера, где вы должны выжать каждый байт пространства для кода.

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

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

    Примечание переводчика:
    Кстати, последний абзац очень гармонично перекликается с основной идеей из статьи «Как улучшить свой стиль программирования?».
    UPD1. Список инструментов по основным языкам программирования, разбитых по категориям: awesome-awesomeness (ссылка предоставлена hell0w0rd в комментариях, ему отдельное спасибо).
    Поделиться публикацией

    Комментарии 52

      +1
      Спасибо за статью. Но мне, как молодому разработчику, было бы интересно и полезно увидеть реальные примеры решений, ссылки на библиотеки, которые лучше всего использовать. С этим Ваша статья станет еще более полной и исчерпывающей.
        +4
        Это зависит от языка, конечно же. Я лично могу советовать только в области Java и Python. А так, гугл поможет по любому языку. Насчет Java и Python по каждому пункту могу написать в личке, если интересно.
          0
          в статью Java и Python! Уверен, что ребята добросят добра и для Ruby, и для PHP
            0
            Не только от языка, но и во многом от операционки. В одном случае при разработке Windows-программы мне оказалось предпочтительнее написать на Delphi собственный XML-парсер, т. к. разработчики программ аналогичного назначения поимели сложностей с Microsoft XML Parser — в основном, отсутствие парсера нужной версии на компе у пользователя или глюки с созданием соответствующего объекта. Потом в моём парсере потребовалось сделать только оптимизацию для ускорения его работы, но вопросов по запуску программы не было ни у кого.
            +8
            Э-э… для какого языка? Может сами поищите, а то вам все найди да в рот положи пример решения приведи…
              –1
              Аналогично с остальными для perl
              Пишите в личку, если что=)
                +1
                Что конкретно для Perl интересует? CPAN большой :) Могу сказать, что у меня в работе в основном XML::XPath и HTML::Tree, если говорить о первых пунктах. Но это далеко не единственные решения, ибо TMTOWTDI, хоть и Perl::Modern.
                  +1
                  Прошу меня простить, я наверное неправильно выразился. Вообще я имел ввиду, что могу оказать помощь=)
                  Но всё равно спасибо за то, что отозвались, в чём-то я всё ещё остался начинающим.
                +34
                github.com/bayandin/awesome-awesomeness — выбирайте ваш язык и найдете почти все популярные решения.
                  +2
                  ссылка супер!
                    +4
                    Еще одно подтверждение, что сила хабра — в комментариях.
                  +2
                  Что думаете насчет своего ORM?
                    +1
                    Только если это оправдано. Писать свой ORM только потому, что Not Invented Here, глупо. Только если есть конкретные причины, по которым ни одно из готовых решений под нужный язык не подходят
                      +1
                      Под аргументом «только если это оправдано» можно и нужно писать что угодно — начиная от собственного механизма разбора регулярных выражений, то ORM )
                      0
                      Если есть проект, а в нем Вы пишите свой ORM, практически всегда это не оправдано. А если команда маленькая, Вы, считай, выкидываете разработчиков из проекта, кидая их только на написания какого-то внутреннего инструментария, неизвестно в каком виде еще получившегося. Чтобы такое делать, надо очень четко понимать, почему имеющиеся на рынке инструменты для Ваших задач не подходят.
                      +23
                      Странно, что автор оригинальной статьи не упоминает вопросы криптографии. На мой взгляд — это именно то, где писать что-то свое не только глупо, но и крайне опасно.
                        +1
                        Да, пожалуй этот пункт должен идти 1м, 2м, 3м и 5м одновременно
                        +4
                        как говорила одна знакомая: «если можешь не кодить самостоятельно — не кодь».
                          +4
                          В примере для CSV у пас некорректный формат. Экранирование кавычек в CSV осуществляется их дублированием. Так что не факт: что выбранная вами библиотека справится с этой строкой. По крайней мере у LibreOffice это не получилось.
                          Имхо, как раз из всего списка самая простая задача — это парсинг csv: gist.github.com/krypt-lynx/c64420a3b5a9d739b174 (сложность — O(n))

                          А вообще, имхо, велосипеды писать полезно — в меру простые задачи неплохо тренируют мозг. Главное, чтобы это было не написание регулярок. И чтобы они не попадали в продакшн коммерческого проекта
                            –2
                            И вы в каждый проект, где вам понадобится парсить CSV, вместо использования готовой библиотеки будете вставлять этот милый «сниппет» на 170 строк? Или, не дай бог, писать каждый раз с нуля?
                              +3
                              А чем он хуже существующих решений? Особенно учитывая, что он использовался в консольной тулзе для модмейкеров одной из игр и нареканий на его работу не поступало?

                              Учитывая, что
                              — Сниппет уже реализован
                              — Представляет из себя полный пригодный для компиляции.cs-файл
                              — В этом нём содержится чтение и запись csv
                              — Спустя полтора года после его создания я всё ещё могу понять как он работает
                              — Встроенных средств парсера csv в C# нет

                              То почему бы и нет?
                                0
                                Ну и забыл самое главное — все найденные решения представляют из себя такие же разработки на коленке, как и эта. Причём в довольно большом количестве.
                                0
                                Готовая библиотека — это готовый код, оформленный в библиотеку. Почти ничем не лучше готового кода, оформленного в сниппет. Лишь не забывай источник и не упускай обновлений.

                                «Готовый код» тут главное же!
                              +4
                              Самобалансирующиеся деревья, сложные алгоритмы сортировки. Как лабораторную стоит, в рабочий код — нет.
                                –1
                                С чего бы? Вы алгоритмы для галочки учите, или чтобы дальше модифицировать, под конкретную задачу?
                                  +2
                                  С точки зрения практики стоит изучать алгоритмы, чтобы свободно выбирать их и структуры данных под задачу. Ну и понимать что происходит в процессе. А не чтобы на гора выкатить самопальные красно-черные деревья.
                                    +1
                                    Ну, я не согласен с этой позицией. Есть множество проектов, которые сами пишут какие-то алгоритмы, и за счет этого выигрывают. Например движки БД модифицируют те же красно-черные деревья для индексов.
                                    Что бы вы не писали — всегда найдется как модифицировать использующиеся алгоритмы под ваши цели. Ну а в статье упоминаются шаблонные задачи, вроде логирования, или валидации, для которых вероятно можно сразу найти приемлимое решение.
                                +2
                                Оформите топик как перевод — вы упоминаете в это в тексте, но ссылки в блоке после статьи нет. В кой-то веки проверил перевод ли это проверкой соответствующей плашки после названия…
                                  +1
                                  У статьи очень неправильный заголовок. Она должна называться как-то типа «перечень проблем которые вы должны рассматривать при написании...»

                                  Cвой HTML/XML парсер я написал когда уже было как минимум несколько библиотек включающих нужную функциональность.

                                  В результате получился самый быстрый HTML/XML парсер который еще и не аллоцирует никакой памяти в процессе работы. В смысле вообще.

                                  Писать свое или не писать это многофакторый анализ зависящий от постановки задачи. «Не всё так однозначно» (С) все знают кто.
                                    +2
                                    Мне кажется, что когда сам пытаешься что-то писать, то получается некоторое «приближение». Например, я почти уверен, что Ваше решение не поддерживает namespaces в XML. И скорее всего не разворачивает entities. В итоге в первом приближении решение работает, но возможно в процессе работы его надо будет еще допиливать и допиливать, и в итоге вырастет классическое библиотечное решение, только со своими ошибками. Хотя, если известно что парситься будет некоторое «подмножество» XML, то почему бы и не воспользоваться таким «велосипедом».

                                    А обычные SAX парсеры разве много аллоцируют памяти в процессе работы? Наверняка константу — почему их не взяли?
                                      +1
                                      «я почти уверен, что Ваше решение не поддерживает namespaces в XML.» ну и зря. Поддерживается там namespaces. В том смысле что при парсинге чего-то типа
                                      <f:name>African Coffee Table</f:name> в scanner.get_tag_name() будет «f:name».
                                      «И скорее всего не разворачивает entities» и это тоже не так :) Там наличесвует virtual wchar resolve_entity(...). Каждый markup language имеет свой допустимый набор entities.

                                      «SAX парсеры разве много аллоцируют памяти в процессе работы» — да. Причем никогда не известно сколько — опредляется входным документом. Что в embedded условиях, скажем, вообще не приемлемо.

                                      И потом SAX парсер это push-parser со всеми вытекающими. У меня же классический pull-parser.
                                      И еще… HTML, например, обычным XML parser'ом распарсить вообще нельзя. На элементе <img> XML парсеру становится плохо. Да и потом HTML считается валидным даже если он не содержит <html> вообще.

                                      А вообще тот парсер писался как раз для того что-бы не писать каждый раз новый лисапет ибо мой вариант это SGML tokenizer, т.е. для HTML и XML. Используется как составная часть HTML, XML и SVG парсеров в моём sciter например. Я знаю что он используется в SVG renderer внутри некоторых знаменитых игрушек, во встраиваемых девайсах и… много где на самом деле — лень перечислять.

                                      В том-то и противоречивость данной статьи. Каждый существующий HTML/XML парсер это коллекция велосипедов сам по себе. Вот зачем нужно каждый раз писать tokenizer если он всегда имплементирует одну и ту же state machine?

                                      Вот и твоя статья про тоже — вместо своего велосипеда возьми чужой. И надейся что он будет лучше. При каких-то условиях — несомненно, ибо человек ленив по определению «зачем делать дурную работу».

                                      Можешь рассказать это скажем Microsoft которая сделала свой SSL велосипед, а не взяла существующий лисапед на котором катались все. И все скопом и докатались.

                                        +4
                                        Велосипеды разные бывают, очевидно же.

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

                                        И совсем другое, когда начинающий программист думает: а нафига мне тащить целую библиотеку? Давай-ка свой костылёчек на коленке накатаю… И в конечном итоге кучу времени тратит не на что-то действительно полезное, а на заматывание изолентой каждой трещинки в этом костыле, который с каждым разом становится только кривей. Не самое осмысленное занятие, IMHO.
                                          +1
                                          Вот, например, даже Oracl для парсинга XML брал (берет?) стороннюю библиотеку sax-парсер.
                                          И я ее тоже взял — libexpat. И быстро, и лицензионно чисто, и оберток куча (для Delphi в том числе).
                                          Памяти есть столько сколько скажешь, многогигабайтные файлы ест без проблем.
                                          Что еще надо для счастья?
                                            +1
                                            xpath запросы ) Но — мечты, мечты. DOM медленный и есть много памяти.
                                            Впрочем, простейшие запросы можно реализовать и без DOM…
                                            В общем, вот простор для велосипедов: SAX XML парсер с поддержкой xpath (или хотя бы его подмножества) ;)
                                              0
                                              Интересовался недавно этим вопросом — таких парсеров уже много. И, вроде, даже стандартные Saxon и Xalan уже поддерживают такое.
                                            0
                                            Это я бы не назвал поддержкой namespace.

                                            Формально два следующих XML — одинаковы:
                                            <root xmlns:b="http://banana.com">
                                              <b:banana id="1"/>
                                            </root>
                                            


                                            <root xmlns:n="http://banana.com">
                                              <n:banana id="1"/>
                                            </root>
                                            


                                            В вашем же парсере надо немного попрыгать с бубном чтобы это понять.

                                            Имя тега в обоих случаях должно быть «banana» (а не b:banana и n:banana), и namespace в обоих случаях должен быть «banana.com»

                                            То, что HTML это не XML — я согласен — его нельзя разбирать обычными XML парсерами, но и тут уже хватает библиотек.

                                            Насчет велосипеда SSL и Микрософта — хоть он и не был подвержен Heartbleed, там хватало своих багов — вот, навскидку — www.symantec.com/security_response/attacksignatures/detail.jsp?asid=20448. Если бы MS взяло бы «общественный» велосипед, возможно, Heartbleed нашли бы намного раньше, возможно, даже на этапе тестирования в Редмонде.
                                        +2
                                        Как ни печально, но это глобальная проблема программирования — всё уже украдено написано за нас. И я думаю, что со мной многие согласятся в том, что разработка сейчас и разработка лет 10 назад — это две большие разницы. Сейчас всё сводится к банальному увязыванию между собой горстки библиотек и плагинов/экстеншенов к ним. Интересным остаётся только создание какого-то узкоспециализированного софта/устройств. Мне, например, такие проекты запомнились больше всего. Но и в эту сферу библиотеки всеми силами тянут свои грязные ручонки…
                                          +1
                                          Вот так и появляются вирусы микропрограммы на пару десятков килобайт, требующие .NET. Одно дело — когда действительно нужно всё предусмотреть (допустим в парсере HTML). Другое дело — когда нужна всего-лишь одна функция. Вот потому я очень люблю OpenSource. Всегда можно дёрнуть нужную функцию из исходного кода библиотеки, не прибегая к подключению всей библиотеки.
                                              +3
                                              Что не нужно кодить самостоятельно?

                                              Все. Для почти всех задач есть готовые библиотеки для популярных языков и фреймворков, код которых вылизан не одним программистом и не за один год.
                                              Для решения проблем есть (гугл) Хабр и StackOverflow — только не стоит переносить оттуда сам код посредством Copy&Paste, комбинируйте, изменяйте и улучшайте решения, подходящие именно Вам.

                                              А что _нужно_ кодить самостоятельно?
                                              1. То же самое, но что никогда не попадет в продакшн — для самообразования. Лучший способ понять принцип работы — попытаться заново ее изобрести. Даже если Вам Ваше решение кажется уникальным — спешу разочаровать, на свете есть люди, у которых были похожие проблемы и путь их мышления был схож с Вашим.
                                              2. Костыли. Шутка: не всегда готовая библиотека лишена багов или покрывает Ваш случай 100%. Но подумайте еще раз: быть может, Вы просто слишком мало искали и нашли не совсем нужное, а копать надо совсем в другом направлении?
                                              3. То, чего совершенно точно нет в Сети — случай редкий, но возможный. Пишите, но не делайте этого в одиночку — отдайте в опенсорс, набирайте единомышленников-коммитеров. Так Вы не только быстро добьетесь годного, стабильного кода, но и достигнете славы; да и в резюме будет что написать с гордостью.
                                                +1
                                                1. Чем хуже я программирую, тем больше я должен программировать, чтобы лучше понять, как это работает.
                                                2. Чем лучше я программирую, тем меньше я должен программировать и больше интегрировать готовые решения под свои нужды.
                                                  +4
                                                  Статья интересная и, безусловно, полезная. Но она заставила меня вспомнить фразу «не наступая на грабли вы лишаете себя бесценного опыта». Разве можно стать программистом не создавая велосипеды? А на чём тогда учиться? Зачем вообще учиться? Если все перестанут кодить и начнут просто собирать решения из готовых библиотек — кто будет писать библиотеки через 50 лет?

                                                  Писать велосипеды только «для себя», а в продакшн пускать библиотеки? Сомнительный подход, для себя никогда не будешь работать так хорошо, как под угрозой перехода твоего кода в продакшн. А значит и должного внимания не проявишь и потенциальных знаний недополучишь.

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

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

                                                  Философия, короче.
                                                    0
                                                    Вряд ли «все перестанут кодить». Безусловно, работа программиста постепенно трансформируется в нечто новое, но, имхо, так или иначе необходим будет интеллект. Если же все можно будет поручить машине, не придем ли мы к тому самому «восстанию машин»?
                                                    А в ином случае — что мешает идти постоянно в ногу со временем? Не пытаетесь ли Вы в примере с табуреткой жаловаться на то, что любимые лошадиные повозки исчезли и все вдруг начали ездить на автомобилях и забыли, как лошади веками помогали человеку путешествовать?

                                                    Вот как и я, ощущаю себя почти динозавром, сравнивая, как сейчас фокус веб-разработки смещается с сугубо системно-серверного программирования а-ля cgi-скрипты на браузерные платформы, и совсем по-стариковски ворчу, что джуниоры не знают сетевых протоколов, а то и даже не приемлют статическую типизацию — в то время, когда я, обладая обширными знаниями и глубоким пониманием, нынче могу этими знаниями подтереться, а изучать новые популярные технологии (фреймворки, библиотеки) просто не успеваю, когда они это знают сразу…

                                                    Но вообще будущее еще менее определено, чем его пытаются придумать…
                                                      +1
                                                      Дело не в лошадях.

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

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

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

                                                      В программировании много ли сейчас людей, знающих машинные коды? Или хотя бы ассемблер? Помнящих о распредеолении и выделении памяти? Это всё по сути уже умерло для абсолютного большинства людей, это делают машины. Скоро и библиотеки будут писать машины. И с одной стороны оно, конечно, хорошо — люди наконец смогут решать свои задачи, использую машины как инструмент, а не решать проблемы программирования, которые по сути к решению задачи не относятся. Но если случится необходимость начать с начала — путь придётся проходить с начала полностью, нельзя будет просто взять и сделать ещё раз то что уже когда-то сделал, потому что никто не будет знать как это делать. Некому будет залезть в библиотеку и исправить метод, залезть в компилятор и исправить баг, залезть в ассемблер и исправить обращение к регистру, залезть в машинные коды и исправить интерпретацию ассемблера, залезть в железо и исправить сбоящий автомат. В случае если библиотека не работает — можно будет только искать другую библиотеку, созданную на другом компьютере.

                                                      В случае с лошадьми проблема не в том что мы не используем лошадей, проблема в том что если полностью автоматизировать создание машин — мы будем ездить на машинах. А если что-то случится с автоматическим их производством — мы тут же вынуждены будем вернуться к лошадям. Потому что не будет уже людей, способных создавать машины. За ненадобностью.

                                                      Говорю же — философия.
                                                        +1
                                                        Дело не в том, что мы не пользуемся старым, дело в том, сможем ли мы воспользоваться старым, если что-то случится с новым?
                                                        Вспомните ли Вы телефон матери, если Ваш смарт вдруг навернется? Как быстро мы освоим лошадей, если производство автомобилей остановится?
                                                        Я лет 10 не использовал ассемблер, но если надо будет — прочту код и разберусь, а поднатужившись — и напишу, хотя материться буду громко и витьевато. Зато я знаю, как лучше писать высокоуровневый код, чтобы он не страдал излишествами для машины или какое решение было бы лучше.
                                                        И ворчу лишь потому, что часто наталкиваюсь на точку зрения «мне это не нужно, значит, никому не нужно, а если никому не нужно — то это отстой и ты зря потратил годы».
                                                          +2
                                                          между «я уже лет 10 не использовал ассемблер» и «а что такое ассемблер?» лежит та пропасть о которой я говорю. Через 50 лет кто будет писать библиотеки? Сейчас мы в переходном периоде, когда мы ещё знаем старое, но уже видим и пользуемся новым. Что будет, когда старое будет не просто забыто, а вырастет поколение вообще ничего о нём не знающее?

                                                          Как понять является ли это старое фундаментом, необходимым каждому для дальнейшего движения или это пережиток прошлого, о котором можно забыть как о тёмном веке? На мой взгляд человек который не пишет велосипедов для продуктива не может быть программистом. Да, современные и новые инструменты дадут ему возможность создавать программы, но не потому что он программист, а потому что инструменты стали очень удобными и простыми. А забери у такого его ИДЕ и набор библиотек и всё, даже хелло ворлд в джаве не скомпилирует. А дальше эта ситуация будет только усугубляться.
                                                    0
                                                    О! А я ухитрился нарушить все, кроме третьего и последнего, пункты сразу, когда писал свои дополнения для Vim:
                                                    1. XML парсера на VimL я просто не нашёл. (Сейчас есть WebAPI.vim, но это сейчас. Да и WebAPI содержит не pull парсер, и даже не push. Ждать парсинга всего документа мне было не с руки).
                                                    2. То же самое про JSON парсер. Бо́льшая часть людей довольствовалась eval, что небезопасно. (Сейчас тоже есть WebAPI.vim).
                                                    3. Проверки адресов мне не были нужны.
                                                    4. Библиотеку с urlescape я даже не искал.
                                                    5. Тот примитив, что у меня (взять дату в одном формате и скормить её дальше в несколько другом, не пытаясь как‐либо обработать вещи вроде часовых поясов) нельзя назвать полноценной работой с датами. Но это всё же есть.
                                                    6. Библиотеку с шаблонами я тоже не искал: что‐то точно было, но вероятность найти библиотеку шаблонов, которая позволит без серьёзной доработки создать подсветку синтаксиса для результата использования шаблона, была весьма призрачна. Особенно учитывая отсутствие поддержки установки зависимостей в большинстве решений для установки дополнений Vim и, как следствие, малое число библиотек.
                                                    7. Логирование я у себя не делал.


                                                    Кстати, а почему в списке нет пункта про frawework’и для тестирования? Они, как и код для логирования, имеют тенденцию разрастаться от простого к сложному: сначала вам нужно просто сравнить две строки, затем вам уже хочется сравнивать строки параллельно (нечего второму/… ядру простаивать), потом ещё внятные сообщения о том, где и что сломалось, сводки, …
                                                      +1
                                                      Когда я искал библиотеку для разбора URL для c++, то наткнулся на ряд проблем:
                                                      1. Qt в том коде я использовать не мог. Да и к тому же QUrl излишне переусложнён и неудобен.
                                                      2. И выбирать больше не из чего.

                                                      В chrome и firefox написан отдельный код для разбора URL, но он… не работает по стандарту. Причём «не по стандарту» у них разное. В обоих случаях, например, туда добавлена поддержка emule, URL'ы которого таковыми на самом деле не являются. Да и вообще код в обоих случаях не выделен в виде отдельной библиотеки и использует внутренние типы.

                                                      В итоге да, я написал свой класс + набор вспомогательных функций. Всё не доходят руки прикрутить туда кодирование/декодирование punicode (мне не нужно, работаю только со своими URL'ами), только это и останавливает от выкладывания на github.
                                                        +1
                                                        С JSON в C++ тоже всё плохо. Т.е. мы пользуемся, конечно, сторонней библиотекой, но в своё время я перебрал около 10, и они все оказались плохими. Какие-то медленные, какие-то неудобные, какие-то вообще с ошибками.
                                                        А уж если затрагивать Binary JSON, то там всё ещё хуже — я знаю 5 разных «стандартов», и они все не подходят для моего случая (малое количество чтений/быстрое смещение к соседнему элементу/быстрый поиск по ключу/аппаратные типы и смещения). В итоге отказался от него совсем в пользу отдельного бинарного формата.
                                                          0
                                                          В общем, из комментов явно видно, что нифига не «всё написано до нас», и велосипеды строить придётся ещё очень много и долго.
                                                            +1
                                                            Понимаю, что слоупочу, но есть еще одна задача, с которой сталкиваюсь часто, вижу, как другие сталкиваются часто, и решается всегда велосипедами. Может быть кто-то знает универсальное реюзабельное решение?

                                                            Задача — описание логики для фильтрация-классификация чего угодно (структур данных), по правилам, которые поставляет юзер.
                                                            Например (на псевдокоде):

                                                            1. Файрвол
                                                            разрешить трафик, если src.ipaddr == 1.2.3.4 and dst.port== 80
                                                            или даже:
                                                            goodip=('1.2.3.4', '5.6.7.8')
                                                            разрешить, если src.addr in goodip

                                                            2. К 8 марту выплатить премию всем женщинам, кроме отдела маркетинга:
                                                            назначить премию, если person.gendder=='F' and person.department != 'marketing'

                                                            3. Всем с детьми от 3 и больше:
                                                            count(person.child)>=3

                                                            Можно свой интерпретатор написать простенький (но если простой — то постоянно будешь сталкиваться с нехваткой фич, или багами велосипеда). Можно в песочнице вызывать какой-нибудь урезаный python или lua, но во-первых, есть риск, что юзерский код «вырвется из песочницы» (import os;), во-вторых, он тупо может сожрать ресурсы или заблочить программу, например, вечным циклом.

                                                            А получается, что в iptables у нас один язык, в snort — другой, в apache mod_security — третий, в apache .htaccess файле — четвертый, в MySQL WHERE — пятый…

                                                            и если хочешь свой проект с гибким языком для юзерской логики — то надо самому веселопедить.
                                                              0
                                                              А что, обязательно нужен комбайн «всё в одном»?
                                                              Тут же явно задачи разные во всех 3 пунктах, зачем их запихивать в одно (ну, если не говорить об очевидном: ты — толстый тролль)

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

                                                            Самое читаемое