[Ответить в тред] Ответить в тред



<<
Назад | Вниз | Каталог | Обновить тред | Автообновление
55 | 5 | 26

Kotlin Аноним 13/09/18 Чтв 23:06:06  1263822  
image.png (6Кб, 250x250)
Что расскажете об этом языке хорошего или плохого?
Аноним 13/09/18 Чтв 23:17:07  1263833
Лучше скалы, хуже жавы.
Аноним 13/09/18 Чтв 23:22:32  1263839
>>1263833
звучит странно
Аноним 14/09/18 Птн 01:34:50  1263890
>>1263822 (OP)
игрушка от авторов платных плагинов для IDE на java. относительно взлетел только из-за встроенного оного в эту IDE, которая же android studio
Аноним 14/09/18 Птн 06:37:38  1263930
>>1263890
>игрушка
до серьезного языка не тянет?
Аноним 14/09/18 Птн 10:22:53  1263991
>>1263930
вне java мирка и intellij idea это мало кому нужно
Аноним 14/09/18 Птн 10:52:51  1264005
>>1263991
а как же котлин.нейтив?
Аноним 14/09/18 Птн 11:02:33  1264017
Trolleybread.jpg (55Кб, 640x446)
>>1264005
Аноним 14/09/18 Птн 11:16:10  1264023
>>1264005
Они вообще что-то годное пилят там или тупо транспайлер в LLVM и ЖС делают и все? причем в последнее, я слышал, что через dart-тулзу пилят??
Аноним 14/09/18 Птн 11:30:51  1264025
>>1263991
Синтаксис как-то сильно похож на джава-фикс. Причем не самый удачный.
val mutableList = mutableListOf<Some>()
было трудно сделать так?
let list = <Some>[]
let list = ["Текст1", "Текст2"] // <String>[]

И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется. Тоже же вопрос с мапами.
Если нужно где-то что-то по быстрому передать - дайте кортежи людям, не уродуйте словами "mutable".
Аноним 14/09/18 Птн 11:32:53  1264026
>>1264023
>Они вообще что-то годное пилят там
убийцу xamarin
Аноним 14/09/18 Птн 11:39:45  1264030
>>1264026
>убийцу xamarin
Что именно?
Аноним 14/09/18 Птн 15:25:32  1264167
>>1264023
Говоришь как будто этого мало, раст тоже например в ллвм компилируется. Да и к тому же не нужно будет иметь 150 мб жава рантайма чтобы запустить программу.
Аноним 14/09/18 Птн 15:32:04  1264171
>>1264025
> И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется
Мутейбл изменяется. Я так понял это килер фича для с++ кодеров, потому что там каждая первая функция принимает const и всех это заебало писать
Аноним 14/09/18 Птн 20:08:54  1264292
>>1264167
Ты не уловил мысль. У раста, как бы, есть свои батарейки, то есть он не тупо транспайлер с тонкой стандартной либой (типа вот вам сделали, дальше сами пилите, за любовь)
Аноним 17/09/18 Пнд 02:22:08  1265325
>>1264025
>И вообще почему надо писать приставку mutable, как часто ты тебе нужен список, который не изменяется.

В большинстве случаев нужен список, из которого элементы только читаются, а сам список не меняется.
Mutable-списки нужны иногда и в ограниченном скоупе.
Аноним 17/09/18 Пнд 07:02:44  1265353
>>1265325
>В большинстве случаев нужен список, из которого элементы только читаются,
Сразу видно настоящих программистов. Но к сожалению, в большинстве своем список (List) нужен чтобы условно-неограниченно и динамично хранить какие-то данные. А вот для ограниченной последовательности подошел бы как раз классический джавовый/сишный массив.

То есть - List вообще не задумывался для того чего от него сейчас хотят. Это бл..дская коллекция, а не встроенный тип данных, от которого еще можно было требовать иммутабельность.
Я вообще не понимаю, каким гуманитарным-инженером надо быть, чтобы коллекции делать иммутабельными.
Аноним 27/09/18 Чтв 11:11:33  1270864
Интересный комментарий
>>1269774
Аноним 27/09/18 Чтв 11:41:04  1270876
>>1265353
Его делают иммутабельным, чтобы безопасно использовать в качестве shared memory в многопоточной программе без использования синхронизации (мьютексов). И внутри этот список не совсем список в классическом виде, а другая похожая структура.
Аноним 27/09/18 Чтв 18:25:01  1271088
>>1270876
Лол, конечно, ведь проблемы многопоточности это как раз та область в которой должны решать проблемы именно коллекции.

Проблема в том, что коллекция перестает быть коллекцией (резиновым контейнером), если она становится иммутабельной. И на самом деле, в жабе есть уже потокобезопасные коллекции (мутабельные).

...когда-то в истории, еще в эпоху С++:

чувак, у нас есть массив, которые удачно расположен в памяти, но он статичен, его неудобно использовать с динамичными данными.
@
хорошо, мы возьмем мощь ООП и сделаем резиновые "массивы" - контейнеры/коллекции!
@
Десятый год 21 века: Я гуманитарный инженер нового поколения, я вижу что коллекции не потокобезопасны!
@
А давайте, сделаем конкурентные многопоточные коллекции???
@
Неее, слишком просто и не модно, давай-те сделаем коллекция вновь статичными! И вообще только для чтения!

Аноним 27/09/18 Чтв 23:46:33  1271194
>>1265353
>То есть - List вообще не задумывался для того чего от него сейчас хотят
Это ты за всех решил, что по назначению, а что нет?
Аноним 27/09/18 Чтв 23:49:49  1271197
>>1264025
>как часто ты тебе нужен список, который не изменяется
Так же часто, насколько часто ты пишешь чистые функции, которые легко тестируются и которые не нужно синхронизировать.
>(List) нужен чтобы условно-неограниченно и динамично хранить какие-то данные
Опять же, в иммутабельных коллекциях спокойно хранятся динамическое кол-во элементов, если они персистентные
Аноним 27/09/18 Чтв 23:51:00  1271198
>>1271088
Массив статичен только размером, данные в нем мутабельны. Садись 2.
Аноним 28/09/18 Птн 01:54:09  1271222
>>1271198
Про размер только и говорили.

А вообще, какой смысл от статичных элементов массива (точнее статичных ссылок в этих элементах) если не факт, что внутри объект потокобезопасный? Квази решения на одном уровне, ну круто че, за то похерили "динамичность" и вообще саму идею коллекций.
Аноним 28/09/18 Птн 01:57:56  1271225
>>1271194
>Это ты за всех решил, что по назначению, а что нет?
Нет, потому что изначально list-контейнер и создавался для динамического размера. Ну то есть, там буквально статический массив пересоздается по мере увеличения (обалдеть, да?)
Видишь и ты тоже не знал, не хочешь тоже свой язык написать?
Аноним 28/09/18 Птн 02:32:10  1271229
>>1271197
>которые легко тестируются
Уже давно все отлично тестируется юнит-тестами.

>которые не нужно синхронизировать.
Нахера тебе синхронизировать в юнит тестах??

Да и вообще, сейчас бы в 2018 году решать проблемы многопоточности через ФП парадигмы в ООП языке с мьютексами в реале надо бить по рукам, если ты мешаешь многопоточность и бизнес-логику в одном месте, даже с иммутабельными данными. Правда, тут никто в реале код и не пишет, так что пох

Тут как получается, либо как в кложе, все иммутабельно и оптимизировано под это, и ты погружаешься в мир ФП как есть, либо нафиг идешь со своей утопией из мутированного монстра вида ООП вперемешку с огрызком из ФП.

>Так же часто, насколько часто ты пишешь чистые функции
То есть практически никогда, если сравнивать с моментом, когда тебе нужны действительно динамический списки коллекции.

>Опять же, в иммутабельных коллекциях спокойно хранятся динамическое кол-во элементов, если они персистентные
Чего бл#?? Ты хоть понял что сам сказал?
Аноним 28/09/18 Птн 11:36:24  1271368
Этот тред назначен точкой сбора первокуров.
Аноним 28/09/18 Птн 12:26:14  1271394
>>1271229
>
>Да и вообще, сейчас бы в 2018 году решать проблемы многопоточности

Нормальных способов решить многопоточность всего 3:

1) Серверный, когда клиенты не взаимодействуют друг-с-другом, просто хуячим одинаковые потоки с однопоточным кодом по количеству ядер и сетевое соединение скедулит сообщения по потокам, в остальном код про многопоточность и не вспоминает.

2) Игроёбский: ECS+Job System, хорошо грузит ядра, снимает проблему "одно ядро долбится в сотку, остальные простаивают", в сириуз бизнес приложениях малоприменим в виду трудоемкости.

3) Правильный: Actor system - самый правильный, но имеет наибольший оверхед из трёх и годится только для действительно крупных систем (распредленных - кластеры, облака), где оверхед сжирается начисто распределенностью.

4) Самый правильный: Не ебать мозг с многопоточностью вовсе, пусть ядро в сотку себе долбится а клиента можно еще и на топ зионы брендовые развести в составе комплексного решения.
Аноним 28/09/18 Птн 12:27:31  1271396
>>1271394
>реверс-прокси-сервер скедулит сообщения по потокам, в остальном код про многопоточность и не вспоминает.

Аноним 28/09/18 Птн 14:45:57  1271464
>>1271396
>в остальном код про многопоточность и не вспоминает.
Именно. Все архитектурно удобно решается.
90% говна с многопоточностью возникают, именно когда одаренные смешивают б-логику и многопоточность в куче.

Аноним 28/09/18 Птн 22:38:51  1271643
>>1271225
Т.е. твой аргумент против иммутабельных коллекций - раз деды сделали, то и неча менять? То что там внутри массив к теме не имеет никакого отношения.
Аноним 29/09/18 Суб 01:12:29  1271679
>>1271643
Если самолет сделали чтобы он летал, не надо ставить его на рельсы потому, что новое поколение гуманитарных инженеров не до конца поняли сути самолета, да?

Пища для ума:
В ФП языках иммутабельные данные - это нехило заоптимизированая фишка языка, потому что реальное клонирование при разработке на иммутабельных данных - пиздец как затратно (а при иммутабельной системе ты реально часто будешь клонировать).
Поэтому заморозить контейнеры и при этом не сделать копи-ин-врайт систему данных - это тупо подражание, а точнее карго культ, который в жабаподобном языке нахер не нужен (потому что не работает).

Для тупых:
Нельзя, бл#, в 100% не иммутабельной системе, решить проблему многопоточности, заморозив только малую часть типов данных. И не спасет тебя и "val", потому что он морозит только ссылку на объект (что в реале нужно для JIT оптимизатора, а не для ФП-макак).

То есть, это чистой воды карго культ, но при этом они обезобразили дефолтный контейнеры.

и да, это реально серьезно, потому что показывает уровень понимания людьми, того что они тащат в свой язык
Аноним 29/09/18 Суб 01:23:26  1271682
>>1271679
>и да, это реально серьезно, потому что показывает уровень понимания людьми, того что они тащат в свой язык

Хотя можно было остановиться еще на том моменте, как только стало понятно, что они типы местами переставили, плюнув всему джава сообществу в лицо.

Надеюсь второй дарт выстрелит, или шарп переживет перерождение, но чтобы такое говно с типами тухло в андеграунде разработки.
Аноним 29/09/18 Суб 05:43:07  1271708
>>1271679
>Если самолет сделали чтобы он летал, не надо ставить его на рельсы потому, что новое поколение гуманитарных инженеров не до конца поняли сути самолета, да?

Если придерживаться твоей аналогии, то у самолета есть как способность летать (MutableList), так и просто перемещаться по земле на колесах (List). И когда тебе от него нужно только второе, ты используешь именно тот интерфейс, который минимальным образом покрывает твои потребности.

Разделение способностей коллекций на два интерфейса - только чтение и чтение-запись - позволяет тебе держать порядок, в голове и в программе.

Например функция, которой нужен список значений, но она собирается эти значения только читать, может объявить тип параметра как List, что позволит принимать ей как мутабельные так и read-only списки. С другой стороны вызывая такую функцию можно не беспокоиться, что список внутри кто-нибудь помутирует.

> Поэтому заморозить контейнеры

Контейнеры никто не замораживает, все стандартные ArrayList, HashMap, HashSet прекрасно мутируемы.
Аноним 29/09/18 Суб 15:43:48  1271887
image.png (576Кб, 667x616)
>>1271708
>Если придерживаться твоей аналогии, то у самолета есть как способность летать (MutableList), так и просто перемещаться по земле на колесах (List). И когда тебе от него нужно только второе, ты используешь именно тот интерфейс, который минимальным образом покрывает твои потребности.
Лол, эти люди реально могут пустить самолет по рельсам.
Kotlin - для настоящих пилотов!

>Разделение способностей коллекций на два интерфейса - только чтение и чтение-запись - позволяет тебе держать порядок, в голове и в программе.
А если ты еще практикуешь зарядку по утрам, то порядок будет у тебя в голове и квартире, да и вообще волосы станут шелковистее. Тупее демагогии я еще не слышал

>С другой стороны вызывая такую функцию можно не беспокоиться, что список внутри кто-нибудь помутирует.
Доктор, я боюсь что мою коллекцию кто-то в функции может помутировать!)))
Аноним 29/09/18 Суб 15:59:44  1271895
>>1271887
Не, я конечно понимаю что джаву и котлин сейчас облепили школьники и студенты, которым купили андроид. Но это, конечно, очень забавно все.
Аноним 10/10/18 Срд 02:04:03  1277124
тред жив?
Аноним 11/10/18 Чтв 21:16:44  1277861
>>1277124
Наигрались уже что ли с котлином?
Аноним 04/11/18 Вск 09:18:42  1289532
>>1263822 (OP)
тред жив?
Аноним 21/11/18 Срд 13:52:19  1298886
Чего хотел-то?
Аноним 22/11/18 Чтв 12:57:30  1299516
>>1298886
счастья
Аноним 22/11/18 Чтв 12:58:20  1299517
>>1299516
А как же здоровье?
Аноним 22/11/18 Чтв 13:09:42  1299520
>>1299517
...и здоровья и хорошего настроения
Аноним 22/11/18 Чтв 14:21:48  1299559
>>1263822 (OP)
KOSTYLIN и этим всё сказано.

Аноним 22/11/18 Чтв 19:04:25  1299720
В катываюсь в Котлин, на Джаве до этого не работал.
Окей, вот у меня есть папочка, в ней несколько .kt файлов, как теперь это всё запустить кошерно?
Аноним 22/11/18 Чтв 21:22:01  1299778
>>1299720
>В катываюсь в Котлин, на Джаве до этого не работал.
Куда ты лезешь тогда?
Аноним 22/11/18 Чтв 21:58:22  1299795
>>1299778
>Куда ты лезешь тогда?
кто не жевал вербозное говно лет 5 лет -- тому сахар не положен?
Аноним 23/11/18 Птн 10:37:11  1300032
image.png (177Кб, 565x565)
>>1299795
Это как сесть в пустой (но возможно красивый для кого-то) кузов от машины и попробовать на нём прокатиться.
Без джава бэкенда (знаний), там непонятно даже для чего половина сахара завезено. Я уверен, у нового анона будет перманентный wtf если он, конечно, не гумунитарь и не вкатывается после тонны маркетинга, о супер-пупер языке будущего
Вторая проблема, что если я захочу vsc, а не "ту" IDE? Мне придется так же страдать как шарпистам на линуксе?
Аноним 27/11/18 Втр 03:49:52  1301664
>>1300032
>Вторая проблема, что если я захочу vsc, а не "ту" IDE?
Забавно, я как-то уже почти решился на фоне хайпа вкатиться в котлин, но потом вспомнил как сильно ненавижу эту IDE, эти вечные мелкие баги, эти вечные перенастройки проектов, эта долгая загрузка, эти неожиданные лагания под курсором, это парные автовставки всяких кавычек, которые чаще приходить убирать и корректировать. Эти подсветки незначительных ошибок, когда ты не использовал переменную (а на самом деле использовал, но мозгов у IDE не хватило понять, что она в форматирование строке).

В итоге отключаешь все это отключаешь, открываешь новый проект и все по новой.

Есть тут люди которые юзали котлин в различных IDE, как там жизнь с ним?
Аноним 27/11/18 Втр 03:51:23  1301665
>>1301664
Ах да, как-то раз случился BSOD и все настройки слетели. Это было шедеврально!
Аноним 27/11/18 Втр 04:02:37  1301667
image.png (52Кб, 1200x365)
Это уже жутковатенько звучит
https://habr.com/company/JetBrains/blog/431082/
Аноним 28/11/18 Срд 16:37:26  1302520
>>1301665
Ну в BSOD-то точно виновата не твоя кривая система, а язык программирования и Бреслав лично, лол )
А если бы ты в это время на АлиЭкспресс по китайски общался -- то китайцы.
Аноним 28/11/18 Срд 19:15:54  1302571
Собираюсь писать под андройд на котлине с поверхностными знаниями в джабе, какие подводные?
Аноним 28/11/18 Срд 20:13:02  1302597
>>1301667
хабропидор не палится
Аноним 29/11/18 Чтв 03:46:41  1302779
>>1302520
Эм... если после BSOD слетают все настройки IDE, то IDE не виновата? Ты здоров?
Аноним 29/11/18 Чтв 03:48:16  1302780
>>1302597
Это ты про автора статьи или читателя?


Топ тредов
Избранное