Как стать автором
Обновить
9
0

Scala developer

Угу. В итоге оказалось лучше искать по списку интересующие jep и читать доку.
JEP 361. Switch-лямбды

Это не лямбды. С чего такая вольность в переложении?!

В своё время в Java 9 появился JShell, очень похожий на питоний Jupiter.

Похож примерно никак. Это калька с реплов, а не семейства ноутбуков.

У котлина вроде фанатиков за глаза, куда больше.
Показал боссу непрограммисту — он всё равно выбрал как предпочтительный вариант на D.
Ради уточнения. Вы понимаете смысл этого кода и считаете что он плохо выглядит или не понимаете и поэтому считаете что он плохо выглядит?
От скалы тут тоже далеко не главное открыли.
1. Вот уж параллельные коллекции использовать не надо. Их выпилят в 2.13.
2. Сравнение с танком странное. Если использовать как better-java, то разницы не особо — синтаксис и еще одно стдлиб. Если использовать фп, ну это как раз для бизнес-приложений отлично. Гарантий больше, тестов меньше.
Ничего из этого не требует теорката для использования (про трансформеры вообще странное упоминание). Это выводилось с помощью теорката и можно так понять базис и более глубокую интуицую получить, но это по желанию. И теоркат это сложно. То что большинство в лучшем случае почитали/посмотрели Бартоша не делает их знающими теоркат.
2 вывода по статье.
* Автор явно не Фейнман. На кого рассчитана статья не понятно.
* Отличный пример, что использовать монады можно понимая ничего в теоркате, а значит и углубляться в него нужно только если действительно хочется.
Не нашел монад в коде %)
Самое простое решение — тупо не использовать эти методы
По названию статьи я подумал, что самое простое — это читать доку =( (шуточное)

заметьте, тут на поверхностный взгляд все «иммутабельно»
AtomicInteger, иммутабельно… Для того чтоб оно было иммутабельным, надо вместо чистого Атомика изобразить какой-то эффект с сохранением прозрачности. Аля Ref или MVar из котов/моникса.

Имхо, проблем две. Согласен, что модель вычисления должна быть одна для двух методов. Только в текущем Map (и его дефолтной реализации) map должен стать ленивым. И тут вторая проблема, что есть имплементации, которые строгие, а разделения на уровне типов нет.

К вашему удовольствию принято решение в 2.13 задепрекейтить mapValue (очень пикантно, для тех кто включает опцию "-deprecation"), а в будущем сделать строгой. Т.е. исправят лишь одну проблему.
То сами специально искали доклады по скалке на конфу, то сами же их и вырезали из итогов. Странная организация.
Это такой способ написать GADT? Ну там как бы этим все не ограничивается.
Т.е. авторитет разработчиков языка не остановил вас от разбирательства в деталях, а авторитет человека неизвестного останавливает.

Я предлагаю вам задуматься над этим «так принято» и переосмыслить критически. Посмотреть в каких случаях что куда приводит, в том числе с учетом вариативности, в том числе с учетом лямбд.

Пока что выглядит как призыв к анемичности (если я корректно интерпретировал «минимальность»).
минимально возможный
Как определен «минимальный»?

ну если IDE догадывается, то и компилятор тоже вполне мог бы
Зачем вообще в типе подменять на интерфейс?
Так мой коммент и не про язык, а про статью как раз.
предложили идеально сработанный язык

По доллару бы за каждый идеал. По два за идеал от рождения.

Это не сборная солянка из идей, а по-настоящему грамотно сделанный язык. В нем собран минимальный набор самых мощных фич, которые в сумме дают вам потрясающие возможности.

Солянка и есть набор из разных мяс.

В общем опять оценка преисполненная поверхностных суждений с базой на эмоциональном восприятии.
Не бывает идеальных языков. Всегда очень много нюансов, когда приходится жертвовать одним против другого. В одних ситуациях это плюс, в других минус. [mode=troll] Даже разработчики go отказались от слова «идеальный» и стали слушать (ну как смогли) фидбэк пользователей. [/mode]
Массивы в скалке реализованы никак. Юзается джавовый класс. Есть только свой имплиситный класс (читай враппер), дополняющий функциональность.
Может лучше с кассандры? У неё язык запросов близок к sql.
На синтетическом примере с wordcount — здесь негде развернуться.
В этом и основной мой посыл был. Пример показывает ровным счетом ничего, но выводов сделано прям как при сравнении тысячи строк.

println! и иже с ним всякие write!, format! в Rust доступны программисту без дополнительных телодвижений (если он не делает странного), в Java аналогичные вещи нужно либо импортировать
Т.е. притащить либу это ни о чем, а импорт целая катастрофа. Это я ёрничаю над объективностью оценки, на самом деле мне лично пофиг и на то и на то (ну кроме идиотского формата в принтлне с перечислением аргументов, вместо использования плейсхолдеров). В плане ио гораздо больше имеет значение работа с файлами. doc.rust-lang.org/1.22.1/std/fs/struct.File.html и что-то я опять не вижу особых различий по примеру, телодвижения ровно такие же как в любом другом языке. Можно рыть глубже и смотреть работу с буфферами для записи/чтения. Зато здесь есть куда более интересный момент с тем, что возвращаемые значения врапнуты (Result), что есть уже далеко не везде. Почему не сравнить это? Вполне практическая вещь, показывающая плюсы (можно спорить насколько жирный плюс, но уж не минус точно).

Про коммуникацию не буду обсуждать, у вас своя волна каких-то теплых человеческих чувств к машине.

Вы напали на бредовый вброс про многословность раста, но сами при этом ответили не особо более качественно.

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность