ХХ
Это так называемые scope functions. Они позволяют выполнять не одну операцию, а целый блок в нужном окружении
Понятно спасибо
someNullableDouble?.let { sqrt(it) }Size: a a a
2021 January 07
ХХ
Ну, т.е. именно в контексте nullalble цепочек, let иногда просто больше вещей позволяет. Например если у вас обычная функция (не экстешн), то с помощью nullable call не получится вызвать. И тогда можно применять nullable let:
И вам
L
Я вот решил проходить его параллельно в скале-котлине,
но крайне полезным счёл бы полиглот ресурс на основе этого учебника
но крайне полезным счёл бы полиглот ресурс на основе этого учебника
Вот, автор пишет разумное, что на динамических языках кроме map-reduce смысла нет извращаться, но есть FP языки с которыми без разницы вообще
"At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role."
Интересно, автор пропустил Kotlin (и С# кстати) потому что "нельзя всё объять", или котлин реально менее гож, чем Swift?
"At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role."
Интересно, автор пропустил Kotlin (и С# кстати) потому что "нельзя всё объять", или котлин реально менее гож, чем Swift?
L
Если так, то чем именно?
AN
Вот, автор пишет разумное, что на динамических языках кроме map-reduce смысла нет извращаться, но есть FP языки с которыми без разницы вообще
"At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role."
Интересно, автор пропустил Kotlin (и С# кстати) потому что "нельзя всё объять", или котлин реально менее гож, чем Swift?
"At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role."
Интересно, автор пропустил Kotlin (и С# кстати) потому что "нельзя всё объять", или котлин реально менее гож, чем Swift?
Что такое "гож"? Кому? Когда? Для чего? Утверждения типа того, что на динамических языках нельзя писать ничего отнесите пожалуйста людям, которые работают на Пайтоне и PHP
L
Что такое "гож"? Кому? Когда? Для чего? Утверждения типа того, что на динамических языках нельзя писать ничего отнесите пожалуйста людям, которые работают на Пайтоне и PHP
Вот полная цитата, думал без неё понятно
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
AN
Вот полная цитата, думал без неё понятно
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
FP - это очень широкое понятие, которое каждый определяет по своему. На котлин не удобно писать в хаскель-стайл. Потому что язык совсем другой. Но есть вполне себе ФП-котлин-стайл.
L
FP - это очень широкое понятие, которое каждый определяет по своему. На котлин не удобно писать в хаскель-стайл. Потому что язык совсем другой. Но есть вполне себе ФП-котлин-стайл.
Меня зацепило упоминание Swift как годного. Я его совсем не знаю, но вижу повсеместные его упоминания вместе с котлиным
AN
Меня зацепило упоминание Swift как годного. Я его совсем не знаю, но вижу повсеместные его упоминания вместе с котлиным
Свифт почти ничем не отличается от котлин идейно. Но он появился в публичном пространстве чуть раньше. Возможно дело в этом. Посмотрите год выпуска книги
AM
Вот полная цитата, думал без неё понятно
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
It is possible to apply the FP paradigm while writing code in any programming language. However, some languages lack certain features that make FP techniques much easier to use in practice. For example, in a language such as Python or Ruby, one can productively use only a limited number of FP idioms, such as the map/reduce operations. More advanced FP constructions are impractical in these languages because the required code becomes too hard to read and to write without errors, which negates the advantages of rigorous reasoning about functional programs.
Some programming languages, such as Haskell and OCaml, were designed specifically for advanced use in the FP paradigm. Other languages, such as ML, F#, Scala, Swift, Elm, and PureScript, have different design goals but still support enough FP features to be considered FP languages. This book uses Scala, but the same constructions may be implemented in other FP languages in a simi- lar way. At the level of detail needed in this book, the differences between languages such as ML, OCaml, Haskell, F#, Scala, Swift, Elm, or PureScript do not play a significant role.
А мой вопрос в силе
Речь не о динамической типизации, а именно о языковых фичах. К примеру, ограничение пайтона с лямбдами в одну строку сильно мешает писать в таком стиле -- там в ходу list comprehensions, а не вот это всё. О руби ничего не могу сказать.
На C# можно писать так, но незачем, так как есть F#. Почему не упомянут котлин -- не знаю. Может, автор с ним не знакомился, может, имеет какие-то предубеждения, может по тому же принципе считает, что раз есть скала, делать то же самое на котлине смысла нет. Вроде наличие Arrow и коммьюнити вокруг него подтверждает обратное.
На C# можно писать так, но незачем, так как есть F#. Почему не упомянут котлин -- не знаю. Может, автор с ним не знакомился, может, имеет какие-то предубеждения, может по тому же принципе считает, что раз есть скала, делать то же самое на котлине смысла нет. Вроде наличие Arrow и коммьюнити вокруг него подтверждает обратное.
L
Она ещё не выпущена) Процесс никак не завершится
AM
Свифт почти ничем не отличается от котлин идейно. Но он появился в публичном пространстве чуть раньше. Возможно дело в этом. Посмотрите год выпуска книги
Идейно нет, а вот экстеншны саифтовые и селф-типы намного больше свободы дают для обсуждаемого способа писать код.
AN
Она ещё не выпущена) Процесс никак не завершится
Ну может он макофил
AM
Ну может он макофил
Это вы за одно упоминание свифта автору такую бирочку выдали?)
AN
Это вы за одно упоминание свифта автору такую бирочку выдали?)
Нет, это была неудачная шутка. Просто свифт популярен в мак-разработке. И если человек сидит только в мак экосистеме, ему свифт может быть сильно виднее, чем котлин.
L
Идейно нет, а вот экстеншны саифтовые и селф-типы намного больше свободы дают для обсуждаемого способа писать код.
Спасибо, именно такого рода ответ хотел
AN
Идейно нет, а вот экстеншны саифтовые и селф-типы намного больше свободы дают для обсуждаемого способа писать код.
Это про экстеншен интерфейсы?
AM
Это про экстеншен интерфейсы?
Я не уверен, что вы называете экстеншн интерфейсами, но в свифте один вид экстеншнов.
AN
Я не уверен, что вы называете экстеншн интерфейсами, но в свифте один вид экстеншнов.
Ну то, что в котлин обсуждается как экстеншен интерфейсы.
АГ
Я пишу и на Котлин и на Свифт и да в Свифте есть некоторые более удобные штуки (сходу не вспомню, но несколько раз ловил ощущение, что нехватает этого в котлине), но Котлин в сумме все равно выигрывает, то есть обратное ощущение возникает чаще