Нет, сайд эффект как раз в выбросе исключения.

Есть вот такой пример, в языке Scala есть монада Try.
Суть в том, что на самом деле Try технически не является монадой, т.к. нарушается первый закон
f(x) == unit(x).bind(f).
(где unit(x) — это конечно Success(x)).

Допустим f(x) = x / 0.
Получается
x / 0 == Success(x).bind(_ / 0)
Разворачиваем правую сторону.
x / 0 == try { Success(x / 0) } catch (e) { Failure(e) }

Очевидно что левая и правая стороны не равны, так как в правой стороне мы получим Failure(DivByZero), а в левой стороне мы НЕ получим результата, но при этом будет выброшено исключение.

Так если исключения менее «функциональны», то зачем их вставлять в язык? Лучше уж переиспользовать существующие механизмы, особенно если они лучше ложатся на функциональный подход.

Думаю что это получилось сразу по нескольким причин:
Во-первых, из-за совместимостью с obj-c,
И во-вторых, из-за того что Swift взял курс на функциональщину по сравнению с obj-c.
Дело в том, насколько я знаю, исключения (такие как в C++ и Java) не очень дружат с функциональщиной, так как выброс исключения это по сути side-effect.

То что у убера есть столько пермишеннов, кстати, ни о чем не говорит.

У Убер есть возможность добавления карточки с помощью фото, для этого и нужен permission для доступа к камере. Доступ к телефонным звонкам нужен для того, что-бы по нажатию кнопки «Связаться с водителем» сразу начать набор номера (Спорное решение, конечно).
Доступ к локации нужен для работы с картой. Доступ к аккаунтам нужен из-за интеграции с Google+ в приложении. Доступ к Wi-Fi оборудованию нужен скорее из-за трекинга устройства — такое обычно нужно для предотвращения регистрации кучи виртуалов с одного устройства.
Доступ к контактам нужен для приглашения друзей из контактной книги.
Это Вам не iOS. Вы либо устанавливаете приложение и даете все пермишены либо не устанавливаете приложение. Простой пользователь скорее всего воспользуется мантрой next-next-next, а продвинутый юзер будет использовать всякие тулзы, вроде того же XPrivacy.

Поймали меня за слово: )
Эта статья что вы привели слишком поверхностная. Там написано что, производительность может быть улучшена из-за выравнивания (flatten) иерархии и как предложение использовать RelativeLayout. Но это далеко не всегда так, из-за того, что RelativeLayout меряет (measure) своих детей в несколько проходов, применяя различные ограничения.

Понятное дело, что нужно сначала мерить, убедиться что есть проблема и затем уже оптимизировать.

Подождите, сейчас то уже поздно — 5.0 ушел в прод. Было бы здорово если они это исправили во время L Developer Preview.

Это все справедливо, как Вы говорите. Но проблема в том, что Google с Вами не согласен и первым начинает вводить свой Material и говорить что это хорошо. Когда эти «остальные приложения» — это вся линейка Google апп, то с этим уже труднее спорить, не так ли?

Я так полагаю Озик хотел сказать что RelativeLayout штука коварная и можете наткнуться на проблемы с производительностью с ней. Как говорится: лучше уж пару вложенных LinearLayout, чем один RelativeLayout.

Я не согласен с Марком в этом плане.
Стоит хотя бы учесть то, что большинство трендмейкеров, таких как Google, Facebook и иже с ними уже переходят на Material во все поля. Таким образом на андроиде вы практически всегда будете инконсистенты с экосистемой, вопрос с какой стороны.
Так же, стоит учесть AppCompat, которая по умолчанию подкрашивает вашу аппу в Material.

Мне кажется Марк своим мнением просто разделил людей на два лагеря.

Мне показалось не очень удобной подсветка выделенной табы. С другой стороны, заливка цветом страницы выглядит неплохо.

А как Вы реализовали suppress layout? Насколько я знаю подобного поведения достичь сложно, а при его отсутствии при анимации изменения размеров будет вызываться layout, что в свою очередь убьет плавность анимаций.

Главное потом скомпилировать и запустить из тетрадки.

Нет поддержки других языков. Для некоторых языков, есть собственный аналоги GWT, например, Scala.js и нативная поддержка в Kotlin. Однако, у них есть другой недостаток: невозможность взаимодействия с существующими Java-библиотеками.

А при использовании серьезных Java библиотек не возникнет ли проблем с быстродействием?

А это уже кармадр-во. На хабре запрещено.

На телефонах хранятся графические пароли.

Я может чего-то не понимаю, но нельзя ли в таком порядке принять правки насчет (не)выезда граждан?

Я так понял, Drawable не рисуется поверх View, а классическим образом устанавливается в качестве background.
Если хочется рисовать Drawable именно поверх View, то вам понадобится ViewOverlay, который, увы, с API 18.

Эффект на Android L реализован с помощью (примерно) такого же Drawable.
Соответственно, проверка должна быть раньше — при установке этого Drawable.

Где подписаться?

Вспомнил замечательное слово — намазывать.
Намазать дизайн из макетов на приложение. Намазать патч.

Сведение и игра на электрогитаре на видео немного прихрамывает.