Я не говорил, что они каррирование, а имел в виду, что привык, что в ML-семействе пайпы обычно определяются примерно так:
f |> g = g f
И, соответственно, нет никаких специальных правил про первый аргумент и прочее. Впрочем, это не мешает эргономике — просто self-аргумент последний, а не первый.
Не подкинете ссылок на какие-нибудь заметки о дизайне Elixir? Интересно, почему авторы решили отойти от проторенной дорожки.
Если self-параметр передается первым, то пайпы работают не за счет каррирования?
Вот, например, функция students_by_grade. Первый параметр — школа, второй — оценка. Но функция передается в пайп с оценкой, т. е. вторым параметром.
Специальный хак для первого параметра? Частичное применение задом-наперед?
На 0.3 совсем мало бы кто перешел, а им нужно как можно больше пользователей:
во-первых, это более массовое тестирование, а значит меньше укромных уголков для крупных дефектов;
во-вторых, после набора определенной критической массы поддержка Obj-C может быть сильно ограничена с высвобождением средств разработки.
Если уж "читается", то следует помнить, что "w" оглушается.
А транслитерировать следует как "Сьвенцкий" или "Сьвентский" (если очевидно происхождение от "święto" — "праздник").
Я думаю, упор не на функциональное программирование как таковое, а скорее на декларативность, достижимую с помощью средств, заимствованных из функционального программирования. Ну и на value semantics. И умный компилятор, который магически улучшает говнокод.
С таким компилятором, кстати, чем меньше свободы людям, тем больше оптимизатору.
Получается очень хороший набор базовых постулатов, с синергией. И очень в духе Apple "Мы делаем лучшие чистилки для апельсинов, потому что мы лучше всех знаем, как чистить апельсины." Можно ли чистить красные апельсины? Я думаю, для этого найдется своя Cydia.
В отличие от математики, программный код разбирает компьютер, а находящиеся по эту сторону монитора не желают ни вводить с клавиатуры длинные последовательности, ни ждать, пока ИИ сможет понимать код, написанный на математическом языке.
Каждая фича в языке, каждая строчка в компиляторе может стоить немалых денег в поддержке. "Общепринятые" вещи из Си отсутствуют во многих языках, на которых выросло поколение авторов Swift, языков, начавших активно выходить за пределы академической среды — функциональных языков, в основном.
Swift — очень современный в этом плане язык, авторы активно движут его к зарекомендовавшим себя и модным ныне практикам ФП, но при этом в нем слишком много фич (а особенно синтаксиса) — скорее всего поэтому авторы убирают все, что в их идеальном стиле не используется, но при этом не ограничивает круг решаемых задач.
Важно понимать, что идеология Swift подразумевает написание идеоматического высокоуровнего высокодекларативного кода, который затем трансформируется очень умным компилятором в эффективный машинный код, который предположительно должен быть таким же быстрым, как написанный с использованием таких фич, как инкремент и цикл for в стиле Си.
Как без С-style цикла сделать итерацию с шагом, отличным от 1?
Скорее всего, авторы хотят сделать акцент на техниках функционального программирования и эти юзкейсы должны покрываться фильтром по индексу, например (псевдокод): collection.filter(eventh).map(doSomething).reduce(calcResult)
Зачем убирать более удобную версию записи каррирования? Новый синтаксис с 3 и более параметрами будет выглядеть монструозно.
В Swift слишком много синтаксиса. Скорее всего, синтаксис каррирования усложнял парсер, так как требовал разрешения неоднозначностей, а может просто прибили как наименее полезный синтаксис по версии авторов.
"Новый" синтаксис — явная форма возврата функции. На практике я довольно редко вижу применение функции больше, чем в две стадии, так что в каком-то смысле компромисс для меня очевидный.
Не знаю как в Swift, но в C# количество элементов кортежа (тип Tuple) тоже ограничено.
В C# это связано с тем, что нет генериков с переменным числом параметров, и вообще вариадики поддерживаются только гомогенные (т. е. одного типа). Поэтому в C# определены сразу несколько типов Tuple: с одним, двумя итд. параметрами.
Если мне память не изменяет, в Swift система типов устроена сходным образом (нет генериков-вариадиков).
<зануда>Прошу прощения, но его имя Бартош: он поляк, и «sz» читается как «ш». А вот Evan Czaplicki — настоящий американец, и свою польскую фамилию как только не произносит, включая невероятное «гзаплики».</зануда>
а если это математик, запершийся в своей комнате уже пару лет, готовящий математическую базу для физических открытий будущего?
а если это действительно хороший художник или музыкант? возможно, можно было бы упразднить авторские отчисления. вам бы понравился мир, где вы можете слушать любую музыку, которая вам нравится, свободно?
еще мне как большому любителю симметрии нравится, что нет дискриминации трудоспособных белых мужчин :)
в Скандинавии есть такое слово arbeidsglede. возможно, где-то ментальность не позволила бы ввести подобное, но, видимо, финны понимают, на что идут.
На самом деле, тут все достаточно просто объяснимо, по крайней мере, постфактум.
1. Случайно образовался JS в браузере. Пусть достаточно случайное явление, но язык не повернется назвать магическим.
2. Жесткая конкуренция за растущий пирог случайно привела к тому, что он оказался во всех современных браузерах. Вот это магия, на мой взгляд. Условия рынка сложились достаточно специфические, здесь было вариантов пока еще много. Дальше все строго предсказуемо.
3. Пирог веба вырос настолько, что браузеры стали использоваться почти всеми цивилизованными людьми чуть ли не каждый день. Оно и понятно: почти мгновенная коммуникация — лучшее изобретение человечества пока что.
Дальше ситуация предсказуемо должна дать попытки найти способ обойти недостатки языка: ошибкоопасность и тормоза.
Попытки увенчались упехом и, по-моему, не могло пойти иначе: конкуренция между браузерами все еще сильна.
Небольшой элемент случайности еще был связан с одновременным развитием мобильного рынка, что подлило масла в огонь, но имхо погоды это не сделало.
Итак, JS везде и не содержит изъянов, делающих его использование невозможным. Чего ждать? Того, что мы сейчас имеем. Пока веб-платформа не упрется в свои фатальные недостатки, она будет расти в сторону еще большего распространения, улучшения скорости работы и развития инструментов разработки. В принципе, после анонса WASM у меня не хватает фантазии, что еще может выйти определяющего.
Разве что расширение набора инструкций ARM для более эффективной работы виртуальной машины JS, но сначала надо стандартизировать их как следует.
Так что, думаю, популярность растет просто потому что до сих пор не уперлась в потолок, но не просто так, а потому что JS-интерпретатор — самый распространенный на планете интерпретатор/компилятор.
И, соответственно, нет никаких специальных правил про первый аргумент и прочее. Впрочем, это не мешает эргономике — просто self-аргумент последний, а не первый.
Не подкинете ссылок на какие-нибудь заметки о дизайне Elixir? Интересно, почему авторы решили отойти от проторенной дорожки.
Вот, например, функция students_by_grade. Первый параметр — школа, второй — оценка. Но функция передается в пайп с оценкой, т. е. вторым параметром.
Специальный хак для первого параметра? Частичное применение задом-наперед?
во-первых, это более массовое тестирование, а значит меньше укромных уголков для крупных дефектов;
во-вторых, после набора определенной критической массы поддержка Obj-C может быть сильно ограничена с высвобождением средств разработки.
Но разделяю вашу фрустрацию.
Вместо постов хранить события "запостил", "исправил", "удалил"?
А транслитерировать следует как "Сьвенцкий" или "Сьвентский" (если очевидно происхождение от "święto" — "праздник").
Есть неплохая статья на вики, которую я бы рекомендовал всем переводчикам, увидевшим в тексте польскую фамилию: https://ru.wikipedia.org/wiki/Польско-русская_практическая_транскрипция
Но поскольку распознать принадлежность имени может быть сложно, я бы просто советовал не транслитерировать в кириллицу никакие нетривиальные имена.
С таким компилятором, кстати, чем меньше свободы людям, тем больше оптимизатору.
Получается очень хороший набор базовых постулатов, с синергией. И очень в духе Apple "Мы делаем лучшие чистилки для апельсинов, потому что мы лучше всех знаем, как чистить апельсины." Можно ли чистить красные апельсины? Я думаю, для этого найдется своя Cydia.
Каждая фича в языке, каждая строчка в компиляторе может стоить немалых денег в поддержке. "Общепринятые" вещи из Си отсутствуют во многих языках, на которых выросло поколение авторов Swift, языков, начавших активно выходить за пределы академической среды — функциональных языков, в основном.
Swift — очень современный в этом плане язык, авторы активно движут его к зарекомендовавшим себя и модным ныне практикам ФП, но при этом в нем слишком много фич (а особенно синтаксиса) — скорее всего поэтому авторы убирают все, что в их идеальном стиле не используется, но при этом не ограничивает круг решаемых задач.
Важно понимать, что идеология Swift подразумевает написание идеоматического высокоуровнего высокодекларативного кода, который затем трансформируется очень умным компилятором в эффективный машинный код, который предположительно должен быть таким же быстрым, как написанный с использованием таких фич, как инкремент и цикл for в стиле Си.
Скорее всего, авторы хотят сделать акцент на техниках функционального программирования и эти юзкейсы должны покрываться фильтром по индексу, например (псевдокод):
collection.filter(eventh).map(doSomething).reduce(calcResult)В Swift слишком много синтаксиса. Скорее всего, синтаксис каррирования усложнял парсер, так как требовал разрешения неоднозначностей, а может просто прибили как наименее полезный синтаксис по версии авторов.
"Новый" синтаксис — явная форма возврата функции. На практике я довольно редко вижу применение функции больше, чем в две стадии, так что в каком-то смысле компромисс для меня очевидный.
В C# это связано с тем, что нет генериков с переменным числом параметров, и вообще вариадики поддерживаются только гомогенные (т. е. одного типа). Поэтому в C# определены сразу несколько типов Tuple: с одним, двумя итд. параметрами.
Если мне память не изменяет, в Swift система типов устроена сходным образом (нет генериков-вариадиков).
В Lisp хотя бы запятых нет :)
Сейчас в мейнстрим вошли уже функциональное программирование и код как данные.
Еще немного, и люди перестанут холиварить о статической типизации.
Lisp, кстати, в 80-е уже давно был и может даже нашлись бы люди, которые уже тогда бы включили его в список «великих изобретений».
Я написал виртуальную машину под твою виртуальную машину, чтобы ты мог тормозить, пока тормозишь.
а если это математик, запершийся в своей комнате уже пару лет, готовящий математическую базу для физических открытий будущего?
а если это действительно хороший художник или музыкант? возможно, можно было бы упразднить авторские отчисления. вам бы понравился мир, где вы можете слушать любую музыку, которая вам нравится, свободно?
еще мне как большому любителю симметрии нравится, что нет дискриминации трудоспособных белых мужчин :)
в Скандинавии есть такое слово arbeidsglede. возможно, где-то ментальность не позволила бы ввести подобное, но, видимо, финны понимают, на что идут.
1. Случайно образовался JS в браузере. Пусть достаточно случайное явление, но язык не повернется назвать магическим.
2. Жесткая конкуренция за растущий пирог случайно привела к тому, что он оказался во всех современных браузерах. Вот это магия, на мой взгляд. Условия рынка сложились достаточно специфические, здесь было вариантов пока еще много. Дальше все строго предсказуемо.
3. Пирог веба вырос настолько, что браузеры стали использоваться почти всеми цивилизованными людьми чуть ли не каждый день. Оно и понятно: почти мгновенная коммуникация — лучшее изобретение человечества пока что.
Дальше ситуация предсказуемо должна дать попытки найти способ обойти недостатки языка: ошибкоопасность и тормоза.
Попытки увенчались упехом и, по-моему, не могло пойти иначе: конкуренция между браузерами все еще сильна.
Небольшой элемент случайности еще был связан с одновременным развитием мобильного рынка, что подлило масла в огонь, но имхо погоды это не сделало.
Итак, JS везде и не содержит изъянов, делающих его использование невозможным. Чего ждать? Того, что мы сейчас имеем. Пока веб-платформа не упрется в свои фатальные недостатки, она будет расти в сторону еще большего распространения, улучшения скорости работы и развития инструментов разработки. В принципе, после анонса WASM у меня не хватает фантазии, что еще может выйти определяющего.
Разве что расширение набора инструкций ARM для более эффективной работы виртуальной машины JS, но сначала надо стандартизировать их как следует.
Так что, думаю, популярность растет просто потому что до сих пор не уперлась в потолок, но не просто так, а потому что JS-интерпретатор — самый распространенный на планете интерпретатор/компилятор.