1. Вот уж параллельные коллекции использовать не надо. Их выпилят в 2.13.
2. Сравнение с танком странное. Если использовать как better-java, то разницы не особо — синтаксис и еще одно стдлиб. Если использовать фп, ну это как раз для бизнес-приложений отлично. Гарантий больше, тестов меньше.
Ничего из этого не требует теорката для использования (про трансформеры вообще странное упоминание). Это выводилось с помощью теорката и можно так понять базис и более глубокую интуицую получить, но это по желанию. И теоркат это сложно. То что большинство в лучшем случае почитали/посмотрели Бартоша не делает их знающими теоркат.
2 вывода по статье.
* Автор явно не Фейнман. На кого рассчитана статья не понятно.
* Отличный пример, что использовать монады можно понимая ничего в теоркате, а значит и углубляться в него нужно только если действительно хочется.
Самое простое решение — тупо не использовать эти методы
По названию статьи я подумал, что самое простое — это читать доку =( (шуточное)
заметьте, тут на поверхностный взгляд все «иммутабельно»
AtomicInteger, иммутабельно… Для того чтоб оно было иммутабельным, надо вместо чистого Атомика изобразить какой-то эффект с сохранением прозрачности. Аля Ref или MVar из котов/моникса.
Имхо, проблем две. Согласен, что модель вычисления должна быть одна для двух методов. Только в текущем Map (и его дефолтной реализации) map должен стать ленивым. И тут вторая проблема, что есть имплементации, которые строгие, а разделения на уровне типов нет.
К вашему удовольствию принято решение в 2.13 задепрекейтить mapValue (очень пикантно, для тех кто включает опцию "-deprecation"), а в будущем сделать строгой. Т.е. исправят лишь одну проблему.
Т.е. авторитет разработчиков языка не остановил вас от разбирательства в деталях, а авторитет человека неизвестного останавливает.
Я предлагаю вам задуматься над этим «так принято» и переосмыслить критически. Посмотреть в каких случаях что куда приводит, в том числе с учетом вариативности, в том числе с учетом лямбд.
Пока что выглядит как призыв к анемичности (если я корректно интерпретировал «минимальность»).
По доллару бы за каждый идеал. По два за идеал от рождения.
Это не сборная солянка из идей, а по-настоящему грамотно сделанный язык. В нем собран минимальный набор самых мощных фич, которые в сумме дают вам потрясающие возможности.
Солянка и есть набор из разных мяс.
В общем опять оценка преисполненная поверхностных суждений с базой на эмоциональном восприятии.
Не бывает идеальных языков. Всегда очень много нюансов, когда приходится жертвовать одним против другого. В одних ситуациях это плюс, в других минус. [mode=troll] Даже разработчики go отказались от слова «идеальный» и стали слушать (ну как смогли) фидбэк пользователей. [/mode]
На синтетическом примере с wordcount — здесь негде развернуться.
В этом и основной мой посыл был. Пример показывает ровным счетом ничего, но выводов сделано прям как при сравнении тысячи строк.
println! и иже с ним всякие write!, format! в Rust доступны программисту без дополнительных телодвижений (если он не делает странного), в Java аналогичные вещи нужно либо импортировать
Т.е. притащить либу это ни о чем, а импорт целая катастрофа. Это я ёрничаю над объективностью оценки, на самом деле мне лично пофиг и на то и на то (ну кроме идиотского формата в принтлне с перечислением аргументов, вместо использования плейсхолдеров). В плане ио гораздо больше имеет значение работа с файлами. doc.rust-lang.org/1.22.1/std/fs/struct.File.html и что-то я опять не вижу особых различий по примеру, телодвижения ровно такие же как в любом другом языке. Можно рыть глубже и смотреть работу с буфферами для записи/чтения. Зато здесь есть куда более интересный момент с тем, что возвращаемые значения врапнуты (Result), что есть уже далеко не везде. Почему не сравнить это? Вполне практическая вещь, показывающая плюсы (можно спорить насколько жирный плюс, но уж не минус точно).
Про коммуникацию не буду обсуждать, у вас своя волна каких-то теплых человеческих чувств к машине.
Вы напали на бредовый вброс про многословность раста, но сами при этом ответили не особо более качественно.
Это не лямбды. С чего такая вольность в переложении?!
Похож примерно никак. Это калька с реплов, а не семейства ноутбуков.
2. Сравнение с танком странное. Если использовать как better-java, то разницы не особо — синтаксис и еще одно стдлиб. Если использовать фп, ну это как раз для бизнес-приложений отлично. Гарантий больше, тестов меньше.
* Автор явно не Фейнман. На кого рассчитана статья не понятно.
* Отличный пример, что использовать монады можно понимая ничего в теоркате, а значит и углубляться в него нужно только если действительно хочется.
AtomicInteger, иммутабельно… Для того чтоб оно было иммутабельным, надо вместо чистого Атомика изобразить какой-то эффект с сохранением прозрачности. Аля Ref или MVar из котов/моникса.
Имхо, проблем две. Согласен, что модель вычисления должна быть одна для двух методов. Только в текущем Map (и его дефолтной реализации) map должен стать ленивым. И тут вторая проблема, что есть имплементации, которые строгие, а разделения на уровне типов нет.
К вашему удовольствию принято решение в 2.13 задепрекейтить mapValue (очень пикантно, для тех кто включает опцию "-deprecation"), а в будущем сделать строгой. Т.е. исправят лишь одну проблему.
Я предлагаю вам задуматься над этим «так принято» и переосмыслить критически. Посмотреть в каких случаях что куда приводит, в том числе с учетом вариативности, в том числе с учетом лямбд.
Пока что выглядит как призыв к анемичности (если я корректно интерпретировал «минимальность»).
Зачем вообще в типе подменять на интерфейс?
По доллару бы за каждый идеал. По два за идеал от рождения.
Солянка и есть набор из разных мяс.
В общем опять оценка преисполненная поверхностных суждений с базой на эмоциональном восприятии.
Не бывает идеальных языков. Всегда очень много нюансов, когда приходится жертвовать одним против другого. В одних ситуациях это плюс, в других минус. [mode=troll] Даже разработчики go отказались от слова «идеальный» и стали слушать (ну как смогли) фидбэк пользователей. [/mode]
Т.е. притащить либу это ни о чем, а импорт целая катастрофа. Это я ёрничаю над объективностью оценки, на самом деле мне лично пофиг и на то и на то (ну кроме идиотского формата в принтлне с перечислением аргументов, вместо использования плейсхолдеров). В плане ио гораздо больше имеет значение работа с файлами. doc.rust-lang.org/1.22.1/std/fs/struct.File.html и что-то я опять не вижу особых различий по примеру, телодвижения ровно такие же как в любом другом языке. Можно рыть глубже и смотреть работу с буфферами для записи/чтения. Зато здесь есть куда более интересный момент с тем, что возвращаемые значения врапнуты (Result), что есть уже далеко не везде. Почему не сравнить это? Вполне практическая вещь, показывающая плюсы (можно спорить насколько жирный плюс, но уж не минус точно).
Про коммуникацию не буду обсуждать, у вас своя волна каких-то теплых человеческих чувств к машине.
Вы напали на бредовый вброс про многословность раста, но сами при этом ответили не особо более качественно.