• Из чего сделан JavaScript?
    0
    В математике так же.
    Переменная — это символ, который принимает некоторое значение в контексте. Например, при вычислении x^2+2*x в контексте [x=3], скажем, при вычислении f(3) функции f(x)=x^2+2*x, значение x неизменно. Однако, мы называем x переменной, потому что она зависит от контекста.

    Либо же в JS так говорят по привычке.
  • Пятничный опрос: Что у вас на Экспресс-панели?
    0
    Как мне видится, Speed Dial может быть функциональной заменой Bookmark Bar, потому что панелька кушает экранное место всегда, а новая вкладка требует большего числа манипуляций с клавиатурой/мышью. Так сказать, размен пространства на время.
  • JavaScript не нужно ничем заменять — другие языки тоже столкнутся с теми же проблемами
    0
    Тут другая аналогия.
    Я примерно понял, как Вы смотрите. Это прагматичный взгляд, чем у меня.
    Как человек, регулярно вписывающий JS в ТЗ, думаю, с Вами я согласен в практическом ключе.
    JS в настоящее время — это язык ассемблера в вебе
    Нет, на ассемблере писать трудно, на JS — просто.
    Согласен, что на JS писать существенно проще.
    Я вкладывал в это утверждение определённый смысл: браузер интерпретирует только JS, для использования любых других языков необходимо транслировать в JS, подобно тому, как на машине мы все высокоуровневые языки вынуждены компилировать. Я не способен писать веб-приложение не на JS и ожидать, что браузер его исполнит без предварительной (с моей стороны) компиляции в JS.
  • JavaScript не нужно ничем заменять — другие языки тоже столкнутся с теми же проблемами
    +1
    Я думаю, здесь вопрос издержек. JavaScript сложно транслировать во что-то более низкоуровневое. Это означает, что каждый выбирает из следующих вариантов:
    1. писать на JS и плакать из-за отсутствия by design полезных фишек языка. Я могу согласиться, что на JS код писать легче, чем на многих других языках, но легко ли? Увы, не легко. Я хочу на шоссейном велосипеде гонять, а Вы сравниваете дорожный и самокат, потому что дорог не завезли.
    2. писать на лучшем языке с последующей компиляцией в JS, иметь проседание производительности (память и время)
    2*. вливать килотонны долларов для создания эвристик, которые бы позволили эффективно исполнять JS-код в типичных случаях его использования. Казалось бы, зачем? если код изначально пишется на языке, в котором можно доказать существование поля определённого типа у переменной, зачем ловить проседание производительности от несовершенства эвристик определения типа поля в скомпилированном в JS коде?

    На asm.js никто не предполагал писать. В него предполагалась только компиляция с другого языка с целью получить заведомо более эффективный код. JS в настоящее время — это язык ассемблера в вебе: альтернативы нет, писать можно, но хочется большего. AsmJs полумера. Поэтому я с интересом наблюдаю за WebAssembly.
  • JavaScript не нужно ничем заменять — другие языки тоже столкнутся с теми же проблемами
    +3
    Тоже вставлю свои 5 копеек. Как мне кажется, проблема JS ставится неправильно:
    Причиной всегда становится то, что у JavaScript накопилось слишком много странностей, которые давно нужно было исправить.
    Проблема JS в вебе по моему мнению в том, что цели, ради которых он разрабатывался, отличаются от целей современной эксплуатации. Для своих целей он был создан на удивление хорошо и ему, в принципе, можно было бы простить всякие странности. В те времена язык для веба должен был учитывать, что:
    — мы не знаем, какой диалект поддерживает браузер
    — мы не знаем, какое API предоставляет браузер (т.е., не знаем среду исполнения)
    — мы хотим сделать максимум из написанного в коде, который рассчитан на определённый диалект(ы) и среду(ы) исполнения
    Поэтому язык должен уметь выживать, когда натолкнётся на неизвестную синтаксическую конструкцию или на отсутствие объекта, поля или метода, наличие которого кодом предполагалось.

    В настоящее время есть стандарт, который в определённой мере поддерживается, а типичные варианты использования JS включают
    — написание скриптов, как раньше, потому что больше писать не на чем
    — компиляцию в JS как язык виртуальной машины кода другого языка (TS, JSX, ES более высокий версий и т.п.)
    причём второй подход все более начинает доминировать. Вариативность диалектов и сред исполнения уменьшается за счёт стандартизации. На первый план выходит требование предсказуемости поведения скриптов, их тестирование, в т.ч. статический анализ (в т.ч. банальное желание иметь умный автокомплит). Таким образом, цели использования JS становятся сходными с другими стандартизированными языками виртуальных машин.

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

    Ремарка: есть asm.js — диалект (точнее, подъязык) JS, который эффективен в качестве языка виртуальной машины, но в него, насколько я знаю, не компилируются другие веб-языки, вроде TS, Elm и пр.
  • История одного хака или не злите программиста
    0
    Ладно, давайте позанудствуем. Математика говорит нам, что целые числа являются подмножеством (или подтипом, как хотите) рациональных.
    Если совсем занудствовать, что стоит говорить о наличии выделенного мономорфизма из Z в Q, сохраняющего порядок, ноль, единицу, сложение, умножение и т.п. и т.д.

    Если, например, мы определяем R как метрическое пополнение Q, то элемент R (вещественное число) по определению является классом эквивалентности фундаментальных последовательностей рациональных чисел, что само по себе не может быть рациональным числом. Но опять же, есть вложение Q в R — мономорфизм, сохраняющий порядок и т.п. и т.д.
    Аналогично, рациональное число определяется, как правило, как класс эквивалентности пар из Z*N, поэтому рациональное число, строго говоря, тоже не может быть целым, будучи множеством пар чисел. Аналогично, есть выделенное вложение Z в Q.

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

    К программированию это не имеет отношения, если что.</offtop>
  • ФП vs ООП
    0
    Вы в ответ на это можете возразить: «ну так давайте считать наши программы на С такой же чистой последовательностью команд, C — чистый язык!» И вы, самое интересное, будете абсолютно правы! Вы можете считать, что весь ваш сишный код просто живёт в монаде IO. Компилятор её там неявно за вас дописывает.
    Я думаю, что после этого предложения стоило бы дописать:
    Впрочем, в вашем сишном коде нет функций, потому что ваш сишный код — экземпляр нефункционального типа IO.

    И вывод: ФЯП нужны, поскольку писать без функций, когда в предметной области есть функциональные зависимости, неуютно.
  • Какую систему управления версиями вы используете (в реальной работе, больше всего)?
    +2
    Ctrl+F darcs → нет результатов
    Ctrl+F pijul → нет результатов

    Как так-то? На работе и в opensource понятно: проще плакать и колоться, но быть понятным большинству потенциальных коллег.
    Но в домашней разработке как можно использовать СКВ без спонтанного ветвления?
  • Переполнение стека вызовов JavaScript, SetTimeout и снижение производительности AJAX
    0
    tl;dr что было актуально раньше — не актуально сейчас.

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

    Насколько я понимаю, все Ваши расчёты исходят из того, что рекурсивная функция не содержит продолжений, то есть мы не можем прямолинейно размотать рекурсивное исполнение функции в цикл. А это именно тот случай, который рассматривается в статье. <off>Впрочем, в Ваших расчётах не учитывается рекурсия с переменной глубиной вызовов, например, обход в глубину графа с радиусом >500, в котором общее число вызовов примерно равен числу вершин.</off>

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

    И «рекурсивный вызов» в setTimeout'е это не рекурсия, потому что это не «вызов», а «добавление события» в eventloop, это совершенно архитектурно разные вещи
    Техника, описанная в статье, конечно, для этого не подходит, но допустим, Вам нужно обойти граф и для этого Вы составили функцию, которая оказалась по всем формальным критериям, рекурсивной. Далее Вы её как-то реализовали в коде. Какая разница, как там под капотом это будет реализовано: через стек, циклом или событиями eventloop? JS увы, требует в коде явно решать такие вопросы, которые большинству программистов не интересны.
    Наконец, мы же справедливо можем назвать рекурсивной любую функцию, в теле которой упоминается она сама.

    Есть async идеально подходящий для этого. Для кроссбраузерности есть промисы (которые в крайнем случае прекрасно полифилятся на callback'ах).
    В 2013 промисов в действующем стандарте ES5 не было, async/await (которые суть сахар над промисами) тем более. С промисами же решение становится почти тривиальным.

    Надо отметить, что в настоящее время задача неактуальна, а решение — тем более. Так что предлагаю с уважением похоронить статью.
  • Хочу рецензии на Хабр
    +2
    Проблематика, которая здесь обсуждается:
    1. Большая доля комментариев носят нетехнический характер, анализ материала в среднем технически менее качественный в комментариях, чем в ответе в виде полноценного поста. Под некоторыми комментариями просят их вынести в отдельный пост, см. п. 2.
    2. Посты-ответы являются обычными постами, а значит 1) их публикация не оповещается, 2) их наличие хламит ленту, 3) их существование невыводимо из текста оригинальной статьи.

    Говорилось (и я согласен с мнением других отписавшихся), что система рецензий как механизма оценки не оправдается из-за 1) отсутствия требований к рецензентам, 2) коммерческих рецензентов.

    Озвучивалась идея рассматривать систему рецензирования как способ организации статей: 1) линковка статей для упрощения навигации, 2) систематизация технических развёрнутых комментариев (выделение из общего потока комментариев, поста-ответа из ленты и т.п.) и 3) мотивация писать подробный текст (пост-ответ, написанный по техническому комментарию, кратно объёмнее и содержательнее)

    Добавлю своё мнение:
    — «рецензия» (пост-ответ) можно не делать отдельной сущностью, ведь это пост
    — но учёт и отображение должно быть отдельно (или отделимо) от прочих постов, чтобы размер ленты не увеличился кратно
    Получается, чтобы в полной мере понять рецензию, сначала надо будет перейти в пост и прочитать его.
    Это в любом случае надо: что для поста-ответа, что для комментария.
    чем не подходит вариант написания развёрнутого комментария к исходному посту?
    Технический комментарий потеряется среди нетехнических или диалогов.
    Почему нельзя обойтись текущими средствами — обычным постом с пометкой о том, что это рецензия?
    Существование поста-ответа не видно со страницы исходного поста.
    Зачем «размазывать» внимание читателей по нескольким постам?
    Не «размазывать» — «систематизировать». Как сказал rpiontik, «Нужно систематизировать уже возникшие процессы. Сделать их де-юре. Чтобы они стали удобными. Понятными для всех.»
    Что с рецензиями на рецензии?
    Как-то обсуждалась кеплеровская механика. Был пост-ответ на ответ на пост-критику поста. Предлагается то же, но систематично, со ссылочками.
    Что делать, если пост-оригинал будет скрыт в черновики?
    А что сейчас с комментариями или постами-ответами? Предлагается то же, но систематично, единообразно.
    в то время как профит от всего этого будет ооочень неочевидным.
    Не то, чтоб ооочень… Профит понятен, но задача определённо не первоочередная, ИМХО. Для сравнения: я испытываю сложности в понимании того, что подлежит оценке в посте/комментарии: полезность лично мне на момент прочтения? для человечества в целом? для аудитории хабра? технический уровень? Из технически грамотного комментария за плохую технологию и хайп-ориентированного комментария за хорошую какой стоит плюсануть? Мне непонятно. И народ тоже как-то бессистемно использует рейтинг. Но чувствую, что изменение системы рейтинга и/или обучение пользователей использованию его точно низкоприоритетная задача.
  • Тесты или типы? — Rust version
    0
    Для system F есть теоремы Рейнольдса. Какой есть аналог для зависимых типов?
  • Исповедь docker хейтера
    0
    Впервые я посмотрел в сторону докера, когда нужно было
    5. [...] современная package management система.
    6. создание окружения для сборки.
    Если бы были альтернативы и материалы по ним, а также доступный интерфейс, пересел бы.

    Пока что
    Альтернативы: разобраться в пакетной системе. Например, deb трекает каждый файл при установке и гарантировано удалит это за собой во время удаления. Есть жизненный цикл пакета — pre/post-install/rm, pre/post-configure и т.д.
    слишком сложно. К тому же есть ли гарантии, что после перехода на Arch (тем более Windows) или что-либо ещё все deb-пакеты не превратятся в тыквы?

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

    И тут на сцену выходят следующие ребята, которые решают и это: nix, guix, flatpack, snap, chef habitat.
    Слишком сложно.
    Есть ли road map по этим технологиям? Глядишь, найдётся более специализированный инструмент под решение этих задач.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    В случае Var[@A=1 or @A=2] таблица истинности предиката включает единственную переменную A, при чем же здесь B?
    В моём понимании таблица истинности — эта таблица из двух колонок, в первой перечислены все объекты из области определения предиката (все возможные узлы в нашем случае, в т.ч. содержащие другие атрибуты, дочерние узлы и т.п.), а во второй — True/False.
    В остальном Ваше отношение понятно.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    0
    полученный XML удовлетворяет ВСЕМ случаям из его таблицы истинности, дающим в результате истинное значение.
    Не всем же.
    Например, Var[@A=1 or @A=2] сгенерирует <Var A=«1»> и <Var A=«2»>, но не <Var A=«1» B=«5»>, хотя он тоже является случаем из таблицы истинности.
    Или: Var[@A=1 or @B=2] что породит? Входит ли <Var A=«1» B=«2»> в результат? Ответ должен следовать из постановки задачи.
  • Конструирующий XPath? Алгоритмический XPath? Ничего, кроме XPath
    +1
    Мне кажется, тут лучше быть более последовательным. Например, при использовании [@A>1], // и * кидать исключение «Порождаемый документ бесконечен из-за элемента ...».

    Кстати, Вы не думали, как формально поставить задачу, который решает Ваш инструмент? Очевидно, речь идёт не о генерации минимального XML, удовлетворяющего XPath, потому что нужно перебирать все члены дизъюнкции под [ ], но и не максимальный XML, потому что другие атрибуты и дочерние узлы, кроме упоминаемых в запросе, не добавляются.
  • Избыточная сложность
    0
    element.classList[ isVisible ? 'add' : 'remove' ]( 'visible' )
    </joke>

    Если я правильно понял посыл автора, то система должна содержать две специализированные функции (add и remove) и, опционально, собранную с параметром (toggle). В первом и особенно во втором примерах обе ветки if-а заинлайнены, а не выделены отдельными именованными функциями.
  • Ненаучно о монадах
    +1
    Функтор не обязан быть чистым или иммутабельным.
    Не обязан, о чём я в следующем же предложении сказал.
    Есть функторы, которые не абстрагируют вычисления. Например, графы, деревья, аппликативный функтор ZipList. В целом, интерфейс Functor очень бедный, о чём в статье упоминалось, чтобы смотреть на функторы как абстракцию вычислений.
    Да, типом данных, которые этот функтор генерирует.
    Генератор случайных чисел генерирует числа. Он же не может генерировать строки, например, или бинарные деревья, иначе он уже не будет генератором чисел. А построить генератор экземпляров произвольного типа невозможно.
  • Ненаучно о монадах
    0
    ИМХО, для лайтового введения в тему слишком много небрежного написано.
    Функтор — это абстракция над произвольным вычислением (computation), возвращающим результат типа А.
    Функтор — это абстракция над способом структурной организации данных, экземпляр функтора F<A> — это какие-то данные типа A (вычисленные или ещё нет), которые как-то собраны в какую-то структуру данных F.
    Абстракция над вычислением, как автор же говорит в комментариях, это монада.
    аппаратный генератор случайных чисел
    Функтор всегда параметризован типом. Чем тип генератора случайных чисел или самой последовательности случайных чисел параметризован? Поэтому вряд ли это пример функтора.
  • О близости вершин
    0
    В последнее время играю в OpenTTD. По моему опыту, если пропускная способность A-B недостаточна для нужд потока, а пропускная способность B-A больше A-B, то в конечном счёте по пути B-A за единицу времени будет проходить тот же поток, что и через A-B. Если, конечно, в городе B нет завода по производству транспорта и работает закон сохранения транспорта, а также нет аварий и поломок.
    Для учёта аварий резистивное расстояние тоже не подходит. Честно говоря, не могу представить бытовую интерпретацию резистивного расстояния для задачи о пропускной способности дорог.
  • Автоматическое разрешение конфликтов с помощью операциональных преобразований
    0
    Если я правильно понял описанную реализацию, слияние не коммутативно.
    Поскольку Петя и Вася в примере начинают редактировать пустой документ, то может случиться, что Вася раньше отправит на сервер изменение, чем Петя. Тогда вторая ревизия будет !Hello, а третья !Hello Habr. Как решается эта проблема?

    По моим представлениям, если версии документа не имеют структуру полурешетки, то с необходимостью возникает проблема слияния. Либо конфликт должен решаться клиентом (как в git), либо из двух клиентов изменения одного должны доминировать над другим.
  • Логична ли математика или почему парадоксальны аксиоматические теории
    0
    Я бы сказал, что в последнем и состоит практическая проблема парадокса: мы (люди-не-зануды) не видим причин считать постановку задачи некорректной и усомниться в существовании брадобрея в зависимости от «требований к клиентам», а она, соб-сно, есть.

    Вот теория множеств ZF пошла по тому же пути: мы не гарантируем существования множества, состоящего только из объектов, удовлетворяющих некоторому (произвольному) предикату; вместо этого мы гарантируем существование множества только для предикатов определённого вида (который требует, чтобы объект, кроме прочего, принадлежал существующему множеству).

    А можно настоять на наших бытовых представлениях и поставить задачу построить такую непротиворечивую теорию, в которой такой брадобрей будет существовать. Например, ценой отказа от булевой логики.
  • Основы реактивного программирования с использованием RxJS
    0
    Первый код на JS представляет некоторую практическую задачу (определить три значения, одно из которых равно сумме двух других). Затем автор рассуждает, что JS из-за своей семантики не позволяет прямо класть в код концепт потока и предлагает JS-подобный псевдоязык, какбы изменив семантику JS, который бы обладал нужными автору свойствами, описанными в коментариях. Поскольку конструкции JS не обладают нужной семантикой, приходится представлять концепты реактивного программирования (потоки, подписку, push-стратегию) сторонними средствами (шаблон/класс Observable, колбеки и т.п.). Автор уже это ответил, но я решил подробнее объяснить, как понимаю.

    Мне интересно вот что: в ФП с иммутабельными данными любой тип эквивалентен безаргументной функции с точностью до расстановки пустых скобок. Если в примере представить a, b и sum (или хотя бы только sum) в виде безаргументной функции, формально добавив после присваивания () => и добавив () после каждой переменной, будет достигнуто то же поведение. Зачем необходим (т.е. какое место занимает) механизм подписки и линейная упорядоченность значений в реактивном программировании?
  • Исследование: большинство пользователей не понимают, как Facebook обращается с их данными
    +1
    Предположу, что опасение исходит от возможности влияния рекламы на человека. То есть реклама, если на неё обращать внимание, может изменить взгляды или предпочтения человека в той или иной мере.
    Но я согласен: наличие рекламы должно восприниматься как плата за предоставляемые услуги.
    И не знаю как вам, но мне лучше увидеть рекламу по интересам, чем рекламу аэрогриля или кружка бальных танцев.
    А я бы предпочёл видеть рекламу аэрогриля или кружка бальных танцев именно потому, что они мне не интересны. Так легче визуально отделять контент от рекламы. Если же, например, на сайте по железу висит реклама клавиатуры, она воспринимается как часть контента, что плохо.
  • Блокчейн мёртв. Да здравствует блокчейн
    +1
    Структура данных гита (и всех известных мне СКВ 2-го поколения) — ациклический орграф. Блокчейн по определению линейная структура (или дерево, если мы учитываем ветвление).

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

    P.S. частичная загрузка действительно инструментальный вопрос.
  • Блокчейн мёртв. Да здравствует блокчейн
    +1
    Блокчейн — это же по сути Git
    К сожалению, нет: гит умеет мержить, а блокчейн нет. Хотя всегда можно вспонить всеми любимый svn :)
    А ещё гит умеет делать частичную загрузки (narrow/partial clone), а блокчейн работает с полной репликацией.
  • Если изобрести язык программирования 21 века
    +2
    Далее наш инструмент получая на входе алгоритмы и структуры данных (в общем формальном описании) на выходе должен выдать программу на существующем или новом ЯП.
    Взаимоисключающие параграфы же.
    Если описание формальное, то оно делается на некотором формальном языке.
    А если мы не используем ни один из существующих или новых ЯП, то как мы программу (алгоритм, зависимость, структуру данных и т.п.) опишем формально? Максимум, полуформально. А полуформальная запись всегда субъективна: если некое описание одна группа лиц считает полуформальным (т.е. они между собой убеждены, что способны описание переложить на любой известный ЯП), то третье лицо вполне может сказать, что это описание имеет не больше смысла, чем сепульки или глокая куздра.

    P.S. статья и некоторые комментарии натолкнули меня на мысль, что все эти ЯП без синтаксиса и ИИ-кодеры могут иметь смысл, только если мы принципиально отказываемся от идеи программы с контролируемой известной логикой, т.е. разрешаем программе быть потенциально непредсказуемой: как человек всегда может (т.е. нет гарантии обратного) неправильно истолковать слова собеседника, так и программа всегда может сделать что-то принципиально отличающееся от того, что программист (по его мнению) написал. Без понятия, какой класс задач будет решаться эффективнее при таком подходе.
  • Забытая история ООП
    0
    Тезис Чёрча-Тьюринга показал, что лямбда-исчисление и машины Тьюринга функционально эквивалентны.

    Тезис Чёрча-Тьюринга не об этом.
  • Kronos: никаких путешествий во времени даже в распределенных системах
    0
    Уточните, пожалуйста, архитектуру системы.
    Правильно ли я понимаю, что в системе данные (например, в KV-хранилищах под каждый диапазон) хранятся распределённо, но при этом есть «маршрутизатор», в котором события регистрируются и рассылаются узлам, и он един (для всех узлов и клиентов)?
    Иначе:
    Isolation: если две транзакции пересекаются по данным, значит они будут связаны причинно-следственной связью в Kronos, а значит одна будет выполнена раньше другой.
    почему из пересечения по данным следует, что причинно-следственная связь будет зарегистрирована с использованием API?
    API реализует только «маршрутизатор», но не каждый из узлов? Система не устойчива к резделению?
  • Европа последний раз переводит часы на зимнее время
    0
    Стоит отметить, что и сейчас у некоторых людей рабочий день начинается и заканчивается в разные даты, а с учётом проблем нет.
    По-моему, здесь скорее нужно ломать привычки тех, кто по текущим часам работал только «в обычную дневную смену».
  • Принцип наименьшего действия в аналитической механике
    0
    Мне это кажется странным. Каждое отдельное действие соответствует задаче с закреплёнными концами. Фактически, в уточнённой Вами постановке решается задача с параметром, в роли параметра выступают начальное и конечное положение.

    Вопрос к Druu: если мы говорим-таки о задаче с закреплёнными концами, почему ниже утверждаете, что нет изолированных минимумов, ведь для каждой пары нач/кон положение действие имеет конечное число минимумов.
  • Принцип наименьшего действия в аналитической механике
    0
    система гарантированно перемещается из одного положения в другое!
    Не могу проследить, в каком порядке используются кванторы перед переменными «начальное положение» и «конечное положение».

    Разверну вопрос. ПНД исходно утверждает, что из того, что система с действием S движется по закону q, следует, что q является (мб, локальным?) минимумом S. То есть в некоторой окрестности q любой закон движения q' должен быть S(q')>S(q).
    Про окрестность и локальность прямо не говорится в определении, но далее по тексту подразумевается.

    Потом в статье пишется, что для нахождения закона движения из точки A в B (какими бы они ни были) нужно проварьировать действие $\delta S(q, \delta q) = S(q+\delta q) — S(q)$, при этом $\delta q(t_1) = \delta q(t_2) = 0$, то есть производится поиск экстремума на множестве всех законов движения из A в B.

    Если это корректное применение ПНД, то, стало быть,
    1) либо S определен только на множестве функций q из A в B, (мб, мы работаем с семейством действий, параметризованных начальным и конечным положением)
    2) либо в формулировке ПНД нужно указать, что минимизация условная, не по всем возможным законами движения из любой точки в любую, а только по множеству законов, которые имеют общие концы.

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

    P.S. прошу прощения, не знаю, как формулы оформлять, чтоб MathJax их отрендерил.
  • Всякие штуки в MetaPost
    0
    толщины линий у которых определяются функцией от освещенности шара в точках, через которые линии проходят

    Как вычисляется освещённость в точке в общем случае со шлангом?
  • Моё разочарование в софте
    +1
    Для справки: в 12-й опере тоже всё тормозит.

    Тема с пагинацией тут не такая очевидная. Пагинация хороша там, где объекты данных (темы, посты, сообщения) линейно упорядочены, обычно по времени. Форумы относятся к этой группе. Комментарии на хабре имеют древовидную структуру и мне не понятно, по какому признаку предлагается разбивать сообщения на страницы? По дате, как на форумах? По веткам обсуждения?
    Вообще, известны примеры пагинации для подобных данных?
  • CRDT: Conflict-free Replicated Data Types
    0
    <off>Очень стыдно, что не в той ветке ответил. Ответ к этому комментарию.</off>
    В случае независимых декрементов наш счётчик должен сойтись в -1.
    Если мы разрешаем счётчику сходится в -1, то как же он тогда может называться неотрицательным?
    Это как вы пожелаете.
    Как так? Вы же задачу ставите. При том конкретную, потому что утверждаете, что «Простой реализации пока не существует».
  • CRDT: Conflict-free Replicated Data Types
    0
    Неотрицательный счётчик (Non-negative counter)
    Простой реализации пока не существует. Предлагайте в комментариях ваши идеи, обсудим.

    Можете пояснить постановку задачи?
    Правильно ли понимаю, что речь идёт о предложении такой решетки, в которой ни один элемент не сооветствует отрицательному значению, т.е. нужно средствами CRDT гарантировать, чтобы на каждой реплике было неотрицательное значение?
    Какое значение должно быть после слияния, если исходно на двух репликах была одно и то же состояние со значением 1 и на обеих репликах был сделан dec?
  • Выборы вообще не работают; во всём нужно винить математику
    0
    она зависит от выбирающих, и чем их больше, тем она меньше
    похоже на отсылку к ЗБЧ. Если бы он был здесь применим, проблемы с народными выборами не было: людей-то много. Насколько я представляю, отличие хорошего метода от плохого заключается в том, что второй при том же распределении голосов выдаёт на выходе худший результат.
    вероятность, что будет выбран метод «хуже» текущего, [...] меньше 0.5, что здесь в принципе предполагается
    почему? если бы все(!) методы так работали, то можно было бы взять любой и задавить количеством избирателей/туров. Но в статье и комментариях аргументируется, что если метод в некотором смысле дефектный, то от количества голосов/туров ничего не зависит.
    вероятность после двух методов выбрать метод «не хуже» первого (стартового) не меньше 0.75, стало быть, ситуация не усугубляется.
    Условная вероятность после двух методов выбрать метод «не хуже» стартового при условии, что первый выбор был «хуже», будет меньше вероятности после первого выбора выбрать «не хуже», потому что второй метод по предположению «хуже» первого (стартового).
    В этом смысле говорилось об усугублении.

    Другими словами:
    чем больше «неправильных» выборов будет совершено на первых итерациях, тем сложнее будет затем вернуться хотя бы к стартовому.
  • Выборы вообще не работают; во всём нужно винить математику
    0
    Метод выбора хорош тогда и только тогда, когда среди вариантов (в т.ч. среди разных методов выбора) он на основе голосов отдаёт предпочтение лучшему варианту (лучшему методу).
    Если мы исходно стартуем с неидеального метода, то есть возмонжость, что результат выбора окажется хуже. На следующем шаге ситуация, очевидно, усугубится.
    Этот алгоритм, кажется, неустойчив.
  • Выборы вообще не работают; во всём нужно винить математику
    0
    upd. ниже есть обсуждение этого вопроса, в т.ч. с обсуждением применения пресловутого блокчейна в общенародных выборах.
  • Выборы вообще не работают; во всём нужно винить математику
    0
    анонимное (тайное) голосование по определению неверифицируемо.
    Я не в теме, поэтому прошу прояснить понятия.
    Всегда считал, что анонимное голосование по определению исключает наличие способа установить, за кого голосовал каждый отдельный человек.
    Верифицируемое голосование предполагает наличие формального доказательства (в некоторых предположениях) того, что каждый голос учтён правильно. Оно, однако, не обязано (по моим представлениям) устанавливать, за кого голосовал каждый отдельно взятый человек.
    Аналогия: блокчейном можно обеспечить и верифицируемость сделки и до определённой степени анонимность участников.

    Прошу объяснить процитированное утверждение в контексте моих слов.
    Что это: текущее техническое ограничение, всеобщая теорема или я неправильно понимаю анонимность и верифицируемость?
  • 10 (не) очевидных советов начинающим WEB-разработчикам
    +2
    Насколько я понял, смысл комментария был в том, что если софт не использует semver, рассчитывать на поведение в соответствии с семверной терминологией не стоит.
    В т.ч. вторая цифра может указывать обратнонесовместимые мажорные изменения.