Comments 24
То что программирование эволюционирует и развивается не говорит о том что программисты должны останавливаться в развитии и стагнировать.
Если же говорить про минимальный приемлимый уровень понимания который должен быть у программиста/разработчика (не важно как вы его обзовёте, сути дела это не меняет), если этот человек имеет дело с императивными ЯП, то он должен хорошо понимать, что такое временная и пространственная сложность, в противном случае, то что он будет писать с большой долей вероятности будет неоптимальной хренью. Наобум склеить библиотечки вместе, чтобы на выходе получился "работоспособный" кусок логики сегодня любой очередняр может(а местами и вовсе ИИ справляется). Программисту/разработчику платят за его знания, за то что он разбирается как лучше, а не за то что он умеет читать доки и водить пальцами по клавиатуре, выводя любой бред который сможет пережевать компилятор.
Я не говорю что обязательно понимать как именно что-то работает под капотом(хоть это и не повредит), но обязательно нужно чётко знать особенности этого чего-то, а как результат при каких условиях это что-то оптимальней использовать.
То что программирование эволюционирует и развивается не говорит о том что программисты должны останавливаться в развитии и стагнировать
Развитие не лишь движение во внутренности. Это и движение (изучение новых фреймворков, архитектурных подходов, предметных областей) и "вверх" (от кода к архитектуре системы, к управлению проектом). Если Вы работаете/работали в компании, то быть может знаете, что в IT так бывает, когда в архитектора переходят из аналитики, иногда из QA.
Наобум склеить библиотечки вместе, чтобы на выходе получился "работоспособный" кусок логики сегодня любой очередняр может
Есть градации, такие как джун/мидл/синиор. Синиоры могут погружаться в платформу, но это не значит, что они даже знают информатику на высоком уровне.
Развитие не лишь движение во внутренности. Это и движение (изучение новых фреймворков, архитектурных подходов, предметных областей) и "вверх" (от кода к архитектуре системы, к управлению проектом).
А я говорил что нужно развиваться только как вы выразились "вниз"? Вы где-нибудь это в тексте видели? Я акцентировал внимание на вопросе оптимизации только как о чрезвычайно проблемной области в нынешних реалиях, в виду того что всё чаще программисты отдают именно этот вопрос на откуп машине, совершенно не задумываясь об нём.
Используют раздутые неоптимальные фреймворки, когда достаточно мелкой библиотечки или и вовсем мелкой самописной функции с меньшими накладными расходаим и куда лучшей ассимптотикой алгоритма, применяют структуры данных не по назначению и т.д. и т.п.. Не счесть примеров подобных косяков, все из которых растут из банального незнания и нежелания бороться со своим незнанием т.е. учиться.
Я не говорил что не нужно учить фреймворки и библиотеки, я говорил что нужно знать их лучше и применять их в нужных местах, а не где и как придётся, как это всё чаще делается сегодня.
Вопрос архитектуры тоже будет не лишним, но именно для программиста куда важнее знать именно паттерны программирования, которые помогут ему лучше организовать его макароны.
Если Вы работаете/работали в компании, то быть может знаете, что в IT так бывает, когда в архитектора переходят из аналитики, иногда из QA.
Действительно бывает, и что с того? Мы же не говорим от том как быть архитекторм, аналитиком или тестером, при чём здесь это? Кажется мы затрагивали тему именно программистов и разработчиков, нет? Для всех специалистов разные требования, хоть и пересекаются в некоторых местах, но не стоит мешать мух с котлетами.
Есть градации, такие как джун/мидл/синиор. Синиоры могут погружаться в платформу, но это не значит, что они даже знают информатику на высоком уровне.
А что синьор должен знать? Только свою платформу? Завтра все перестанут её применять и этот узкоспециализированный "синьор" переедет со своими знаниями платформы на помойку.
Есть набор фундаментальных знаний, что позволяет человеку быстрее освоиться в любой среде и на любой платформе, поскольку эти знания общие для всей сферы программирования в целом, именно эти знания и отличают хорошего профессионала.
Используют раздутые неоптимальные фреймворки, когда достаточно мелкой библиотечки или и вовсем мелкой самописной функции с меньшими накладными расходаим и куда лучшей ассимптотикой алгоритма, применяют структуры данных не по назначению и т.д. и т.п.. Не счесть примеров подобных косяков, все из которых растут из банального незнания и нежелания бороться со своим незнанием т.е. учиться.
Я не говорил что не нужно учить фреймворки и библиотеки, я говорил что нужно знать их лучше и применять их в нужных местах, а не где и как придётся, как это всё чаще делается сегодня.
Даже если человек погружен в низкий уровень, на то, чтобы разобраться в библиотеках, ему понадобится время. Если перед тобой стоит задача использовать более маленькую и возможно, производительную библиотеку, пожалуйста, сегодня есть AI, который проанализирует тысячи ссылок минут за 10 и даст результат.
Более того, если в тз или спецификации нет требования о маленьком размере бинарника, это не твоя забота, как разработчика.
Итак, каков смысл в том, чтобы тратить время на изучение каждой библиотеки внутри?
Time to market важен. И компания всегда заинтересована оставить не специалиста, который знает глубже, а того, который сделает быстрее и эффективнее. Компании не позволено держать зазнайку, который знает больше, а делает дольше.
Таким образом, постепенно специалисты делятся на тех, которые научились применять AI и на тех, которые не приспособились.
То же, что и с плюсами. Сайты на ассемблере делать можно. И делали. Пойди на рынок, заработай на этом...
Даже если человек погружен в низкий уровень, на то, чтобы разобраться в библиотеках, ему понадобится время.
Какой к чёрту "низкий уровень"? Что вы заладили "низкий уровень, низкий уровень", базовое понимание как оценивать сложность алгоритма - это НЕ низкий уровень, это в нормальных колледжах и институтах должны учить на алгоритмах и структурах данных. Низкий уровень - это ассемблер или в крайнем случае Си для bare metal, даже C++ сложно однозначно причислить к низкому уровню с его механизмами абстракций. Единственное что вы демонстрируйте сыпя термином "низкий уровень" - это свою некомпетентность в вопросах программирования.
Если перед тобой стоит задача использовать более маленькую и возможно, производительную библиотеку, пожалуйста, сегодня есть AI, который проанализирует тысячи ссылок минут за 10 и даст результат.
Проанализирует тысячи строк и даст результат? Да, вот только в этом результате с большой вероятностью будут баги, из-за которых куда больше времени уйдёт на отладку, чем ушло бы на само написание кода. ИИ инструментами нужно пользоваться чрезвычайно аккуратно, они могут за тебя написать какой-нибудь бойлерплейт, но стоит задаче хоть немного отойти от общего случая, то из ИИ тут же польётся полная лажа.
Более того, если в тз или спецификации нет требования о маленьком размере бинарника, это не твоя забота, как разработчика.
При чём тут маленький размер бинаря? Я говорю про сложность операций и накладные расходы, размер бинаря тут дело десятое.
Time to market важен. И компания всегда заинтересована оставить не специалиста, который знает глубже, а того, который сделает быстрее и эффективнее. Компании не позволено держать зазнайку, который знает больше, а делает дольше.
Я понимаю, что тебе сложно это видимо даже представить, но прикинь, а можно ведь и быстро и оптимально, достаточно просто немного знаний и периодически включать голову. Но да, это ведь таааак сложно, не так ли?
Таким образом, постепенно специалисты делятся на тех, которые научились применять AI и на тех, которые не приспособились.
Не спорю, вот только нужно понимать, что тебе ИИ высрал, по хорошему разбирать каждую строчку отдельно, а не в тупую копировать всё в IDE надеясь что это заработает, в противном случае единственный результат на который тебе стоит надеяться - это то что ты капитально окретинешься, не более.
То же, что и с плюсами. Сайты на ассемблере делать можно. И делали. Пойди на рынок, заработай на этом...
При чём тут это? Что это вообще за ахинея? Я разве предлагал применять инструменты не по назначению?
ИМХО, чем больше знаешь, тем лучше. Потом проще разбираться с любой новой технологией. У вас появится собственный взгляд на те инструменты и подходы, которые продвигают сообщества и возможность делать более осознанный выбор, а не просто бежать за чем-то хайповым. Не будет такой жесткой привязки к библиотеке, системе сборки и пр. Сможете заглядывать "под капот" ваших инструментов и библиотек. Но все это, если вам интересно ваше дело. Как и в любой прфессии.
Без универа, без технических знаний, и создают величайшее искусство, даже понятия не имея, что такое бинарный поиск.
Я результаты этого "величайшего" искусства на работе разгребаю каждый день :((
Принцип общий, независимо от рода деятельности - базовый кругозор, затем специализация.
30 лет назад было более чем достаточно высокоуровневых задач и не все долбились в машинных кодах, и на С можно вполне себе комфортно писать хорошо структурированный код похожий на объектный (поддерживать его труднее, это да, и сломать легко) но писать можно. На питоне можно такую портянку написать при желании (встречал) или на Java (встечал в консалтинге такие ужасы что можно помереть) - не каждый на С сможет такое создать. Высокая абстракция не запрещает создавать непонятные конструкции.
В реальных бизнес задачах алгоритмы не нужно разрабатывать - достаточно знать какие есть и правильно их применять (в виде коллекций и библиотек). С другой стороны, иногда возникает необходимость сделать какой нибудь троттлинг и тут как раз алгоритмическая база не лишняя - хотя бы на коленке сделать что то не работающее в сложности 2^N a хотя бы в N^2
Вот я, "жаба" программист с 25 летним стажем (и немного в других языках), сел и закрыл пробел с питоном этим летом (время появилось). Зачем? Для кругозора и для понимания процессов в ML/AI сообществе чтоб отслеживать их тектонические активности. Хотя меня уже тошнит от кодирования, пора бы на рисование кубиков переходить...
Языкам программирования на развитие требуется некоторое время. 15 лет назад Python был эдаким языком энтузиастов. 10 лет назад он зашевелился, а сегодня Google имеет принцип: "Python там, где это возможно, C++ там, где вынуждены."
Может быть Вы немного проспали но Google вместо "Python там, где это возможно, C++ там, где вынуждены." давно создали себе целый язык Go потому что видимо это не очень работала история c преисполнившимся за 15 лет Python.
Я долго пытался решить для себя, кто же прав. Пытался нащупать центр проблемы. И мне кажется, что я нашел, а центром является эволюция.Программирование эволюционирует. И это касается не лишь языков или парадигм, но и вообще взгляда на него.
Да я не спорю языки программирования эволюционируют потихоньку. Но по факту то что Вы описываете вывозит не их эволюция а эволюция железа и эволюция компаний по умению впаривать плохой софт.
Вы так описываете как будто ничего не поменялось и там где раньше нужны были знания и умения, сейчас все по волшебству само хорошо работает. Не работает. С каждым годом софт становиться все хуже и хуже. Эти проблемы закрывают в основном производители железа. Компаниям и пользователям все больше и больше приходиться платить из своего кошелька за все большую криворукость разработчиков. Нужно каждые n лет менять железо чтобы запустить банальный "калькулятор" или текстовый редактор. Компании это устраивает, у людей нет выбора.
Посмотрите на врачей. Зачем то учат по много лет анатомию, химию, каждую косточку тела, чтобы потом таблетки на приемах выписывать. Какая глупость да? А могли бы эволюционировать и не забивать себе голову такой ерундой. Или не могли бы? Разница в том что за свои ошибки врач будет расплачиваться сам а за ошибки и некомпетентность программиста в большинстве случаев расплачиваются пользователи, причем в прямом смысле.
Компаниям плевать на пользователей, им нужно тяп ляп и в прод чтобы конкурентов обскакать и впарить продукт людям у которые и выбора то нет. А потом гордые разработчики рассказывают как производительность не важна и как они балуются с новыми фреймворками и изощряются в абстракциях. По Вашему это эволюция? Ну не знаю...
Вы можете привести практические примеры, пожалуйста?
Да что угодно, большинство web приложений, мессенджеры, фреймворки типа spring, IntelijIdea, Продолжать можно долго.
Браузер жрёт 7гб в простое - десять лет назад это была бы вся моя память, пятнадцать лет назад я бы просто посмеялся.
По играм есть замечательное видео https://www.youtube.com/watch?v=WOQbEBcQ0bo. Есть спекуляции, типа плохой стелс не в стелс играх, но общий посыл - правда.
Каждые 5 лет новая волна жалоб на следующую версию windows. Спустя 20 лет XP всё ещё лучшая.
Правильно говорите товарищ!
Да и то я не уверен, если это нельзя решить, поскольку есть векторизация с помощью NumPy.
Это точно не перевод? "Если это нельзя решить" выглядит как калька с английского.
где-то в инете читал тоже такую тему, что надо знать из таких-то языков, и вобщем повторю частично, придётся знать С(и всю зависимость, это если разобраться) по другому сразу тогда (любой другой ЯП) алгоритмы/структуры данных, но по итогу истина по середине причем зная С/С++, что-то изучить проще
может быть даже сразу изучайте раст если вам нравится, всё равно по итогу вникать придётся во всё
где-то в инете читал тоже такую тему, что надо знать из таких-то языков, и вобщем повторю частично, придётся знать С(и всю зависимость, это если разобраться) по другому сразу тогда (любой другой ЯП) алгоритмы/структуры данных, но по итогу истина по середине причем зная С/С++, что-то изучить проще
может быть даже сразу изучайте раст если вам нравится, всё равно по итогу вникать придётся во всё
Здесь скорее вопрос личного интереса и мотивации. Если ты мечтаешь разобраться, как работает процессор, тебе будет интересно. А если ты сайты хочешь делать, тогда такой метод приведет лишь к выгоранию.
Алгоритмы никто не отменял. Но вот я например, надо было мне разобраться, как работает экран, пиксели физические и логические, для решения конкретной задачи, я с большим интересом изучал. А с низу вверх...
Вердикт прост - вам в 1С программисты :-)
Начинать нужно с дискретной математики, теории алгоритмов, теории типов, основ кодирования, если мы говорим о практике то любой из системных языков - C, Pascal, Rust, C++, это база, мне ещё не встречался действительно сильный программист на Python, PHP или Java, обычно они варятся в какой-то своей проблематике, не способны определить сложность алгоритма, понять разницу между AoS и SoA, а от слов типа BWT-преобразование или коды Рида-Соломона падают в обморок
мне ещё не встречался действительно сильный программист
Определите термины. Действительно сильный программист - это?
Это в смысле прям академические знания, как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работают
как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работают
Вы определяете "силу" программиста по его способности решать системные задачи.
Но тот пример, который Вы привели, это не проблема отсутствия академических, как Вы сказали, знаний, а проблема неверного подхода того C# синиора к решению задачи. Ему надо было бы разобраться в причинах происходящего, вспомнить/разобраться, как работают TCP сокеты, как C# управляет памятью и неуправляемыми ресурсами. А что сделал он? Остался на своем уровне абстракции и придумал неэффективное "решение", которое просто работает в его искаженной картине мира.
Сильный прикладной программист не тот, который знает больше и из-за этого не допускает ошибок, а тот, который может загуглить "c# tcp socket keeps closing" и найти информацию про IDisposable, using и правильное управление жизненным циклом соединения. Сегодня с AI это так вообще делается за мгновения.
Большинство прикладных разработчиков не используют те же алгоритмы в сыром виде. Значит ли это, что они не нужны? Они должны понимать сложность алгоритмов не для того, чтобы применять ежедневно, а чтобы не написать случайно в коде цикл в цикле там, где это приведет к коллапсу системы при 1000 пользователях.
Поверьте, заказчику, если это не продуктовая компания, глубоко фиолетово, знаете вы упомянутые вами BWT-преобразование или нет, пишете код сами, или его вам приносит на блюдечке брат, сват, сосед или AI. Вы программируете, чтобы решить задачу заказчика, а не экзаменатора.
Я знаю сотни разработчиков, которые работают в геймдеве или вебе, и понятия о бинарном поиске не имеют. И производят результат, которым клиент доволен.
Программист на Python, который создал веб-сервис с миллионной аудиторией, не обязательно сможет написать драйвер. Это разные "виды силы".
Лестница абстракций и где на ней стоять: изучать ли программирование сложным способом?