А меня вот как-раз бесит попытки перевода проф. терминов на великий и могучий. Ощущение, что разговариваешь со школьником, который не нашел ничего лучшего, чем засунуть документацию в гугл-транслэйт и так и учился.
Ну и да, пункт про скрам позабавил. Дальше серьезно относиться к статье не смог.
Вы меня немного не поняли. Я только сказал, что существуют люди, кому интереснее поддержка legacy кода. И из таких людей даже команды собираются. То, что вы в таких не работали говорит только о том, что у вас другой взгляд и другие приоритеты.
И ваше утверждение про
команда, застрявшая на старых технологиях, начинает терять мотивацию.
верно не везде и всегда, а только в конкретных случаях для конкретных команд.
Это не функциональный стиль программирования, это стремление создать запутанную конструкцию там, где она не нужна) Вопрос в понимании что такое ФП, а не в языке)
Есть в ваших словах доля истины, но есть и то с чем не согласен.
Для начала, про востребованность. Кто лучше, кандидат, который знает вдоль и поперек UI движок платформы и владеет только одним языком или тот, кто знает пять языков программирования но поверхностно? К сожалению рынок труда у нас построен так, что хотят видеть тех, кого могут проверить, а проверить базовые знания по языкам проще, чем глубокие по архитектуре или фундаментальные по программированию. Да и в 90% случаев не нужны эти глубокие знания. Вот и получается, что второй кандидат востребованнее, вот только технологии создают и развивают люди с глубокими и фундаментальными знаниями.
Писать на Котлине это не "выход из зоны комфорта", это переход на более совершенную модель того же инструмента. Развитие происходит от смены парадигмы мышления и паттернов проектирования. Писать объектный код можно и на C и на многих языках, просто это не так удобно. То же касается и функционального кода. Его никто не мешает писать и на Java 7 и на Java 6. Просто это не так удобно. А говорить "я не могу писать функциональный код, по тому что я пишу на Java" — это уход от ответственности. По тому, что в данной фразе виноват не я, а обстоятельства.
Не соглашусь с тем, что "применить на практике" = "выбрать работу, где его используют". Можно писать библиотеки для open source, можно делать интересные утилиты и выкладывать их в GP. Можно брать на аутсорсинг проекты и там применять. Возможностей много если стоит острое желание попробовать. Я довел два проекта до релиза полностью написав их на Котлине и ни один из них не был привязан к моей постоянной работе. Так что не согласен.
Сам недавно сталкивался с Котлином, и, на мой взгляд, самой главной фичей этого языка можно назвать возможность применять функциональный стиль программирования без приплясыванием с лямбдами или адом анонимных классов. Вообще данный язык бессмысленен если писать "как привык", но когда мозг перестраивается на реактивный и/или компонентный подход в проектировании приложений, то тогда весь "сахар" языка становится необходимостью, без которой читаемость кода будет на нуле.
Ну и не понимаю я людей, которые идут работать "по тому, что тут пишут на новомодном языке"
А меня вот как-раз бесит попытки перевода проф. терминов на великий и могучий. Ощущение, что разговариваешь со школьником, который не нашел ничего лучшего, чем засунуть документацию в гугл-транслэйт и так и учился.
Ну и да, пункт про скрам позабавил. Дальше серьезно относиться к статье не смог.
И ваше утверждение про
верно не везде и всегда, а только в конкретных случаях для конкретных команд.
Я вас удивлю, но есть команды с обратным эффектом. Вы явно фанат новых технологий, но поверьте, не все люди такие)
Это не функциональный стиль программирования, это стремление создать запутанную конструкцию там, где она не нужна) Вопрос в понимании что такое ФП, а не в языке)
Есть в ваших словах доля истины, но есть и то с чем не согласен.
Для начала, про востребованность. Кто лучше, кандидат, который знает вдоль и поперек UI движок платформы и владеет только одним языком или тот, кто знает пять языков программирования но поверхностно? К сожалению рынок труда у нас построен так, что хотят видеть тех, кого могут проверить, а проверить базовые знания по языкам проще, чем глубокие по архитектуре или фундаментальные по программированию. Да и в 90% случаев не нужны эти глубокие знания. Вот и получается, что второй кандидат востребованнее, вот только технологии создают и развивают люди с глубокими и фундаментальными знаниями.
Писать на Котлине это не "выход из зоны комфорта", это переход на более совершенную модель того же инструмента. Развитие происходит от смены парадигмы мышления и паттернов проектирования. Писать объектный код можно и на C и на многих языках, просто это не так удобно. То же касается и функционального кода. Его никто не мешает писать и на Java 7 и на Java 6. Просто это не так удобно. А говорить "я не могу писать функциональный код, по тому что я пишу на Java" — это уход от ответственности. По тому, что в данной фразе виноват не я, а обстоятельства.
Не соглашусь с тем, что "применить на практике" = "выбрать работу, где его используют". Можно писать библиотеки для open source, можно делать интересные утилиты и выкладывать их в GP. Можно брать на аутсорсинг проекты и там применять. Возможностей много если стоит острое желание попробовать. Я довел два проекта до релиза полностью написав их на Котлине и ни один из них не был привязан к моей постоянной работе. Так что не согласен.
Сам недавно сталкивался с Котлином, и, на мой взгляд, самой главной фичей этого языка можно назвать возможность применять функциональный стиль программирования без приплясыванием с лямбдами или адом анонимных классов. Вообще данный язык бессмысленен если писать "как привык", но когда мозг перестраивается на реактивный и/или компонентный подход в проектировании приложений, то тогда весь "сахар" языка становится необходимостью, без которой читаемость кода будет на нуле.
Ну и не понимаю я людей, которые идут работать "по тому, что тут пишут на новомодном языке"