Наличие функций еще не делает язык функциональным

Суть вопроса: я не вдупляю парадигму функционального программирования. Стоит ли бросать изучание котлина и заполнять ЭТОТ пробел?

Суть вопроса: я не вдупляю парадигму функционального программирования. Стоит ли бросать изучание котлина и заполнять ЭТОТ пробел?

Нет

Бросать не стоит

А то уже курсы "Functional programming on Scala" нашёл.

Суть вопроса: я не вдупляю парадигму функционального программирования. Стоит ли бросать изучание котлина и заполнять ЭТОТ пробел?

сумневаюсь, что в котлин-чате сидят те, кто скажет, что язык этот нужно сжечь ссаными тряпками?

Вот и я, слушая ребят из JB, сделал примерно такой же вывод. Однако, стоит чуть капнуть я сразу вижу что-то типа: "так было раньше, это отстой, в Kotlin можно вот так..." и идёт куча всяких → и прочего.

Котлин продвигается как инструмент для работяг уставших от бойлерплейта Java (что бы удобно было IDEA пилить). Паттерн-матчинг/каррирование/тайп класссы - не для продакшена.

А то уже курсы "Functional programming on Scala" нашёл.

Норм, сам сейчас их смотрю http://rutracker.org/forum/viewtopic.php?t=4442274 (не врубился как на курсере смотреть бесплатно)

Норм, сам сейчас их смотрю http://rutracker.org/forum/viewtopic.php?t=4442274 (не врубился как на курсере смотреть бесплатно)

Огромное спасибо! Ты сэкономил мне $! Я как раз про них.

курсы бесплатные на курсере

платный только сертификат, если захотите корочку

по скале

курсы бесплатные на курсере

А мне норм - накачал на телефон и в метро смотрю пока еду (без инета).

курсы бесплатные на курсере

на курсере можно заниматься, скажем, только по воскресеньям?

там есть дедлайны по заданиям

по скале, насколько я помню, был дедлайн на каждую неделю

но можно заранее все сделать

там есть дедлайны по заданиям

вот ж блин печаль

и весь твой прогресс сохраняется между сессиями, то есть если не успел в одной сессии, то можно перекатиться на другую с сохранением прогресса

Котлин как раз хорош тем что его просто берёшь и используешь, не надо морочиться с парадигмами

Котлин как раз хорош тем что его просто берёшь и используешь, не надо морочиться с парадигмами

я вчера как раз так и сделал, взял-бы жаву, или шарп, часа на два раньше-б закончил)

Котлин как раз хорош тем что его просто берёшь и используешь, не надо морочиться с парадигмами

Может и так, но в моём случае получается так, что это работает, а я не врубаюсь КАК.

Суть вопроса: я не вдупляю парадигму функционального программирования. Стоит ли бросать изучание котлина и заполнять ЭТОТ пробел?

Советую пролистать https://www.ozon.ru/context/detail/id/139640075/ А Антон Архипов советует http://book.realworldhaskell.org/ (пруф http://blog.golodnyj.ru/2017/02/130-art-of-programming-hr.html)

Советую пролистать https://www.ozon.ru/context/detail/id/139640075/ А Антон Архипов советует http://book.realworldhaskell.org/ (пруф http://blog.golodnyj.ru/2017/02/130-art-of-programming-hr.html)

Спасибо за материал, полистаю. Главное, не начать стричь яков. Задача-то всё-таки вкатиться в Андроид на Котлине.

я вчера как раз так и сделал, взял-бы жаву, или шарп, часа на два раньше-б закончил)

ну, тут зависит от кого какой хочется результат

заюзать интересный язык, которому нет применения в твоей повседневности?

Может и так, но в моём случае получается так, что это работает, а я не врубаюсь КАК.

как это работает можно и по ходу понять

заюзать интересный язык, которому нет применения в твоей повседневности?

тогда всё ок :-)

тогда всё ок :-)

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

переполнение стека?

https://kotlinlang.org/docs/reference/functions.html

tail recursive functions

не любую рекурсию можно сделать хвостовой

переполнение стека?

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

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

Всем привет. Собрал в одном месте все чаты для программистов - @Chats_Developers, пользуйтесь на здоровье. Ваш чат у нас тоже есть, не удаляйте это сообщение.

я так понимаю в марте будет релиз 1.1?

Вполне возможно ;)

ну вроде говорили в Q1 будет релиз

И коррутины будут по ключику?

так не будет же по ключику

все через либы

там только 1 ключевое слово вроде добавили для функций

А зачем он сейчас требует добавлять в gradle? kotlin { experimental { coroutines "enable" } }

чтобы kotlin.coroutines.experimental можно было юзать

чтобы kotlin.coroutines.experimental можно было юзать

И если этого не будет то в релизной версии 1.1 ...

в релизной версии они переедут обратно без experimental, если ниче не поменялось

Корутины вроде в 1.1 будут эксперементальной фичей

>So, meet one of the bigger features of Kotlin 1.1: coroutines.

а есть где анонс что они останутся эксперементальными?

Корутины вроде в 1.1 будут эксперементальной фичей

С чего бы это?

Ну да, самая крутая эксперементальная фича релиза ?

киллер фича

https://discuss.kotlinlang.org/t/experimental-status-of-coroutines-in-1-1-and-related-compatibility-concerns/2236

походу придется 1.2 ждать

Хм, риальне.

походу придется 1.2 ждать

Почему? В целях совместимости пакет experimental оставят ещё на какое-то время.

Да все верно. На всякий случай проясню, дело в том, что дизайн корутин достатно нов, а фича достаточно сложна и главное многогранна. Мы до сих пор не можем поверить нашему счастью что все так удачно сошлось под дизайну, что относительно небольшое изменение в языке покрывает все возможные случаи испольщования. Поэтому мы на всякий случай оставляем ее под экспериментальным флагом. Скорее всего языковых правил менять не придется, но вот API теоретически может чуть-чуть измениться. Чтобы не терять обратной совместимости, принято вот такое решение о статусе этой фичи

Да все верно. На всякий случай проясню, дело в том, что дизайн корутин достатно нов, а фича достаточно сложна и главное многогранна. Мы до сих пор не можем поверить нашему счастью что все так удачно сошлось под дизайну, что относительно небольшое изменение в языке покрывает все возможные случаи испольщования. Поэтому мы на всякий случай оставляем ее под экспериментальным флагом. Скорее всего языковых правил менять не придется, но вот API теоретически может чуть-чуть измениться. Чтобы не терять обратной совместимости, принято вот такое решение о статусе этой фичи

тоесть на выхлопе мы что получаем? 1.0.6 с breacking changes в апи + врапперы над интеропом?

Эскейп параметров лямбд

Несколько эксьенш функций

))

ERROR: S client not available

Алиасы

Эскейп параметров лямбд

эт как в свифте $0 $1 .. ?

_ , _ ->

>Subclasses of sealed classes in the same file Это зачем вообще?

Как зачем

чтобы было?

Удобнее

Хотя я чет не сильно силед классами пользуюсь

он же sealed => не должен наследоваться

Эм

Силед классы нужны как раз для того чтобы ограничить колиество наследников

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

Удобно просто если эти классы наследники маленькие ,держать их вместе с родителем

это в принципе понятие sealed превращает в пыль

Вон в джаве локальные классы тут упоминались

Силед классы в котлине куда профитнее)

наверное я не так понимаю sealed в контексте котлина

А как понимаешь?

Берешь класс. Помечаешь его sealed и можешь внутри него перечислить классы которые от него наследуются

А для неуказанных классов он будет final

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

да в жаве это final

Прост у меня деформация похоже от этого https://msdn.microsoft.com/ru-ru/library/88c54tsw.aspx

Берешь класс. Помечаешь его sealed и можешь внутри него перечислить классы которые от него наследуются

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

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

Не слышал про такое)

Слышал что реализация родителя должна быть максимально скрыта от потомков

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

В котлине это не то немного. И в котлине в принципе все классы final по умолчанию

Слышал что реализация родителя должна быть максимально скрыта от потомков

тоесть то, что родитель знает, кто его потомки - это ок для тебя? хотя я тут с позиции ОО подхода сужу

А как разница?

Он никак не может с ними работать