Size: a a a

Kotlin Community

2020 March 19

AN

Alexander Nozik in Kotlin Community
Слава
Ну почему. Зависит от смотрящего. Они жили с этим сервером 10 лет? Да. Всё работало? Да. Могло бы работать дальше? Да, и у многих работает. Зачем им усложнять себе жизнь и хранить код скажем в TFS online, куда я перетащил часть проектов той конторы. Но вот есть нюанс- как бы усложнение добавляет безопасности и удобства.
Вообще не связано никак. Пошли в @pofftop, будете рассказыать юз кейсы для HKT кроме сериализации и либ
источник

С

Слава in Kotlin Community
Или вот люди писали себе на perl портянки кода, скажем в мэйлру. И всё работало, в начале нулевых
источник

AN

Alexander Nozik in Kotlin Community
Слава
Или вот люди писали себе на perl портянки кода, скажем в мэйлру. И всё работало, в начале нулевых
Да не об этом речь вообще. HKT в хаскеле лет 30 уже. Вопрос про конкретные юз кейсы
источник

H

Hadji in Kotlin Community
Спасибо)
источник

H

Hadji in Kotlin Community
Alexander Nozik
И опять же тулинг. Я так понял, что пакетного менеджера и сборки нормальной нет, все на хкод завязано. Оно вообще не полетит отдельно от эпла. А котлин нейтив уже его сильно догоняет
Вот, кстати, с тулингом там и правда какое-то средневековье
источник

AN

Alexander Nozik in Kotlin Community
Hadji
Вот, кстати, с тулингом там и правда какое-то средневековье
Так это главное. Та же джулия тоже хороша, пока до тулинга не добираешься. А у котлин еще и мультиплатформа. Собственно в свифте кроме автодифа в компилляторе нечего предложить. А запилить этот автодиф после IR будет не проблема и в котлин
источник

IK

Igor Komarov in Kotlin Community
Hadji
Знаю про неё, но как-то не поверил я в ее потенциал. Я с интересом посматриваю на эксперименты гугла со свифтом: swift for tensorflow. Они наняли создателя свифта к себе, создали отельную ветку и пилят в ней автодифференцирование, тензоры и интероп с питоном. Грозятся влить это в основную ветку и сделать свифт официальным языком разработки тензорфлоу
Товарищ один, который довольно-таки авторитетен в вопросах визуализации данных кипятком от нее писал. Скорее всего вопрос желания использовать что-то (вкуса)
источник

H

Hadji in Kotlin Community
Alexander Nozik
Так это главное. Та же джулия тоже хороша, пока до тулинга не добираешься. А у котлин еще и мультиплатформа. Собственно в свифте кроме автодифа в компилляторе нечего предложить. А запилить этот автодиф после IR будет не проблема и в котлин
Согласен. Просто одно дело, когда тулинга нет и нет надежд на будущее, а другое, когда компания уровня Гугла готова вкладывать свои деньги во что-то. Они даже Go сделали популярным со своими ресурсами)
источник

AN

Alexander Nozik in Kotlin Community
Igor Komarov
Товарищ один, который довольно-таки авторитетен в вопросах визуализации данных кипятком от нее писал. Скорее всего вопрос желания использовать что-то (вкуса)
Там JIT на минуту подвисает. Но если смотреть как на better python- отличный вариант
источник

AN

Alexander Nozik in Kotlin Community
Hadji
Согласен. Просто одно дело, когда тулинга нет и нет надежд на будущее, а другое, когда компания уровня Гугла готова вкладывать свои деньги во что-то. Они даже Go сделали популярным со своими ресурсами)
так они и в котлин вкладываются вовсю. Щупалец много
источник

Oℕ

Oleg ℕizhnik in Kotlin Community
в дотнете без hkt в принципе контейнерную библиотеку нормально не сделать

вернее нормально с точки зрения более позднего фп подхода.

пока фп претензий не было, не-хкт иерархией интерфейсов вполне можно было пользоваться меняя что-то на месте. т.е. мы через интерфейс ICollection или IList что-то теребим в коллекции, а ссылка -то вот она, того же типа осталась.
потом начались линкострадания и сишарп сразу уперся в ограничения дженериков, потому что теперь то надо результат возвращать. а линковые функции в основном возвращают IEnumerable, стирая статическую информацию о типе коллекции.

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

т.е. досвидания статика, привет динамический глюкодром

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

Oℕ

Oleg ℕizhnik in Kotlin Community
Beholder
А решают ли все эти hkt и тайпклассы какие-нибудь практические задачи, или они для красоты?
Telegram
Oleg ℕizhnik in Kotlin Community
в дотнете без hkt в принципе контейнерную библиотеку нормально не сделать

вернее нормально с точки зрения более позднего фп подхода.

пока фп претензий не было, не-хкт иерархией интерфейсов вполне можно было пользоваться меняя что-то на месте. т.е. мы через интерфейс ICollection или IList что-то теребим в коллекции, а ссылка -то вот она, того же типа осталась.
потом начались линкострадания и сишарп сразу уперся в ограничения дженериков, потому что теперь то надо результат возвращать. а линковые функции в основном возвращают IEnumerable, стирая статическую информацию о типе коллекции.

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

т.е. досвидания статика, привет динамический глюкодром

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

AN

Alexander Nozik in Kotlin Community
Oleg ℕizhnik
в дотнете без hkt в принципе контейнерную библиотеку нормально не сделать

вернее нормально с точки зрения более позднего фп подхода.

пока фп претензий не было, не-хкт иерархией интерфейсов вполне можно было пользоваться меняя что-то на месте. т.е. мы через интерфейс ICollection или IList что-то теребим в коллекции, а ссылка -то вот она, того же типа осталась.
потом начались линкострадания и сишарп сразу уперся в ограничения дженериков, потому что теперь то надо результат возвращать. а линковые функции в основном возвращают IEnumerable, стирая статическую информацию о типе коллекции.

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

т.е. досвидания статика, привет динамический глюкодром

если надо что-то возращать, а не изменять на месте -  дженерики без хкт уже не катят, все фп потуги в языке без хкт или похожего инструментария ничем хорошим не закончатся.
Так это опять небось F# и хаскель стайл
источник

AN

Alexander Nozik in Kotlin Community
Хаскель без них не живет, тут никто не спорит
источник

H

Hadji in Kotlin Community
Alexander Nozik
так они и в котлин вкладываются вовсю. Щупалец много
Это правда. Но в котлин вкладывается их андроидная щупальца, которая от меня далеко, а в свифт - дип лернинг щупальца, которая близко :D Я к тому, что упомянул этот проект не как что-то, что должно сделать свифт предпочтительнее, чем котлин, а как что-то, что, возможно, даст альтернативу питончику в ML-проектах.
источник

Oℕ

Oleg ℕizhnik in Kotlin Community
разница примерно как между дженерик и недженерик коллекциями в дотнете, либо все типизировано статически либо каститшь
источник

Oℕ

Oleg ℕizhnik in Kotlin Community
Alexander Nozik
Так это опять небось F# и хаскель стайл
нет, обычный ООП язык
источник

Oℕ

Oleg ℕizhnik in Kotlin Community
либо нормально типизировано, либо полудинамическая типизация и касты
источник

AN

Alexander Nozik in Kotlin Community
Hadji
Это правда. Но в котлин вкладывается их андроидная щупальца, которая от меня далеко, а в свифт - дип лернинг щупальца, которая близко :D Я к тому, что упомянул этот проект не как что-то, что должно сделать свифт предпочтительнее, чем котлин, а как что-то, что, возможно, даст альтернативу питончику в ML-проектах.
Свифт недавно RedHat выкинул с бэка.
источник

Oℕ

Oleg ℕizhnik in Kotlin Community
и ответ на все вопросы "зачем нужна такая-то фича в системе типов" будет такой же
источник