Мне кажется, что есть ещё третья ошибка, возникающая при программировании конечных автоматов, от которой спасают акторы. Я называю её "object reentrancy". Суть вот в чём: функция или метод, принимающая событие, должна сделать две вещи: поменять состояние, и выполнить всякие side effect-ы. Представим, что она это делает в таком порядке: сначала выполняет сайд-эффекты, а потом меняет состояние. Если side effect - это синхронный вызов, то в его процессе может породиться новое событие, и в том же потоке выполнения снова вызовется метод, принимающий событие. Но состояние-то осталось старым! Потом эта цепочка начнёт раскручиваться, и состояния начнут обновляться задом наперёд. Mutex-ы не спасут, они обычно позволяют себя повторно захватить потоку, который ими и так уже владеет.
В ООП есть понятие "class invariant". Это нормально, что внутри метода этот инвариант временно ломается, пока это не наблюдаемо извне. Но если метод временно передаёт управление, например в какой-нибудь callback, пока инвариант сломан, то возможна неожиданная жопа. Я с таким сталкивался, когда у меня несколько стейт-машин общались друг с другом.
Поэтому для конечных автоматов есть два варианта: или дисциплина "сначала меняем состояние, потом выполняем остальные действия", или все события только через очередь. Мне больше нравится первый вариант, очень люблю сквозную отладку.
Нормальная история человека, чьё самолюбие настолько велико, что он решил стать самым умным, чтобы все его любили и уважали, после чего он, наконец, смог бы полюбить себя сам. Читать интересно. Главным образом затем, чтобы понимать, как не надо делать. Кошку жалко. Статью плюсанул.
Хотел предложить распространять LookAndFeel отдельно, глянул в исходники, чтобы поглядеть, какие шрифты используются, и понял, что это покрашенный Metal. Ну тоже норм. А можно убрать установку цветов Foreground/Background/Caret/Selection для JTextArea в UIManager?
Ещё посмотрел, как сделана подсветка синтаксиса, увидел regexp-ы. Имеет смысл вынести компиляцию Patter-нов куда-нибудь в конструктор или инициализацию, они же не меняются. И я не увидел паттерн для чисел, а на скриншотах они подсвечены, как это сделано?
Статья очень хорошая. Но у меня есть пара вопросов.
В первом листинге я сначала удивился, зачем вы загружаете значение из AddedThreadCounter сначала в BL, а оттуда в AL, можно же было сразу. Только потом я увидел, что BL используется как параметр в GetSavedSPOffset, сильно ниже по листингу. Неочевидно. И ещё по этому листингу получается, что самый первый элемент в области ThreadStacks не используется, теоретически он под main зарезервирован?
Где вы набираетесь этой манеры излагать: с драматизацией, с громкими словами, с пафосом? Это звучит как клоунство. На конференциях что ли? По тону сразу чувствуется, что тебе будут что-то продавать, нахваливая достоинства, скрывая проблемы и недостатки.
«Но ведь события усложняют отладку!» — скажете вы. Отвечу историей: когда в нашем проекте внедрили событийную модель, новый разработчик за день подключил фичу, которую раньше делали бы неделю. Он просто нашёл нужное событие в документации и подписался.
Уж ответил так ответил, просто размазал аргументацией.
В целом статья вроде норм, но было бы лучше, если бы часть "pub/sub решит все ваши проблемы" была поменьше.
Нет, это разные люди. "Отрепьев" был либеральных взглядов, а "Георгий" - социалистических. Ещё я бы сказал, что "Отрепьев" лет на 10 моложе, более агрессивный, активный и конкретный. А "Георгий" любит глобальные темы, и все его "атаки" - это защиты.
На графиках видно, что степень сжатия lossless-кодеками составляет 40%-70% от исходного wav-файла. Формат mp3 сжимает сильно лучше (15%-25%), на его фоне остальные смотрелись бы бледно. Все ухищрения, описанные в статье, влияют на скорость запаковки-распаковки и на вычислительную нагрузку, а не на степерь сжатия.
Добрый человек, расскажи, пожалуйста, про ноги и педали, это доставляет мне максимальный дискомфорт. У меня не получается держать пятку на полу и жать носком, я полностью поднимаю ногу и давлю. И при этом не могу точно контролировать силу нажатия. Есть техники, чтобы лучше управляться с педалями?
Есть стойкое ощущение, что вы очень хотите поспорить, и совсем не хотите понять (ну и на текущий момент не понимаете функциональщину). Из-за этого ваш спор сводится к цитированию википедии, апелляциям к "общепринятым терминам" и спорам о словах. Если вдруг захотите понять, то дайте знать, тогда будет смысл. А сейчас не интересно. Я поражаюсь терпеливости IU.
Я понимаю, что статья ознакомительно-популярная, и её идея "смотрите, все эти страшные слова на самом деле вам знакомы, эндофунктор - это массив!". Но цельности не хватает, многие вещи упомянуты как важные, и тут же брошены без применения.
Операция над элементами полугруппы обязательно должна обладать свойством ассоциативности
Это нигде не применяется. И вообще объяснение полугруппы выглядит так, будто это такая штука, чтобы элементы поместить в массив и как-то схлопнуть.
Статья получилось разделённой на две не связанные части: одна про полугруппы, другая про функторы, а описание монады в конце осталось подвешенным, просто flatMap из Array. Хотя нужно совсем немного, чтобы сделать статью цельной и понятной: нужно объявить Array полугруппой, операцией будет конкатенация. Тогда fold будет соединять массивы в массиве, получится тот же flatMap. А монаду определить через fold, соединив функторы и полугруппы.
Я нифига не понял аргументации. Функции плохо подходят для отложенных вычислений, потому что есть частный случай: анонимные функции плохо пригодны для сериализации-десериализации, потому что захватывают контекст. Но АСТ тоже не захватывает контекст! А во-вторых, есть простейшие рефакторинги: сделать функцию не-анонимной, передавать аргумент в явном виде.
Дальше был первый пример кода, и тут мне непонятно: а "матчер" - это что? Выглядит как синтаксический сахар для функции x -> boolean . Какой это тип?
Последняя часть статьи не использует сериализации анонимных функций, из-за чего вся статья странная, в ней абстрактное про одно, а конкретное - про совсем другое. Код я не понял, но чисто теоретически интересуюсь: если есть крон-строка, и на основе её сгенерируется какой-то код, и этот код в рантайме окажется сломанным, насколько просто понять, причина в коде или в кривой крон-строке?
Я пишу этот комментарий ещё не прочитав вторую часть, но уже сейчас я со многим не согласен. Память для кадра локальных переменных функции можно выделять на стеке или в куче, оба этих региона ограничены, не только стек. На нём сильно проще выделить память (константное время) и проще вернуть.
Но есть ещё один момент. В функциональных языках поддерживаются значения-функции, которые запомнили контекст, в котором были определены, включая локальные переменные этого контекста. Такое хранилище контекста функции называется "замыкание"/"closure", и, поскольку для него порядок создания не соответствует обратному порядку удаления, оно создаётся на куче. А раз уж там живут локальные переменные, то имеет смысл его использовать в качестве кадра локальных переменных функции.
Мне кажется, что есть ещё третья ошибка, возникающая при программировании конечных автоматов, от которой спасают акторы. Я называю её "object reentrancy". Суть вот в чём: функция или метод, принимающая событие, должна сделать две вещи: поменять состояние, и выполнить всякие side effect-ы. Представим, что она это делает в таком порядке: сначала выполняет сайд-эффекты, а потом меняет состояние. Если side effect - это синхронный вызов, то в его процессе может породиться новое событие, и в том же потоке выполнения снова вызовется метод, принимающий событие. Но состояние-то осталось старым! Потом эта цепочка начнёт раскручиваться, и состояния начнут обновляться задом наперёд. Mutex-ы не спасут, они обычно позволяют себя повторно захватить потоку, который ими и так уже владеет.
В ООП есть понятие "class invariant". Это нормально, что внутри метода этот инвариант временно ломается, пока это не наблюдаемо извне. Но если метод временно передаёт управление, например в какой-нибудь callback, пока инвариант сломан, то возможна неожиданная жопа. Я с таким сталкивался, когда у меня несколько стейт-машин общались друг с другом.
Поэтому для конечных автоматов есть два варианта: или дисциплина "сначала меняем состояние, потом выполняем остальные действия", или все события только через очередь. Мне больше нравится первый вариант, очень люблю сквозную отладку.
Господа, каламбурчик:
Извините
Нормальная история человека, чьё самолюбие настолько велико, что он решил стать самым умным, чтобы все его любили и уважали, после чего он, наконец, смог бы полюбить себя сам. Читать интересно. Главным образом затем, чтобы понимать, как не надо делать. Кошку жалко. Статью плюсанул.
Очень неплохо!
Хотел предложить распространять LookAndFeel отдельно, глянул в исходники, чтобы поглядеть, какие шрифты используются, и понял, что это покрашенный Metal. Ну тоже норм. А можно убрать установку цветов Foreground/Background/Caret/Selection для JTextArea в UIManager?
Ещё посмотрел, как сделана подсветка синтаксиса, увидел regexp-ы. Имеет смысл вынести компиляцию Patter-нов куда-нибудь в конструктор или инициализацию, они же не меняются. И я не увидел паттерн для чисел, а на скриншотах они подсвечены, как это сделано?
Спасибо за наводку, неплохая игра. Скачал демку, прошёл. На первом уровне все секреты нашёл, на втором два не смог расковырять. Зато вот что нашёл:
Совет 0: не вставлять свою фотографию как картинку к статье, аудитория заподозрит, что технического содержимого нет, только самореклама.
Как жаль, что статья не соответствует этим критериям.
С чего бы?
Статья очень хорошая. Но у меня есть пара вопросов.
В первом листинге я сначала удивился, зачем вы загружаете значение из AddedThreadCounter сначала в BL, а оттуда в AL, можно же было сразу. Только потом я увидел, что BL используется как параметр в GetSavedSPOffset, сильно ниже по листингу. Неочевидно. И ещё по этому листингу получается, что самый первый элемент в области ThreadStacks не используется, теоретически он под main зарезервирован?
Использовать слово "антипаттерн" - это антипаттерн. А уж настолько облениться, что прогонять ответ на комментарий через LLM - это супер-антипаттрн.
Где вы набираетесь этой манеры излагать: с драматизацией, с громкими словами, с пафосом? Это звучит как клоунство. На конференциях что ли? По тону сразу чувствуется, что тебе будут что-то продавать, нахваливая достоинства, скрывая проблемы и недостатки.
Уж ответил так ответил, просто размазал аргументацией.
В целом статья вроде норм, но было бы лучше, если бы часть "pub/sub решит все ваши проблемы" была поменьше.
Нет, это разные люди. "Отрепьев" был либеральных взглядов, а "Георгий" - социалистических. Ещё я бы сказал, что "Отрепьев" лет на 10 моложе, более агрессивный, активный и конкретный. А "Георгий" любит глобальные темы, и все его "атаки" - это защиты.
Первая часть статьи: какая-то каша из цитат разных авторов.
Вторая часть статьи: вопросительные предложения, непонятно к кому обращённые.
На графиках видно, что степень сжатия lossless-кодеками составляет 40%-70% от исходного wav-файла. Формат mp3 сжимает сильно лучше (15%-25%), на его фоне остальные смотрелись бы бледно. Все ухищрения, описанные в статье, влияют на скорость запаковки-распаковки и на вычислительную нагрузку, а не на степерь сжатия.
Статью минусанул, автору карму не стал минусить, ибо какой он, нахрен, автор? Этот LLM-ный текстосодержащий продукт не должен тут оставаться.
Добрый человек, расскажи, пожалуйста, про ноги и педали, это доставляет мне максимальный дискомфорт. У меня не получается держать пятку на полу и жать носком, я полностью поднимаю ногу и давлю. И при этом не могу точно контролировать силу нажатия. Есть техники, чтобы лучше управляться с педалями?
Есть стойкое ощущение, что вы очень хотите поспорить, и совсем не хотите понять (ну и на текущий момент не понимаете функциональщину). Из-за этого ваш спор сводится к цитированию википедии, апелляциям к "общепринятым терминам" и спорам о словах. Если вдруг захотите понять, то дайте знать, тогда будет смысл. А сейчас не интересно. Я поражаюсь терпеливости IU.
Я понимаю, что статья ознакомительно-популярная, и её идея "смотрите, все эти страшные слова на самом деле вам знакомы, эндофунктор - это массив!". Но цельности не хватает, многие вещи упомянуты как важные, и тут же брошены без применения.
Это нигде не применяется. И вообще объяснение полугруппы выглядит так, будто это такая штука, чтобы элементы поместить в массив и как-то схлопнуть.
Статья получилось разделённой на две не связанные части: одна про полугруппы, другая про функторы, а описание монады в конце осталось подвешенным, просто flatMap из Array. Хотя нужно совсем немного, чтобы сделать статью цельной и понятной: нужно объявить Array полугруппой, операцией будет конкатенация. Тогда fold будет соединять массивы в массиве, получится тот же flatMap. А монаду определить через fold, соединив функторы и полугруппы.
Отличная реклама получилась
Я нифига не понял аргументации. Функции плохо подходят для отложенных вычислений, потому что есть частный случай: анонимные функции плохо пригодны для сериализации-десериализации, потому что захватывают контекст. Но АСТ тоже не захватывает контекст! А во-вторых, есть простейшие рефакторинги: сделать функцию не-анонимной, передавать аргумент в явном виде.
Дальше был первый пример кода, и тут мне непонятно: а "матчер" - это что? Выглядит как синтаксический сахар для функции x -> boolean . Какой это тип?
Последняя часть статьи не использует сериализации анонимных функций, из-за чего вся статья странная, в ней абстрактное про одно, а конкретное - про совсем другое. Код я не понял, но чисто теоретически интересуюсь: если есть крон-строка, и на основе её сгенерируется какой-то код, и этот код в рантайме окажется сломанным, насколько просто понять, причина в коде или в кривой крон-строке?
Я пишу этот комментарий ещё не прочитав вторую часть, но уже сейчас я со многим не согласен. Память для кадра локальных переменных функции можно выделять на стеке или в куче, оба этих региона ограничены, не только стек. На нём сильно проще выделить память (константное время) и проще вернуть.
Но есть ещё один момент. В функциональных языках поддерживаются значения-функции, которые запомнили контекст, в котором были определены, включая локальные переменные этого контекста. Такое хранилище контекста функции называется "замыкание"/"closure", и, поскольку для него порядок создания не соответствует обратному порядку удаления, оно создаётся на куче. А раз уж там живут локальные переменные, то имеет смысл его использовать в качестве кадра локальных переменных функции.