Pull to refresh

Comments 24

Хотелось бы еще добавить, что использовать лямбды можно не только в Java 8 благодаря проекту RetroLambda — github.com/orfjackal/retrolambda
Точнее, компилятор нужен будет все равно из JDK8, однако для запуска сгодится любая другая JRE вплоть до Java 5. Особенно это должно помочь разработчикам под андроид.
Я подключал проект retrolambda по вот этой вот инструкции. Подключается легко, работает, но мне показалось этого мало, и решил попробовать написать что-нибудь простенькое на Scala. :) Пока что нахожусь на стадии работающего hello-world'a.
P.S. Да, вот ссылка на плагин для gradle, который сильно упрощает работу со Scala в Android. Проект не мой, благодарности автору.
А я вот gradle терпеть не могу, поэтому описывал когда-то как с обычным ant то же самое сделать — zserge.com/blog/android-lambda.html
От лямбд, конечно, сплошной восторг. А Scala пробовал, но уж больно она медленная, повременю пока с ней.
А я вот gradle терпеть не могу

Если не секрет, почему так?
Я бы сказал, что Gradle является прекрасным до тех пор, пока не начнёшь его использовать и не поймёшь, что сборка проекта, занимающая в Ant'е 2 секунды, может занять в Gradle (в основном, конечно, всякие инициализации) до 30 секунд.
Именно! Скорость, скорость. Даже gradle в режиме демона и параллельное выполнение не спасают. Ant все равно быстрее, а когда на каждое изменние кода ждешь по 30-60 секунд чтобы увидеть результат — о комфортной работе и говоритть нечего.
Реально?
На моём стареньком G2020 с жестким 7200 оборотов, пересборка средненького проекта (10ток фрагментов, 60-70 классов) заняла 10.115 секунд. Вполне приемлимо я считаю. При желании можно апнуть проц и рам диск настроить и вообще летать будет.
ну так это же типичный java подход — если программа работает медленно — добавьте рамы и проца
Как будто что-то плохое.
[sarcasm]Нет, что вы. Всем должно хватать 640кб памяти.[\sarcasm]
крупнейшего обновления в модели программирования, когда-либо бывшего в Java, — большего, чем даже дженерики

Ну уж ладно… все-таки до дженериков совсем тухло было. Хотя я это время уже не застал.
Используйте массив длиной 1


Не используйте массив длиной 1. Для таких случаев существует потокобезопасный AtomicInteger, который можно и изменять и декрементировать атомарно.
Иногда такое невозможно, в силу ограничения платформы. Например GWT
выигрышная стратегия – смешивать объектно-ориентированное программирование и функциональное


Эрик Мейер на эту тему написал статью месяц назад: «Mostly functional» programming does not work.
Вообще нативные ламбды — это плюс. Через пару лет даже научаться их пользовать. К генерикам, вон, тоже привыкали. Интересно вот, какие грабли будут найдены :)

Ну и чуть критики про java 8. Самое забавное — это про то как лямбды живут с примитивами:
java.dzone.com/articles/whats-wrong-java-8-part-ii

«В этой статье были описаны лямбда-выражения в качестве единого крупнейшего обновления в модели программирования, когда-либо бывшего в Java, — большего, чем даже дженерики.»
Вы сильно переоцениваете лямбды. Лямбды используются для сокращения записи анонимных классов при передаче. И все. Они никак не могут быть лучше, чем коллекции или дженерики. Если бы их и не ввели, то мы бы особо ничего и не потеряли бы.
Дженерики — это всего-навсего способ избавиться от некоторого количества явных приведений типа (see type erasure), так что они вполне сравнимы по своему эффекту с лямбдами. А вот как раз коллекции — большое дело, без них как бы вообще очень тяжело программировать,
Дженерики делают код более безопасным.
Только опосредованно: они позволяют компилятору проверить некоторые локальные инварианты, не более того.
это type safety и далеко не «всего-навсего»
Нет там никакой type safety. Вам легко может придти какой-нибудь List<String> в котором будет лежать совсем-совсем не String.
Только если вы или пользователь вашего API явно привел List<Нечто> к List<String>, ССЗБ.

Дженерики позволяют писать более выразительные API с информацией о типах.
Sign up to leave a comment.

Articles