В плане демострации каких-то математических абстракций может быть действительно это оптимальный подход. Но когда речь идет о таких обыденных вещах, как работа с xml и json, лично мне было бы приятнее работать с библиотекой, по коду которой я без проблем могу сказать, что она делает, не тратя часы на то самое разматывание кода. Ну и опять же, в хаскеле подобный код читается легче из-за большей заточенности языка под функциональный подход и там можно разбираться даже в текстовом редакторе, что как бы говорит о том, что одни и те же вещи можно реализовать с разной красотой и аккуратностью.
Здесь конечно слишком мало кода, чтобы можно было оценить возможную обфусцированность. Гораздо интереснее в этом смысле читается код самой Scalaz.
вот это я вообще каждый раз удивляюсь как встречаю, что IDE отменили? вроде уже даже Eclipse умеет переходить в имплиситы и подчёркивать их
В том то и дело, что для того, чтобы понять, что же происходит, надо по каждому методу тыкать ctrl+click и смотреть куда в итоге попадешь, а имплиситы могут быть и многоуровневыми (особенно во всяких Scalaz). В то время как обычный код можно просто читать. Из-за этого разница в скорости понимания происходящего будет в разы.
Получилось конечно кратко, но на мой взгляд проблема подобного кода в том, что без соответствующей статьи с пояснениями его поддерживать невозможно. Такое лучше писать на хаскеле хотя бы потому, что там подобный код будет более читаемым и понятным, а на скале с кучей имплиситов можно потом очень долго пытаться понять какие преобразования и откуда применились в этой функции на пять строк. Кроме того, описанная тут задача решается даже на яве без необходимости написания сотен строк копипасты. В общем применение подобного подхода в целом и Scalaz в частности кажется здесь весьма надуманным и сильно усложнит жизнь тем, кому с этим потом придется работать.
Мне кажется не важно заказ это или нет в данном случае (хотя не могу придумать кому это нужно), т.к. все аргументы легко проверить самостоятельно. А если видите здесь какую-то неправоту автора, то можете опровергать фактами, если найдете такие.
Я так понимаю, что кастомный билд JDK пришлось делать потому, что ваши исправления не удавалось пропихнуть в OpenJDK. А с чем было связано нежелание принимать ваши исправления, когда речь идет об исправлении их же косяков, чем это аргументировалось? Я просто не в курсе ситуации и мне интересно.
А откуда вообще пошла эта дичь, что Солнце не вращается вокруг Земли, причем без всяких уточнений относительно системы координат? Не первый раз уже вижу это высказывание. А реальные исследования как раз-таки и показывают, что оно вращается, если система координат связана с Землей. А как известно, все движение у нас во вселенной относительное и без указания системы координат о нем вообще говорить бессмысленно.
Вот это пояснение расставило всё по местам. Благодарю.
Я сначала думал, что часть вывода идет из строки
(display (*env* #t)) и это меня сбило с толку. Теперь же понятно, что весь вывод только из (display test-func), а все после (*env* #t) никогда не будет выполнено.
Я сейчас понял, что слишком слабо понимаю принцип работы интерпретатора lisp, а без этого дальнейшее объяснение мало чем поможет. В общем спасибо за пояснения.
Немного поясню, как я вижу процесс выполнения.
В вызове (display (*env* #t))
(*env* #t) выполняется и заменяется на результат своего выполнения, т.е. «true». Таким образом мы получаем выражение (display «true»). Здесь нет никакого цикла, выражение просто печатает текст на экран и завершается.
Все понятно и логично до момента «будет подставлено #t и поэтому в конце-концов будет распечатано „true“».
А дальше тот же логический переход, что и на схеме «А потом снова будет (*env* #t)…».
Но откуда там второй вызов (*env* #t)? В коде его нет.
Не могли бы вы более подробно пояснить, откуда в первом примере (с тремя схемами) взялся цикл. На второй схеме четко видно, что его нет, а на 3-ей, где мы просто подставляем значения он появляется. Этот логический переход я не осилил. А т.к. лисп я особо не знаю, то пытаюсь понять смысл по схемам и внешнему виду кода, что не совсем эффективно.
Ну смотрите, он же предал государство (т.е. организацию со своими интересами к обогащению и удержанию власти), которое его теперь ругает. Но сделал он это для защиты прав таких же людей, как и он сам, свободу которых это государство ущемляет. И эти люди, которые не продавали свободу ради безопасности (или которых вынудили это сделать без их явного согласия), как раз таки его хвалят. Просто в данном случае их оказалось достаточно много, чтобы иногда казалось, что его прямо таки все вокруг хвалят, хотя противников на самом деле хватает.
Хотел у вас спросить, несколько отклоняясь от основной линии дискуссии. Я уже не первый раз вижу негативное отношение к перегруженным методам с scala-сообществе. И, если я правильно понимаю, вы разделяете это мнение. Но я никак не могу понять, чем можно было бы их заменить, и в чем конкретно проблемы с ними связанные, кроме более сложного рефлекшена. Просто, только лишь усложнение рефлекшна мне кажется гораздо менее важным, чем наличие перегрузок, т.к. рефлекшн, по большому счету некий костыль, которым пытаются компенсировать негибкость языка и его использование в любом случае должно быть минимальным.
Вообще я читал в обсуждении сроков 2.13, что на эту версию не меньше двух лет планируют потратить. Поэтому даже альфа в этом году выглядит сомнительно. Но если я правильно понимаю, то те улучшения, которые тренируют на dotty будут вносить в scala уже в версии после 2.13 (2.14 или 3.0). Поэтому вот и кажется мне, что всё самое интересное будет ещё не скоро.
На мой взгляд проблема в том, что сейчас существует много аккаунтов, отстаивающих интересы определенных корпораций. Например раньше можно было спокойно обсуждать косяки каких-нибудь корпоративных продуктов, типа windows / ie и пр., т.к. сообщество в основном состояло из независимых пользователей. А теперь попробуй сказать что-то хотя бы отдаленно негативное про яндекс, или особо яркий пример go. Ты будешь слит раньше, чем кто-то некорпоративный прочитает статью/комментарий. И даже после этого обычные пользователи не пойдут плюсовать слитую карму. В то же время попробуйте слить кого-то, кто активно отстаивает интересы хорошо представленной здесь корпорации. Не хочу приводить конкретные примеры, многие и сами вспомнят подобные случаи, когда это похоже на использование тем пользователем читов типа «godmode on». В итоге независимые пользователи теряют мотивацию общаться где-то кроме своих тем или узкого круга особо интересующих разделов и уж тем более открыто высказывать мнение по широкому кругу вопросов, даже если они в них компетентны.
зы: тем не менее, это всё равно лучше чем то, что сейчас творится на гиктаймсе и пр., т.к. там теперь просто невозможно читать комментарии и уж тем более нет смысла общаться с какими-то полуботами.
Согласен с тем, что сравнение двух языков — это скорее для отдельной статьи. Но мы здесь это обсуждаем потому, что не обсуждать же REST-сервис? Понятно для чего статья была написана. К сожалению полноценно поспорить с вами не могу, т.к. kotlin не знаю и именно по этому считаю статью с честным сравнением и примерами кода наиболее интересным вариантом знакомства с языком. Однако попробую написать по поводу известных вещей.
— По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
По идее инкрементальная компиляция может работать параллельно с написанием кода, сводя до минимума ожидание. Но даже если она отрабатывает по всем изменениям, то это обычно значительно меньше целого проекта. Т.к. она даже не будет целые файлы перекомпилировать.
На счет работы с null. В scala достаточно удобно использовать Option, особенно в сочетании с for, хотя это не 100% защита от null. Однако не так давно было обсуждение, а не ввести ли в scala аналогичные nullable типы, так что возможно скоро здесь не будет различий.
— отсутствие implicit
Не сказал бы что это прямо плюс. Считаю, что при аккуратном использовании implicit дает больше преимуществ, чем недостатков.
— лучшее взаимодействие с java
Это палка о двух концах. Если в kotlin такая хорошая интероперабильность с java, то значит, что ряд косяков за java перенесся в kotlin. Кроме того, если где-то надо предоставить какое-то очень навороченно api из scala, то можно и несколько оберток написать, как например play делает. Но этот сценарий встречается гораздо реже, чем наоборот. А наоборот почти никаких проблем нет, а с выходом 2.12 будет ещё меньше.
— отличная поддержка от студии
Это не плюс kotlin'а, это — минус jetbrains'у )
— готовые решения для работы в jvm, android, трансляции в js
Для js в scala точно есть решение — scalajs. На счет android не знаю. Возможно здесь действительно есть объектичное преимущество kotlin.
— стабильная обратная совместимость
В scala совместимость на уровне исходных кодов до версии 3. Но сейчас идет активная работа над тем, чтобы компилировать исходники в ast-деревья и распространять пакеты с ними, а не с class-файлами. Тогда не будет зависимости от версии.
Скажем так, при множестве функций вариант из scala в итоге станет короче, это то что объективно можно померить. Но по большому счету синтаксис здесь скорее дело вкуса. Однако надо учитывать, что в scala это не просто функция, а класс, в котором могут быть в приватные методы и даже переменные, хотя это уже отдельный случай, т.к. будет производится выделение памяти.
В том то и дело, что для того, чтобы понять, что же происходит, надо по каждому методу тыкать ctrl+click и смотреть куда в итоге попадешь, а имплиситы могут быть и многоуровневыми (особенно во всяких Scalaz). В то время как обычный код можно просто читать. Из-за этого разница в скорости понимания происходящего будет в разы.
Я сначала думал, что часть вывода идет из строки
(display (*env* #t)) и это меня сбило с толку. Теперь же понятно, что весь вывод только из (display test-func), а все после (*env* #t) никогда не будет выполнено.
В вызове (display (*env* #t))
(*env* #t) выполняется и заменяется на результат своего выполнения, т.е. «true». Таким образом мы получаем выражение (display «true»). Здесь нет никакого цикла, выражение просто печатает текст на экран и завершается.
А дальше тот же логический переход, что и на схеме «А потом снова будет (*env* #t)…».
Но откуда там второй вызов (*env* #t)? В коде его нет.
зы: тем не менее, это всё равно лучше чем то, что сейчас творится на гиктаймсе и пр., т.к. там теперь просто невозможно читать комментарии и уж тем более нет смысла общаться с какими-то полуботами.
— По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
По идее инкрементальная компиляция может работать параллельно с написанием кода, сводя до минимума ожидание. Но даже если она отрабатывает по всем изменениям, то это обычно значительно меньше целого проекта. Т.к. она даже не будет целые файлы перекомпилировать.
На счет работы с null. В scala достаточно удобно использовать Option, особенно в сочетании с for, хотя это не 100% защита от null. Однако не так давно было обсуждение, а не ввести ли в scala аналогичные nullable типы, так что возможно скоро здесь не будет различий.
— отсутствие implicit
Не сказал бы что это прямо плюс. Считаю, что при аккуратном использовании implicit дает больше преимуществ, чем недостатков.
— лучшее взаимодействие с java
Это палка о двух концах. Если в kotlin такая хорошая интероперабильность с java, то значит, что ряд косяков за java перенесся в kotlin. Кроме того, если где-то надо предоставить какое-то очень навороченно api из scala, то можно и несколько оберток написать, как например play делает. Но этот сценарий встречается гораздо реже, чем наоборот. А наоборот почти никаких проблем нет, а с выходом 2.12 будет ещё меньше.
— отличная поддержка от студии
Это не плюс kotlin'а, это — минус jetbrains'у )
— готовые решения для работы в jvm, android, трансляции в js
Для js в scala точно есть решение — scalajs. На счет android не знаю. Возможно здесь действительно есть объектичное преимущество kotlin.
— стабильная обратная совместимость
В scala совместимость на уровне исходных кодов до версии 3. Но сейчас идет активная работа над тем, чтобы компилировать исходники в ast-деревья и распространять пакеты с ними, а не с class-файлами. Тогда не будет зависимости от версии.