Size: a a a

2020 April 14

AN

Alexander Nozik in Kotlin Moscow
Alexander Nozik
стдлиба с рефлектом вместе в районе 3 мб - и это всего. Сколько из этого подкгружается зависит от вашей программы. Вы можете большую часть выпилить при помощи какого-нибудь r8 или как его.
ну и по сравнению с жавовой стдлибой - это вообще ноль
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Раз пошла такая пьянка, решил глянуть, что у нас понаписано во всяких core-tools. Вдруг бросится в глаза, что можно выкинуть.
1. числа - всё плохо с BigDecimal/BigInteger. из коробки полно extension для Float/Double/Int, но нет аналогов для BigDecimal/BigInteger. Сиди пиши сам
2. Sequence - здесь более хитрые штуки, которые изначально мы реализовывали руками, но после появления windowedSequence часть кода ушла. Всё равно остаются кастомные сплиттеры (по условию, балансировщик, ...) и аналоги аналитических функций из SQL (скользящие окна, в которых агрегаты пересчитываются с учётом ограничений на контракт функции). Зачем-то сделан свой аналог FlatteningSequence. Возможно его не было в те времена
%)
3. ленивые Tuples
4. curry/uncarry/compose/decompose - вот это вообще подстава, так как приходится писать бесконечное кол-во довольно тупых перегрузок
5. мемоизация
6. recursiveConstruct(constructor: (() -> T) -> T), когда объекту для конструирования нужно передать способ получения себя же готового
7. Деревья/иерархии
8. interface Mapping<K, V> {
 operator fun get(key: K): V?
}, KeyValue<K,V>, ... Всё-таки Map<K,V> это очень жирный интерфейс со строгим контрактом. Как только хочешь сделать что-то ленивое и всякие там copy-on-write сразу хочется вырезать из него всё лишнее (ключи заранее неизвестны, никаких тебе isEmpty, keys, values, ...) Очень жалко, что у Map в Kotlin нет вменяемых предков, так можно было бы не извращаться с адаптерами
источник

AN

Alexander Nozik in Kotlin Moscow
Maxim Zinchenko
Раз пошла такая пьянка, решил глянуть, что у нас понаписано во всяких core-tools. Вдруг бросится в глаза, что можно выкинуть.
1. числа - всё плохо с BigDecimal/BigInteger. из коробки полно extension для Float/Double/Int, но нет аналогов для BigDecimal/BigInteger. Сиди пиши сам
2. Sequence - здесь более хитрые штуки, которые изначально мы реализовывали руками, но после появления windowedSequence часть кода ушла. Всё равно остаются кастомные сплиттеры (по условию, балансировщик, ...) и аналоги аналитических функций из SQL (скользящие окна, в которых агрегаты пересчитываются с учётом ограничений на контракт функции). Зачем-то сделан свой аналог FlatteningSequence. Возможно его не было в те времена
%)
3. ленивые Tuples
4. curry/uncarry/compose/decompose - вот это вообще подстава, так как приходится писать бесконечное кол-во довольно тупых перегрузок
5. мемоизация
6. recursiveConstruct(constructor: (() -> T) -> T), когда объекту для конструирования нужно передать способ получения себя же готового
7. Деревья/иерархии
8. interface Mapping<K, V> {
 operator fun get(key: K): V?
}, KeyValue<K,V>, ... Всё-таки Map<K,V> это очень жирный интерфейс со строгим контрактом. Как только хочешь сделать что-то ленивое и всякие там copy-on-write сразу хочется вырезать из него всё лишнее (ключи заранее неизвестны, никаких тебе isEmpty, keys, values, ...) Очень жалко, что у Map в Kotlin нет вменяемых предков, так можно было бы не извращаться с адаптерами
источник

AN

Alexander Nozik in Kotlin Moscow
Но это мультиплатформа. В JVM используете жавовый и не паритесь
источник

MZ

Maxim Zinchenko in Kotlin Moscow
да понятно. на самом деле либ полно, но... непонятно почему этого нет в коробке. что за дискриминация BigDecimal/BigInteger. мы работаем в основном с ними
источник

AN

Alexander Nozik in Kotlin Moscow
Потому что они только на JVM и с ними на самом деле мало кто работает
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Alexander Nozik
Потому что они только на JVM и с ними на самом деле мало кто работает
и в native думаю тоже. то есть отпадает только JS?
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Функционал работы с большими числами без потерь точности, мне кажется, востребован везде. Можно реализовать его для тех платформ, где его нет (точнее повзаимствовать). Но это взгляд со стороны кровавого энтерпрайза, может они только нам и нужны
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Собственно ваша ссылка это оно и есть. Можно узаконить  интерфейсы, а имплементацию уже в каждой платформе делать свою, либо использовать общую межплатформенную.
источник

AN

Alexander Nozik in Kotlin Moscow
Maxim Zinchenko
Функционал работы с большими числами без потерь точности, мне кажется, востребован везде. Можно реализовать его для тех платформ, где его нет (точнее повзаимствовать). Но это взгляд со стороны кровавого энтерпрайза, может они только нам и нужны
Только финансы на самом деле. В остальных местах это слишком дорого
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Управление, статистика, планирование. Для планирования в некоторых случаях приходится конвертить исходники во что-то попроще, чтобы ворочать математику, но терять точность в исходных данных нам жалко.
источник

AN

Alexander Nozik in Kotlin Moscow
Maxim Zinchenko
Управление, статистика, планирование. Для планирования в некоторых случаях приходится конвертить исходники во что-то попроще, чтобы ворочать математику, но терять точность в исходных данных нам жалко.
Любые тяжелые математические операции надо биг числами - это дико дорого. Статистика над большими данными тоже. Вообще слабо себе представляют статистику с точностью 1e-12
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Ещё из-за того, что у нас 90% кода на Java, довольно много дурацкого библиотечного кода написано только ради упрощения interop. Но это уже наша боль, тут вряд ли придумаешь что-то универсальное и точно не надо совать это в стандартную библиотеку. Самая частая тема - хочется чтобы код на java был похож на код koltin. То есть, всякие plus, sequence, toMap, ... Возможно это блажь, но из-за этого для java мы понаделали кучу обёрток вокруг inline, чтобы их можно было дёргать
источник

MZ

Maxim Zinchenko in Kotlin Moscow
Alexander Nozik
Любые тяжелые математические операции надо биг числами - это дико дорого. Статистика над большими данными тоже. Вообще слабо себе представляют статистику с точностью 1e-12
тут проблема разных срезов. может получится так, что в вашем срезе будут супер маленькие значения, а в соседнем - супер большие. в рамках среза большая точность не нужна и можно это превратить во float и считать. срез может строится в том числе через вычитания и деления и вот тут-то могут случится приколы. например план-факт могут отличаться очень слабо, если это план-факт в рамках дня. но суммы для плана и факта могут быть нереальных порядков
источник

AN

Alexander Nozik in Kotlin Moscow
Maxim Zinchenko
Ещё из-за того, что у нас 90% кода на Java, довольно много дурацкого библиотечного кода написано только ради упрощения interop. Но это уже наша боль, тут вряд ли придумаешь что-то универсальное и точно не надо совать это в стандартную библиотеку. Самая частая тема - хочется чтобы код на java был похож на код koltin. То есть, всякие plus, sequence, toMap, ... Возможно это блажь, но из-за этого для java мы понаделали кучу обёрток вокруг inline, чтобы их можно было дёргать
Ну идиоматичный код на kotlin вообще не похож на жаву и плохо интеропится
источник

AN

Alexander Nozik in Kotlin Moscow
Maxim Zinchenko
тут проблема разных срезов. может получится так, что в вашем срезе будут супер маленькие значения, а в соседнем - супер большие. в рамках среза большая точность не нужна и можно это превратить во float и считать. срез может строится в том числе через вычитания и деления и вот тут-то могут случится приколы. например план-факт могут отличаться очень слабо, если это план-факт в рамках дня. но суммы для плана и факта могут быть нереальных порядков
Если вы это лечите биг децималами - это не есть очень хорошо. Скорее надо логарифмировать данные на входе. Но опять, если нет больших данных, то можно использовать что угодно
источник

MZ

Maxim Zinchenko in Kotlin Moscow
да, речь о чисто процедурных вызовах. ну и коллекторы для stream вполне можно сделать в духе коллекторов для sequence (хотя бы названия чтобы были те же)
источник

MZ

Maxim Zinchenko in Kotlin Moscow
проблему с вычитаниями логарифмированием не решишь
источник

AN

Alexander Nozik in Kotlin Moscow
Ну так библиотека этих экстеншенов для всего этого на весь агромадных проект пишется за день. Я не очень понимаю, зачем все с стдлибе
источник

MZ

Maxim Zinchenko in Kotlin Moscow
ну и такие решения хороши, когда уже модель есть. а если модель меняется постоянно и неизвестно какие вещи захочется завтра посчитать? жалко терять исходную информацию, это же самое ценное
источник