Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Программисты как спортсмены
Почему бы не делать акцент не на инструментах, а на задачах, которые были решены с их помощью? Тогда и не будет нужды в особой гонке за «понтами», которые, «дороже денег».
Почему вы никогда не выучите все фреймворки
Задач, которые вы способны решить, явно меньше, чем всякого рода фреймворков. Поэтому и нет никакой необходимости их все учить. Только те, которые реально помогают...
На самом деле это называется "все побежали - и я побежал", стадный эффект, которому многие подвержены.
"Ты до сих пор используешь Perl и C? Они устарели!"
Но они же работают, задачу решают? Если не решают - вот тогда надо искать другой инструмент, который решает, и решает лучше.
Другой - не всегда "самый новый", а заказчику не нужен бег, ему нужен результат.
Бег ради бега нужен только бегуну и тому, кто продает бегунам приспособления для бега...
Другой - не всегда "самый новый", а заказчику не нужен бег, ему нужен результат.
между разработчиком и заказчиком теперь столько слоев, что то, что нужно заказчику ни как не влияет на разработчиков, в большинстве случаев, к сожалению.
Бежать все-таки нужно иногда - когда ты наемный программист и видишь, что кол-во вакансий по твоему текущему стеку неуклонно и быстро уменьшается, или уже уменьшилось ниже некого порога.
И наступает время, когда эта одна вакансия пропадает, потому что соседняя группа наконец-то, за 5 лет работы переписала всё на Java. И сразу без работы и без шансов найти что-то на Коболе.
Есть у меня подозрение однако, что legacy хватит и на век @cupraer, и на век нынешних джунов - тоже.
а если количество вакансий растет, но не по одной вакансии никто не в состоянии сказать что же они делают и что в конечном итоге должно получиться?
Вместо работы - перечисление (как бы) технологий, вместо слов наборы букв, то есть сплошной ЛЛМ головного мозга.
Фреймворки устаревают. То, что сегодня преподносится как мастхэв, каттинг-эдж и "все это используют", завтра станет устаревшим, а послезавтра - вонючим давно не поддерживаемым легаси, которое отовсюду надо выпилить, но непонятно как это сделать.
Первый фреймворк, который я освоил, был 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 похож на тот нож, которому нет сноса: у которого трижды заменяли лезвие и дважды - рукоятку.
Я помню.
А какой язык или фреймворк не развивались после этой версии?
Хорошо, конечно, было бы придумать раз и навсегда язык или фреймворк, и чтобы он оставался применимым всегда. Но по жизни так не получается. Почему это так на глубоком филосовском уровне - про это вы должны были учить на занятиях по диалектическому материализму, но если не учили - это не важно - потому что по жизни оно именно так.
То есть, с одной стороны, развитие средств 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 программы для Windows с их оконными процедурами, или же - консольные программы. Интересуюсь, потому что Win32 API - понятие растяжимое: в основном под ним понимают системные вызовы к ОС (точнее, к подсистеме Win32 или как она сейчас там называется), а 32-х и больше расширение WinAPI в него то включают, то не включают. Если вы таки писали именно оконные процедуры, то я удивляюсь вашим эстетическим предпочтениям (и точно уверен, что их разделяют немногие). Ну, а консольные программы - они везде похожи, различаются только конкретные системные вызовы.
Ничего, скоро стюардессу закопают обратно, это всё еще тупиковый путь.
"Блажен кто верует - тепло ему на свете"(с)
Пока переключение контекста не перестанет стоить так дорого - не закопают, и путь асинхронности останется магистральным. А оно в обозримом будущем - не перестанет.
И потому, что конвейерная архитектура с предварительным выполнением операций вряд ли куда-то денется, ибо без предварительного выполнения сложно равномерно загрузить исполнительные устройства процессора - а переключение контекста ведет к перезапуску конвейера. И потому что современные процессоры не могут позволить себе однородный доступ к памяти, т.к. доступ к динамическому ОЗУ слишком медленный, а потому вынуждены обмазываться кэшами для ускорения выполнения - а переключение контекста ведет к сбросу кэшей.
Поэтому в языках программирования могут думать всё, что им нравится, но определяющую роль играет архитектура железа - о которой вы, похоже, при всей своей эрудиции просто не задумываетесь.
от нас требовалось две версии: для собственно станка (одно большое окно) и «прорабская», со всеми окнами всех станков
Если это окно имело фиксированный размер и содержало только стандартные элементы управления, то это менее сложно, чем рисовать свое окно со своим содержимым: можно было обойтись созданием шаблона в Dialog Editor и запуском диалогового окна с урезанной процедурой обработчика. Лично я предпочитал в начале 90-х свою мелочовку делать именно так. Но Delphi все равно лучше, хотя бы тем, что там можно использовать более разнообразные элементы управления и даже создавать свои. Ну и без церемоний с обработкой сообщений можно вообще обойтись.
Зато масштабировать параллельность гораздо легче...
... если не учитывать затраты на переключение контекста.
писать и читать код гораздо легче,
Нет. Плавали - знаем: нужно аккуратно избегать гонок и вообще одновременного доступа к переменным и прочим общим ресурсам. Однопоточное приложение, где такое невозможно в принципе, писать проще. Асинхронное приложение на async/await. которое на уровне исходного кода весьма успешно мимикрирует под однопоточное - тоже. Но про гонки и одновременный доступ при асинхронном выполнении в многопоточной среде (а они сейчас в том же C# все такие, ASP.NET Framework с его ровно одним потоком в контексте синхронизации обработчика веб-запроса остался фактически в прошлом) совсем забыть всё же не получится.
а еще параллельное выполнение быстрее на целом классе задач.
Кто-то, помнится, чуть выше писал что для 99% приложений это не нужно. К тому же, асинхронность не исключает параллезацию: в том же .NET все нужные инструменты для ее использования есть.
Переключение контекстов в виртуальной машине бесплатное.
Чего? Процессор-то у виртуальной машины остается все тем же физическим - точнее, под его предствление выделяются сколько-то физических ядер физического процессора(ов), которые гипервизор, к тому же, старается лишний раз не менять.
И как, по-вашему, предсказатель ветвлений в этом физическом ядре предскажет переход на код в другом контексте? И как в кэше нужного физического процессора окажутся данные, которые использует код в контексте, куда произошло переключение?
Учитесь основам. Это замедлит устаревание ваших знаний.
Во-1 это опасно.
Нас нанимают не-технари — люди, далекие от всех инженерных подходов сразу. И мы вынуждены играть по их правилам, иначе "работодатель не готов пригласить вас" ©.
Они оценивают нас по названиям технологий, не понимая что кроется за ними: банально сравнивая написанные в нашем резюме названия со списком, присланным тимлидами.
И хорошо если тимлид/сеньор проекта сформулировал требования, достаточные для порхождения кандидатом первичного фильтра в виде HR, а не просто перечислил названия популярных на сегодняшний день фреймворков.
Но оказалось сеньоры бывают разные...
Во-2 основы не интересны этим самым нанимающим людям.
Разумеется я не имею в виду инженеров, которым — несмотря на их опыт — до сих пор любопытно "а что будет если". Я имею в виду людей, для которых задача "написать аналог гугла" состоит из вывода на экран одного инпута и одной кнопки.
И когда эти люди будут нанимать вас на подобную задачу, они будут ожидать от вас перечисления все тех же названий фреймворков из п.1, с помощью которых вы будете выводить инпут и кнопку на экран. А отнюдь не рассказа о веб-краулерах и уровнях кэша на пути от сервера до клиента...
Нас нанимают не-технари — люди, далекие от всех инженерных подходов сразу. И мы вынуждены играть по их правилам, иначе "работодатель не готов пригласить вас" ©.
Это - рынок, и работодатели на нем бывают разные. Но, главное: потенция, чтоб не сваливать - она сохранается у тех, кто делает меньше ошибок. Так что оценка соискателей по "списку фреймворков" - она, если ведет к ошибкам, использоваться перестанет - как (вроде бы), перестала использоваться оценка по задачам "про люки".
Я имею в виду людей, для которых задача "написать аналог гугла" состоит из вывода на экран одного инпута и одной кнопки.
Конечно, никто из заказчиков/нанимателей не отказался бы от того, чтобы всё делалось по одной кнопке. Но по жизни, как известно, "по одной кнопке только вода из бачка сливается", а потому так сделать чаще всего не получается. Но будущее индустрии, я полагаю - именно за пользователями фреймворков. Которыми однако, я полагаю, будут роботы на основе LLM (или что ещё там придумают вместо).
Кароче, вывод: актальный набор инструментов изучить надо, но когда появятся ресурсы на изучение чего-то ещё, имеет смысл вложиться в общие принципы, чтобы облегчить себе изучение других инструментов. Но - только если изучение этих общих принципов действительно облегчит изучение новых инструментов.
А облегчит ли - это зависит от требуемой глубины изучения. И для типичного современного разработчика - оператора фреймворка, к примеру, знать общие принципы выглядит необязательным: для решения большнства задач достаточно изучить и использовать набор заклинаний для управления этим фрейворком. Но при этом кто-то всё-таки должен решать то меньшинство задач, для которых использования заклинаний без понимания того, что они делают, не хватает.
Найдется ли этот кто-то на конкретном предприятии - зависит от организации процесса разработки на нем. И в целом, по моим впечатлениям, индустрия разработки ПО до нужного уровня организации разделения труда ещё не доросла. Но, возможно, я ошибаюсь - в конце концов, я - не менеджер, профессионально организующий разработку ПО. А потому в дальнейших спорах на эту тему (буде они возникнут) я участвовать не буду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему вы никогда не выучите все фреймворки