Комментарии 43
Программисты как спортсмены
Почему бы не делать акцент не на инструментах, а на задачах, которые были решены с их помощью? Тогда и не будет нужды в особой гонке за «понтами», которые, «дороже денег».
Почему вы никогда не выучите все фреймворки
Задач, которые вы способны решить, явно меньше, чем всякого рода фреймворков. Поэтому и нет никакой необходимости их все учить. Только те, которые реально помогают...
На самом деле это называется "все побежали - и я побежал", стадный эффект, которому многие подвержены.
"Ты до сих пор используешь Perl и C? Они устарели!"
Но они же работают, задачу решают? Если не решают - вот тогда надо искать другой инструмент, который решает, и решает лучше.
Другой - не всегда "самый новый", а заказчику не нужен бег, ему нужен результат.
Бег ради бега нужен только бегуну и тому, кто продает бегунам приспособления для бега...
Другой - не всегда "самый новый", а заказчику не нужен бег, ему нужен результат.
между разработчиком и заказчиком теперь столько слоев, что то, что нужно заказчику ни как не влияет на разработчиков, в большинстве случаев, к сожалению.
Бежать все-таки нужно иногда - когда ты наемный программист и видишь, что кол-во вакансий по твоему текущему стеку неуклонно и быстро уменьшается, или уже уменьшилось ниже некого порога.
Никогда не смотрел на количество вакансий, меня всегда интересовало только качество инструментария в моих глазах.
Чтобы быть трудоустроенным, мне нужна 1 (одна) вакансия, а не все до какого-то там порога. Нравился бы мне КОБОЛ или перл — до сих пор писал бы на КОБОЛе или перле.
И наступает время, когда эта одна вакансия пропадает, потому что соседняя группа наконец-то, за 5 лет работы переписала всё на Java. И сразу без работы и без шансов найти что-то на Коболе.
Я — рисковый малый.
Есть у меня подозрение однако, что legacy хватит и на век @cupraer, и на век нынешних джунов - тоже.
Разумеется. И на век еще не родившихся джуниоров тоже.
Ну вот мне уже не хватило (desktop-apps и классический client-server, т.е. не в Вебе). Пришлось переучиваться.
Команду разработки Microsoft Office разогнали? Браузеры перетащили с десктопа в веб? Еще миллион примеров живущих и здравствующих десктопов?
Найдите вакансии в hh или даже на зарубежных ресурсах на десктопные позиции, чтобы работать удаленно дома в РФ.
Нет, я буквально парочку в hh видел (из тысяч других), но там нужен Qt или Avalonia.
Нет, так это не работает. Я отвечал вот на этот комментарий:
Бежать все-таки нужно иногда - когда ты наемный программист и видишь, что кол-во вакансий по твоему текущему стеку неуклонно и быстро уменьшается, или уже уменьшилось ниже некого порога.
Ни про какие дополнительные условия, наподобие удаленной работы, или поиска вакансий через какие-то сайты — речь не шла. Если надо без лишних телодвижений устраиваться через эйчаров на любую мало-мальски подходящую по стеку вакансию — тогда мой вариант не подходит.
а если количество вакансий растет, но не по одной вакансии никто не в состоянии сказать что же они делают и что в конечном итоге должно получиться?
Вместо работы - перечисление (как бы) технологий, вместо слов наборы букв, то есть сплошной ЛЛМ головного мозга.
Фреймворки устаревают. То, что сегодня преподносится как мастхэв, каттинг-эдж и "все это используют", завтра станет устаревшим, а послезавтра - вонючим давно не поддерживаемым легаси, которое отовсюду надо выпилить, но непонятно как это сделать.
Первый фреймворк, который я освоил, был TurboVision. Тогда это была моднейшая штука, на которой можно делать всё что угодно. Ну и что? Где он сейчас? Кто-нибудь о нём помнит?
Первый фреймворк, который я освоил, был TurboVision.
У меня это ObjectProfessional (OP), причем, в исходных кодах. На нем тоже «можно было делать всё что угодно». В то время требовали уже срочно сдавать компьютерную отчетность, но программ для их создания еще не было. Написал свою, на OP. Было очень круто тогда… :)
В то же время есть Spring и ASP, которые перешагнули 20-летний рубеж и все еще держатся бодрячком, и даже если завтра выйдет что-то "быстрее, выше, сильнее", будут востребованы еще как минимум десятилетие за счет легаси.
а еще есть Линукс и Виндос. кооторые перешагнули 30-летний рубеж и которые в каком-то смысле тоже фреймворки или даже фреймворки для фреймворков.
есть ... и ASP, которые перешагнули 20-летний рубеж и все еще держатся бодрячком
Вы ASP.NET имели в виду? Интересуюсь, потому что до него был ASP.Classic он же - просто ASP, основными языками программирования на котором были VBScripj и JavaScript (который - сильно не тот JavaScript, который можно сегодня выполнять на Node.JS).
Так вот, программирование на тогдашнем ASP.NET разительно отличалось от такового на современном ASP.NET. Исходный ASP.NET (фреймворк WebForms) имитировал для тогдашнего разработчика знакомую ему парадигму программирования для ПК (типа Delphi, Visual Basic и т.п.) и был существенно завязан на возможности Internet Information Server (IIS) для Windows. Современный ASP.NET Core даже уже не поддерживает WebForms и никак не привязан к IIS и Windows. И даже основной язык программирования - C# - сильно изменился: достаточно вспомнить, что в исходном C# не было даже generic-типов. Короче, ASP.NET похож на тот нож, которому нет сноса: у которого трижды заменяли лезвие и дважды - рукоятку.
Я помню.
Если язык или фреймворк «развивается» после фиксации версии 1.0.0 — значит, это говно, а не язык (фреймворк), он спроектирован дебилами, и использовать его в работе — вечная непобедимая боль.
А какой язык или фреймворк не развивались после этой версии?
Если бы не маркетинг и не необходимость прямо вчера заставить толпу хомячков пойти за дудочкой гугла — таким языком был бы Go. Он перестанет чинить родовые травмы после версии 2.0, что тоже вполне достойно.
У раста были шансы, но команда буквально закапывает сама себя вместе с языком.
Если бы третий питон назвали бы — не знаю — Liasis, — он бы попал в этот список.
Руби не сильно менялся (и не ломал обратныю совместимость) с версии 1.0.
Эликсир, без оговорок.
Кложа, без оговорок.
Наверное что-то еще, но лень вспоминать.
У раста были шансы, но команда буквально закапывает сама себя вместе с языком.
А что там?
На мой облыжный взгляд, они слишком увлечены добавлением новых оптимизаций и вообще расширением возможностей, вместо того, чтобы зафиксировать язык в каком-то состоянии и дальше заниматься нестандартными библиотеками.
Вот, очень яркий пример: встроенные атрибуты. Зачем их столько? А главное, если tool attributes — не встроенные, то что вообще означает фраза «Note: rustc currently recognizes the tools “clippy”, “rustfmt”, “diagnostic”, “miri” and “rust_analyzer”»? Я уж молчу про то, как организована работа с AST, как будто команда сама не очень понимает, зачем оно вообще нужно.
Чуть копнешь в сторону от стандартного пути — и адхок на адхоке, причем всё размазано ровным слоем: часть в языке, часть — в стандартной библиотеке, часть — на откуп библиотекам, и мне (возможно, только мне) вообще неясно, как определяется, куда пойдёт то или иное расширение и почему.
В этот же самый момент команда занята оптимизацией енумов.
Хорошо, конечно, было бы придумать раз и навсегда язык или фреймворк, и чтобы он оставался применимым всегда. Но по жизни так не получается. Почему это так на глубоком филосовском уровне - про это вы должны были учить на занятиях по диалектическому материализму, но если не учили - это не важно - потому что по жизни оно именно так.
То есть, с одной стороны, развитие средств IT идет, и возможности аппаратного обеспечения растут. А, с другой стороны жизнь меняется и потому к аппаратно-программным комплексам возникают новые требования. Так что, по жизни постоянно возникают новые задачи, которые требуется решать новыми средствами.
И тут возникает дилемма: придумывать новый "вечный" язык/фреймворк под эти задачи или же дорабатывать старый, чтобы его можно было бы использовать и для новых задач тоже. Индустрия предсказуемо идет, в целом, по второму пути, потому что первый путь сразу делает всё ранее написанное этим самым legacy. На втором пути legacy тоже по жизни возникает, но в меньшем количестве.
Программисты на си сейчас удивились.
Программисты на эрланге не удивились, потому что мир в лице самых передовых его особей пока еще только топчется на пороге переизобретения неспецифицированной, глючной и медленной реализации половины эрланга во флагманах. Мой прогноз: в го они дойдут до этого примерно через полтора года, в расте — года через три.
Программисты на си сейчас удивились.
Я - не удивился. Потому что много чего помню.
Я программировал на C (в том числе) на момент начала массового распространения Windows. И я отлично помню, каким геморроем было написание программы для Windows "по книге Петцольда"- первым ее изданиям, когда C был единственным доступным для этого инструментом, и на нем надо было писать обработчики всех сообщений в одном огромном switch в оконной процедуре. И помню, каким облегчением было появление более адекватных средств разработки в виде библиотек классов OWL и MFC для тогдашнего C++ (от Borland и MS соответственно), которые хоть и не позволяли абстрагироваться от сообщений, но, по крайней мере, убирали многие детали "под капот", чтобы о них не надо было заботиться. Ну, а потом появилась Delphi, а вместе с ней - формошлёпы.
Я, вроде бы, нигде не утверждал, что библиотеки писать не нужно.
Это - не библиотеки, а фреймворки: они не просто предоставляли дополнителные функции, а определяли саму структуру программ. Для программирования под Windows библиотеками не отделаться: там - другая парадигма, событийно-ориентированная, и, соответсвенно - другая структура программы. Поэтому, по хорошему, потребовался именно фреймворк - т.е. каракас приложения с заранее заданной структурой.
Не то, чтобы событийно-ориентированная структура программ ранее не встречалась - к примеру, для MS DOS TSR-программы с обработчиками прерываний внутри были событийно-ориентированными - но основная масса программ пользовалась последовательной логикой. Для Windows это не годилось.
А когда Windows поменялась - вместо Win3.x с чисто кооперативнной многозадачностью (она же - асинхронность) появилась Win9x с какой-никакой вытесняющей многозадачностью - то и фреймворкам пришлось развиться: например, та же Delphi получила версию 2.0 с поддержкой всех этих потоков, примитивов синхронизации и прочих механизмов вытесняющей многозадачности.
Ну, а потом асинхронность вернулась - в современном програмировании для серверной части веб-приложений (back-end), например, она используется часто.
Это уже немного терминологический спор: мне удавалось писать на Win32API без фреймворков, насколько я любил Дельфи, настолько же мне было непонятно, зачем вообще тащить в такой прекрасный API ту же парадигму в виде C++Builder’а, когда на Win32API это проще и быстрее. Но ок, пусть это даже будут фреймворки: новые фреймворки (в первой версии) нужны, вы меня убедили (да и убеждать не надо было особо, я и новые языки встречаю с теплотой и ожиданиями, жаль они все в современном мире вылупляются довольно убогими, кроме эликсира, кложы, идриса и отчасти эльма). А вторая и последующие семь зачем?
потом асинхронность вернулась
Ничего, скоро стюардессу закопают обратно, это всё еще тупиковый путь. Даже в го уже сообразили, что на кооперативе удобно только бухгалтершу охмурить.
мне удавалось писать на Win32API без фреймворков,
Позвольте уточнить: вы писали на API программы для Windows с их оконными процедурами, или же - консольные программы. Интересуюсь, потому что Win32 API - понятие растяжимое: в основном под ним понимают системные вызовы к ОС (точнее, к подсистеме Win32 или как она сейчас там называется), а 32-х и больше расширение WinAPI в него то включают, то не включают. Если вы таки писали именно оконные процедуры, то я удивляюсь вашим эстетическим предпочтениям (и точно уверен, что их разделяют немногие). Ну, а консольные программы - они везде похожи, различаются только конкретные системные вызовы.
Ничего, скоро стюардессу закопают обратно, это всё еще тупиковый путь.
"Блажен кто верует - тепло ему на свете"(с)
Пока переключение контекста не перестанет стоить так дорого - не закопают, и путь асинхронности останется магистральным. А оно в обозримом будущем - не перестанет.
И потому, что конвейерная архитектура с предварительным выполнением операций вряд ли куда-то денется, ибо без предварительного выполнения сложно равномерно загрузить исполнительные устройства процессора - а переключение контекста ведет к перезапуску конвейера. И потому что современные процессоры не могут позволить себе однородный доступ к памяти, т.к. доступ к динамическому ОЗУ слишком медленный, а потому вынуждены обмазываться кэшами для ускорения выполнения - а переключение контекста ведет к сбросу кэшей.
Поэтому в языках программирования могут думать всё, что им нравится, но определяющую роль играет архитектура железа - о которой вы, похоже, при всей своей эрудиции просто не задумываетесь.
Windows с их оконными процедурами
Ну окна были не сильно навороченными, это точно, но это был GUI. Там был долгоиграющий проект с каким-то ЧПУ, вот мы клепали к нему ПО. Зачем-то на нем крутилась полноценная винда, и от нас требовалось две версии: для собственно станка (одно большое окно) и «прорабская», со всеми окнами всех станков в трее (я тогда еще страшно гордился воим решением затолкать в трей только одну иконку с количеством станков, которую мы перекрашивали в красный при инцидентах). Я не помню уже, возможно, мои предпочтения были обусловлены тем, что в станковой версии (а это был просто ключ запуска, потому что оператору могла при сбоях потребоваться вся винда) нужно было перехватывать все на свете, и во фреймворках того времени это было сложнее, чем на голом АПИ. А может быть, я просто извращенец.
определяющую роль играет архитектура железа
Вы переоцениваете значимость производительности для примерно 99% задач. Зато масштабировать параллельность гораздо легче, писать и читать код гораздо легче, а еще параллельное выполнение быстрее на целом классе задач. Если вас не убеждает пример го, который начинался с кооператива, но неизбежно пришел к вытеснению, — просто оставлю здесь два ключевых слова: виртуальная машина.
Переключение контекстов в виртуальной машине бесплатное. Но баре метал, разумеется, останется, просто там не нужна никакая многозадачность обычно, а там, где нужна — можно и на си помучаться.
от нас требовалось две версии: для собственно станка (одно большое окно) и «прорабская», со всеми окнами всех станков
Если это окно имело фиксированный размер и содержало только стандартные элементы управления, то это менее сложно, чем рисовать свое окно со своим содержимым: можно было обойтись созданием шаблона в Dialog Editor и запуском диалогового окна с урезанной процедурой обработчика. Лично я предпочитал в начале 90-х свою мелочовку делать именно так. Но Delphi все равно лучше, хотя бы тем, что там можно использовать более разнообразные элементы управления и даже создавать свои. Ну и без церемоний с обработкой сообщений можно вообще обойтись.
Зато масштабировать параллельность гораздо легче...
... если не учитывать затраты на переключение контекста.
писать и читать код гораздо легче,
Нет. Плавали - знаем: нужно аккуратно избегать гонок и вообще одновременного доступа к переменным и прочим общим ресурсам. Однопоточное приложение, где такое невозможно в принципе, писать проще. Асинхронное приложение на async/await. которое на уровне исходного кода весьма успешно мимикрирует под однопоточное - тоже. Но про гонки и одновременный доступ при асинхронном выполнении в многопоточной среде (а они сейчас в том же C# все такие, ASP.NET Framework с его ровно одним потоком в контексте синхронизации обработчика веб-запроса остался фактически в прошлом) совсем забыть всё же не получится.
а еще параллельное выполнение быстрее на целом классе задач.
Кто-то, помнится, чуть выше писал что для 99% приложений это не нужно. К тому же, асинхронность не исключает параллезацию: в том же .NET все нужные инструменты для ее использования есть.
Переключение контекстов в виртуальной машине бесплатное.
Чего? Процессор-то у виртуальной машины остается все тем же физическим - точнее, под его предствление выделяются сколько-то физических ядер физического процессора(ов), которые гипервизор, к тому же, старается лишний раз не менять.
И как, по-вашему, предсказатель ветвлений в этом физическом ядре предскажет переход на код в другом контексте? И как в кэше нужного физического процессора окажутся данные, которые использует код в контексте, куда произошло переключение?
Слухи о моей эрудиции сильно преувеличены, мне неизвестны три четверти баззвордов современного программирования.
Учитесь основам. Это замедлит устаревание ваших знаний.
Во-1 это опасно.
Нас нанимают не-технари — люди, далекие от всех инженерных подходов сразу. И мы вынуждены играть по их правилам, иначе "работодатель не готов пригласить вас" ©.
Они оценивают нас по названиям технологий, не понимая что кроется за ними: банально сравнивая написанные в нашем резюме названия со списком, присланным тимлидами.
И хорошо если тимлид/сеньор проекта сформулировал требования, достаточные для порхождения кандидатом первичного фильтра в виде HR, а не просто перечислил названия популярных на сегодняшний день фреймворков.
Но оказалось сеньоры бывают разные...
Во-2 основы не интересны этим самым нанимающим людям.
Разумеется я не имею в виду инженеров, которым — несмотря на их опыт — до сих пор любопытно "а что будет если". Я имею в виду людей, для которых задача "написать аналог гугла" состоит из вывода на экран одного инпута и одной кнопки.
И когда эти люди будут нанимать вас на подобную задачу, они будут ожидать от вас перечисления все тех же названий фреймворков из п.1, с помощью которых вы будете выводить инпут и кнопку на экран. А отнюдь не рассказа о веб-краулерах и уровнях кэша на пути от сервера до клиента...
Нас нанимают не-технари […]
Отучаемся, пожалуйста, говорить за всю сеть. Я с не-технарями даже разговаривать не стану, например.
Нас нанимают не-технари — люди, далекие от всех инженерных подходов сразу. И мы вынуждены играть по их правилам, иначе "работодатель не готов пригласить вас" ©.
Это - рынок, и работодатели на нем бывают разные. Но, главное: потенция, чтоб не сваливать - она сохранается у тех, кто делает меньше ошибок. Так что оценка соискателей по "списку фреймворков" - она, если ведет к ошибкам, использоваться перестанет - как (вроде бы), перестала использоваться оценка по задачам "про люки".
Я имею в виду людей, для которых задача "написать аналог гугла" состоит из вывода на экран одного инпута и одной кнопки.
Конечно, никто из заказчиков/нанимателей не отказался бы от того, чтобы всё делалось по одной кнопке. Но по жизни, как известно, "по одной кнопке только вода из бачка сливается", а потому так сделать чаще всего не получается. Но будущее индустрии, я полагаю - именно за пользователями фреймворков. Которыми однако, я полагаю, будут роботы на основе LLM (или что ещё там придумают вместо).
Кароче, вывод: актальный набор инструментов изучить надо, но когда появятся ресурсы на изучение чего-то ещё, имеет смысл вложиться в общие принципы, чтобы облегчить себе изучение других инструментов. Но - только если изучение этих общих принципов действительно облегчит изучение новых инструментов.
А облегчит ли - это зависит от требуемой глубины изучения. И для типичного современного разработчика - оператора фреймворка, к примеру, знать общие принципы выглядит необязательным: для решения большнства задач достаточно изучить и использовать набор заклинаний для управления этим фрейворком. Но при этом кто-то всё-таки должен решать то меньшинство задач, для которых использования заклинаний без понимания того, что они делают, не хватает.
Найдется ли этот кто-то на конкретном предприятии - зависит от организации процесса разработки на нем. И в целом, по моим впечатлениям, индустрия разработки ПО до нужного уровня организации разделения труда ещё не доросла. Но, возможно, я ошибаюсь - в конце концов, я - не менеджер, профессионально организующий разработку ПО. А потому в дальнейших спорах на эту тему (буде они возникнут) я участвовать не буду.
Почему вы никогда не выучите все фреймворки