Я бы выучил джаву. Взаимодействовать, скорее всего, придется. Ну там полазить в кишках библиотек и т.д. А идеоматически Котлин все дальше и дальше от Джавы в плане стиля кода. Я раньше иногда понять не мог на каком языке написан код - на джаве или котлине. Сейчас, если писать в стиле Котлин, как-то уже и совсем не Джава стиль получается.
Во-первых, В Java и Kotlin интерфейсы необязательны. В Kotlin даже классы необязательны (хотя в байткоде обернутся все же в классы функции и переменный объявленые вне классов). Поэтому метод с параметрами необязательно должен стыковаться с каким-то там интерфейсом. Даже если у класса, в котором объявлен метода с параметрами по умолчанию, есть интерфейс - ну и ладно. Я лично так делал и не страдал от нарушения идеологий. Да и не понимаю я, в чем нарушение? Интерфейс - это контракт на структуру и результат, а не на данные или способ подкапотного функционирования этой структуры. Данные как раз предполагаются быть разными в имплементациях, раз уж интерфейс объявлен.
Во-вторых, это плохо иметь 10 параметров в методе. И в Котлине для таких случаев тоже надо использовать билдеры, хоть самому писать, хоть с использованием тех же библиотек из Джавы
Да не то только null protection фишка котлина. Функциональное программирование в котлин в разы удобнее. Эти collection.stream()…..collect(…) в java просто ужас какой многословный по сравнению с collection.map{…} А если взять функции-расширения, перегрузка операторов, всякие делегаты с синглтонами, то и получается, что джаве еще далеко до удобства котлина. Сам пишу по работе на обоих языках примерно 50/50, не хейтю джаву, но такое вот субъективное мнение
На мой взгляд, мобильная разработка это, во-первых, и есть фулстек фронт+бек, пусть в рамках мобильных устройств. Во-вторых, сколько поменял проектов, но никогда не видел, чтобы мобильную разработку объединяли с большим фронтом или беком. Разные сочетания фулстеков видел. Фронт+бек, бек+девопс, фронт+дба. Но мобильную разработку не объединяли ни с кем.
Ну и кстати из фулстеков получаются архитекторы. Важно же не только выбрать БД, тип архитектуры и т.д. Надо еще и уметь подобрать стек. А для этого нужен опыт, понимание разработки и бека и фронта. Что выбрать - SSR или CSR? Реактивный стек бека или все таки нет
С одной стороны согласен, что в первую очередь, от кого зависит выстрел в ногу - это программист. Но язык тоже должен помогать не стрелять себе в ногу. На примере джавы могу сказать - джава это наследие С и С++ . Там взяли и многие скользкие моменты убрали из языка, например вольности с неявным преобразованием типов, один из самых частых источников проблем. Но в джаве, понятно, такой дизайн с самого начала, когда не надо было оглядываться на обратную совместимость. Но в JS, на мой взгляд, очень много неоднозначных моментов, которые как раз путают и разрешают отстрелить себе просто обе ноги. И эти моменты никак не уменьшаются, не исправляются. Хотя use strict ввели, но как-то мягко он работает. Вот и получается, что на проекте первый программист пишет в одном стиле, после него приходит другой и начинает писать/переписывать в другом стиле. И начинается ад и зоопарк. И это только про стиль написания код, я не говорю про рантаймы (просто знаний не хватает говорить про это).
В этом плане мне нравится дзен питона - явное лучше неявного. Вот как раз этого, мне кажется, языку JS не хватает. Не хватает единого стиля.
Хотя, если уж быть объективным, этим страдают многие языки. И даже мой любимый Котлин, который, наверное больше всех подвержен этому. В нем можно писать и в Котлин/Функциональном стиле, с втыканием лямбд везде где только можно, но также и в Джава/ООП стиле, без этих функциональных возможностей. Благо я, пришедший в Котлин из джавы, могу читать оба стиля написания. Но я представляю чувства программиста, у которого первый язык Котлин, и он будет читать код программиста, который пишет как в Джава. И наоборот. Мне лично тяжело было перестроиться, а тем более читать код в стиле Котлина, когда я только начал его изучать.
Замыкания я знаю, мой основной язык Котлин/Джава. Просто в этих языках замыкания как-то без изысков, и соответственно запомнить легко. В случае с JS приходится подглядывать в документацию. Цепочка вызовов лексических окружений, new Function и т.д. То же самое с this в разных контекстах.
Насколько я помню даже книга есть, название что-то типа "вы не знаете замыкания" и в ней речь идет про замыкания JS. Точно такая же есть и для async await, но там понятно, целая книга для нелегкого асинхронного программирования. Но для замыканий...
Я, как вечный новичок в Джаваскрипт (периодически приходится на нем писать, и заново подучивать/вспоминать) скажу, что замыкания одна из сложно запоминаемых вещей. Примерно на уровне конкатенации переменных разных типов в JS. Ну это мое такое вот джуновское мнение
Так и до айфона были телефоны с сенсорным экраном и без кнопок, но эпл из этого сделала культ. И удачно сделала
АРМ процессоры тоже вроде пихали в ноуты, Microsoft surface например (полупланшет полу ноутбук), но эпл сделала из этого культ (ладно, до культа еще далеко, но идея очень даже удачная)
То что делали до эпл, но не зашло, не значит что у эпла тоже не получится. Есть очень большие шансы что доработают и сделают так как надо
Я не боготворю эпл, эта та еще корпорация зла. Но вещи переосмысливать и представлять как новую крутую фичу они ой как умеют
А расскажите что за костыли? У меня айпад и ручка второй версии, с беспроводной зарядкой. Вроде нет проблем с ней. Или костыли - это про следующую версию с type-c зарядкой?
Вот честно, отдельные полосы для обгона не видел. На двухполосной только прерывистая разделительная линия и знаки. И мне на моем авто с 230лс иногда не хватает, хочется больше, хотя опыта езды в межгороде достаточно.
Вы, судя по всему, никогда между городами сами за рулем не ездили. На участке двухполосном, который можно проехать за 10 минут, ты будешь тащиться за фурой 2 часа если по встречке не проедешь. На таких дорогах обгон с выездом на встречную полосу разрешен, знаки об это информируют. И быстрый и резвый автомобиль дает огромные преимущества. Даже там, где обгон тебе разрешен (а встречным соответственно нет) всегда найдется какой-нибудь встречный баран, которому плевать на правила и знаки. Вот чтобы лишний раз не столкнуться с таким дятлом и нужен быстрый автомобиль. Объехал медленно движущее препятствие, встал на полосу и едешь дальше
Ой, да, помню в году, кажется, 2007 - фу, что это за хрень, телефон без кнопок, большой, несуразный какой-то. Его никто не купит
К слову, я сам не сильно понял, что там Эпл хочет хочет внедрить, но считаю что вот как раз Эпл является пионерским локомотивом на рынке. Там дизайнеры зря свой хлеб не едят
Попробовал я раз этот джитси. Вот прямо из коробки не завелся. Хотя видимость успешного запуска была. Создаю я конференцию - все ок, как только подключается второй участник - крашилось. Ковырялся, ковырялся, но заказчик в итоге нашел каких-то опытных ребят, которые починили это все. Впечатление - ну очень сырой продукт, статья тому подтверждение
Видимо недавно добавили. У меня толи 17, толи 19 версия джавы. Компиляция в 17 установлена
Какая площадь теплицы для 2х млн тюльпанов?
Я бы выучил джаву. Взаимодействовать, скорее всего, придется. Ну там полазить в кишках библиотек и т.д. А идеоматически Котлин все дальше и дальше от Джавы в плане стиля кода. Я раньше иногда понять не мог на каком языке написан код - на джаве или котлине. Сейчас, если писать в стиле Котлин, как-то уже и совсем не Джава стиль получается.
Как нет? У стримов есть zip метод
Streams.zip(Collection1, Collection2, лямбда).как_всегда_collect(...)
Во-первых, В Java и Kotlin интерфейсы необязательны. В Kotlin даже классы необязательны (хотя в байткоде обернутся все же в классы функции и переменный объявленые вне классов). Поэтому метод с параметрами необязательно должен стыковаться с каким-то там интерфейсом. Даже если у класса, в котором объявлен метода с параметрами по умолчанию, есть интерфейс - ну и ладно. Я лично так делал и не страдал от нарушения идеологий. Да и не понимаю я, в чем нарушение? Интерфейс - это контракт на структуру и результат, а не на данные или способ подкапотного функционирования этой структуры. Данные как раз предполагаются быть разными в имплементациях, раз уж интерфейс объявлен.
Во-вторых, это плохо иметь 10 параметров в методе. И в Котлине для таких случаев тоже надо использовать билдеры, хоть самому писать, хоть с использованием тех же библиотек из Джавы
Да не то только null protection фишка котлина. Функциональное программирование в котлин в разы удобнее. Эти collection.stream()…..collect(…) в java просто ужас какой многословный по сравнению с collection.map{…} А если взять функции-расширения, перегрузка операторов, всякие делегаты с синглтонами, то и получается, что джаве еще далеко до удобства котлина. Сам пишу по работе на обоих языках примерно 50/50, не хейтю джаву, но такое вот субъективное мнение
На мой взгляд, мобильная разработка это, во-первых, и есть фулстек фронт+бек, пусть в рамках мобильных устройств. Во-вторых, сколько поменял проектов, но никогда не видел, чтобы мобильную разработку объединяли с большим фронтом или беком. Разные сочетания фулстеков видел. Фронт+бек, бек+девопс, фронт+дба. Но мобильную разработку не объединяли ни с кем.
Ну и кстати из фулстеков получаются архитекторы. Важно же не только выбрать БД, тип архитектуры и т.д. Надо еще и уметь подобрать стек. А для этого нужен опыт, понимание разработки и бека и фронта. Что выбрать - SSR или CSR? Реактивный стек бека или все таки нет
А, понял, спасибо. У меня заголовки обрезало и чтобы увидеть, что такое пищевой принтер, надо было оказывается зайти внутрь товара.
Я уже было подумал что это какой-то 3D принтер, но печатает из мастики. Обрадовался, что такие технологии появились
А что такое пищевой принтер? У вас по ссылке какие-то обычные струйники для печати на бумаге.
С одной стороны согласен, что в первую очередь, от кого зависит выстрел в ногу - это программист. Но язык тоже должен помогать не стрелять себе в ногу. На примере джавы могу сказать - джава это наследие С и С++ . Там взяли и многие скользкие моменты убрали из языка, например вольности с неявным преобразованием типов, один из самых частых источников проблем. Но в джаве, понятно, такой дизайн с самого начала, когда не надо было оглядываться на обратную совместимость. Но в JS, на мой взгляд, очень много неоднозначных моментов, которые как раз путают и разрешают отстрелить себе просто обе ноги. И эти моменты никак не уменьшаются, не исправляются. Хотя use strict ввели, но как-то мягко он работает. Вот и получается, что на проекте первый программист пишет в одном стиле, после него приходит другой и начинает писать/переписывать в другом стиле. И начинается ад и зоопарк. И это только про стиль написания код, я не говорю про рантаймы (просто знаний не хватает говорить про это).
В этом плане мне нравится дзен питона - явное лучше неявного. Вот как раз этого, мне кажется, языку JS не хватает. Не хватает единого стиля.
Хотя, если уж быть объективным, этим страдают многие языки. И даже мой любимый Котлин, который, наверное больше всех подвержен этому. В нем можно писать и в Котлин/Функциональном стиле, с втыканием лямбд везде где только можно, но также и в Джава/ООП стиле, без этих функциональных возможностей. Благо я, пришедший в Котлин из джавы, могу читать оба стиля написания. Но я представляю чувства программиста, у которого первый язык Котлин, и он будет читать код программиста, который пишет как в Джава. И наоборот. Мне лично тяжело было перестроиться, а тем более читать код в стиле Котлина, когда я только начал его изучать.
Замыкания я знаю, мой основной язык Котлин/Джава. Просто в этих языках замыкания как-то без изысков, и соответственно запомнить легко. В случае с JS приходится подглядывать в документацию. Цепочка вызовов лексических окружений, new Function и т.д. То же самое с this в разных контекстах.
Насколько я помню даже книга есть, название что-то типа "вы не знаете замыкания" и в ней речь идет про замыкания JS. Точно такая же есть и для async await, но там понятно, целая книга для нелегкого асинхронного программирования. Но для замыканий...
Я, как вечный новичок в Джаваскрипт (периодически приходится на нем писать, и заново подучивать/вспоминать) скажу, что замыкания одна из сложно запоминаемых вещей. Примерно на уровне конкатенации переменных разных типов в JS. Ну это мое такое вот джуновское мнение
Так и до айфона были телефоны с сенсорным экраном и без кнопок, но эпл из этого сделала культ. И удачно сделала
АРМ процессоры тоже вроде пихали в ноуты, Microsoft surface например (полупланшет полу ноутбук), но эпл сделала из этого культ (ладно, до культа еще далеко, но идея очень даже удачная)
То что делали до эпл, но не зашло, не значит что у эпла тоже не получится. Есть очень большие шансы что доработают и сделают так как надо
Я не боготворю эпл, эта та еще корпорация зла. Но вещи переосмысливать и представлять как новую крутую фичу они ой как умеют
А расскажите что за костыли? У меня айпад и ручка второй версии, с беспроводной зарядкой. Вроде нет проблем с ней. Или костыли - это про следующую версию с type-c зарядкой?
Вот честно, отдельные полосы для обгона не видел. На двухполосной только прерывистая разделительная линия и знаки. И мне на моем авто с 230лс иногда не хватает, хочется больше, хотя опыта езды в межгороде достаточно.
Этим водителям фур отдельный котел в аду.
Вы, судя по всему, никогда между городами сами за рулем не ездили. На участке двухполосном, который можно проехать за 10 минут, ты будешь тащиться за фурой 2 часа если по встречке не проедешь. На таких дорогах обгон с выездом на встречную полосу разрешен, знаки об это информируют. И быстрый и резвый автомобиль дает огромные преимущества. Даже там, где обгон тебе разрешен (а встречным соответственно нет) всегда найдется какой-нибудь встречный баран, которому плевать на правила и знаки. Вот чтобы лишний раз не столкнуться с таким дятлом и нужен быстрый автомобиль. Объехал медленно движущее препятствие, встал на полосу и едешь дальше
Ой, да, помню в году, кажется, 2007 - фу, что это за хрень, телефон без кнопок, большой, несуразный какой-то. Его никто не купит
К слову, я сам не сильно понял, что там Эпл хочет хочет внедрить, но считаю что вот как раз Эпл является пионерским локомотивом на рынке. Там дизайнеры зря свой хлеб не едят
Попробовал я раз этот джитси. Вот прямо из коробки не завелся. Хотя видимость успешного запуска была. Создаю я конференцию - все ок, как только подключается второй участник - крашилось. Ковырялся, ковырялся, но заказчик в итоге нашел каких-то опытных ребят, которые починили это все. Впечатление - ну очень сырой продукт, статья тому подтверждение
Вот прям стало интересно, что это за программа за 3К и которую с 2006 еще не сломали? Какой-то уж очень специфичный софт?