Не так давно на Хабре был пост, комментарии к которому заставили меня задуматься о нескольких взаимосвязанных вопросах. Результатами этих раздумий (или их отсутствием, тут уж как посмотреть) я хочу поделиться с сообществом.

Что такое боль?

Как-то раз у меня болел зуб. Я лежал на диване и пытался не обращать на это внимания. Я думал о том, что боль — это просто сигнал, идущий в мой мозг. Такой же сигнал, как наличие или отсутствие напряжения в проводке, идущем к PS/2 разъёму системного блока. Сам по себе он не несёт никакой семантики, это моё сознание выбирает, как его интерпретировать. Если я перестану воспринимать его как боль, а вместо этого проигнорирую или просто «приму к сведению», мне станет легче.

Легко передать видео сигнал, если ты отдален на расстояние спутника. Если выйти за пределы солнечной системы, то для передачи обычной картинки на Землю может потребоваться несколько часов. Но если же сигнал идет из удаленной на миллион световых лет галактики, то лишь обрывки символов долетают до нас. Иногда их можно расшифровать и сложить в анимацию, сделанную из ASCII символов. Эта история об одном странном мире, в котором технологии переплелись с древностью. Возможно, этой цивилизации уже не существует, ведь сигнал шел миллион лет.

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

1. Вчера отстоял многочасовую очередь, чтобы записаться в школу космических полетов. Шел дождь с коэффициентом радиоактивности 56Гз, но мне не страшно, ведь я [неразборчиво]. И ведь не взяли!

Рандомайзер Link to the Past может изменять не только содержимое сундуков и награды в игре, но и спрайт персонажа, создаваемых врагов и цветовую палитру мира!

Прохождение любимой игры детства похоже на встречу с давним другом. Ты чувствуешь облегчение, зная, что находится в сундуке, из какого куста выскочит враг, что за секретная тактика позволяет с лёгкостью победить неприятеля. Такая успокаивающая тесная связь становится очевидным выбором, когда ты хочешь расслабиться в игре.

Но что если к знакомому игровому процессу добавить немного перца? Пройдя игру несколько раз и запомнив её, как нам вернуть ощущение приключения и исследований, которое испытывали при первом прохождении? Небольшое, но активно развивающееся сообщество сцены эмуляции ретро-игр ищет ответ на этот вопрос благодаря использованию модов и хаков, называемых «рандомайзерами».

Что ж, всё плохо. Немного забавно так говорить: на конференции (Web à Québec) было много разговоров об удивительном будущем и вещах, возможных благодаря новым технологиям. О новых средствах и устройствах, которые должны сделать нашу жизнь проще. Мои знакомые знают, что у меня обычно очень циничный взгляд на технологии; лично я боюсь всех этих умных устройств, которые реагируют на мои слова, чем восхищались другие спикеры.

В основном потому, что чем больше времени я трачу на программирование и провожу в этой отрасли, тем больше узнаю, как всё работает изнутри, и тем меньше доверия всё это мне внушает. Я подобрал изображение для слайда. Это картина «Триумф смерти» Питера Брейгеля. В некоторой степени она раскрывает моё отношение к «умному дому».

В первой статье Введение в теорию магии был дан обзор основных тем теории магии. Теперь мы переходим к рассмотрению пространства свойств, его особенностей и характеристик.

* скорее всего, я что-нибудь да упустил, но уверен, в комментариях мне это подскажут

Эту статью я пишу для своих личных нужд. Планируется, что она будет содержать в себе ответы на все вопросы, которые мне задают студенты на эту тему. Если она пригодится кому-то ещё — здорово.


Содержание.

1. Введение
2. Заблуждения о this
3. Как определить значение this

Первая статья из цикла «Теория магии» носит обзорный характер. Ее цель — сформулировать основные вопросы рассматриваемой дисциплины преимущественно на качественном уровне, а так же разъяснить, какие принято выделять субдисциплины, и как аспекты, находящиеся в центре их внимания, связаны между собой.

Привет, Хабр! Представляю вашему вниманию перевод статьи «JavaScript Async/Await and Promises: Explained like you’re five years old» автора Jack Pordi.

Каждый, кто считает себя JavaScript-разработчиком, в какой-то момент должен был столкнуться с callback-функциями, промисами или, с недавних пор, с синтаксисом async/await. Если вы пробыли в игре достаточно долго, вы, вероятно, застали времена, когда вложенные callback-функции были единственным способом достижения асинхронности в JavaScript.

Когда я начал изучать и писать на JavaScript, уже существовало миллиард руководств и туториалов, объясняющих, как добиться асинхронности в JavaScript. Тем не менее, многие из них просто объясняли, как преобразовать callback-функции в промисы или промисы в async/await. Для многих этого, вероятно, более чем достаточно, чтобы они «поладили» с ними и начали использовать их в своем коде.

Однако если вы, как я, действительно хотите понять асинхронное программирование (а не только синтаксис JavaScript!), то, возможно, вы согласитесь со мной, что существует нехватка материалов, объясняющих асинхронное программирование фактически с нуля.

1. Вступление

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

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

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

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

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

JavaScript язык особенный. Сколько его не изучай, всегда найдутся моменты, которые заставят даже матёрого профессионала начать чесать репу.

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

Задачка 1 — «BANANA»

Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

И вот несколько вещей, которые вызывают у меня непонимание.

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



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