Comments 103
Момент с «мини-рефакторингом» не понял. Выглядит как изменение ради изменения.
И epoch.stop же будет возвращать 201, а не 200? :)
Ага, я неправильно написал в статье :(
История про девочку - это пиар конкретной площадки. Всё ради привлечения пользователей. А они в свою очередь привлекут прибыль. Хоботы сейчас вопрос денежных отношений
Плюсую! Постмодерн, симулякры и прочий Бодрийяр)
При прочих равных потребитель выберет тот курс, создатели которого больше врут обещают больший результат меньшими усилиями. Онлайн-школа не может не приукрашивать реальность, если она хочет конкурировать.
Со временем реальность искажается больше: кто-то первым начинает приукрашивать чуть сильнее, остальные подтягиваются до этого уровня — и вот уже будущим разрабам обещают 300k в наносекунду за работу, с которой якобы и дурак справится.
Вот это накипело, коллега. Думаю эти мифы придумывают не сами программисты. А кто продает курсы программирования.
Предлагаю продолжить тему, программирование это очень веселое занятие, и рассказать, как весело бывает решать конфликты, при мерже веток, например, или поиск ошибок при запуске контейнеров, когда он не запускается ))
поиск ошибок при запуске контейнеров
Это не программирование. debug.
согласен, это один из инструментов, как и IDE, которые болью откликаются при работе
Это не программирование.
После беглого прочтения статьи, у меня возникло ощущение, что она вся целиком - не о программировании, если не понимать этот термин максимально расширительно. Сложности обитания в конкретных средах проектирования - это проблемы кодировщика (со всем уважением), а не программиста. Имхо.
Дык а программист всегда и сразу такие проблемы решает?
Сложности обитания в конкретных средах проектирования - это проблемы кодировщика (со всем уважением)
"The myth of the coder", свежатинка.
Но как минимум случай с PgBouncer это уже архитектурный вопрос. А доступность вроде бы удалённого в github - уже уровень общего секьюрити.
Предлагаю продолжить тему, программирование это очень веселое занятие, и рассказать, как весело бывает решать конфликты, при мерже веток, например, или поиск ошибок при запуске контейнеров, когда он не запускается
На самом деле это иногда весело. Тут двояко, так как бывает, что весело становится в конце, понимая, что я сам тот кто накосячил и не видел слона. А бывает весело именно искать косяк, так как косяка нет, а он как суслик есть. Самому себе говорю, что не может так работать код, и смёшься чуть ли не до истерики. А код работает, да ещё и лучше, чем раньше
изучение багов от либ и фреймворков довольно интересные. особенно когда баги не закрываются годами.
в обсуждения встречаются такие забавные комментарии.
или при изучении исходных кодов можно встречать "интересные" наименования и комментарии кода.
или можно приятно удивляться запасу прочности написанного тобой кода.
Ещё бывает отладка многопоточных приложений с гонками, deadlocks и прочими весёлостями.
Которые, например, случаются раз в месяц на машине у клиента на другом конце планеты, а у разработчика в его офисе и даже у тестеров - нет. И клиенту это приносит серьёзные убытки.
Привет с PythonNN
ZeroVer - это прям про Rust. КУЧА библиотек имеют версию 0.*. Смотрим:
axum - v0.7.6
tower - v0.5.1
sqlx - v0.8.1
Окей, с вебом понятно, может с чем-то базовым получше?
rand - v0.8.5
num - v0.4.3
hashbrown - v0.14.5
itertools - v0.13.0
И, наконец, мой любимец:
base64 - v0.22.1
Алгоритм кодирования в base64 же у нас каждые полгода меняется и всё никак не хочет стабилизироваться, верно? :]
derive-more пару лет имел версию 0.99
Алгоритм кодирования в base64 же у нас каждые полгода меняется и всё никак не хочет стабилизироваться, верно? :]
А вдруг на следующей машине в байте будет не 8, а 8.5 бит?
(крякает и убегает)
А ещё лучше делать версии с двумя нулями! Вот например Discord клиент для Linux - у меня последняя сейчас 0.0.64. Это значит, меняться может всё.
Алгоритм то может и не меняется, а реализация вполне может. С оптимизацией под многопоточность, под особенности конкретного процессора... Прежде чем хихикать, надо в changelog смотреть ;)
То, что вы описали - это изменения в основном под капотом, они не должны затрагивать публичный API библиотеки, для которого версионирование в первую очередь и делается.
С ZeroVer тоже можно гарантировать, что изменение патч-версии не сломает обратную совместимость. Вот, например, caret requirements в Poetry.
Другое дело, что зачастую разработчики не придерживаются вообще никаких правил и ломают что угодно когда угодно, хотя вроде бы на словах придерживаются SemVer.
А чтобы "добавить энтузиазма" начинающим - надо иметь ввиду, что скажем лет через 5-10-20... весь ваш опыт с нынешним стэком будет никому не нужен, ибо будут новые языки, новые железки, новые экосистемы (поверьте, так уже было и не раз...) и вам придётся все учить снова, и снова, и снова... если конечно эту инициативу у вас не заберёт ЭйАй )
- а вот карандаш и бумага - живёт дольше...) остальное в песок...
вы про операторов фреймворков и им подобных.
нормальный программист-разработчик со временем/опытом будет понимать как работает код на глубоких уровнях и сможет на не знакомом ЯП за пол часа написать полезную программу.
Не уверен, что за пол часа разберётся..., тем более никакая приличная компания не даст писать в прод без опыта в стэке и в языке.
Сможете сходу написать что-то полезное на Haskell, Prolog, Common Lisp и Forth?
сможет на не знакомом ЯП за пол часа написать полезную программу.
За полчаса может полезную и сможет. А вот сможет ли написать качественную за месяц?
Это как взять переводчика не знающего китайский и сказать что он за полчаса напишет статью на нем. Просто потому, что он 20 лет лингвистом работает. Да, напишет, но насколько хорошо? А если надо не статью, а книгу?
Не зная язык, его особенностей, его функций, его библиотек, его экосистемы, практики его применения - ничего качественного на серьезном уровне не напишешь.
Эта современная манера рассуждать, что мол "язык знать не надо, ИДЕ подскажет да и погуглить можно" звучит как "японский знать не надо, есть словари и гугл транслейт".
"японский знать не надо, есть словари и гугл транслейт"
...увы, широкая доступность поверхностных "знаний" играет свою злую шутку. Насколько злую? - человечество ещё не осознало (как бы пафосно это не звучало).
...сразу вспоминаешь педагогику от "Ландавшица", когда за непринуждённой фразой "очевидно что" скрыта страница выводов... в качестве упражнения. )
есть языковые группы. если знать сходные то можно даже не зная ориентироваться и/или относительно быстро и легко подтянуть нужное.
например старые кандзи(яп. иероглифы) почти копия китайских, зная иероглиф аптеки на яп. найдешь её и в кит.
есть различия в глубине познания и то что это даёт. это не даст того же мастерства как у профильного специалиста но достижение этого уровня будет намного быстрей и легче.
Учите c++ или Fortran, они будут всегда :)
Можно добавить в список обновление зависимостей. Например в Symfony или npm
Вот так я узнал, что click и argparse работают по-разному, но чтобы это узнать, нужно поставить куда-нибудь знак «=». Люблю программирование!
click использует старую библиотеку optparse из stdlib. Она именно так и работает. Проверьте. :)
from optparse import OptionParser
from argparse import ArgumentParser
import click
def prog_optparse():
p = OptionParser()
p.add_option('--queues', '-Q')
print(p.parse_args())
def prog_argparse():
p = ArgumentParser()
p.add_argument('--queues', '-Q')
print(p.parse_args())
@click.command()
@click.option('-Q', '--queues')
def prog_click(queues):
print(queues)
if __name__ == '__main__':
prog_optparse() # (<Values at 0x7f2c115e7890: {'queues': '=values'}>, [])
# prog_argparse() # Namespace(queues='values')
# prog_click() # =value
А библиотека Celery - это вообще дно, не надо этим пользоваться. :)
в питоне каждая библиотека - дно, если так смотреть. всё из-за низкого порога входа и разработчиков, которые сами не понимают что делают
Вообще, многие проблемы в статье решаются использованием языка со статической, а не динамической типизацией. Взял ту же Java/C#/Scala/Rust/etc и забыл о проблемах «я не правильно указал символ в django-конфиге».
Примеры с JavaScript валидные, но надуманные. Если брать реакт, то вряд ли кто-то будет писать проект с нуля на JavaScript, а не typescript.
Меня всегда интересовало, зачем вообще использовать динамические языки для чего-то сложнее, чем скрипт/или dag в airflow? Берешь статическую типизацию и больше не надо есть кактус
Вы СИЛЬНО ошибаетесь (((
стат. типизация не решает проблемы кривых рук (говорю, как обладатель). Ничто и никогда не помешает использовать any (((
новый проект на реакте без ts - ЭТО НОРМА! наблюдение последних 4-5 лет.
динамическая типизация - не проблема. проблема - не правильное использование.
стат. типизация не решает проблемы кривых рук (говорю, как обладатель). Ничто и никогда не помешает использовать any (((
Использование Any (или подобного ему псевдотипа) в сколько-нибудь осмысленной форме возможно только в TS. Автор комментария не приводил его как пример статической типизации (её там, собственно, и нет)
стат. типизация не решает проблемы кривых рук (говорю, как обладатель). Ничто и никогда не помешает использовать any (((
Если её максимально использовать - решает. По крайней мере количество проблем типа "хотел число, получил строку" сокращает в десятки раз.
Бывают и более хитрые ситуации. Недавно в одном проекте заменял везде секунды на миллисекунды. Если бы это был C++, то его типизация в chrono не пустила бы меня передать значение другого типа, компиляция бы свалилась и я бы был вынужден вставлять преобразования. Но это Python, и всем там плевать, поэтому я менял названия переменных, полей всяких JSON и функций, чтобы линтеры и потом тесты показали, где я недоработал. (Можно потом обратно поменять, если нужны фиксированные имена, но промежуточное состояние должно быть зафиксировано отдельным коммитом.)
динамическая типизация - не проблема. проблема - не правильное использование.
Когда "правильное использование" динамической типизации в разы дороже статической, это таки проблема. "Зачем платить больше?" (c)
уже лет 10 на C# программирую, ни одной из этих проблем не встречал... ну JS да куролесит иногда, но щас есть blazor поэтому можно JS вобще не использовать
За что так с celery?..
В целом я согласен про Celery, а что можно использовать вместо неё? Изобретать очередной кастомный велосипед?
Насчёт pytest, pdm и relative import. Прочитайте внимательно ошибку. Там речь про "top-level package" — пакет, а не модуль. Теперь внимательно смотрим, что в питоне понимается под пакетом: папка, содержащая __init__.py
Частая ошибка разработчиков в Python, что они пытаются импортировать пакеты и не через relative, и не через absolute import. Вот простой пример:
foo
__init__.py
types.py
logging.py
bar.py
И кто-то пишет в bar.py: import types, logging и получает конфликт с stdlib, импортирует stdlib пакеты вместо своих.
Потому что надо либо from . import types, либо from foo import types, то есть использовать либо относительный, либо абсолютный импорт. И это всегда будет работать как ожидается. Импортируют неправильно и вылезают баги в самых неожиданных местах, потому что система импорта в Python на самом деле сложная и запутанная.
Хирургия - это просто. Режем лягушку за 15 минут.
Автомеханика - это просто. Меняем колесо за 10 минут.
Ну и так далее.
Учёба - это просто. Научу чему угодно за минуту.
Подписывайтесь. Ставьте лайк.
А где ссылка на ТГ-канал?
По бразильской системе?
И да... миллионы ботов уже подписались, лайкнули, и откомментили свой восторг..., а вы все ещё думаете? )
Спасибо, ruff, так гораздо лучше. Как, говоришь, тебя удалить?
ruff ещё и "очень логичный". Чтобы запустить авто-форматтер вместе с линтером и фиксами надо вот так и никак иначе. :)
ruff format . && ruff check --fix .
То есть, просто check делается вот так:
ruff check .
А проверка формата (например, в CI) вот так:
ruff format --check .
Всё очень логично и консистентно, правда же? :)
У них даже issues на этот счёт есть (лень искать).
Но вообще тула очень быстрая и в целом норм. Можно не удалять, можно добавить метакомменты для пометки кусочков кода, чтобы он туда не лез со своим "правильным" форматированием.
С опцией - как раз click работает тут так, как работают подобные опции вообще изначально, начиная с libc getopt() и большинством его продолжателей. Однобуквенные опции (которые к тому же с одиночным дефисом перед ними) имеют жёстко заданное наличие или отсутствие параметра, и параметр пишется или следующим argv, или до конца того же, но без всяких '='. Упомянутый рядом optparse работает точно так же. То есть для них всех "-Qdefault" или "-Q" "default", но никак не "-Q=default".
Формат с = для длинных опций (которые начинаются уже с двух дефисов) введён для того, чтобы, в первую очередь, можно было твёрдо определять конец названия опции; во вторую, чтобы можно было делать вариант optional_argument - у таких опций, если он есть, идёт после '=' в том же argv (не в следующем). Это разработка ещё 80-х, POSIX.2 (но у него вместо -- было -W ; -- это уже доработка GNU).
Наоборот, то, что делает argparse, это что-то неожиданное (я вот впервые из вашей статьи узнал про это) и я не понимаю, почему они так сделали, сломав совместимость. Может, это вообще баг, надо поискать, были ли на него тикеты.
Собственно, общего вывода вашей статьи это не нарушает. Но отношение к собственному примеру у вас какое-то странное.
(продолжение, возможно, следует. у вас много букв;))
Согласен. Думаю, в argparse как раз баг, потому что короткие (односимвольные) опции по стандарту с = не пишутся. Всё, что идёт после опции является значением, поэтому там даже пробел между опцией и значением не обязателен.
Зафайлил баг: https://github.com/python/cpython/issues/124305
Наблюдаем...
Весь этот бред нелогичности, абсурда и безумия в кодах создали люди)) Просто из статьи кажется будто эти программы появились из ни откуда сами по себе. Источник абсурдных решений в кодировании это люди которые сами не понимают что делают, то есть не профессионалы, либо если вы профи то в очень редких случаях вы сами что-то не допонимаете и то или ное решение только кажется нелогичным. Вся эта статья отличный пример того, что ИИ еще далеко до того, чтобы полностью заменить профессионалов программистов, правда если верить последним новостям то ИИ о1 чуть ли не бог программирования в сравнении с чатом гпт4.
Я не программист и пока не появится волшебной программы которая по моему словесному запросу ТЗ будет создавать какую угодно программу/сайт/приложение работающее идеально - программисты люди будут нужны также как и в прошлом. Тут конечно же встаёт вопрос кривых ТЗ от нубов и дилетантов которые опять же сами не знают чего хотят, но это все ладится в процессе лобового столкновения их продукта с реальностью - главное чтобы был тот ИИ программист полубог которые мог бы сделать все что угодно.
Опять же читая о повышенных возможностях этого о1 начинает верится в то, что скатерть самобранка в области программирования это не такая уж и фантастика, просто я как дилетант понимаю отличие такого ИИ от программиста даже самого высокого уровня будет заключаться в том, что такая ИИ имеет непосредственный доступ ко всей доступной информации из области программирования, доступ ко всем возможным ошибкам, и механизму их решения, плюс о1 умеет в рассуждения мы все это уже поняли, человеку даже самому умному программисту все это вместе взятое не под силу.
С другой стороны даже в этом случае отказаться от услуг реальных программистов это все равно что превратиться в домашних животных по отношению к этому ИИ) Судите сами: Мы делаем запрос и получаем готовый продукт, а как он получился мы сами не знаем, ситуация будет так себе, не зная того, как получился тот или иной результат мы ставим себя в один ряд с нашими петами)) Ведь они тоже требуют от нас еды например, и она каким то неведомым и чудесным образом для них материализуется у них перед носом) Мы даже не сможем проверить результат на ошибки ибо мы обычные юзеры не сможем понять как проверить, придется в слепую доверять результату ИИ.
На Хабре уже немало статей в духе "как я за полчаса создал сложную программу с помощью ChatGPT, программисты скоро станут не нужны". Но мало создать программу, даже если это получилось успешно и быстрее, чем если бы её человек сам делал с нуля.
Следующий уровень - развивать и поддерживать программу, в том числе по замечаниям и пожеланиям пользователей. И вряд ли ChatGPT сумеет выполнить запрос "переделай готовую программу так, чтобы она приносила в 10 раз больше денег, чем сейчас".
"придется в слепую доверять результату ИИ"
- и почему "ИИ" вообще "захочет" делать бесконечно что-то полезное для человека?
придется в слепую доверять результату ИИ
Это не недоработка ИИ как такового, это минус стандартного workflow в духе "будь послушной собачкой, выдай мне гигабайты результатов из сотни байт инпута здесь и сейчас".
Хороший ИИ может работать так же, как и наёмный профессионал, в диалоговом режиме, с уточняющими вопросами, конструктивной критикой идеи и её согласованием от общего к частному.
Вот прямо вчера было. Взял репозиторий из рабочего (локального) github. Что-то поисправлял, сделал commit. А push не проходит - Visual Studio пишет сообщение "не могу, смотрите логи".
Пошёл то же самое делать в командной строке. git add, git commit - всё ок.
git push выдаёт: repository not found! Да как же не найден, ты же сам мне показываешь URL, из которого я час назад сделал clone?
На машине у коллеги проделали то же самое, у него всё работает. После некоторых раздумий он полез смотреть настройки репозитория - ну точно, забыли именно мне дать права на модификацию.
Ну хорошо, это всё понятно, и догадаться, наверное, можно было сразу, но почему в сообщении написано "repository not found", а не "access denied" или хоть что-то про права доступа?
Напоминает какую-то древнюю историю, когда база данных кому-то выдала сообщение "не могу".
Точно так же работает Oracle, если нет прав на таблицу: выдает "table or view does not exist". Кажется, это сделано для того, чтобы атакующий подбором имен объектов получал меньше информации.
Я догадывался, что здесь есть технические причины для этого. Но кто мешает в клиенте добавить в сообщении подсказку вроде "Check your access rights"? Тем более, клиент вполне в состоянии понять, что раз я смог из этого же репозитория получить проект, значит, хотя бы в момент получения этот репозиторий был existing. Можно и так написать: please check that repository still exist and you have enough rights for pushing to it.
но почему в сообщении написано "repository not found", а не "access denied" или хоть что-то про права доступа?
Чтобы потенциальный взломщик не мог перебрать названия существующих репозиториев по access denied.
Примеры показывают только одно - программирование это не написание литературного текста. Оно всё ещё требует точного (ещё раз для читателей статьи считающих что в статье описаны реальные проблемы - ТОЧНОГО, господа егэшники) понимания, и уже создаёт иллюзию что всё можно нагуглить. Это плохо, а когда добавится иллюзия с AI - будет очень плохо, это как с пятницей 13-го и субботой 14-го.
Как капля в которой отражается океан -
В питоне тоже всё просто, скобки всегда означают одно и то же...
да, всё просто, не веришь не видишь не понимаешь - отойди от компа навсегда
с какой стать скобки должны означать одно и то же, ведь тогда они смогут означать только что-то одно
скобки сами по себе ничего не означают
Когда человеку что-то говорят, в том числе письменной речью, нужно стремиться понять что тебе говорят. Но строить свою собственную теорию и усваивать её - проще. Программистов сужественно больше чем людей которым энергетические ресурсы мозга позволяют поступать иначе. Это не завуалированное оскорбление, это медицинский факт. Не понимать смысл == и === в JavaScript - естественное следствие.
Кто виноват - капиталистический способ производства (поганого) программного обеспечения.
Что делать? Пользоваться дарованной Господом в Его беспричинной милости свободой воли, как именно - утверждение рекурсивное.
Нытьё бесит, но наверно не всех, чем и следует утешаться.
Вы были бы очень хорошим следователем
Плюс десктоп на Электроне
Можно расширить тему!
В статье приведены примеры как выстрелить себе в ногу при использовании Питона.
Можно взять другие области - науку, менеджмент, преподавание...
А я говорил, надо становиться было магом-целителем премиум класса. Там хотя бы нету магии, как в погромировании
Когда что-то не работает, и ты пока не можешь понять, почему оно не работает, это еще мелочи и абсолютно естественно, ибо "нельзя объять необъятное", "глаз замыливается" и все такое.
А вот когда работавшая годами без проблем программа вдруг сбоит, ты смотришь ее древний код и не понимаешь, как оно вообще эти года работало, вот это да.
А главное не то что все не так просто, а то что оно все не-проще и не-проще со временем.
Но когда не-проще уже будет некуда, что-то произойдет. Как показывает история сначала не очень позитивное.
Скачать сотни репозиториев из Гита чтобы скомпилировать какой-то Хело-Верд это уже практически какой-то стандарт "нормального" проэкта. Мне кажется не долго осталось.
Занимайтесь тем что вам по душе.
Согласен с некоторыми из предыдущих ораторов. Автор, как будто, говорит "Рисование - это не просто! Вот поглядите: Картину художника Х украли из охраняемого музея. Или ещё, другой художник упал с лестницы когда расписывал стену".
Программирование - это просто. Не всегда очевидно, но не сложно. Другое дело, что вокруг программирования есть ещё много других активностей - от глубокого погружения в чужой код до ведения проекта, от строения сетей до всратых собесов в 20 этапов. И что с того? Вокруг любой деятельности можно найти кучу всего, чем придется заниматься помимо неё.
Другое дело, что в отношении программирования со всем этим можно разобраться в разумные сроки и, если не решить, то хотя бы обойти проблему. Плюс эксперименты бесплатные. Физикам и химикам остается о таком только мечтать
Поэтому он выполняет команду
false, она возвращает ошибку, но по умолчанию (чья это была идея, блин?) баш игнорирует ошибки и выполняет команды дальше — а дальшеrm -rf ~. Удобно? Удобно.
По дефолту баш не останавливает выполнение, если какая-то из команд завершилась с ошибкой, и это нормально - ВСЕ языки так делают. Если не продолжать выполнение, то то банальное if/else невозможно будет создать, потому что if должен всегда быть true.
В баш есть возможность поменять это условия для определенных моментов, например отладка или какие-то специфичные пайплайны, где любой не true должен привести к остановке скрипта. То, что кто-то добавил опцию в интерпретатор, так причем тут баш?
Добавьте какой-нить #!/usr/bin/python /etc/passwd
И посмотрим почему этот скрипт не хочет нормально выполняться, а почему-то начинает пытаться выполнить /etc/passwd
P.S. А в целом статья шикарная
fk my life once again
Из моей копилки, последнее. Mysql 8.0 innodb, который блокировки накладывает по строчно.
Код в скрипте и код в скрипте внутри хранимки должен же работать одинаково? Правда же ведь?
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
INSERT INTO MyTable
SELECT Name, ... другие поля...
FROM MyTable
WHERE Id = @MyId;
COMMIT/ROLLBACK;Вот эта штука, при параллельном запуске с двумя разными @MyId внутри хранимки работало так, будто блокирует всю таблицу. Если запускать вне хранимки - работает как и описано в документации, с блокировкой по строкам.
Так то дело было в уникальном индексе на одно из полей в списке select, что как бы логично. Но какого хрена…???
Почему так? Потому что «датаклассовость» не наследуется.
А если бы наследовалась? Пришлось бы добавлять декоратор @not_a_dataclass_anymore_ha_ha, чтобы отменить, когда нужно?
Миф 2: У нас есть версии и системы контроля версий, так что ничего не ломается и всё отслеживается
Миф 7: Это программирование, поэтому помощь повсюду: документация, IDE, LLM, …
Миф 8: Это программирование, поэтому всё надёжно
Если человек верит рекламе, что программирование — это просто, то он вряд ли мыслит в категориях VCS, IDE и качества кода.
По сумме всей статьи.
1. Категорически согласен с общим выводом. Почти все примеры не из моих областей, но я их понимаю и верю описанному. (Ну с argparse уже разобрались до уровня багрепорта.) Мог бы привести пачку своих аналогичных, но это было бы повторением того же с другой спецификой.
2. Но теперь нужно переходить к двум главным вопросам, как обычно. Но при этом на метауровне. Главное, "Что делать?" превращается в "Для чего именно - что делать?" Первая проблема - обучение. Уже были голоса, что заметная часть входящих в IT спотыкается именно на том, что на них наваливается реальная сложность, и должно хватить сил для её преодоления. А ещё это создаёт барьер между теми, кто "вошёл", и теми, кто не идёт напрямую в IT, но мог бы брать на себя простейшие задачи. Вторая - как в реальных системах уменьшать избыточную сложность, а перед этим - как её детектировать и помечать. Одна из этих задач более техническая, а две - гуманитарные, в хорошем смысле.
Коммит с названием maybe ready for prod гениален даже в одном экземпляре. И по бессмысленности своей и по кровожадности. Что уж говорить про несколько. Мне вот интересна была бы подборка комментов от лидов и ревьюверов к непринятому PR с подобным названием. Желательно без незапиканных матов.
А когда-то я искренне полагал, что лучшие байки - армейские.
вообще, любая деятельность, не связанная с лопатой, непроста. И вот эти батлы про то, что "это просто" и "это пипец как сложно" смысл имеют очень небольшой.
Потому что у людей у всех разный бэкграунд, и то, что одному сложно, для другого - семечки.
При понимании, что все ЯП - языки искусственные, половина описанных в статье сложностей просто пропадает. Да пофигу, обозначают скобки одно и то же или что-то разное в разных случаях. Просто держим в уме это и работаем. Никто не требует от английского отказаться от некоторых явно излишних форм прошедшего времени, которые причем сами носители употребляют неправильно в более чем половине случаев, кроме продвинутых филологов. И все нормально употребляют язык. Так и тут. Многие вещи непривычны новичку (как сложение в JS), но это искусственный язык, у него может быть произвольная логика и еще более произвольный синтаксис. Ну, типично - вон в экселе в стандартных формулах параметр 0 означает строгое соответствие, единица нестрогое, я в пользовательские функции писал буквенные параметры, просто чтобы юзера читали хелпик, так как надо было понимать, что ставишь, а не просто по дефолту, потому что "у VLOOKUP вот так, и я привык". Логика некоторых вещей в ЯП скрыта или исторически обусловлена. Это данность с ней и живем. К вопросу, с множеством нелогичных или непонятных вещей как с данностью работают, и весьма успешно, во многих областях.
Про документирование и хелпики. Ну, не везде. Напороться в прикладном программировании на незадокументированную или не описанную где-то функцию или проблему надо еще суметь. Описанные в статье случаи сколько времени собирались? Если неделю, то да, программирование - это сложней, чем бегать по минному полю. А у меня вот всяких странностей, сложностей, нелогичностей, ошибок и прочего с объемом на статью лет за 10 разве что накопилось. И ситуаций, когда я нигде помощи найти не мог, буквально три за последние три года. Одна связана с аппаратными проблемами. Только одна из ситуаций как-то повлияла на работу и зарплату (долго возился, развел руками и отдал на аутсортс).
Ну, а то, что систем контроля нет - практически в любой отрасли дырки. На складе организовали еще до меня канбан на упаковку, приехал, сходу обнаружил, что есть совершенно провальные звенья процесса, когда точного учета материалов производство фактически не ведет, а тупо подмахивает не глядя.
С пробелом и я сегодня столкнулся. Потребовалось мне воспользоваться магией ./configure , которому передаётся куча параметров. И добрый человек в примере записал это так:
./configure \
--with-a \
--with-b \
(и так далее..)Поскольку мой опыт в этой магии близок к нулю, я эту команду строил в текстовом файле. Сделал, копирую в консоль - не работает. И ошибки какие-то странные:
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type:
configure: WARNING: unrecognized options: --with-webp-dir
Причём в примере никакие "--build, --host, --target" не указаны 100%!
Разгадка проста в строчке перед "--with-webp-dir" у меня после обратного слеша затесался пробел, и обратный слеш стал экранировать не перевод строки, а этот самый пробел.
Эх, я недавно одну лишнюю скобочку удалил и накрыл региональную инфраструктуру, на восстановление которой полторы недели ушло... Good times.
Прочитал только первый пример и дальше читать желание отпало.
Автор хотел показать как страшно ошибаться в программировании и привел целый пример и даже эксперимент провёл.
Неясно осталось что произошло вследствие ошибки: дом упал, кто-то умер, ракета не взлетела или села куда-то не туда?
Зы. дописал комментарий и подумал - может статья сарказм? Пролистал и вижу, что нет.
Накину 5 копеек
Есть такая очень неплохая CMS Pimcore
Не без тараканов в головах разрабов(особенно с 10-й версии), но гуд
И как-то нарвались на лютую проблему: устанавливаем дату в поде соответствующего типа, а она сохраняется в базу на день раньше!!!
Я чуть крышей не поехал, пока понял что происходит.
А происходит тривиальная, совершенно логичная вещь.
У сервера есть настройка часового пояса. ВСЕГДА.
У CMS есть настройка часового пояса клиента.
Когда клиент вводит дату, происходит коррекция. Правильно? Правильно. Логично? Логично!
А что происходит если работает ДВА клиента в РАЗНЫХ часовых поясах?? :))))))))))))))
Привет автор.
Да понимаю, особенно когда ты начиающий программист. Я сейчас именно начинающий. Проблема в программировании по большей степени что знать всё невозможно и опечатка даже в одном символе решает всё. Думаю когда накопиться опыт работы с частью того с чем работаешь то и опечатываться станешь реже ну или хотя бы замечать опечатки можно будет немного чаще.
Это я думаю самая вредная проблема программистов разного уровня. Да и ещё добавлю что технологии настолько разные что путаться между ними будешь часто особенно если использовать много разных технологий с похожими настройками (но такими разными в мелочах) ;-(.
Программирование — это вообще не просто!⠀