Я к тому, что без побочных эффектов, широко используемых в императивном стиле, сильно проще писать и рефакторить приложения. В функциональном стиле рестарт дает такой же эффект, в императивном надо залезть в код и посмотреть, можно ли сделать рестарт, все ли восстановится после остановки или останутся предыдущие значения, к примеру.

Забавно :-) Добавлю свои 5 копеек

Функциональное программирование это как разбрызгиватель, вода и трубы. Вы точно знаете, что воду можно пустить по трубам, а если соединить трубу с разбрызгивателем, то вода пойдет по трубам и будет орошать ваш огород. Как только вы перекроете воду, орошение завершится, включите — начнется снова.

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

Вот же облом, в минуту опоздал )))

Добрый день, можно забронировать High Performance Spark?

Ну тут хотя бы можно вернуться к другому ядру без каких-либо танцев с бубном. В некоторых других ОС ситуация с откатом посложнее будет.

Несколько раз слышал, что девушкам (именно молодым чаще всего) не по причинам, что они девушки, а из страха, что они такие симпатичные и вдруг внезапно уйдут в декрет в нужный момент. А так — я не вижу какой-то особой разницы между стилями мышления, общался и с тестировщицами и разработчицами, многие очень любознательные и не сидят на попе ровно, постоянно что-то новое изучают, чем заслуживают уважение коллег ничуть не меньше, чем мужчинам. Это же относится и к тем, кто сидит на попе ровно и нифига не изучает, не зависит от пола :-)

Попробую несогласиться с вами. Я начинал писать с GUI приложений, потом приложения двух-звенные с БД, чисто sql отчеты размерами несколько тысяч строк кода, потом веб-приложения с множеством модулей, сейчас чисто backend-микросервисы. Кроме того, чисто для себя изучал программирование микроконтроллеров, писал на железе вообще без ОС. И весь этот опыт позволяет мне думать обо всех этапах работы кода, вплоть о том, как мои данные передаются и по сети и почему они могут вызвать проблему OutOfMemory на сервере на ровном месте казалось бы.
Недостаточно заниматься Front-End 10 лет и понимать при этом множество других аспектов. Это будет лишь «отличное понимаение как пишется Front-End». Автор скорее имел ввиду, что кто-то превосходно может разбираться в своей области, и это отлично, на самом деле, но недостаточно, чтобы предоставить возможность тому разработчику спроектировать новое приложение с нуля самостоятельно.

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

Т.е. фактически не решен вопрос прозрачности гос. закупок? Ведь мы можем всё равно скрыть данные о том, кто что выполнил, и насколько качественно, если эти данные видны лишь им двоим. А захочет третий заказчик иметь дело с ними, но их история им недоступна. Тут должно быть как раз таки всё прозрачно, видеть кто, когда и что именно выполнил, в каких масштабах. Разве нет?

Я когда устраивался в Exante, то в первый раз на позицию Scala Swing разработчика. Но мне она не очень нравилась, поэтому я сообщил об этом на собеседовании, что максимум через год буду проситься перейти в backend-разработку. Тянули достаточно долго с ответом, и примерно через месяц только ответили, что взяли другого. Правда еще через 2-3 месяца написали еще раз уже с предложением интересной мне позиции на backend. Ничуть не жалею, что не взяли на swing )))

#1 Kotlin — не какой-то там странный язык, рождённый в академических кругах.
Это должно быть мотиватором для тех, кто не осилил Scala?

Огромное спасибо вам за труды. Пробовал читать книжки по теории категорий, но очень тяжело. А эта серия статей прям находка. Подскажите, пожалуйста, планируете ли переводить другие части?

Просто выключить и посмотреть крутится или нет, выходит, что недостаточно. Ведь он может и не крутится, когда всё выключено, а вот когда включено — накручивает втридорого :-) Надо поставить какой-то прибор учета дополнительно, которому можно доверять. И вот тогда сравнивать их результаты.

Ничего не упадет, вторая транзакция будет ждать пока вы отпустите данные, либо упадет, по истечении дедлайна. А он может быть установлен даже в несколько часов (лимит времени ожидания). Тут же не взаимоблокировка, поэтому на уровне сервера БД ему нет причины убивать какую-то из транзакций

Работаю удаленно 5 лет. Соглашусь, что посещать офис несколько раз в месяц было бы неплохо, пообщаться с коллегами вживую. Но моя компания находится в Москве, а я в Чебоксарах. Поэтому только посредством скайпа, почты и VPN. Но с другой стороны, есть же корпоративы, на которых и можно строить тим билды (более успешные компании могут устраивать тим билды значительно чаще, чем 1-2 раза в год). Но вот переехать в Москву ради работы в офисе… да никогда, даже за зарплату в 2.5x выше, чем сейчас. Другое дело, если 2.5x + новый проект на любимом фреймворке и новом языке программирования. Чисто just for fun. А так — я не трачу на дорогу до работы и обратно нисколько, и это время могу потратить на изучение моего любимого языка программирования, на изучение и написание кода на котором я не могу тратить рабочее время.

Наушники противошумные 3M Peltor серия OPTIME I H510A. Защита для уровня звука 87-98 dB. Чтобы уж основательно :-)

Работаю 5 лет по удаленке. В принципе, в офис вернуться мог бы, но очень сильно привык к тишине и комфорту работы из дома. Побывав недавно в офисе, было достаточно трудно нормально сосредоточиться, когда вокруг очень много шума. Я даже для некоторых случаев работы из дома приобрел наушники для защиты от шума, что уж говорить про офис… я бы в них целый день сидел там, видимо ))