Использование чистых функций в грязном мире: как писать долговечный код (почти) без багов

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

Я полагаю, что за пределами демонстрируемой крутизны есть куча менее удобных и более практичных примеров, на которых фп сосёт. Но я недостаточно хорошо знаю фп, чтобы сказать, какие это приметы.

«Я есть Ты: Диалог об Истине, которая всегда была одна»

Возможно, само по себе не отпустит, нужна помощь специалиста

React уходит от Meta! Создаётся независимая React Foundation

Ура, мы больше не экстремисты

Эволюция языков программирования

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

О книге «Фулстек JavaScript: Секреты, которые должен знать каждый миддл»

Для экономии времени я читал сразу в туалете

Проблема, о которой вы наверняка не задумывались: print(.1+.2)

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

Протоарифметика или Стратифицированная система без нуля: фундаментальные основания

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

Протоарифметика или Стратифицированная система без нуля: фундаментальные основания

Есть ли какие-то исследования, намекающие на то, что развитие ИИ упирается в проблемы текущей математической аксиоматики?

В начале была цифра. Почему создание поисковых систем началось с Библии

Относительно какой именно правды Библия врёт?

Протоарифметика или Стратифицированная система без нуля: фундаментальные основания

У меня математическое образование, но я после прочтения статьи так и не понял, зачем оно. Перечитывание соответствующих секций понимания всё равно не добавило. Возможно, это знак, что для 99% потенциальных читателей нужно развёрнутое пояснение именно мотивации данной конструкции.

Исследование: зумеры предпочитают письменную работу гаджетам

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

Если сложность письма действительно такой важный фактор, то им пользуются недостаточно.

Как Node.js выжимает максимум из I/O в 2025 году

Зачем в названии упоминается 2025 год? Какие-то из упомянутых механик - новшества крайней ноды? Если да, то какие? Если нет, то см. первое предложение.

Я тимлид, который искал работу в 2025

А в каком языке мутабельный инт?)

Кэширование DNS в NodeJS

Возможно, даже слишком потрясающе. Количество DNS-запросов упало до нуля

В голос

Promise.try: единый вход для sync/async и единая обработка ошибок

Да, тут наврал. Более безопасно при обработке ошибок в пределах async-функций. Но так-то и на промисы можно catch навесить.

Но в любом случае мой вариант не менее безопасен, чем исходный. Прув ми вронг)

Promise.try: единый вход для sync/async и единая обработка ошибок

Во-первых, поправка: не менее, а более безопасно) в случае чего ошибки вывалятся нормально, а не uncaught (in promise)

Во-вторых, даже просто глазу приятнее. Нет бойлерплейта с .then и стрелками.

В-третьих, а какие именно чудеса вам должен явить async/await? Это по сути синтаксический сахар, позволяющий вместо цепочек .then и .catch (которые могут быть очень длинными, да ещё и вложенными) писать синхронно выглядящий код. Мой пойнт не в том, что с их помощью можно сделать что-то особенное, а в том, что с ними можно сделать то же, что и без них, но красивее, удобнее и ошибкобезопаснее

Promise.try: единый вход для sync/async и единая обработка ошибок

Чтоб не быть голословным, вот эквивалентный код

class ModuleB {

  constructor() {
    this.init()
  }
  
  async init() {
    this.data = await fetch('someApi')
  }
}

// moduleA.js
import { ModuleB } from './moduleB'

class ModuleA {
  moduleB = new ModuleB();
  
  // вы, видимо, пропустили
  constructor() {
    this.init()
  }
  
  async init() {
    this.data = await fetch('someApi')
  }
}

new ModuleA() 

Promise.try: единый вход для sync/async и единая обработка ошибок

Крутая возможность async/await - не использовать await, если не нужно дожидаться результата. Просто вызываем что нужно без await, и будет счастье

await Promise.all требуется, если мы хотим получить результаты или хотя бы дождаться момента завершения. Если мы запускаем асинхронные таски в стиле fire&forget, то нам просто не нужен await на верхнем уровне (хотя мы можем использовать async/await в самих тасках)

Promise.try: единый вход для sync/async и единая обработка ошибок

Я не уследил, в какой момент в РФ запретили await Promise.all

Promise.try: единый вход для sync/async и единая обработка ошибок

Чем только люди не занимаются, лишь бы не использовать async/await