По глобальным переменным могу уточнить. Само понятие глобальности относительно. Например переменная, объявленная внутри функции (я сейчас говорю не про функцию из ФП, а про обычную функцию из императивного ЯП), является локальной для этой функции, т.к. существует только в момент вызова этой функции. И при следующем вызове будет создана новая такая же переменная. Но это будет уже другой ее экземпляр. Однако, если мы внутри функции объявим еще одну, вложенную функцию, то эта же самая переменная, для вложенной функции будет уже глобальной. То же самое с полями объекта. Они существуют все время существования объекта, и являются глобальными для его методов. Единственное, что тут спасает, это, что их область видимости обычно ограничена одним объектом. И между методами объекта существует обязательство, сохранять данные в полях в непротиворечивом состоянии, и учитывать особенности работы остальных методов данного объекта. Это делает объект сильно связной сущностью. В общем-то для того и понадобилось объединить данные и методы в одну сущность, чтобы хоть как-то локализовать взаимную зависимость методов и данных. То есть ООП это компромисс. У объектов есть состояние, но мы работаем с нм максимально аккуратно. Ну это в теории должно быть так. На деле все сильно зависит от компетентности программиста.
В принципе, можно дать некое определение глобальности. Объект «a» является глобальным по отношению к объекту «b», если объект «b» имеет доступ к объекту «a», и при этом время жизни объекта «a» больше, чем время жизни объекта «b».
При этом, если глобальной является некая константа, то с ней проблем нет. Ее значение не меняется. Если же это переменная, и мы можем ее изменить (а как правило, изменить ее можем не только мы, но и чужая функция, что еще хуже), то выполнение нашей функции становится непредсказуемым. Два раза подряд вызвав функцию с одними и теми же параметрами мы можем получить разные результаты. Это вообще противоречит определению функциональной зависимости. Математическая функция обязана для каждого аргумента «x», входящего в область допустимых значений, возвращать определенный, всегда один и тот же результат «y». Только тогда мы имеем право, написать, что y=f(x). То есть сказать, что «y» функционально зависит от «x». Соответственно, чтобы не было противоречий с математикой, мы вынуждены считать, что все глобальные переменные, от которых зависит функция, так же являются ее параметрами. Проблема в том, что эти параметры, во-первых являются неявными, а во-вторых, если несколько функций обращаются к одной и той же глобальной переменной, и хотя бы кто-то в нее пишет, они начинают неявно влиять друг на друга. Возникают побочные эффекты. Такой код крайне сложно поддерживать и масштабировать. А если код еще и может выполняться асинхронно и параллельно, то это вообще ад.
И еще, следует понимать, что под «отсутствием состояния» в ФП подразумевается отсутствие состояния на уровне функции. На уровне же всей программы, всего алгоритма, естественно мы меняем некое состояние. Просто мы передаем его из одной функции в другую с помощью параметров и возвращаемых значений, явно и только тогда, когда нам это нужно. При этом каждая отдельная функция состояния не имеет, и ничего о нашем состоянии не знает. Она универсальна.
Вы меня конечно извините, но распределенный DNS это такие же прятки. Типа, чтобы хулиган не разбивал лампочки в подъезде, большинство предлагает спрятать лампочки, вы предлагаете сделать их из бронированного стекла. Но проблема не в лампочках, и не в том, где они находятся. Проблема в хулигане. Хулиган понимает только силу, к сожалению. Что делать если силы, справиться с ним, не хватает? У меня была такая проблема в школе. Помог перевод в другую школу. Впрочем, последнее тоже можно считать прятками.
З.Ы. Я ни к чему не призываю, если что. Просто констатирую факт.
По сути состояние это неявный параметр функции. К примеру есть функция f(x), которая что-то делает, например умножает x на 5. f(x){return x*5;} У такой функции нет состояния. Т.к. параметр x передается явно, а число 5 никогда не меняется. Как результат f(7) всегда будет равно 35, сколько бы раз мы ее не вызывали.
Теперь изменим условия. Допустим f1 это метод объекта, и у объекта есть поле y. Пусть метод f1 представляет собой следующую операцию: f1(x) {buf = x; x = x * y; y = buf; return x;}. У этого метода есть состояние. Результат его выполнения зависит от предыдущего вызова. Предположим, изначально y равен нулю. Тогда первый вызов f1(7) вернет ноль. А второй вызов вернет 49. После этого f1(5) выдаст 35. А если повторить вызов, то результат будет уже 25. Зависимость довольно простая, но если не знать потрохов объекта, даже такой простой случай может показаться магией. Вы скажете, что две эти функции f и f1 — разные по своей сути? Но дело в том, что можно реализовать метод f1 избежав зависимости от состояния. Назовем такую функцию f2. Тогда f2(x,y){buf = x; x = x * y; return x, buf;}. Здесь мы получили и новое значение x и новое значение y. При желании можем использовать возвращенное значение y, для повторного вызова f2. Но теперь мы знаем что и откуда берется, т.к. явно это указываем. То есть речь тут скорее не об отсутствии состояния, а о явной его передаче от вызова к вызову. В то же время, мы всегда можем разорвать эту зависимость, вызвав функцию с другими параметрами. Разумеется, отсутствие состояния можно реализовать и в ООП. И в какой-то степени, к этому надо стремиться. Чем меньше состояний у объектов, тем универсальнее и гибче будет объект. Хотя, если дойти в этом до крайности, то объект превратиться просто в набор методов, а полей в нем не останется. Во всем нужна мера, как и всегда.
Из примеров выше видно, что состояние несет в себе те же риски, что и глобальные переменные. Потому что это, в общем-то, и есть глобальные переменные. Поля глобальны для методов объекта. А если поле еще и статическое, то оно глобально для всех объектов данного класса. Если оно при этом будет публичным, то вообще ничем от глобальной переменной отличаться не будет. Следовательно и методы борьбы с состоянием будут такие же, как с глобальными переменными: минимизировать область видимости на сколько это возможно, т.е. сделать глобальные данные локальными. Принимаемый функцией параметр — это как раз и есть локальные данные. Естественно, часть данных из реального мира будет где-то храниться глобально по отношению к программе. Но это не проблема. Просто функции будут принимать эти данные в качестве явных параметров.
Тоже в недоумении. Что автор хотел всем этим сказать? Сначала я подумал, что он говорит, что не нужно городить кучу абстракций и шаблонов, там где нужна максимальная производительность. Но в итоге у него получилось что-то вроде: «Не нужно использовать абстракции и шаблоны нигде, потому что кое-где нужна максимальная производительность». А потом он и вовсе ушел от темы. Началось с того, что не нужно использовать современный C++, а закончилось тем, что пора валить с плюсов, и вообще будущее за интернетом вещей и надо программировать микроконтроллеры. И вот тут я просто впал в ступор. Смешались в кучу люди, кони.
По теме, я всегда считал, что основная парадигма C++ это мультипарадигменность. Хочешь, используй шаблоны, хочешь — классы. А можно и то и другое одновременно. Можно написать в процедурном стиле, можно вообще в C-стиле. То есть C++ это, как бы, не один язык, а сразу много языков. И его основная сила, на мой взгляд, в том, что нет необходимости сочетать несколько языков, чтобы использовать в программе несколько парадигм. Разные парадигмы и стили программирования можно сочетать между собой нативно. При этом, не нужно задумываться о том, как использовать код, написанный на одном языке из другого языка. Можно написать часть программы, требующую максимальной производительности, в C-стиле, с указателями, битовыми операциями, и прочими прелестями. А остальную часть написать в ООП стиле. И все это будет одна программа, написанная на одном языке. Добавление функциональных элементов вполне вписывается в эту концепцию. Мультипарадигменность от этого еще больше увеличивается. Так что у меня нет ощущения, что язык свернул не туда. Он уверенно следует своему пути.
На этом пути, как и на любом другом, могут возникать сложности. Прежде всего, это делает сам язык сложным. Он сложен, как для людей, так и для компилятора. И люди так устроены, что им сложно переключаться с одного стиля мышления на другой. Сложно переключаться между разными парадигмами. Вот это и есть две основные проблемы: сложность самого языка, и непонимание, в каком случае какую парадигму использовать. В принципе это типичные проблемы любого универсального, многофункционального инструмента. Но это не делает инструмент плохим. Был бы он другим, проблемы просто были бы другими. Но они бы все равно были.
Насколько я понял из статьи (сам я никогда не использовал, ни Rails, ни Ruby, знаю только самые общие вещи о них, так что, все что я напишу ниже это выводы, сделанные исключительно из данной статьи), проблема в том, что большинство методов и компонентов Rails завязаны на некое глобальное состояние. Еще автор жалуется на засилье наследования. Все это, конечно же, приводит к слишком большой связности между сущностями. В результате это мешает использовать некоторые части Rails независимо. То есть, если используешь, то используешь все полностью. Как следствие, архитектура твоего приложения становится продолжением архитектуры Rails, которую автор считает крайне плохой. Если там действительно все на глобальном состоянии построено, то я с ним полностью соглашусь. Одна вот эта фраза чего стоит: «в Rails всё должно быть доступно везде, для вашего удобства.» — просто убило. Для маленьких проектов это может быть и удобно, но когда проект начнет расти, это будет боль. Ну и, поскольку Rails это главный фреймворк в мире Ruby, всем, кто пишет свои компоненты на Ruby, приходится делать их совместимыми с Rails. Плюс, помимо плохой архитектуры фреймворка, его основные разработчики еще и ведут себя довольно агрессивно, и всем пытаются доказать, что другая архитектура не нужна. Видимо, не хотят все переписывать. Вот это то, что я понял из статьи. В принципе краткое ее изложение получилось.
Как-то вся аргументация строится на утверждении: «Голландия — очень хорошая страна, у них ничего не может быть сделано плохо.»
По-моему это не очень правильная позиция. Я еще могу понять апелляцию к авторитету, когда речь идет об авторитетном человеке. Но страна? Страна это слишком комплексная сущность. В любой стране есть хорошие люди и плохие. Толковые и бестолковые. Умные и глупые. И, разумеется, проекты у этих людей, могут быть, как удачные, так и неудачные.
А в статье, тем временем, нет технических подробностей. Да и на сайте их нет. Вся информация в виде вопрос-ответ, причем содержание ответа крайне сухое. Практически да/нет. И еще какой-то кривой чертеж. Такое ощущение, что его кто-то от руки карандашиком накидал за 10 минут. То, что принимают только предварительные заказы, говорит вовсе не о высоком спросе, а лишь о том, что спрос пока превышает предложение. Примерно так: имеется два заказа, а готовых изделий — ноль. В результате дефицит стремится к бесконечности. Занимательная математика. На сайте написано, что они делают 12 домов в год. Но почему-то нет ни одной живой фотографии дома, или хотя бы сегмента. По факту, имеем только 3D рендер, и много красивых слов.
Мой вывод — просто очередной стартап с идеей, но без реализации. Первые заказчики возьмут на себя кучу дополнительных рисков, связанных с новой технологией, т.е. станут, фактически, инвесторами. Это не то, чтобы плохо, но в таких случаях как раз надо больше технической информации, чтобы хоть как-то оценить плюсы и минусы. А не так как тут, показали красивую картинку и просят 30 тысяч долларов.
Если родители этого ребенка окажутся неспособны сдать обычный тест на получение родительских прав, то ребенку, наверное, будет лучше без них. В таком случае его можно отдать приемным родителям, которые этот тест сдали, либо отдать в спецучреждение. Ну а что еще делать? Отдать ребенка людям, которые объективно не способны справиться с ним? Разумеется, говоря все это, я подразумеваю, что тест будет именно объективно, без перегибов, оценивать способности родителей к выполнению своих обязанностей. В противном случае, все это теряет смысл, т.к. вообще любую идею и любой закон, при желании, можно довести до состояния практической непригодности и исключительной вредности.
Чтобы повышение зарплат адекватно работало, нужно чтобы в компании были более менее фиксированные категории программистов. С определенными диапазонами зарплат. И если человек дорос из категории «junior», до категории «middle», то это надо оформлять официальным повышением в должности, с соответствующим повышением зарплаты. В итоге компания имеет нового «middle» разработчика, а на освободившееся место «junior», найти нового сотрудника всяко проще, чем нового «middle». Единственное существенное ограничение здесь, это ситуация, когда компании не нужен новый «middle». Но это, чаще всего, означает стагнацию в компании, и тут есть о чем задуматься. Для подросшего программиста это действительно повод уйти в другую компанию. А компания просто найдет себе нового «junior», раз их устраивает разработчик именно такого уровня. Это, кстати, возможность для бывшего «junior» самому побыть в роли наставника, подготовив себе замену, а потом уже уйти. Таким образом он и сам наберется дополнительного опыта, и заодно отдаст свой «долг» компании, которая помогла ему сделать первые шаги.
И еще, на мой взгляд, тут главное не искать себе «junior» разработчика только ради того, чтобы воспитать из него «middle»/«senior». Если вам нужен именно «middle»/«senior», то скорее всего он нужен вам прямо сейчас, а не через полтора-два года. Так что первое, что нужно сделать, прежде чем начать нанимать новичков — выстроить процесс разработки таким образом, чтобы появились задачи, которые можно доверить именно новичкам. Если в компании каждый разработчик ведет свой проект от и до, то нанять новичка будет пустой тратой времени и денег. Да и новичку будет тяжело. Все будут пытаться отбрыкаться от него. Будут те самые вздохи и закатывание глаз, как описано в статье.
Помню, один мой друг, когда учил ПДД, скидывал мне ссылку на сайт с тестированием. Я, не зная ни одного правила и ни одного билета не видя в глаза, отвечал верно на ~50% вопросов. Эксперимент повторял 4 раза. Все 4 раза результат был примерно 50%. Конечно, чтобы сдать на права надо набрать где-то 99%, но тем не менее, правила и знаки дорожного движения вполне логичны и интуитивны. Вообще, смысл не в том, чтобы можно было интуитивно до всего додуматься, а в том, чтобы не было противоречий, между интуицией и правилами. Например, было бы странно, если бы на знаке «STOP» надо было ускоряться. Запомнить было бы можно, но все равно это было бы странно.
Ну это понятно, что о внутренностях черной дыры ничего особо не известно. Оттуда и столько домыслов. Я просто поинтересовался с той точки зрения, что существует предположение, что внутри черной дыры другая вселенная. И непонятно, что в таком случае произойдет с этой вселенной, при гибели внешней вселенной. Обидно будет, если все «вложенные» вселенные погибнут вместе с родительской. В частности, гипотеза Ли Смолина о «размножении» вселенных, одна из самых интересных, что я слышал, как-то теряет смысл в этом случае. Какой толк в потомках, если они вместе с родителем погибают.
Кстати, чисто гипотетически, в случае тепловой смерти Вселенной, или ее расширения до невозможности существования стабильных атомов, что случится с черной дырой? Имеется в виду некая гипотетическая, ничем не примечательная черная дыра, каких во Вселенной много. То есть насколько судьба черной дыры зависит от состояния Вселенной, в которой эта дыра существует? И если черная дыра является внутренней Вселенной, не прекратит ли она свое существование вместе с внешней Вселенной, в которой она находится?
Но все же автопилот и круиз-контроль — не одно и то же. Автопилот выполняет больше функций и от него зависит намного больше, чем от обычного круиз-контроля. Так что, как минимум, сигнализация о его включении/отключении должна быть более явной. Да и о методах его отключения стоит задуматься отдельно, а не просто слепо копировать существующую схему с круиз-контролем. Вообще взаимодействие водителя и автопилота это отдельная очень сложная тема, требующая детальной проработки и стандартизации. Пожалуй даже человек должен проходить отдельный инструктаж и сдавать экзамен, чтобы получить право использовать автопилот в машине. Ведь, по сути, у одной машины получается два водителя. А в аварийной ситуации, некогда думать, кто и как должен управлять в данный момент. У человека должно быть до автоматизма отработано взаимодействие с автопилотом.
Кстати вполне логичный вариант. Мне вообще всегда казалось, что строить сферу Дайсона вокруг своей звезды это чревато экологической катастрофой в масштабе Солнечной системы. А вот построить ее вокруг соседней звезды, возможно и вовсе необитаемой, чтобы никому не вредить, и передавать себе требуемое количество энергии направленным пучком — это более разумный подход. Кстати еще есть одно предположение. Звезды ведь разного типа бывают. Возможно эффективность, или сложность/стоимость постройки сферы разная для разных типов звезд. Это был бы еще один аргумент, чтобы построить сферу вокруг другой звезды, а не своей.
Насколько я понимаю, там никакие новые API не нужны. Google Translate просто запускает демона, который постоянно отслеживает буфер обмена, и при изменении его содержимого, отображает свою кнопку поверх другого приложения. Результат так же отображается во всплывающем окне. Выше правда писали, что в Андроид 6+ это реализовано по другому, с помощью контекстной кнопки. Вот видимо там действительно используется какое-то новое API.
Прекрасно подойдет тем, кто в целом язык понимает, но словарный запас не очень хороший. Когда языка не знаешь совсем, переводить по словам очень тяжело.
К тому же, в силу интерфейса смартфонов, где частое переключение между приложениями это настоящая боль, такой подход — это то, чего я давно ждал. Теперь можно читать книгу на английском и на лету подсматривать незнакомые слова. Раньше люди даже специальные приложения писали для этого: habrahabr.ru/post/155675 Теперь такой функционал доступен из любого приложения, в любой книге, в любом чате, на любом сайте. Лично мне такое пригодится.
>Кстати, тут недавно до 14 дней эмбрионы в искусственной среде довыращивали, аж новость пробегала.
Это как бы и есть та самая новость. Мы ее как раз и обсуждаем.
В принципе, можно дать некое определение глобальности. Объект «a» является глобальным по отношению к объекту «b», если объект «b» имеет доступ к объекту «a», и при этом время жизни объекта «a» больше, чем время жизни объекта «b».
При этом, если глобальной является некая константа, то с ней проблем нет. Ее значение не меняется. Если же это переменная, и мы можем ее изменить (а как правило, изменить ее можем не только мы, но и чужая функция, что еще хуже), то выполнение нашей функции становится непредсказуемым. Два раза подряд вызвав функцию с одними и теми же параметрами мы можем получить разные результаты. Это вообще противоречит определению функциональной зависимости. Математическая функция обязана для каждого аргумента «x», входящего в область допустимых значений, возвращать определенный, всегда один и тот же результат «y». Только тогда мы имеем право, написать, что y=f(x). То есть сказать, что «y» функционально зависит от «x». Соответственно, чтобы не было противоречий с математикой, мы вынуждены считать, что все глобальные переменные, от которых зависит функция, так же являются ее параметрами. Проблема в том, что эти параметры, во-первых являются неявными, а во-вторых, если несколько функций обращаются к одной и той же глобальной переменной, и хотя бы кто-то в нее пишет, они начинают неявно влиять друг на друга. Возникают побочные эффекты. Такой код крайне сложно поддерживать и масштабировать. А если код еще и может выполняться асинхронно и параллельно, то это вообще ад.
И еще, следует понимать, что под «отсутствием состояния» в ФП подразумевается отсутствие состояния на уровне функции. На уровне же всей программы, всего алгоритма, естественно мы меняем некое состояние. Просто мы передаем его из одной функции в другую с помощью параметров и возвращаемых значений, явно и только тогда, когда нам это нужно. При этом каждая отдельная функция состояния не имеет, и ничего о нашем состоянии не знает. Она универсальна.
З.Ы. Я ни к чему не призываю, если что. Просто констатирую факт.
Теперь изменим условия. Допустим f1 это метод объекта, и у объекта есть поле y. Пусть метод f1 представляет собой следующую операцию: f1(x) {buf = x; x = x * y; y = buf; return x;}. У этого метода есть состояние. Результат его выполнения зависит от предыдущего вызова. Предположим, изначально y равен нулю. Тогда первый вызов f1(7) вернет ноль. А второй вызов вернет 49. После этого f1(5) выдаст 35. А если повторить вызов, то результат будет уже 25. Зависимость довольно простая, но если не знать потрохов объекта, даже такой простой случай может показаться магией. Вы скажете, что две эти функции f и f1 — разные по своей сути? Но дело в том, что можно реализовать метод f1 избежав зависимости от состояния. Назовем такую функцию f2. Тогда f2(x,y){buf = x; x = x * y; return x, buf;}. Здесь мы получили и новое значение x и новое значение y. При желании можем использовать возвращенное значение y, для повторного вызова f2. Но теперь мы знаем что и откуда берется, т.к. явно это указываем. То есть речь тут скорее не об отсутствии состояния, а о явной его передаче от вызова к вызову. В то же время, мы всегда можем разорвать эту зависимость, вызвав функцию с другими параметрами. Разумеется, отсутствие состояния можно реализовать и в ООП. И в какой-то степени, к этому надо стремиться. Чем меньше состояний у объектов, тем универсальнее и гибче будет объект. Хотя, если дойти в этом до крайности, то объект превратиться просто в набор методов, а полей в нем не останется. Во всем нужна мера, как и всегда.
Из примеров выше видно, что состояние несет в себе те же риски, что и глобальные переменные. Потому что это, в общем-то, и есть глобальные переменные. Поля глобальны для методов объекта. А если поле еще и статическое, то оно глобально для всех объектов данного класса. Если оно при этом будет публичным, то вообще ничем от глобальной переменной отличаться не будет. Следовательно и методы борьбы с состоянием будут такие же, как с глобальными переменными: минимизировать область видимости на сколько это возможно, т.е. сделать глобальные данные локальными. Принимаемый функцией параметр — это как раз и есть локальные данные. Естественно, часть данных из реального мира будет где-то храниться глобально по отношению к программе. Но это не проблема. Просто функции будут принимать эти данные в качестве явных параметров.
По теме, я всегда считал, что основная парадигма C++ это мультипарадигменность. Хочешь, используй шаблоны, хочешь — классы. А можно и то и другое одновременно. Можно написать в процедурном стиле, можно вообще в C-стиле. То есть C++ это, как бы, не один язык, а сразу много языков. И его основная сила, на мой взгляд, в том, что нет необходимости сочетать несколько языков, чтобы использовать в программе несколько парадигм. Разные парадигмы и стили программирования можно сочетать между собой нативно. При этом, не нужно задумываться о том, как использовать код, написанный на одном языке из другого языка. Можно написать часть программы, требующую максимальной производительности, в C-стиле, с указателями, битовыми операциями, и прочими прелестями. А остальную часть написать в ООП стиле. И все это будет одна программа, написанная на одном языке. Добавление функциональных элементов вполне вписывается в эту концепцию. Мультипарадигменность от этого еще больше увеличивается. Так что у меня нет ощущения, что язык свернул не туда. Он уверенно следует своему пути.
На этом пути, как и на любом другом, могут возникать сложности. Прежде всего, это делает сам язык сложным. Он сложен, как для людей, так и для компилятора. И люди так устроены, что им сложно переключаться с одного стиля мышления на другой. Сложно переключаться между разными парадигмами. Вот это и есть две основные проблемы: сложность самого языка, и непонимание, в каком случае какую парадигму использовать. В принципе это типичные проблемы любого универсального, многофункционального инструмента. Но это не делает инструмент плохим. Был бы он другим, проблемы просто были бы другими. Но они бы все равно были.
По-моему это не очень правильная позиция. Я еще могу понять апелляцию к авторитету, когда речь идет об авторитетном человеке. Но страна? Страна это слишком комплексная сущность. В любой стране есть хорошие люди и плохие. Толковые и бестолковые. Умные и глупые. И, разумеется, проекты у этих людей, могут быть, как удачные, так и неудачные.
А в статье, тем временем, нет технических подробностей. Да и на сайте их нет. Вся информация в виде вопрос-ответ, причем содержание ответа крайне сухое. Практически да/нет. И еще какой-то кривой чертеж. Такое ощущение, что его кто-то от руки карандашиком накидал за 10 минут. То, что принимают только предварительные заказы, говорит вовсе не о высоком спросе, а лишь о том, что спрос пока превышает предложение. Примерно так: имеется два заказа, а готовых изделий — ноль. В результате дефицит стремится к бесконечности. Занимательная математика. На сайте написано, что они делают 12 домов в год. Но почему-то нет ни одной живой фотографии дома, или хотя бы сегмента. По факту, имеем только 3D рендер, и много красивых слов.
Мой вывод — просто очередной стартап с идеей, но без реализации. Первые заказчики возьмут на себя кучу дополнительных рисков, связанных с новой технологией, т.е. станут, фактически, инвесторами. Это не то, чтобы плохо, но в таких случаях как раз надо больше технической информации, чтобы хоть как-то оценить плюсы и минусы. А не так как тут, показали красивую картинку и просят 30 тысяч долларов.
И еще, на мой взгляд, тут главное не искать себе «junior» разработчика только ради того, чтобы воспитать из него «middle»/«senior». Если вам нужен именно «middle»/«senior», то скорее всего он нужен вам прямо сейчас, а не через полтора-два года. Так что первое, что нужно сделать, прежде чем начать нанимать новичков — выстроить процесс разработки таким образом, чтобы появились задачи, которые можно доверить именно новичкам. Если в компании каждый разработчик ведет свой проект от и до, то нанять новичка будет пустой тратой времени и денег. Да и новичку будет тяжело. Все будут пытаться отбрыкаться от него. Будут те самые вздохи и закатывание глаз, как описано в статье.
К тому же, в силу интерфейса смартфонов, где частое переключение между приложениями это настоящая боль, такой подход — это то, чего я давно ждал. Теперь можно читать книгу на английском и на лету подсматривать незнакомые слова. Раньше люди даже специальные приложения писали для этого: habrahabr.ru/post/155675 Теперь такой функционал доступен из любого приложения, в любой книге, в любом чате, на любом сайте. Лично мне такое пригодится.
Это как бы и есть та самая новость. Мы ее как раз и обсуждаем.