Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Спасибо за статью. Но мне, как молодому разработчику, было бы интересно и полезно увидеть реальные примеры решений, ссылки на библиотеки, которые лучше всего использовать. С этим Ваша статья станет еще более полной и исчерпывающей.
Это зависит от языка, конечно же. Я лично могу советовать только в области Java и Python. А так, гугл поможет по любому языку. Насчет Java и Python по каждому пункту могу написать в личке, если интересно.
в статью Java и Python! Уверен, что ребята добросят добра и для Ruby, и для PHP
Не только от языка, но и во многом от операционки. В одном случае при разработке Windows-программы мне оказалось предпочтительнее написать на Delphi собственный XML-парсер, т. к. разработчики программ аналогичного назначения поимели сложностей с Microsoft XML Parser — в основном, отсутствие парсера нужной версии на компе у пользователя или глюки с созданием соответствующего объекта. Потом в моём парсере потребовалось сделать только оптимизацию для ускорения его работы, но вопросов по запуску программы не было ни у кого.
Э-э… для какого языка? Может сами поищите, а то вам все найди да в рот положи пример решения приведи…
Аналогично с остальными для perl
Пишите в личку, если что=)
Пишите в личку, если что=)
github.com/bayandin/awesome-awesomeness — выбирайте ваш язык и найдете почти все популярные решения.
Что думаете насчет своего ORM?
Только если это оправдано. Писать свой ORM только потому, что Not Invented Here, глупо. Только если есть конкретные причины, по которым ни одно из готовых решений под нужный язык не подходят
Если есть проект, а в нем Вы пишите свой ORM, практически всегда это не оправдано. А если команда маленькая, Вы, считай, выкидываете разработчиков из проекта, кидая их только на написания какого-то внутреннего инструментария, неизвестно в каком виде еще получившегося. Чтобы такое делать, надо очень четко понимать, почему имеющиеся на рынке инструменты для Ваших задач не подходят.
Странно, что автор оригинальной статьи не упоминает вопросы криптографии. На мой взгляд — это именно то, где писать что-то свое не только глупо, но и крайне опасно.
как говорила одна знакомая: «если можешь не кодить самостоятельно — не кодь».
В примере для CSV у пас некорректный формат. Экранирование кавычек в CSV осуществляется их дублированием. Так что не факт: что выбранная вами библиотека справится с этой строкой. По крайней мере у LibreOffice это не получилось.
Имхо, как раз из всего списка самая простая задача — это парсинг csv: gist.github.com/krypt-lynx/c64420a3b5a9d739b174 (сложность — O(n))
А вообще, имхо, велосипеды писать полезно — в меру простые задачи неплохо тренируют мозг. Главное, чтобы это было не написание регулярок. И чтобы они не попадали в продакшн коммерческого проекта
Имхо, как раз из всего списка самая простая задача — это парсинг csv: gist.github.com/krypt-lynx/c64420a3b5a9d739b174 (сложность — O(n))
А вообще, имхо, велосипеды писать полезно — в меру простые задачи неплохо тренируют мозг. Главное, чтобы это было не написание регулярок. И чтобы они не попадали в продакшн коммерческого проекта
И вы в каждый проект, где вам понадобится парсить CSV, вместо использования готовой библиотеки будете вставлять этот милый «сниппет» на 170 строк? Или, не дай бог, писать каждый раз с нуля?
А чем он хуже существующих решений? Особенно учитывая, что он использовался в консольной тулзе для модмейкеров одной из игр и нареканий на его работу не поступало?
Учитывая, что
— Сниппет уже реализован
— Представляет из себя полный пригодный для компиляции.cs-файл
— В этом нём содержится чтение и запись csv
— Спустя полтора года после его создания я всё ещё могу понять как он работает
— Встроенных средств парсера csv в C# нет
То почему бы и нет?
Учитывая, что
— Сниппет уже реализован
— Представляет из себя полный пригодный для компиляции.cs-файл
— В этом нём содержится чтение и запись csv
— Спустя полтора года после его создания я всё ещё могу понять как он работает
— Встроенных средств парсера csv в C# нет
То почему бы и нет?
Готовая библиотека — это готовый код, оформленный в библиотеку. Почти ничем не лучше готового кода, оформленного в сниппет. Лишь не забывай источник и не упускай обновлений.
«Готовый код» тут главное же!
«Готовый код» тут главное же!
Самобалансирующиеся деревья, сложные алгоритмы сортировки. Как лабораторную стоит, в рабочий код — нет.
С чего бы? Вы алгоритмы для галочки учите, или чтобы дальше модифицировать, под конкретную задачу?
С точки зрения практики стоит изучать алгоритмы, чтобы свободно выбирать их и структуры данных под задачу. Ну и понимать что происходит в процессе. А не чтобы на гора выкатить самопальные красно-черные деревья.
Ну, я не согласен с этой позицией. Есть множество проектов, которые сами пишут какие-то алгоритмы, и за счет этого выигрывают. Например движки БД модифицируют те же красно-черные деревья для индексов.
Что бы вы не писали — всегда найдется как модифицировать использующиеся алгоритмы под ваши цели. Ну а в статье упоминаются шаблонные задачи, вроде логирования, или валидации, для которых вероятно можно сразу найти приемлимое решение.
Что бы вы не писали — всегда найдется как модифицировать использующиеся алгоритмы под ваши цели. Ну а в статье упоминаются шаблонные задачи, вроде логирования, или валидации, для которых вероятно можно сразу найти приемлимое решение.
Оформите топик как перевод — вы упоминаете в это в тексте, но ссылки в блоке после статьи нет. В кой-то веки проверил перевод ли это проверкой соответствующей плашки после названия…
У статьи очень неправильный заголовок. Она должна называться как-то типа «перечень проблем которые вы должны рассматривать при написании...»
Cвой HTML/XML парсер я написал когда уже было как минимум несколько библиотек включающих нужную функциональность.
В результате получился самый быстрый HTML/XML парсер который еще и не аллоцирует никакой памяти в процессе работы. В смысле вообще.
Писать свое или не писать это многофакторый анализ зависящий от постановки задачи. «Не всё так однозначно» (С) все знают кто.
Cвой HTML/XML парсер я написал когда уже было как минимум несколько библиотек включающих нужную функциональность.
В результате получился самый быстрый HTML/XML парсер который еще и не аллоцирует никакой памяти в процессе работы. В смысле вообще.
Писать свое или не писать это многофакторый анализ зависящий от постановки задачи. «Не всё так однозначно» (С) все знают кто.
Мне кажется, что когда сам пытаешься что-то писать, то получается некоторое «приближение». Например, я почти уверен, что Ваше решение не поддерживает namespaces в XML. И скорее всего не разворачивает entities. В итоге в первом приближении решение работает, но возможно в процессе работы его надо будет еще допиливать и допиливать, и в итоге вырастет классическое библиотечное решение, только со своими ошибками. Хотя, если известно что парситься будет некоторое «подмножество» XML, то почему бы и не воспользоваться таким «велосипедом».
А обычные SAX парсеры разве много аллоцируют памяти в процессе работы? Наверняка константу — почему их не взяли?
А обычные SAX парсеры разве много аллоцируют памяти в процессе работы? Наверняка константу — почему их не взяли?
«я почти уверен, что Ваше решение не поддерживает namespaces в XML.» ну и зря. Поддерживается там namespaces. В том смысле что при парсинге чего-то типа
«И скорее всего не разворачивает entities» и это тоже не так :) Там наличесвует
«SAX парсеры разве много аллоцируют памяти в процессе работы» — да. Причем никогда не известно сколько — опредляется входным документом. Что в embedded условиях, скажем, вообще не приемлемо.
И потом SAX парсер это push-parser со всеми вытекающими. У меня же классический pull-parser.
И еще… HTML, например, обычным XML parser'ом распарсить вообще нельзя. На элементе
А вообще тот парсер писался как раз для того что-бы не писать каждый раз новый лисапет ибо мой вариант это SGML tokenizer, т.е. для HTML и XML. Используется как составная часть HTML, XML и SVG парсеров в моём sciter например. Я знаю что он используется в SVG renderer внутри некоторых знаменитых игрушек, во встраиваемых девайсах и… много где на самом деле — лень перечислять.
В том-то и противоречивость данной статьи. Каждый существующий HTML/XML парсер это коллекция велосипедов сам по себе. Вот зачем нужно каждый раз писать tokenizer если он всегда имплементирует одну и ту же state machine?
Вот и твоя статья про тоже — вместо своего велосипеда возьми чужой. И надейся что он будет лучше. При каких-то условиях — несомненно, ибо человек ленив по определению «зачем делать дурную работу».
Можешь рассказать это скажем Microsoft которая сделала свой SSL велосипед, а не взяла существующий лисапед на котором катались все. И все скопом и докатались.
<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 велосипед, а не взяла существующий лисапед на котором катались все. И все скопом и докатались.
Вот, например, даже Oracl для парсинга XML брал (берет?) стороннюю библиотеку sax-парсер.
И я ее тоже взял — libexpat. И быстро, и лицензионно чисто, и оберток куча (для Delphi в том числе).
Памяти есть столько сколько скажешь, многогигабайтные файлы ест без проблем.
Что еще надо для счастья?
И я ее тоже взял — libexpat. И быстро, и лицензионно чисто, и оберток куча (для Delphi в том числе).
Памяти есть столько сколько скажешь, многогигабайтные файлы ест без проблем.
Что еще надо для счастья?
Это я бы не назвал поддержкой namespace.
Формально два следующих XML — одинаковы:
В вашем же парсере надо немного попрыгать с бубном чтобы это понять.
Имя тега в обоих случаях должно быть «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 нашли бы намного раньше, возможно, даже на этапе тестирования в Редмонде.
Формально два следующих 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 нашли бы намного раньше, возможно, даже на этапе тестирования в Редмонде.
Как ни печально, но это глобальная проблема программирования — всё уже украдено написано за нас. И я думаю, что со мной многие согласятся в том, что разработка сейчас и разработка лет 10 назад — это две большие разницы. Сейчас всё сводится к банальному увязыванию между собой горстки библиотек и плагинов/экстеншенов к ним. Интересным остаётся только создание какого-то узкоспециализированного софта/устройств. Мне, например, такие проекты запомнились больше всего. Но и в эту сферу библиотеки всеми силами тянут свои грязные ручонки…
Вот так и появляются вирусы микропрограммы на пару десятков килобайт, требующие .NET. Одно дело — когда действительно нужно всё предусмотреть (допустим в парсере HTML). Другое дело — когда нужна всего-лишь одна функция. Вот потому я очень люблю OpenSource. Всегда можно дёрнуть нужную функцию из исходного кода библиотеки, не прибегая к подключению всей библиотеки.
Что не нужно кодить самостоятельно?
Все. Для почти всех задач есть готовые библиотеки для популярных языков и фреймворков, код которых вылизан не одним программистом и не за один год.
Для решения проблем есть (гугл) Хабр и StackOverflow — только не стоит переносить оттуда сам код посредством Copy&Paste, комбинируйте, изменяйте и улучшайте решения, подходящие именно Вам.
А что _нужно_ кодить самостоятельно?
1. То же самое, но что никогда не попадет в продакшн — для самообразования. Лучший способ понять принцип работы — попытаться заново ее изобрести. Даже если Вам Ваше решение кажется уникальным — спешу разочаровать, на свете есть люди, у которых были похожие проблемы и путь их мышления был схож с Вашим.
2. Костыли. Шутка: не всегда готовая библиотека лишена багов или покрывает Ваш случай 100%. Но подумайте еще раз: быть может, Вы просто слишком мало искали и нашли не совсем нужное, а копать надо совсем в другом направлении?
3. То, чего совершенно точно нет в Сети — случай редкий, но возможный. Пишите, но не делайте этого в одиночку — отдайте в опенсорс, набирайте единомышленников-коммитеров. Так Вы не только быстро добьетесь годного, стабильного кода, но и достигнете славы; да и в резюме будет что написать с гордостью.
Все. Для почти всех задач есть готовые библиотеки для популярных языков и фреймворков, код которых вылизан не одним программистом и не за один год.
Для решения проблем есть (гугл) Хабр и StackOverflow — только не стоит переносить оттуда сам код посредством Copy&Paste, комбинируйте, изменяйте и улучшайте решения, подходящие именно Вам.
А что _нужно_ кодить самостоятельно?
1. То же самое, но что никогда не попадет в продакшн — для самообразования. Лучший способ понять принцип работы — попытаться заново ее изобрести. Даже если Вам Ваше решение кажется уникальным — спешу разочаровать, на свете есть люди, у которых были похожие проблемы и путь их мышления был схож с Вашим.
2. Костыли. Шутка: не всегда готовая библиотека лишена багов или покрывает Ваш случай 100%. Но подумайте еще раз: быть может, Вы просто слишком мало искали и нашли не совсем нужное, а копать надо совсем в другом направлении?
3. То, чего совершенно точно нет в Сети — случай редкий, но возможный. Пишите, но не делайте этого в одиночку — отдайте в опенсорс, набирайте единомышленников-коммитеров. Так Вы не только быстро добьетесь годного, стабильного кода, но и достигнете славы; да и в резюме будет что написать с гордостью.
1. Чем хуже я программирую, тем больше я должен программировать, чтобы лучше понять, как это работает.
2. Чем лучше я программирую, тем меньше я должен программировать и больше интегрировать готовые решения под свои нужды.
2. Чем лучше я программирую, тем меньше я должен программировать и больше интегрировать готовые решения под свои нужды.
Статья интересная и, безусловно, полезная. Но она заставила меня вспомнить фразу «не наступая на грабли вы лишаете себя бесценного опыта». Разве можно стать программистом не создавая велосипеды? А на чём тогда учиться? Зачем вообще учиться? Если все перестанут кодить и начнут просто собирать решения из готовых библиотек — кто будет писать библиотеки через 50 лет?
Писать велосипеды только «для себя», а в продакшн пускать библиотеки? Сомнительный подход, для себя никогда не будешь работать так хорошо, как под угрозой перехода твоего кода в продакшн. А значит и должного внимания не проявишь и потенциальных знаний недополучишь.
В общем мы находимся в переходном периоде когда должна измениться парадигма программирования, в очередной раз, которая сместит разработчиков ещё дальше от машин ещё ближе к людям. Ещё больший класс задач разработки будет решаться не людьми, а компьютерами, а люди будут визуально программировать из интуитивно понятного интерфейса. И разработчиками будущего будут девочки-секретарши настоящего.
Но лично мне, как человеку как раз выросшему в период этого стыка очень сложно действительно принять новую реальность и отказаться от старой. Потому что именно на моих глазах из этой старой реальности рождалась эта новая и для меня это выглядит, некоторым образом, как попытка вытащить табуретку из под человека, тянущегося с неё на верхнюю полку. То-есть по факту он, может, уже залез на эту полку целиком и табуретка ему без надобности, но в моей памяти ещё свежо что без неё у него ничего не получилось бы, а если он свалится вниз то без этой табуретки былых высот он не достигнет ещё долго.
Философия, короче.
Писать велосипеды только «для себя», а в продакшн пускать библиотеки? Сомнительный подход, для себя никогда не будешь работать так хорошо, как под угрозой перехода твоего кода в продакшн. А значит и должного внимания не проявишь и потенциальных знаний недополучишь.
В общем мы находимся в переходном периоде когда должна измениться парадигма программирования, в очередной раз, которая сместит разработчиков ещё дальше от машин ещё ближе к людям. Ещё больший класс задач разработки будет решаться не людьми, а компьютерами, а люди будут визуально программировать из интуитивно понятного интерфейса. И разработчиками будущего будут девочки-секретарши настоящего.
Но лично мне, как человеку как раз выросшему в период этого стыка очень сложно действительно принять новую реальность и отказаться от старой. Потому что именно на моих глазах из этой старой реальности рождалась эта новая и для меня это выглядит, некоторым образом, как попытка вытащить табуретку из под человека, тянущегося с неё на верхнюю полку. То-есть по факту он, может, уже залез на эту полку целиком и табуретка ему без надобности, но в моей памяти ещё свежо что без неё у него ничего не получилось бы, а если он свалится вниз то без этой табуретки былых высот он не достигнет ещё долго.
Философия, короче.
Вряд ли «все перестанут кодить». Безусловно, работа программиста постепенно трансформируется в нечто новое, но, имхо, так или иначе необходим будет интеллект. Если же все можно будет поручить машине, не придем ли мы к тому самому «восстанию машин»?
А в ином случае — что мешает идти постоянно в ногу со временем? Не пытаетесь ли Вы в примере с табуреткой жаловаться на то, что любимые лошадиные повозки исчезли и все вдруг начали ездить на автомобилях и забыли, как лошади веками помогали человеку путешествовать?
Вот как и я, ощущаю себя почти динозавром, сравнивая, как сейчас фокус веб-разработки смещается с сугубо системно-серверного программирования а-ля cgi-скрипты на браузерные платформы, и совсем по-стариковски ворчу, что джуниоры не знают сетевых протоколов, а то и даже не приемлют статическую типизацию — в то время, когда я, обладая обширными знаниями и глубоким пониманием, нынче могу этими знаниями подтереться, а изучать новые популярные технологии (фреймворки, библиотеки) просто не успеваю, когда они это знают сразу…
Но вообще будущее еще менее определено, чем его пытаются придумать…
А в ином случае — что мешает идти постоянно в ногу со временем? Не пытаетесь ли Вы в примере с табуреткой жаловаться на то, что любимые лошадиные повозки исчезли и все вдруг начали ездить на автомобилях и забыли, как лошади веками помогали человеку путешествовать?
Вот как и я, ощущаю себя почти динозавром, сравнивая, как сейчас фокус веб-разработки смещается с сугубо системно-серверного программирования а-ля cgi-скрипты на браузерные платформы, и совсем по-стариковски ворчу, что джуниоры не знают сетевых протоколов, а то и даже не приемлют статическую типизацию — в то время, когда я, обладая обширными знаниями и глубоким пониманием, нынче могу этими знаниями подтереться, а изучать новые популярные технологии (фреймворки, библиотеки) просто не успеваю, когда они это знают сразу…
Но вообще будущее еще менее определено, чем его пытаются придумать…
Дело не в лошадях.
Я о том, например, что сейчас я не помню ни одного номера телефона, кроме своего, который периодически диктую людям. Все номера живут в памяти моего телефона, потому что это логично и удобно. А ещё 20 лет назад я помнил несколько десятков номеров и в любое время в любом месте мог их вспомнить. Сейчас же без смарта я не смогу позвонить даже маме.
Повсеместность интернета искореняет необходимость держать в голове знания, которые ещё недавно считались необходимым для каждого человека минимумом.
Плохо ли это? Если преодолеть свою привязку к прошлому то — нет. Потому что освобождение человека от необходимости делать что-то даёт ему возможность делать что-то другое, это и есть путь вперед. Но если есть желание поворчать то достаточно представить современного телефонно-интернетного человека в месте где нет ни телефона ни интернета.
В программировании много ли сейчас людей, знающих машинные коды? Или хотя бы ассемблер? Помнящих о распредеолении и выделении памяти? Это всё по сути уже умерло для абсолютного большинства людей, это делают машины. Скоро и библиотеки будут писать машины. И с одной стороны оно, конечно, хорошо — люди наконец смогут решать свои задачи, использую машины как инструмент, а не решать проблемы программирования, которые по сути к решению задачи не относятся. Но если случится необходимость начать с начала — путь придётся проходить с начала полностью, нельзя будет просто взять и сделать ещё раз то что уже когда-то сделал, потому что никто не будет знать как это делать. Некому будет залезть в библиотеку и исправить метод, залезть в компилятор и исправить баг, залезть в ассемблер и исправить обращение к регистру, залезть в машинные коды и исправить интерпретацию ассемблера, залезть в железо и исправить сбоящий автомат. В случае если библиотека не работает — можно будет только искать другую библиотеку, созданную на другом компьютере.
В случае с лошадьми проблема не в том что мы не используем лошадей, проблема в том что если полностью автоматизировать создание машин — мы будем ездить на машинах. А если что-то случится с автоматическим их производством — мы тут же вынуждены будем вернуться к лошадям. Потому что не будет уже людей, способных создавать машины. За ненадобностью.
Говорю же — философия.
Я о том, например, что сейчас я не помню ни одного номера телефона, кроме своего, который периодически диктую людям. Все номера живут в памяти моего телефона, потому что это логично и удобно. А ещё 20 лет назад я помнил несколько десятков номеров и в любое время в любом месте мог их вспомнить. Сейчас же без смарта я не смогу позвонить даже маме.
Повсеместность интернета искореняет необходимость держать в голове знания, которые ещё недавно считались необходимым для каждого человека минимумом.
Плохо ли это? Если преодолеть свою привязку к прошлому то — нет. Потому что освобождение человека от необходимости делать что-то даёт ему возможность делать что-то другое, это и есть путь вперед. Но если есть желание поворчать то достаточно представить современного телефонно-интернетного человека в месте где нет ни телефона ни интернета.
В программировании много ли сейчас людей, знающих машинные коды? Или хотя бы ассемблер? Помнящих о распредеолении и выделении памяти? Это всё по сути уже умерло для абсолютного большинства людей, это делают машины. Скоро и библиотеки будут писать машины. И с одной стороны оно, конечно, хорошо — люди наконец смогут решать свои задачи, использую машины как инструмент, а не решать проблемы программирования, которые по сути к решению задачи не относятся. Но если случится необходимость начать с начала — путь придётся проходить с начала полностью, нельзя будет просто взять и сделать ещё раз то что уже когда-то сделал, потому что никто не будет знать как это делать. Некому будет залезть в библиотеку и исправить метод, залезть в компилятор и исправить баг, залезть в ассемблер и исправить обращение к регистру, залезть в машинные коды и исправить интерпретацию ассемблера, залезть в железо и исправить сбоящий автомат. В случае если библиотека не работает — можно будет только искать другую библиотеку, созданную на другом компьютере.
В случае с лошадьми проблема не в том что мы не используем лошадей, проблема в том что если полностью автоматизировать создание машин — мы будем ездить на машинах. А если что-то случится с автоматическим их производством — мы тут же вынуждены будем вернуться к лошадям. Потому что не будет уже людей, способных создавать машины. За ненадобностью.
Говорю же — философия.
Дело не в том, что мы не пользуемся старым, дело в том, сможем ли мы воспользоваться старым, если что-то случится с новым?
Вспомните ли Вы телефон матери, если Ваш смарт вдруг навернется? Как быстро мы освоим лошадей, если производство автомобилей остановится?
Я лет 10 не использовал ассемблер, но если надо будет — прочту код и разберусь, а поднатужившись — и напишу, хотя материться буду громко и витьевато. Зато я знаю, как лучше писать высокоуровневый код, чтобы он не страдал излишествами для машины или какое решение было бы лучше.
И ворчу лишь потому, что часто наталкиваюсь на точку зрения «мне это не нужно, значит, никому не нужно, а если никому не нужно — то это отстой и ты зря потратил годы».
Вспомните ли Вы телефон матери, если Ваш смарт вдруг навернется? Как быстро мы освоим лошадей, если производство автомобилей остановится?
Я лет 10 не использовал ассемблер, но если надо будет — прочту код и разберусь, а поднатужившись — и напишу, хотя материться буду громко и витьевато. Зато я знаю, как лучше писать высокоуровневый код, чтобы он не страдал излишествами для машины или какое решение было бы лучше.
И ворчу лишь потому, что часто наталкиваюсь на точку зрения «мне это не нужно, значит, никому не нужно, а если никому не нужно — то это отстой и ты зря потратил годы».
между «я уже лет 10 не использовал ассемблер» и «а что такое ассемблер?» лежит та пропасть о которой я говорю. Через 50 лет кто будет писать библиотеки? Сейчас мы в переходном периоде, когда мы ещё знаем старое, но уже видим и пользуемся новым. Что будет, когда старое будет не просто забыто, а вырастет поколение вообще ничего о нём не знающее?
Как понять является ли это старое фундаментом, необходимым каждому для дальнейшего движения или это пережиток прошлого, о котором можно забыть как о тёмном веке? На мой взгляд человек который не пишет велосипедов для продуктива не может быть программистом. Да, современные и новые инструменты дадут ему возможность создавать программы, но не потому что он программист, а потому что инструменты стали очень удобными и простыми. А забери у такого его ИДЕ и набор библиотек и всё, даже хелло ворлд в джаве не скомпилирует. А дальше эта ситуация будет только усугубляться.
Как понять является ли это старое фундаментом, необходимым каждому для дальнейшего движения или это пережиток прошлого, о котором можно забыть как о тёмном веке? На мой взгляд человек который не пишет велосипедов для продуктива не может быть программистом. Да, современные и новые инструменты дадут ему возможность создавать программы, но не потому что он программист, а потому что инструменты стали очень удобными и простыми. А забери у такого его ИДЕ и набор библиотек и всё, даже хелло ворлд в джаве не скомпилирует. А дальше эта ситуация будет только усугубляться.
О! А я ухитрился нарушить все, кроме третьего и последнего, пункты сразу, когда писал свои дополнения для Vim:
Кстати, а почему в списке нет пункта про frawework’и для тестирования? Они, как и код для логирования, имеют тенденцию разрастаться от простого к сложному: сначала вам нужно просто сравнить две строки, затем вам уже хочется сравнивать строки параллельно (нечего второму/… ядру простаивать), потом ещё внятные сообщения о том, где и что сломалось, сводки, …
- XML парсера на VimL я просто не нашёл. (Сейчас есть WebAPI.vim, но это сейчас. Да и WebAPI содержит не pull парсер, и даже не push. Ждать парсинга всего документа мне было не с руки).
- То же самое про JSON парсер. Бо́льшая часть людей довольствовалась eval, что небезопасно. (Сейчас тоже есть WebAPI.vim).
- Проверки адресов мне не были нужны.
- Библиотеку с urlescape я даже не искал.
- Тот примитив, что у меня (взять дату в одном формате и скормить её дальше в несколько другом, не пытаясь как‐либо обработать вещи вроде часовых поясов) нельзя назвать полноценной работой с датами. Но это всё же есть.
- Библиотеку с шаблонами я тоже не искал: что‐то точно было, но вероятность найти библиотеку шаблонов, которая позволит без серьёзной доработки создать подсветку синтаксиса для результата использования шаблона, была весьма призрачна. Особенно учитывая отсутствие поддержки установки зависимостей в большинстве решений для установки дополнений Vim и, как следствие, малое число библиотек.
- Логирование я у себя не делал.
Кстати, а почему в списке нет пункта про frawework’и для тестирования? Они, как и код для логирования, имеют тенденцию разрастаться от простого к сложному: сначала вам нужно просто сравнить две строки, затем вам уже хочется сравнивать строки параллельно (нечего второму/… ядру простаивать), потом ещё внятные сообщения о том, где и что сломалось, сводки, …
Когда я искал библиотеку для разбора URL для c++, то наткнулся на ряд проблем:
1. Qt в том коде я использовать не мог. Да и к тому же QUrl излишне переусложнён и неудобен.
2. И выбирать больше не из чего.
В chrome и firefox написан отдельный код для разбора URL, но он… не работает по стандарту. Причём «не по стандарту» у них разное. В обоих случаях, например, туда добавлена поддержка emule, URL'ы которого таковыми на самом деле не являются. Да и вообще код в обоих случаях не выделен в виде отдельной библиотеки и использует внутренние типы.
В итоге да, я написал свой класс + набор вспомогательных функций. Всё не доходят руки прикрутить туда кодирование/декодирование punicode (мне не нужно, работаю только со своими URL'ами), только это и останавливает от выкладывания на github.
1. Qt в том коде я использовать не мог. Да и к тому же QUrl излишне переусложнён и неудобен.
2. И выбирать больше не из чего.
В chrome и firefox написан отдельный код для разбора URL, но он… не работает по стандарту. Причём «не по стандарту» у них разное. В обоих случаях, например, туда добавлена поддержка emule, URL'ы которого таковыми на самом деле не являются. Да и вообще код в обоих случаях не выделен в виде отдельной библиотеки и использует внутренние типы.
В итоге да, я написал свой класс + набор вспомогательных функций. Всё не доходят руки прикрутить туда кодирование/декодирование punicode (мне не нужно, работаю только со своими URL'ами), только это и останавливает от выкладывания на github.
С JSON в C++ тоже всё плохо. Т.е. мы пользуемся, конечно, сторонней библиотекой, но в своё время я перебрал около 10, и они все оказались плохими. Какие-то медленные, какие-то неудобные, какие-то вообще с ошибками.
А уж если затрагивать Binary JSON, то там всё ещё хуже — я знаю 5 разных «стандартов», и они все не подходят для моего случая (малое количество чтений/быстрое смещение к соседнему элементу/быстрый поиск по ключу/аппаратные типы и смещения). В итоге отказался от него совсем в пользу отдельного бинарного формата.
А уж если затрагивать Binary JSON, то там всё ещё хуже — я знаю 5 разных «стандартов», и они все не подходят для моего случая (малое количество чтений/быстрое смещение к соседнему элементу/быстрый поиск по ключу/аппаратные типы и смещения). В итоге отказался от него совсем в пользу отдельного бинарного формата.
В общем, из комментов явно видно, что нифига не «всё написано до нас», и велосипеды строить придётся ещё очень много и долго.
Понимаю, что слоупочу, но есть еще одна задача, с которой сталкиваюсь часто, вижу, как другие сталкиваются часто, и решается всегда велосипедами. Может быть кто-то знает универсальное реюзабельное решение?
Задача — описание логики для фильтрация-классификация чего угодно (структур данных), по правилам, которые поставляет юзер.
Например (на псевдокоде):
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 — пятый…
и если хочешь свой проект с гибким языком для юзерской логики — то надо самому веселопедить.
Задача — описание логики для фильтрация-классификация чего угодно (структур данных), по правилам, которые поставляет юзер.
Например (на псевдокоде):
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 — пятый…
и если хочешь свой проект с гибким языком для юзерской логики — то надо самому веселопедить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что не нужно кодить самостоятельно