Вот прям топ-топовые зарплаты (по крайней мере, при работе по найму) — они за вакансии, где нужны плюсы.
Возможно… И от этого еще больше адреналина )) Но это те деньги, которые видны сейчас, а если развиваться по той теме, которая нравится, то еще неизвестно, куда кривая вывезет (в плане плюс или минус по деньгам).
Во-первых, вы там сначала говорили про 10 000 часов — с чем я не согласен (там надо всего лишь 1 000 часов на новую технологию). Во-вторых, если ТС пишет, что ему на С++ писать становиться просто мучительно, то значит дельта по производительности уже ощущается (а значит и дельта по оплате будет, хоть и не в прямо-пропорциональной зависимости). В-третьих, нервы тоже стоят денег.
Один профит от перехода, кроме того, что придется годик пожить как средний работник на Западе (занимаясь при этом любимым делом).
Скорей всего, проблемы с С++ стали всего лишь катализатором накопившейся усталости от однообразия выполняемых заданий. Или круче того — подсознательно надоело быть разработчиком и пришла пора двигаться в: архитекторы, СТО, науку, создать свой форк С++, etc.
А жалеть о временном проседании з/п не стоит — потери могут быть гораздо бОльшими, если уже сейчас не начать что-то предпринимать.
Надеюсь, не слишком позанудствовал.
Старый и новый дизайн лично для меня по удобности и ясности ничем не отличаются. И там и там надо долго всматриваться и размышлять. Привет вашему социологу и аналитику ))
Нет нет, я не про Anemic Domain Model, где в базовом классе хранятся только голые данные, а условия их изменения и соответствующие методы вынесены во внешние классы. Для меня это тоже анти-паттерн.
Речь про то, чтобы объект хранил только данные и условия, проверяющие что и когда надо с ними делать. А все методы (по изменению этих данных) лучше выносить наружу в виде отдельных процедур.
(то есть в объекте остаются только if-ы, дергающие внешние функции)
Когда в ООП придумали принцип композиции данных и функций, то сделали очевидный первый шаг — объединили их в одном куске кода. Теперь, когда есть проблемы раздувания классов, очевидным шагом будет эти классы декомпозировать: высушенные «характерные» объекты вызывают нужные им методы. Это лучше для тестирования, применения ФП и т.д.
Это тоже будет ООП подход, но с облегченными классами/объектами. Ведь все равно главным актором остается объект, который вызывает нужные ему функции. Это как-бы следующий уровень развития ООП подхода: от универсальных и тяжелых классов/объектов — к объектам поведенченским. Вот здесь и ФП хорошо ляжет (на вызываемые функции).
Было бы хорошо, чтобы были ООП языки и без инкапсуляции. Чтобы объекты хранили в себе только: данные, условия для их изменения и вызовы внешних необходимых методов.
Да и где стейты критичны, тоже. Там как раз хорошо, стейт сразу видно, он везде явный, а не «вот если у этого объекта дёрнуть это, а потом у того то, то первый будет в нужном стейте, но при этом вот этот метод дёргать нельзя, а то всё сломается».
Согласен, нынешние дизайны ООЯП подталкивают к «макаронной» архитектуре.
JediPhilosopher Вот почему Гугл на Котлин подсел — вообще не пойму. Ведь они могли любой свой ЯП туда присобачить (да хоть новый с нуля разработать). Теория заговоров какая-то…
ФП хорошо работает там, где идут потоки информации, которые надо обрабатывать в реальном режиме времени, а стейты некритичны. Думаю, такие ниши есть.
А вот как «better java» (ответ на ваш нижний комментарий) — это вопрос интересный.
Если делать better_java для простых задач, то это не ниша Скалы (и там уже укрепился Котлин). А вот для сложных задач (чтобы их можно было делать легко и быстро) может и взлететь. Хотя здесь ее уже тоже подпирают не-jvm-ские Haskell и Rust. Но это по-любому означает необходимость кардинальной переработки Скалы, чтобы она перестала быть всем для всех.
Scala проигрывает по всем фронтам, и даже Хаскель уже хайповее. Очень жаль, ведь именно она понесла ФП в массы. Я думаю ей надо развиваться не во всех направлениях (как это предлагается в статье), а выбрать те ниши, где ФП подход однозначно выгоднее простого ООП и процедурного. Возможно, ей надо в новой версии сделать полностью асинхронное ядро (ну или какую-то другую киллер-фичу).
Один профит от перехода, кроме того, что придется годик пожить как средний работник на Западе (занимаясь при этом любимым делом).
А жалеть о временном проседании з/п не стоит — потери могут быть гораздо бОльшими, если уже сейчас не начать что-то предпринимать.
Надеюсь, не слишком позанудствовал.
Речь про то, чтобы объект хранил только данные и условия, проверяющие что и когда надо с ними делать. А все методы (по изменению этих данных) лучше выносить наружу в виде отдельных процедур.
(то есть в объекте остаются только if-ы, дергающие внешние функции)
Когда в ООП придумали принцип композиции данных и функций, то сделали очевидный первый шаг — объединили их в одном куске кода. Теперь, когда есть проблемы раздувания классов, очевидным шагом будет эти классы декомпозировать: высушенные «характерные» объекты вызывают нужные им методы. Это лучше для тестирования, применения ФП и т.д.
UPD
JediPhilosopher Вот почему Гугл на Котлин подсел — вообще не пойму. Ведь они могли любой свой ЯП туда присобачить (да хоть новый с нуля разработать). Теория заговоров какая-то…
А вот как «better java» (ответ на ваш нижний комментарий) — это вопрос интересный.
Если делать better_java для простых задач, то это не ниша Скалы (и там уже укрепился Котлин). А вот для сложных задач (чтобы их можно было делать легко и быстро) может и взлететь. Хотя здесь ее уже тоже подпирают не-jvm-ские Haskell и Rust. Но это по-любому означает необходимость кардинальной переработки Скалы, чтобы она перестала быть всем для всех.