Этого треда уже нет.
Это копия, сохраненная 27 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 27 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
>>263833
звучит странно
звучит странно
>>263822 (OP)
игрушка от авторов платных плагинов для IDE на java. относительно взлетел только из-за встроенного оного в эту IDE, которая же android studio
игрушка от авторов платных плагинов для IDE на java. относительно взлетел только из-за встроенного оного в эту IDE, которая же android studio
>>264005
Они вообще что-то годное пилят там или тупо транспайлер в LLVM и ЖС делают и все? причем в последнее, я слышал, что через dart-тулзу пилят??
Они вообще что-то годное пилят там или тупо транспайлер в LLVM и ЖС делают и все? причем в последнее, я слышал, что через dart-тулзу пилят??
>>263991
Синтаксис как-то сильно похож на джава-фикс. Причем не самый удачный.
val mutableList = mutableListOf<Some>()
было трудно сделать так?
let list = <Some>[]
let list = ["Текст1", "Текст2"] // <String>[]
И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется. Тоже же вопрос с мапами.
Если нужно где-то что-то по быстрому передать - дайте кортежи людям, не уродуйте словами "mutable".
Синтаксис как-то сильно похож на джава-фикс. Причем не самый удачный.
val mutableList = mutableListOf<Some>()
было трудно сделать так?
let list = <Some>[]
let list = ["Текст1", "Текст2"] // <String>[]
И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется. Тоже же вопрос с мапами.
Если нужно где-то что-то по быстрому передать - дайте кортежи людям, не уродуйте словами "mutable".
>>264023
Говоришь как будто этого мало, раст тоже например в ллвм компилируется. Да и к тому же не нужно будет иметь 150 мб жава рантайма чтобы запустить программу.
Говоришь как будто этого мало, раст тоже например в ллвм компилируется. Да и к тому же не нужно будет иметь 150 мб жава рантайма чтобы запустить программу.
>>264025
Мутейбл изменяется. Я так понял это килер фича для с++ кодеров, потому что там каждая первая функция принимает const и всех это заебало писать
> И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется
Мутейбл изменяется. Я так понял это килер фича для с++ кодеров, потому что там каждая первая функция принимает const и всех это заебало писать
>>264167
Ты не уловил мысль. У раста, как бы, есть свои батарейки, то есть он не тупо транспайлер с тонкой стандартной либой (типа вот вам сделали, дальше сами пилите, за любовь)
Ты не уловил мысль. У раста, как бы, есть свои батарейки, то есть он не тупо транспайлер с тонкой стандартной либой (типа вот вам сделали, дальше сами пилите, за любовь)
>>264025
В большинстве случаев нужен список, из которого элементы только читаются, а сам список не меняется.
Mutable-списки нужны иногда и в ограниченном скоупе.
>И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется.
В большинстве случаев нужен список, из которого элементы только читаются, а сам список не меняется.
Mutable-списки нужны иногда и в ограниченном скоупе.
>>265325
Сразу видно настоящих программистов. Но к сожалению, в большинстве своем список (List) нужен чтобы условно-неограниченно и динамично хранить какие-то данные. А вот для ограниченной последовательности подошел бы как раз классический джавовый/сишный массив.
То есть - List вообще не задумывался для того чего от него сейчас хотят. Это бл..дская коллекция, а не встроенный тип данных, от которого еще можно было требовать иммутабельность.
Я вообще не понимаю, каким гуманитарным-инженером надо быть, чтобы коллекции делать иммутабельными.
>В большинстве случаев нужен список, из которого элементы только читаются,
Сразу видно настоящих программистов. Но к сожалению, в большинстве своем список (List) нужен чтобы условно-неограниченно и динамично хранить какие-то данные. А вот для ограниченной последовательности подошел бы как раз классический джавовый/сишный массив.
То есть - List вообще не задумывался для того чего от него сейчас хотят. Это бл..дская коллекция, а не встроенный тип данных, от которого еще можно было требовать иммутабельность.
Я вообще не понимаю, каким гуманитарным-инженером надо быть, чтобы коллекции делать иммутабельными.
Интересный комментарий
>>1269774
>>1269774
>>265353
Его делают иммутабельным, чтобы безопасно использовать в качестве shared memory в многопоточной программе без использования синхронизации (мьютексов). И внутри этот список не совсем список в классическом виде, а другая похожая структура.
Его делают иммутабельным, чтобы безопасно использовать в качестве shared memory в многопоточной программе без использования синхронизации (мьютексов). И внутри этот список не совсем список в классическом виде, а другая похожая структура.
>>270876
Лол, конечно, ведь проблемы многопоточности это как раз та область в которой должны решать проблемы именно коллекции.
Проблема в том, что коллекция перестает быть коллекцией (резиновым контейнером), если она становится иммутабельной. И на самом деле, в жабе есть уже потокобезопасные коллекции (мутабельные).
...когда-то в истории, еще в эпоху С++:
чувак, у нас есть массив, которые удачно расположен в памяти, но он статичен, его неудобно использовать с динамичными данными.
@
хорошо, мы возьмем мощь ООП и сделаем резиновые "массивы" - контейнеры/коллекции!
@
Десятый год 21 века: Я гуманитарный инженер нового поколения, я вижу что коллекции не потокобезопасны!
@
А давайте, сделаем конкурентные многопоточные коллекции???
@
Неее, слишком просто и не модно, давай-те сделаем коллекция вновь статичными! И вообще только для чтения!
Лол, конечно, ведь проблемы многопоточности это как раз та область в которой должны решать проблемы именно коллекции.
Проблема в том, что коллекция перестает быть коллекцией (резиновым контейнером), если она становится иммутабельной. И на самом деле, в жабе есть уже потокобезопасные коллекции (мутабельные).
...когда-то в истории, еще в эпоху С++:
чувак, у нас есть массив, которые удачно расположен в памяти, но он статичен, его неудобно использовать с динамичными данными.
@
хорошо, мы возьмем мощь ООП и сделаем резиновые "массивы" - контейнеры/коллекции!
@
Десятый год 21 века: Я гуманитарный инженер нового поколения, я вижу что коллекции не потокобезопасны!
@
А давайте, сделаем конкурентные многопоточные коллекции???
@
Неее, слишком просто и не модно, давай-те сделаем коллекция вновь статичными! И вообще только для чтения!
>>265353
Это ты за всех решил, что по назначению, а что нет?
>То есть - List вообще не задумывался для того чего от него сейчас хотят
Это ты за всех решил, что по назначению, а что нет?
>>264025
Так же часто, насколько часто ты пишешь чистые функции, которые легко тестируются и которые не нужно синхронизировать.
Опять же, в иммутабельных коллекциях спокойно хранятся динамическое кол-во элементов, если они персистентные
>как часто ты тебе нужен список, который не изменяется
Так же часто, насколько часто ты пишешь чистые функции, которые легко тестируются и которые не нужно синхронизировать.
>(List) нужен чтобы условно-неограниченно и динамично хранить какие-то данные
Опять же, в иммутабельных коллекциях спокойно хранятся динамическое кол-во элементов, если они персистентные
>>271198
Про размер только и говорили.
А вообще, какой смысл от статичных элементов массива (точнее статичных ссылок в этих элементах) если не факт, что внутри объект потокобезопасный? Квази решения на одном уровне, ну круто че, за то похерили "динамичность" и вообще саму идею коллекций.
Про размер только и говорили.
А вообще, какой смысл от статичных элементов массива (точнее статичных ссылок в этих элементах) если не факт, что внутри объект потокобезопасный? Квази решения на одном уровне, ну круто че, за то похерили "динамичность" и вообще саму идею коллекций.
>>271194
Нет, потому что изначально list-контейнер и создавался для динамического размера. Ну то есть, там буквально статический массив пересоздается по мере увеличения (обалдеть, да?)
Видишь и ты тоже не знал, не хочешь тоже свой язык написать?
>Это ты за всех решил, что по назначению, а что нет?
Нет, потому что изначально list-контейнер и создавался для динамического размера. Ну то есть, там буквально статический массив пересоздается по мере увеличения (обалдеть, да?)
Видишь и ты тоже не знал, не хочешь тоже свой язык написать?
>>271197
Уже давно все отлично тестируется юнит-тестами.
Нахера тебе синхронизировать в юнит тестах??
Да и вообще, сейчас бы в 2018 году решать проблемы многопоточности через ФП парадигмы в ООП языке с мьютексами в реале надо бить по рукам, если ты мешаешь многопоточность и бизнес-логику в одном месте, даже с иммутабельными данными. Правда, тут никто в реале код и не пишет, так что пох
Тут как получается, либо как в кложе, все иммутабельно и оптимизировано под это, и ты погружаешься в мир ФП как есть, либо нафиг идешь со своей утопией из мутированного монстра вида ООП вперемешку с огрызком из ФП.
То есть практически никогда, если сравнивать с моментом, когда тебе нужны действительно динамический списки коллекции.
Чего бл#?? Ты хоть понял что сам сказал?
>которые легко тестируются
Уже давно все отлично тестируется юнит-тестами.
>которые не нужно синхронизировать.
Нахера тебе синхронизировать в юнит тестах??
Да и вообще, сейчас бы в 2018 году решать проблемы многопоточности через ФП парадигмы в ООП языке с мьютексами в реале надо бить по рукам, если ты мешаешь многопоточность и бизнес-логику в одном месте, даже с иммутабельными данными. Правда, тут никто в реале код и не пишет, так что пох
Тут как получается, либо как в кложе, все иммутабельно и оптимизировано под это, и ты погружаешься в мир ФП как есть, либо нафиг идешь со своей утопией из мутированного монстра вида ООП вперемешку с огрызком из ФП.
>Так же часто, насколько часто ты пишешь чистые функции
То есть практически никогда, если сравнивать с моментом, когда тебе нужны действительно динамический списки коллекции.
>Опять же, в иммутабельных коллекциях спокойно хранятся динамическое кол-во элементов, если они персистентные
Чего бл#?? Ты хоть понял что сам сказал?
Этот тред назначен точкой сбора первокуров.
>>271229
Нормальных способов решить многопоточность всего 3:
1) Серверный, когда клиенты не взаимодействуют друг-с-другом, просто хуячим одинаковые потоки с однопоточным кодом по количеству ядер и сетевое соединение скедулит сообщения по потокам, в остальном код про многопоточность и не вспоминает.
2) Игроёбский: ECS+Job System, хорошо грузит ядра, снимает проблему "одно ядро долбится в сотку, остальные простаивают", в сириуз бизнес приложениях малоприменим в виду трудоемкости.
3) Правильный: Actor system - самый правильный, но имеет наибольший оверхед из трёх и годится только для действительно крупных систем (распредленных - кластеры, облака), где оверхед сжирается начисто распределенностью.
4) Самый правильный: Не ебать мозг с многопоточностью вовсе, пусть ядро в сотку себе долбится а клиента можно еще и на топ зионы брендовые развести в составе комплексного решения.
>
>Да и вообще, сейчас бы в 2018 году решать проблемы многопоточности
Нормальных способов решить многопоточность всего 3:
1) Серверный, когда клиенты не взаимодействуют друг-с-другом, просто хуячим одинаковые потоки с однопоточным кодом по количеству ядер и сетевое соединение скедулит сообщения по потокам, в остальном код про многопоточность и не вспоминает.
2) Игроёбский: ECS+Job System, хорошо грузит ядра, снимает проблему "одно ядро долбится в сотку, остальные простаивают", в сириуз бизнес приложениях малоприменим в виду трудоемкости.
3) Правильный: Actor system - самый правильный, но имеет наибольший оверхед из трёх и годится только для действительно крупных систем (распредленных - кластеры, облака), где оверхед сжирается начисто распределенностью.
4) Самый правильный: Не ебать мозг с многопоточностью вовсе, пусть ядро в сотку себе долбится а клиента можно еще и на топ зионы брендовые развести в составе комплексного решения.
>>271394
>реверс-прокси-сервер скедулит сообщения по потокам, в остальном код про многопоточность и не вспоминает.
>>271396
Именно. Все архитектурно удобно решается.
90% говна с многопоточностью возникают, именно когда одаренные смешивают б-логику и многопоточность в куче.
>в остальном код про многопоточность и не вспоминает.
Именно. Все архитектурно удобно решается.
90% говна с многопоточностью возникают, именно когда одаренные смешивают б-логику и многопоточность в куче.
>>271225
Т.е. твой аргумент против иммутабельных коллекций - раз деды сделали, то и неча менять? То что там внутри массив к теме не имеет никакого отношения.
Т.е. твой аргумент против иммутабельных коллекций - раз деды сделали, то и неча менять? То что там внутри массив к теме не имеет никакого отношения.
>>271643
Если самолет сделали чтобы он летал, не надо ставить его на рельсы потому, что новое поколение гуманитарных инженеров не до конца поняли сути самолета, да?
Пища для ума:
В ФП языках иммутабельные данные - это нехило заоптимизированая фишка языка, потому что реальное клонирование при разработке на иммутабельных данных - пиздец как затратно (а при иммутабельной системе ты реально часто будешь клонировать).
Поэтому заморозить контейнеры и при этом не сделать копи-ин-врайт систему данных - это тупо подражание, а точнее карго культ, который в жабаподобном языке нахер не нужен (потому что не работает).
Для тупых:
Нельзя, бл#, в 100% не иммутабельной системе, решить проблему многопоточности, заморозив только малую часть типов данных. И не спасет тебя и "val", потому что он морозит только ссылку на объект (что в реале нужно для JIT оптимизатора, а не для ФП-макак).
То есть, это чистой воды карго культ, но при этом они обезобразили дефолтный контейнеры.
и да, это реально серьезно, потому что показывает уровень понимания людьми, того что они тащат в свой язык
Если самолет сделали чтобы он летал, не надо ставить его на рельсы потому, что новое поколение гуманитарных инженеров не до конца поняли сути самолета, да?
Пища для ума:
В ФП языках иммутабельные данные - это нехило заоптимизированая фишка языка, потому что реальное клонирование при разработке на иммутабельных данных - пиздец как затратно (а при иммутабельной системе ты реально часто будешь клонировать).
Поэтому заморозить контейнеры и при этом не сделать копи-ин-врайт систему данных - это тупо подражание, а точнее карго культ, который в жабаподобном языке нахер не нужен (потому что не работает).
Для тупых:
Нельзя, бл#, в 100% не иммутабельной системе, решить проблему многопоточности, заморозив только малую часть типов данных. И не спасет тебя и "val", потому что он морозит только ссылку на объект (что в реале нужно для JIT оптимизатора, а не для ФП-макак).
То есть, это чистой воды карго культ, но при этом они обезобразили дефолтный контейнеры.
и да, это реально серьезно, потому что показывает уровень понимания людьми, того что они тащат в свой язык
>>271679
Хотя можно было остановиться еще на том моменте, как только стало понятно, что они типы местами переставили, плюнув всему джава сообществу в лицо.
Надеюсь второй дарт выстрелит, или шарп переживет перерождение, но чтобы такое говно с типами тухло в андеграунде разработки.
>и да, это реально серьезно, потому что показывает уровень понимания людьми, того что они тащат в свой язык
Хотя можно было остановиться еще на том моменте, как только стало понятно, что они типы местами переставили, плюнув всему джава сообществу в лицо.
Надеюсь второй дарт выстрелит, или шарп переживет перерождение, но чтобы такое говно с типами тухло в андеграунде разработки.
>>271679
Если придерживаться твоей аналогии, то у самолета есть как способность летать (MutableList), так и просто перемещаться по земле на колесах (List). И когда тебе от него нужно только второе, ты используешь именно тот интерфейс, который минимальным образом покрывает твои потребности.
Разделение способностей коллекций на два интерфейса - только чтение и чтение-запись - позволяет тебе держать порядок, в голове и в программе.
Например функция, которой нужен список значений, но она собирается эти значения только читать, может объявить тип параметра как List, что позволит принимать ей как мутабельные так и read-only списки. С другой стороны вызывая такую функцию можно не беспокоиться, что список внутри кто-нибудь помутирует.
Контейнеры никто не замораживает, все стандартные ArrayList, HashMap, HashSet прекрасно мутируемы.
>Если самолет сделали чтобы он летал, не надо ставить его на рельсы потому, что новое поколение гуманитарных инженеров не до конца поняли сути самолета, да?
Если придерживаться твоей аналогии, то у самолета есть как способность летать (MutableList), так и просто перемещаться по земле на колесах (List). И когда тебе от него нужно только второе, ты используешь именно тот интерфейс, который минимальным образом покрывает твои потребности.
Разделение способностей коллекций на два интерфейса - только чтение и чтение-запись - позволяет тебе держать порядок, в голове и в программе.
Например функция, которой нужен список значений, но она собирается эти значения только читать, может объявить тип параметра как List, что позволит принимать ей как мутабельные так и read-only списки. С другой стороны вызывая такую функцию можно не беспокоиться, что список внутри кто-нибудь помутирует.
> Поэтому заморозить контейнеры
Контейнеры никто не замораживает, все стандартные ArrayList, HashMap, HashSet прекрасно мутируемы.
576 Кб, 667x616>>271708
Лол, эти люди реально могут пустить самолет по рельсам.
Kotlin - для настоящих пилотов!
А если ты еще практикуешь зарядку по утрам, то порядок будет у тебя в голове и квартире, да и вообще волосы станут шелковистее. Тупее демагогии я еще не слышал
Доктор, я боюсь что мою коллекцию кто-то в функции может помутировать!)))
>Если придерживаться твоей аналогии, то у самолета есть как способность летать (MutableList), так и просто перемещаться по земле на колесах (List). И когда тебе от него нужно только второе, ты используешь именно тот интерфейс, который минимальным образом покрывает твои потребности.
Лол, эти люди реально могут пустить самолет по рельсам.
Kotlin - для настоящих пилотов!
>Разделение способностей коллекций на два интерфейса - только чтение и чтение-запись - позволяет тебе держать порядок, в голове и в программе.
А если ты еще практикуешь зарядку по утрам, то порядок будет у тебя в голове и квартире, да и вообще волосы станут шелковистее. Тупее демагогии я еще не слышал
>С другой стороны вызывая такую функцию можно не беспокоиться, что список внутри кто-нибудь помутирует.
Доктор, я боюсь что мою коллекцию кто-то в функции может помутировать!)))
>>271887
Не, я конечно понимаю что джаву и котлин сейчас облепили школьники и студенты, которым купили андроид. Но это, конечно, очень забавно все.
Не, я конечно понимаю что джаву и котлин сейчас облепили школьники и студенты, которым купили андроид. Но это, конечно, очень забавно все.
>>277124
Наигрались уже что ли с котлином?
Наигрались уже что ли с котлином?
>>263822 (OP)
тред жив?
тред жив?
>>299517
...и здоровья и хорошего настроения
...и здоровья и хорошего настроения
>>263822 (OP)
KOSTYLIN и этим всё сказано.
KOSTYLIN и этим всё сказано.
В катываюсь в Котлин, на Джаве до этого не работал.
Окей, вот у меня есть папочка, в ней несколько .kt файлов, как теперь это всё запустить кошерно?
Окей, вот у меня есть папочка, в ней несколько .kt файлов, как теперь это всё запустить кошерно?
177 Кб, 565x565>>299795
Это как сесть в пустой (но возможно красивый для кого-то) кузов от машины и попробовать на нём прокатиться.
Без джава бэкенда (знаний), там непонятно даже для чего половина сахара завезено. Я уверен, у нового анона будет перманентный wtf если он, конечно, не гумунитарь и не вкатывается после тонны маркетинга, о супер-пупер языке будущего
Вторая проблема, что если я захочу vsc, а не "ту" IDE? Мне придется так же страдать как шарпистам на линуксе?
Это как сесть в пустой (но возможно красивый для кого-то) кузов от машины и попробовать на нём прокатиться.
Без джава бэкенда (знаний), там непонятно даже для чего половина сахара завезено. Я уверен, у нового анона будет перманентный wtf если он, конечно, не гумунитарь и не вкатывается после тонны маркетинга, о супер-пупер языке будущего
Вторая проблема, что если я захочу vsc, а не "ту" IDE? Мне придется так же страдать как шарпистам на линуксе?
>>300032
Забавно, я как-то уже почти решился на фоне хайпа вкатиться в котлин, но потом вспомнил как сильно ненавижу эту IDE, эти вечные мелкие баги, эти вечные перенастройки проектов, эта долгая загрузка, эти неожиданные лагания под курсором, это парные автовставки всяких кавычек, которые чаще приходить убирать и корректировать. Эти подсветки незначительных ошибок, когда ты не использовал переменную (а на самом деле использовал, но мозгов у IDE не хватило понять, что она в форматирование строке).
В итоге отключаешь все это отключаешь, открываешь новый проект и все по новой.
Есть тут люди которые юзали котлин в различных IDE, как там жизнь с ним?
>Вторая проблема, что если я захочу vsc, а не "ту" IDE?
Забавно, я как-то уже почти решился на фоне хайпа вкатиться в котлин, но потом вспомнил как сильно ненавижу эту IDE, эти вечные мелкие баги, эти вечные перенастройки проектов, эта долгая загрузка, эти неожиданные лагания под курсором, это парные автовставки всяких кавычек, которые чаще приходить убирать и корректировать. Эти подсветки незначительных ошибок, когда ты не использовал переменную (а на самом деле использовал, но мозгов у IDE не хватило понять, что она в форматирование строке).
В итоге отключаешь все это отключаешь, открываешь новый проект и все по новой.
Есть тут люди которые юзали котлин в различных IDE, как там жизнь с ним?
52 Кб, 1200x365Это уже жутковатенько звучит
https://habr.com/company/JetBrains/blog/431082/
https://habr.com/company/JetBrains/blog/431082/
>>301665
Ну в BSOD-то точно виновата не твоя кривая система, а язык программирования и Бреслав лично, лол )
А если бы ты в это время на АлиЭкспресс по китайски общался -- то китайцы.
Ну в BSOD-то точно виновата не твоя кривая система, а язык программирования и Бреслав лично, лол )
А если бы ты в это время на АлиЭкспресс по китайски общался -- то китайцы.
Собираюсь писать под андройд на котлине с поверхностными знаниями в джабе, какие подводные?
>>302520
Эм... если после BSOD слетают все настройки IDE, то IDE не виновата? Ты здоров?
Эм... если после BSOD слетают все настройки IDE, то IDE не виновата? Ты здоров?
>>302597
Это ты про автора статьи или читателя?
Это ты про автора статьи или читателя?
Тред утонул или удален.
Это копия, сохраненная 27 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 27 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.