Есть конечно скала, но это вообще два метра колючей проволоки.

мне иногда не хватает определения операторов

Вперед, в скалу

кто-то говорит, что код превращается в набор ASCII символов, но в некоторых случаях код становится читаемее, потому что данные визуально хорошо отличаются от операторов

я б сделал чтобы можно было добавить оператор, но при этом у метода должно быть имя

Не понял

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

Ну паттерн матчинг - естественное следствие из типизированого лямбда исчисления для суммы типов. Вообще с ФП очень плохо всё в JVM. Главная проблема - нет оптимизации хвостовых вызовов, в результате на чистом ФП не попишешь (в лямбда исчислении нет циклов, только рекурсия, а она без оптимизации очень быстро стек переполнит)

что то вроде @Operator("|>") fun <T> T.pipe(f: (T)->R):R = f(this)

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

Систематическая ошибка выжившего

что то вроде @Operator("|>") fun <T> T.pipe(f: (T)->R):R = f(this)

и тогда можно и погуглить и использовать явно имя и похоливарить на досуге

Ну паттерн матчинг - естественное следствие из типизированого лямбда исчисления для суммы типов. Вообще с ФП очень плохо всё в JVM. Главная проблема - нет оптимизации хвостовых вызовов, в результате на чистом ФП не попишешь (в лямбда исчислении нет циклов, только рекурсия, а она без оптимизации очень быстро стек переполнит)

Дались всем эти хвостовые рекурсии. В Котлин они есть и что? Никогда в жизни не возникало желания воспользоваться

и тогда можно и погуглить и использовать явно имя и похоливарить на досуге

Тулинг превращатся в тыкву. В скале все это есть. Попробуйте.

и не понятно, чем это хуже инфиксных функций

что то вроде @Operator("|>") fun <T> T.pipe(f: (T)->R):R = f(this)

Когда я пробовал делать |> в scala, там нельзя было юзать больше одного, из-за порядка применения операторов. Норм |> работают только в ML языках.

Чего-то я обнаружил какую-то аномалию. На вызов KProperty::isAccessible выкидывается java.lang.ClassNotFoundException: org.jetbrains.kotlin.name.ClassId. Это как?

При чем сам этот ClassId даже не в рефлектах живет, а в ядре

Чего-то я обнаружил какую-то аномалию. На вызов KProperty::isAccessible выкидывается java.lang.ClassNotFoundException: org.jetbrains.kotlin.name.ClassId. Это как?

Может класслоадер левый?

Дались всем эти хвостовые рекурсии. В Котлин они есть и что? Никогда в жизни не возникало желания воспользоваться

В Котлине их нет. Там tailrec не может оптимизировать только тривиальный хвостовой вызов из функции себя же, а взаимную рекурсию уже никак. А не возникало желани пользоваться потому, что есть циклы. Проблема в том, что в ФП парадигме циклов нет, так как её теоретическая основа - лямбда исчисление. Я же не говорил, что JVM плохая. Просто сказал, что на ней проблематично реализовать чистый ФП язык.

Класслодер не совсем правый, но он наследован от основного, причем остальные классы как-то работают

Класслодер не совсем правый, но он наследован от основного, причем остальные классы как-то работают

Ага, все-таки есть вмешательство, я бы поразнюхивал в этом направлении

В Котлине их нет. Там tailrec не может оптимизировать только тривиальный хвостовой вызов из функции себя же, а взаимную рекурсию уже никак. А не возникало желани пользоваться потому, что есть циклы. Проблема в том, что в ФП парадигме циклов нет, так как её теоретическая основа - лямбда исчисление. Я же не говорил, что JVM плохая. Просто сказал, что на ней проблематично реализовать чистый ФП язык.

Я понимаю. Просто я постоянно сталкиваюсь с точкой зрения, что если нету паттерн матчинга и хвостовых рекурсий, то язык... выберите свое слово.

Чего-то я обнаружил какую-то аномалию. На вызов KProperty::isAccessible выкидывается java.lang.ClassNotFoundException: org.jetbrains.kotlin.name.ClassId. Это как?

почему exception а не error?

Ну паттерн матчинг - естественное следствие из типизированого лямбда исчисления для суммы типов. Вообще с ФП очень плохо всё в JVM. Главная проблема - нет оптимизации хвостовых вызовов, в результате на чистом ФП не попишешь (в лямбда исчислении нет циклов, только рекурсия, а она без оптимизации очень быстро стек переполнит)

Ну фиг знает, пишу на F#, рекурсией не пользуюсь. Есть же библиотечный функции для работ с колекциями.

почему exception а не error?

в смысле?

Ну фиг знает, пишу на F#, рекурсией не пользуюсь. Есть же библиотечный функции для работ с колекциями.

Которые написаны с использованием хвостовой рекурсии. Если циклов нет, то иначе никак, а в лямбда исчислении циклов нет

в смысле?

ClassNotFoundException — это следствие рефлексии.

Естественно, если я с пропертями работаю, то это уже в рефлексии. Я не понимаю, почему такая странная ошибка

Ошибка выкидывается на корневом класслоадере

не, именно джавовой рефлексии

В общем, мистика

Да. Сейчас стак трейс скину

Я понимаю. Просто я постоянно сталкиваюсь с точкой зрения, что если нету паттерн матчинга и хвостовых рекурсий, то язык... выберите свое слово.

Если нет паттерн матчинга, то его можно реализовать в рамках синтаксиса лямбда исчисления. Если нет оптимизации хвостовой рекурсии, то язык не поддерживает ФП в полном объёме, то есть нельзя писать программы на чистом ФП.

java.lang.ClassNotFoundException: org.jetbrains.kotlin.name.ClassId at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at kotlin.reflect.jvm.internal.KDeclarationContainerImpl.parseType(KDeclarationContainerImpl.kt:271) at kotlin.reflect.jvm.internal.KDeclarationContainerImpl.loadReturnType(KDeclarationContainerImpl.kt:286) at kotlin.reflect.jvm.internal.KDeclarationContainerImpl.findMethodBySignature(KDeclarationContainerImpl.kt:214) at kotlin.reflect.jvm.internal.KPropertyImplKt.computeCallerForAccessor(KPropertyImpl.kt:237) at kotlin.reflect.jvm.internal.KPropertyImplKt.access$computeCallerForAccessor(KPropertyImpl.kt:1) at kotlin.reflect.jvm.internal.KPropertyImpl$Getter$caller$2.invoke(KPropertyImpl.kt:157) at kotlin.reflect.jvm.internal.KPropertyImpl$Getter$caller$2.invoke(KPropertyImpl.kt:148) at kotlin.reflect.jvm.internal.ReflectProperties$LazySoftVal.invoke(ReflectProperties.java:93) at kotlin.reflect.jvm.internal.ReflectProperties$Val.getValue(ReflectProperties.java:32) at kotlin.reflect.jvm.internal.KPropertyImpl$Getter.getCaller(KPropertyImpl.kt) at kotlin.reflect.jvm.ReflectJvmMapping.getJavaMethod(ReflectJvmMapping.kt:62) at kotlin.reflect.jvm.ReflectJvmMapping.getJavaGetter(ReflectJvmMapping.kt:47) at kotlin.reflect.jvm.KCallablesJvm.isAccessible(KCallablesJvm.kt:46)

Причем этот метод обычно работает нормально. Но в одном конретном случае ломается

Вообще какая-то фантастика. Метод несколько раз вызвывается нормально при одних и тех же условиях, а потом на чем-то крэшится. Это жж не спроста

Вообще какая-то фантастика. Метод несколько раз вызвывается нормально при одних и тех же условиях, а потом на чем-то крэшится. Это жж не спроста

Как разберетесь, напишите пожалуйста, думаю будет поучительно

Пальцем в небо - java.net.URLClassLoader.findClass(URLClassLoader.java:381) - ресурс не берется с директории от примонтированной nfs?

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

очень важный(на самом деле нет) вопрос: у вас есть строки a и b. вы хотите получить "$a $b", но только если b не пустая. иначе вам нужна a есть ли в стдлибе функция которая это умеет делать? О_О мне надоело писать a + b.let{ if(it.isNotEmpty()) " $it" else "" } (свою util функцию тоже не хочу писать)

очень важный(на самом деле нет) вопрос: у вас есть строки a и b. вы хотите получить "$a $b", но только если b не пустая. иначе вам нужна a есть ли в стдлибе функция которая это умеет делать? О_О мне надоело писать a + b.let{ if(it.isNotEmpty()) " $it" else "" } (свою util функцию тоже не хочу писать)

listOf(a, b).filter(String::isNotEmpty).joinToString(delimiter = " ")

но вообще да, я писал when для этого

if b.isNotEmpty() "$a $b" else "$a" )

listOf(a, b).filter(String::isNotEmpty).joinToString(delimiter = " ")

ну это понятно. но это же ужас!

ну это понятно. но это же ужас!

по производительности ужас, но читаемо!

if b.isNotEmpty() "$a $b" else "$a" )

о, так кстати приятнее

по производительности ужас, но читаемо!

имхо, мой вариант более читаем

о, так кстати приятнее

А с тернарным оператором....

А с тернарным оператором....

ой всё! :D

if b.isNotEmpty() "$a $b" else "$a" )

Похади, а где скобки у if?

"$a $b".trim()

"$a $b".trim()

Другой результат при a = " "

"$a $b".trim()

круто!

Другой результат при a = " "

это норм. у меня a — это вообще число :)

Тогда красиво :)

ктонть вкурсе почему нету linkedListOf<>()? =)

ктонть вкурсе почему нету linkedListOf<>()? =)

Напиши себе сам

Напиши себе сам

так я спрашиваю почему нету =) как жить я этим я вкурсе

просто наколбасили методов по созданию разных колекций, но линкедлист как-то обошли стороной, стало интересно почему

ктонть вкурсе почему нету linkedListOf<>()? =)

Его очень редко используют (linked list)

он оказывается был, но в 1.0.0 RC его задепрекейтили

Его очень редко используют (linked list)

мне кажется чаще чем linkedMapOf() и linkedSetOf() - они то есть =)

но тут я могу ошибацца

мне кажется чаще чем linkedMapOf() и linkedSetOf() - они то есть =)

Не чаще. Linkedmap -- это вполне себе lru cache

но тут я могу ошибацца

ошибацца что чаще

А linked list обычно только а лабах нужен

А linked list обычно только а лабах нужен

там есть нужный метод removeLast() =)))

мне кажется чаще чем linkedMapOf() и linkedSetOf() - они то есть =)

Хе, в некоторых языках, не буду пальцем показывать, эти коллекции используются в качестве дефолтной реализации, а ты вот так хочешь их выкинуть из стдлиба

А вот линкедлист это почти атавизм. Даже очередь на массивах неплохо работает

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

он оказывается был, но в 1.0.0 RC его задепрекейтили

и хорошо!

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

LinkedHashMap — везде

LinkedHashMap — везде

Ну, значит не показалось

А про kotlinx.collections.immutable уже все забыли

Не взлетели

Думаю это кто-то в итоге сделает приличной либой

Я признаца сам тоже не юзаю линедлист (как впрочем и остальные линкед* - по крайней мере явно). Но вот код с которым мне приходится сейчас работать им полон

Я признаца сам тоже не юзаю линедлист (как впрочем и остальные линкед* - по крайней мере явно). Но вот код с которым мне приходится сейчас работать им полон

> признаца но олбанский же уже не в моде? :)

Я признаца сам тоже не юзаю линедлист (как впрочем и остальные линкед* - по крайней мере явно). Но вот код с которым мне приходится сейчас работать им полон

Gson по моему по умолчаю использует LinkedHaspMap и LinkedList

> признаца но олбанский же уже не в моде? :)

с телефона норм, покороче, да и вывих мозга то уже не вылечить

добрый день, может кто знает ответ: мне приходит в метод параметр type: Type? (java.lang.reflect), как я могу проверить что type == MyClass.kt при проверке получаю ошибку if (type is MyClass) Incompatible types: Type? and MyClass

можно ли как-то проверять этот тип вообще ?

в java работало как-то так: type.equals(MyClass.class) вроде бы, но я точно сейчас это проверить не могу, но вроде тип проверить можно было так

о, похоже так работает if (type == MyClass::class.java) хм..

Это не баг, это фича. KClass не является наследником Type. Там надо взять от этого Type javaerasure, тогда все будет хорошо

у type нет такого поля

а, стоп

Это я про KType

это ж вообще интерфейс, считай пустой

хм

а как тут быть в моем варианте

о, похоже так работает if (type == MyClass::class.java) хм..

это не работает

https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Type.html

У вас чисто джавовская конструкция, MyClass::class.java - это то, что надо

хм, похоже тогда дело в листе

а если List<MyClass>

как сравнить с type

Никак. Типы стариются в рантайме

type == List::class.java это не проходит

Так лист может быть разный