Откуда взяться таким цифрам, если ML-ассистенты - это всего лишь ассистенты. Они и джуна то заменить не в состоянии.
А чуть что не совсем тривиальное, так от них толку как от козла молока. Вчера только эксперимент ставил. Просил GPT-4o написать docker-compose.yml для запуска Kafka в SASL режиме. То, что он с первого раза просто нерабочий конфиг выдал можно даже не говорить. Но он и за 10 раундов уточнений так и не справился.
Нет, ни несуществующий ИИ, ни даже ML к текущей волне сокращений ни малейшего отношения не имеют. Всё дело в том, что подавляющее большинство IT-компаний развиваются на кредитные деньги, которые надолго стали очень дорогими.
Надо понимать, что для компании сокращение 25-30% разработчиков - это по сути переход на режим выживания. Как только ключевую ставку понизят хотя бы до 12-14%, начнётся найм как не в себя.
А сеньор - тот кто может сделать проект полностью.
Это какие-то воспоминания из романтики нулевых. Где вы сейчас видели проекты, которые кто-то в одиночку пилит? Да и о какого рода проектах идёт речь? У меня просто сейчас вокруг примеры проектов, где минимум по 100 программистов, а то и 200-300.
Однако, безотносительно проектов есть теория 10 тысяч часов, которые нужно уделить осознанной практике, чтобы выйти на мировой уровень компетенции в любом навыке. Я подразумеваю, что если человек работает вдумчиво, а не на автомате, то в районе 1000 часов в год такой практики у него набирается. Итого, 3 года обучения + 7 лет карьеры - это самый пик квалификации по хардам, выше уже не будет. Дальше просто старые нефундаментальные знания частично замещаются новыми.
При том, что в этом же документе прямым текстом написано:
I should stress that the RMM, while a good way to think about what the elements of REST, is not a definition of levels of REST itself. Roy Fielding has made it clear that level 3 RMM is a pre-condition of REST.
Вам лишь бы докопаться, право слово. Как говорится, кто хочет, тот ищет возможности, кто не хочет — ищет причины для оправданий.
Я лично в прошлом году нанимал людей без коммерческого опыта на Elixir. И не надо мне рассказывать, что я один такой на всю Россию. Или 2024-й уже тоже слишком в прошлом?
Я же написал, что я сам занимаюсь наймом программистов. Работает, и не такие уж редкие кейсы.
А что мне должно доказать жалобное сообщение от некого Антона Могилёва - я не понял. Самое смешное, что в моей карьере был эпизод, когда я с PHP на C# переходил. Вообще без проблем. Потом правда с C# ушёл на Ruby. А с Ruby уже перешёл на Elixir. И всё исключительно по своему желанию и тяге к прекрасному.
Всё ведь от подхода зависит. Можно тупо завести аккаунт на HH написать, что ты C# программист, а весь опыт на PHP. Конечно, так не сработает. Подходите на конференциях или пишите в TG напрямую нанимающим менеджерам, которые выступают на конференциях, и всё получится. А если уровень пока не сеньорный, то тут через стажировки и OSS надо заходить.
Насчет распространенности я не знаю как это оценить. Я вот не видел ни одного продукта, написанного с их использованием за 25 лет в индустрии
Так это эффект информационного пузыря в чистом виде. Я точно так же могу сказать, что за 20 лет карьеры не видел ни одного продукта написанного на Python или Java. Зато видел десятки на Ruby, включая проекты мирового уровня. Но я хотя бы не делаю из этого глупых выводов, что на Python и Java пишут одни фрики xD
В общем, если вы чего-то не видели, это не значит, что этого нет. Это значит исключительно то, что ваш фокус внимания был направлен в другую сторону.
И что тут скажет кандидат, решивший сыграть на диспропорциях чисел вакансий и дохода? Что он тут чисто ради hard cold cash?
Ну, я предполагаю, что у кандидата достаточно компетенций, чтобы провести сравнительный анализ нескольких ЯП и выделить плюсы и минусы каждого именно в техническом плане. Для такого кандидата будет несложно ответить на вопрос чем его заинтересовал какой-то конкретный язык.
Вопрос вероятностей. На менее хайповом стеке гораздо выше вероятность, что вас возьмут без опыта, чем на хайповом.
К тому же, если у вас есть релевантный опыт, не связанный с конкретным языком, это будет весомым плюсом. Условно говоря, если вакансия на backend и вы хорошо знаете Postgres, Kafka, имеете опыт с разными вариантами API, понимаете в system design, то уже не так уж и важно какой у вас коммерческий опыт в конкретном языке. Пару книг про новый ЯП прочитали, с примерами поэкспериментировали, ключевые отличия от других ЯП поняли - берём.
Так вы бы прочитали ответ на его комментарий, прежде чем писать свой.
Я предлагаю достаточно распространенные ЯП, чтобы вообще не париться по вопросу поиска работы. Ещё раз подчеркну, что найти по ним хорошую работу проще, чем по хайповым.
А экзотика - это Idris, Pharo Smalltalk, OCaml, Common Lisp, Racket. Их да, если только для общего развития стоит изучать.
будучи совсем не мальчиком начинать всё сначала
Вы тут палитесь. Если для вас новый ЯП == начинать всё сначала, значит у вас нет нормального багажа знаний. Потому что ЯП (включая фреймворки и либы) - это от силы 10% от всех компетенций. И другие 90% шарятся, если вы не меняете направление. Условно, если вы 10 лет разрабатывали backend, то при смене языка вы по зарплате в худшем случае на 10% просядете и то максимум на год.
Так я ничего экзотического или устаревшего не назвал. Это распространенные стеки, просто не заезженные, и желающие войти-в-айти по-быстрому о них не в курсе.
Kotlin для бекенда и Scala для дата-слоя к этой же истории относятся. На C# тоже ситуация получше, чем в Java. Вот вам уже 5 вариантов.
привел пример вообще без switch / case, на обобщениях
Не хочу вас расстраивать, но обобщенное программирование - это тоже отдельная парадигма :-)
И вы еще и ошибаетесь что switch / case не расширяем - оборачиваешь функцию другой, добавляешь новый тип, предоставляешь библиотеке новую функцию (разумеется автор предусмотрел если делал ее расширяемой).
Автор библиотеки должен предусмотреть, что надо использовать не библиотечную функцию, а вашу? Прям даже интересно, сможете ли вы найти хоть одну реальную либу с таким "расширяемым" switch / case.
Ну, т.е. сделать то в таком стиле можно, но там switch / case вообще не нужен. Просто сигнатуру лямбды фиксируешь и даёшь возможность её в настройках либы указать. Но это несколько другая история.
Отлично, может когда нибудь на Elixir начну писать, но пока на нем нет возможности делать мобилки / веб приложения и многое другое.
Если вас исключительно фронт и мобилки интересует, то ваш выбор: ReScript, есть и под React, и под React Native, и под много что ещё биндинги. Почитайте сравнение с TypeScript в идеалогическом плане.
Больше. С другой стороны, зачем быть леммингом и вестись на массовые стеки? Вам мало языков программирования что-ли? Например, на Ruby и Elixir гораздо меньше конкуренция за вакансии. Я часто на эти стеки людей нанимал за предыдущие 10 лет.
Ладно бы ещё эти ваши популярные JS, Python, PHP ценились как-то высоко, но они ж наоборот ушли на дно под натиском 1000 резюме на 1 вакансию.
это медианы вне зависимости от квалификации, но тенденция понятна
Вот мне все интересно, пять лет опыта - это уже считается "суперопытным"?
Под словосочетанием "суперопытный мидл" имелось в виду, что человек суперопытный на задачах мидла.
Ну, сами подумайте, если человек 2-3 года учил теорию и писал что-то для себя, потом ещё 5 лет работал на реальных проектах, и за это время не достиг уровня middle+/senior-, то, кажется, такому человеку пора бы задуматься о смене профессии.
к более-менее профессиональному, где человек уже что-то может сам
Да, всё так. Вас тянет к ФП, но вы не решаетесь попробовать функциональный язык, а довольствуетесь отдельными элементами. Например, вы не хотите использовать полиморфизм в стиле ООП, который в TypeScript является основным вариантом полиморфизма, и довольствуетесь switch/case.
Когда вам справедливо указывают, что такой вариант не расширяем (если вы пользуетесь какой-то либой, а её разработчик не предусмотрел case под ваш случай), вы просто обижаетесь и пытаетесь что-то доказывать.
В TypeScript ничего подобного нет и не будет, потому что его основная парадигма - ООП. Вы не в силах это изменить, но яростно гребёте против течения. Вместо того, чтобы выбрать подходящий ЯП себе по вкусу.
Чем же вы тогда лучше так ненавистных вам программистов на Java и C#? Да по сути ничем, вы так же как и они продолжаете пользоваться ОО-языками с элементами ФП.
Никак. В этом и суть парадигмы, что это максимально чистый набор идей без малейших примесей от других парадигм.
Языки, в которых есть элементы разных парадигм, называются мультипарадигмальными. Зайдите на ту же вики и почитайте элементы каких парадигм есть в TypeScript. Там их штук 7 где-то, а вы пытаетесь всё упростить, где не надо.
У вас память как у рыбки. Я ж вам в другой ветке уже писал, что ваш код с элементами ФП. Но отдельных элементов ФП мало, чтобы признать язык функциональным.
А в этой ветке мы обсуждаем определения, а не код. Перечитайте её сначала.
Я добавил определение процедурного стиля, и оно совсем отличается от моего Фп. Что в нем не так?
ПП - это не стиль ФП, это совсем разные парадигмы. Так что в ваших определениях всё не так. Почитайте хотя бы Википедию, если книги по Computer Science осилить не можете. И не выдумывайте собственных определений. Берите готовые и давайте ссылку на источник определения.
В примерах я возвращаю из функций новые функции с замыканием - это ПП?
Это элементы ФП, но отдельных элементов ФП недостаточно, чтобы назвать язык функциональным. Должен присутствовать полный комплект.
Откуда взяться таким цифрам, если ML-ассистенты - это всего лишь ассистенты. Они и джуна то заменить не в состоянии.
А чуть что не совсем тривиальное, так от них толку как от козла молока. Вчера только эксперимент ставил. Просил GPT-4o написать docker-compose.yml для запуска Kafka в SASL режиме. То, что он с первого раза просто нерабочий конфиг выдал можно даже не говорить. Но он и за 10 раундов уточнений так и не справился.
Нет, ни несуществующий ИИ, ни даже ML к текущей волне сокращений ни малейшего отношения не имеют. Всё дело в том, что подавляющее большинство IT-компаний развиваются на кредитные деньги, которые надолго стали очень дорогими.
Надо понимать, что для компании сокращение 25-30% разработчиков - это по сути переход на режим выживания. Как только ключевую ставку понизят хотя бы до 12-14%, начнётся найм как не в себя.
Это какие-то воспоминания из романтики нулевых. Где вы сейчас видели проекты, которые кто-то в одиночку пилит? Да и о какого рода проектах идёт речь? У меня просто сейчас вокруг примеры проектов, где минимум по 100 программистов, а то и 200-300.
Однако, безотносительно проектов есть теория 10 тысяч часов, которые нужно уделить осознанной практике, чтобы выйти на мировой уровень компетенции в любом навыке. Я подразумеваю, что если человек работает вдумчиво, а не на автомате, то в районе 1000 часов в год такой практики у него набирается. Итого, 3 года обучения + 7 лет карьеры - это самый пик квалификации по хардам, выше уже не будет. Дальше просто старые нефундаментальные знания частично замещаются новыми.
Да, встречал такое, что любые вызовы по HTTP называли REST API.
Самое смешное, что я встречал, когда говорили "у нас REST level 1", ссылаясь на https://martinfowler.com/articles/richardsonMaturityModel.html
При том, что в этом же документе прямым текстом написано:
Вам лишь бы докопаться, право слово. Как говорится, кто хочет, тот ищет возможности, кто не хочет — ищет причины для оправданий.
Я лично в прошлом году нанимал людей без коммерческого опыта на Elixir. И не надо мне рассказывать, что я один такой на всю Россию. Или 2024-й уже тоже слишком в прошлом?
Я же написал, что я сам занимаюсь наймом программистов. Работает, и не такие уж редкие кейсы.
А что мне должно доказать жалобное сообщение от некого Антона Могилёва - я не понял. Самое смешное, что в моей карьере был эпизод, когда я с PHP на C# переходил. Вообще без проблем. Потом правда с C# ушёл на Ruby. А с Ruby уже перешёл на Elixir. И всё исключительно по своему желанию и тяге к прекрасному.
Всё ведь от подхода зависит. Можно тупо завести аккаунт на HH написать, что ты C# программист, а весь опыт на PHP. Конечно, так не сработает. Подходите на конференциях или пишите в TG напрямую нанимающим менеджерам, которые выступают на конференциях, и всё получится. А если уровень пока не сеньорный, то тут через стажировки и OSS надо заходить.
Так это эффект информационного пузыря в чистом виде. Я точно так же могу сказать, что за 20 лет карьеры не видел ни одного продукта написанного на Python или Java. Зато видел десятки на Ruby, включая проекты мирового уровня. Но я хотя бы не делаю из этого глупых выводов, что на Python и Java пишут одни фрики xD
В общем, если вы чего-то не видели, это не значит, что этого нет. Это значит исключительно то, что ваш фокус внимания был направлен в другую сторону.
Ну, я предполагаю, что у кандидата достаточно компетенций, чтобы провести сравнительный анализ нескольких ЯП и выделить плюсы и минусы каждого именно в техническом плане. Для такого кандидата будет несложно ответить на вопрос чем его заинтересовал какой-то конкретный язык.
Вопрос вероятностей. На менее хайповом стеке гораздо выше вероятность, что вас возьмут без опыта, чем на хайповом.
К тому же, если у вас есть релевантный опыт, не связанный с конкретным языком, это будет весомым плюсом. Условно говоря, если вакансия на backend и вы хорошо знаете Postgres, Kafka, имеете опыт с разными вариантами API, понимаете в system design, то уже не так уж и важно какой у вас коммерческий опыт в конкретном языке. Пару книг про новый ЯП прочитали, с примерами поэкспериментировали, ключевые отличия от других ЯП поняли - берём.
Так вы бы прочитали ответ на его комментарий, прежде чем писать свой.
Я предлагаю достаточно распространенные ЯП, чтобы вообще не париться по вопросу поиска работы. Ещё раз подчеркну, что найти по ним хорошую работу проще, чем по хайповым.
А экзотика - это Idris, Pharo Smalltalk, OCaml, Common Lisp, Racket. Их да, если только для общего развития стоит изучать.
Вы тут палитесь. Если для вас новый ЯП == начинать всё сначала, значит у вас нет нормального багажа знаний. Потому что ЯП (включая фреймворки и либы) - это от силы 10% от всех компетенций. И другие 90% шарятся, если вы не меняете направление. Условно, если вы 10 лет разрабатывали backend, то при смене языка вы по зарплате в худшем случае на 10% просядете и то максимум на год.
Так я ничего экзотического или устаревшего не назвал. Это распространенные стеки, просто не заезженные, и желающие войти-в-айти по-быстрому о них не в курсе.
Kotlin для бекенда и Scala для дата-слоя к этой же истории относятся. На C# тоже ситуация получше, чем в Java. Вот вам уже 5 вариантов.
Не хочу вас расстраивать, но обобщенное программирование - это тоже отдельная парадигма :-)
Автор библиотеки должен предусмотреть, что надо использовать не библиотечную функцию, а вашу? Прям даже интересно, сможете ли вы найти хоть одну реальную либу с таким "расширяемым" switch / case.
Ну, т.е. сделать то в таком стиле можно, но там switch / case вообще не нужен. Просто сигнатуру лямбды фиксируешь и даёшь возможность её в настройках либы указать. Но это несколько другая история.
Если вас исключительно фронт и мобилки интересует, то ваш выбор: ReScript, есть и под React, и под React Native, и под много что ещё биндинги. Почитайте сравнение с TypeScript в идеалогическом плане.
А бек, IoT, ML и интерактивчики - лучше на Elixir
В общем, слезайте уже с объектно-ориентированных Go и TypeScript. А то весь ваш посыл выглядит неконгруентно, как "пчёлы против мёда".
Больше. С другой стороны, зачем быть леммингом и вестись на массовые стеки? Вам мало языков программирования что-ли? Например, на Ruby и Elixir гораздо меньше конкуренция за вакансии. Я часто на эти стеки людей нанимал за предыдущие 10 лет.
Ладно бы ещё эти ваши популярные JS, Python, PHP ценились как-то высоко, но они ж наоборот ушли на дно под натиском 1000 резюме на 1 вакансию.
Под словосочетанием "суперопытный мидл" имелось в виду, что человек суперопытный на задачах мидла.
Ну, сами подумайте, если человек 2-3 года учил теорию и писал что-то для себя, потом ещё 5 лет работал на реальных проектах, и за это время не достиг уровня middle+/senior-, то, кажется, такому человеку пора бы задуматься о смене профессии.
т.е. к сеньорному, если одним словом)
Вы просто не в курсе. Дело давно было, для SQL в 1974 году, например. Когда, он ещё назывался SEQUEL
А про FORTRAN для физиков так ещё раньше - в 1950-х
Да, всё так. Вас тянет к ФП, но вы не решаетесь попробовать функциональный язык, а довольствуетесь отдельными элементами. Например, вы не хотите использовать полиморфизм в стиле ООП, который в TypeScript является основным вариантом полиморфизма, и довольствуетесь switch/case.
Когда вам справедливо указывают, что такой вариант не расширяем (если вы пользуетесь какой-то либой, а её разработчик не предусмотрел case под ваш случай), вы просто обижаетесь и пытаетесь что-то доказывать.
В функциональных языках просто есть нормальные решения для полиморфизма на этот случай. Например, протоколы в Elixir: https://hexdocs.pm/elixir/protocols.html
В TypeScript ничего подобного нет и не будет, потому что его основная парадигма - ООП. Вы не в силах это изменить, но яростно гребёте против течения. Вместо того, чтобы выбрать подходящий ЯП себе по вкусу.
Чем же вы тогда лучше так ненавистных вам программистов на Java и C#? Да по сути ничем, вы так же как и они продолжаете пользоваться ОО-языками с элементами ФП.
Спасибо, интересно. По многословности кода понятно, что всё-таки работа с массивами - это edge-кейс для этих языков.
В каком-нибудь Ruby это делается сильно проще:
Никак. В этом и суть парадигмы, что это максимально чистый набор идей без малейших примесей от других парадигм.
Языки, в которых есть элементы разных парадигм, называются мультипарадигмальными. Зайдите на ту же вики и почитайте элементы каких парадигм есть в TypeScript. Там их штук 7 где-то, а вы пытаетесь всё упростить, где не надо.
У вас память как у рыбки. Я ж вам в другой ветке уже писал, что ваш код с элементами ФП. Но отдельных элементов ФП мало, чтобы признать язык функциональным.
А в этой ветке мы обсуждаем определения, а не код. Перечитайте её сначала.
ПП - это не стиль ФП, это совсем разные парадигмы. Так что в ваших определениях всё не так. Почитайте хотя бы Википедию, если книги по Computer Science осилить не можете. И не выдумывайте собственных определений. Берите готовые и давайте ссылку на источник определения.
Это элементы ФП, но отдельных элементов ФП недостаточно, чтобы назвать язык функциональным. Должен присутствовать полный комплект.
Вы эти грибы больше не ешьте, а то галлюционируете похлеще самой убогой нейросетки xD
Процедурный стиль к ФП вообще никакого отношения не имеет.