Три ужасные фичи программирования из прошлого

Думал недавно про исключения как похожий "динамический" аналог GOTO. Пример в статье можно написать на исключениях как-то так:

def path2():
  try:
    f()
  catch SELECT_PATH:
    print("path 2")

def path3():
  try:
    f()
  catch SELECT_PATH:
    print("path 3")

def f():
  raise SELECT_PATH()

if WS_X = 2:
     path2()
elif WS-X = 3:
     path3()

Только исключения немного по другому подходят к динамичности GOTO: место, где окажется поток выполнения определяется стеком вызовов, а не значением метки. Думаю, если писать в Continuation Passing Style, то можно из исключений сделать хаос не хуже GOTO.

Потоковая обработка на go1.18

Можно подробнее про "Есть простор для оптимизации? Да.", в чем этот вариант может быть оптимальнее по скорости/памяти?

Потоковая обработка на go1.18

Не совсем понял, какие проблемы. В стримах с моим подходом не обязательно выдаются ошибки, это раз. Два, Option это обертка над указателем, у меня, чтобы получить следующий элемент, надо просто вызвать Next, с sql.Rows надо вызвать Next, проверить значение, создать контейнер для результата, вызвать Scan. Из плюсов, что нет копирования, значение пишется в предоставленный пользователем контейнер. В моих стримах проще интерфейс и использование, но есть копирование. Я что-то упускаю?

Потоковая обработка на go1.18

Я писал эту библиотеку для использования в своем проекте по сбору данных из ВКонтакте

код

Деплой, базы данных и мониторинг: жизнь после перехода на Go

это не ключевые слова, это builtin

С C# все будет хорошо, и Страуструп тут не при чем

• P.S. не очень корректно обвинять автора в узколобости, так его основной опыт работы с C# в контексте Unity, а для игр очень плохо подходят концепции функционального программирования

Можно раскрыть тезис про "для игр очень плохо подходят концепции функционального программирования"? Насколько я знаю Джон Кармак высказывался в пользу использования функционального программирования для разработки игр. Не знаю, какие конкретно проблемы в Unity для использования идей из фп, но не вижу вообще никаких проблем в их использовании.

Реализация простого механизма регулярных выражений в 70 строк кода

С обычными символами не будет работать, это я упустил.

Реализация простого механизма регулярных выражений в 70 строк кода

В конкретно упомянутой постановке задача допускает гораздо более простое решение. Единственный элемент, который действительно сопоставляется - это точка "." (в настоящих регулярных выражениях есть еще "один из символов" "[a-z]" и "один символ кроме перечисленых" "[^a-z]" например. Поэтому регулярное выражение из символов "^$.*?+" это указание, сколько точек нужено найти, возможно с привязкой к началу/концу строки.
Конкретнее, регулярное выражение это строка следующего вида:

1. "^" - начало строки, либо есть, либо нет. Пока пропускаем.

2. Последовательность из ".", ".*", ".?", ".+". В этой последовательности каждая часть - это просто указание, от скольки до скольки произвольных символов может подойти. Точнее:

   • "." - минимум 1 символ, максимум 1 символ, далее - (1, 1);

   • ".*" - (0, ∞);

   • ".?" - (0, 1);

   • ".+" - (1, ∞);

3. "$" - конец строки, либо есть либо нет. Пока пропускаем.

Для пар (минимум, максимум) в регулярном выражении считаем сумму всех пар (допускаем, что ∞ + x = ∞ для любого x). Получаем (min, max).
В итоге регулярное выражение - это указание, что в строке от min до max символов в строке, возможно с привязкой к началу/концу. Дальше можно разобрать случаи с началом/концом:

• Есть и "^", и "$". Тогда считаем количество символов в строке, если min <= len <= max, то вся строка и подходит, иначе совпадения нет;

• Есть только "^". Тогда возвращаем min первых символов, если столько есть, иначе совпадения нет.

• Есть только "$". Тогда возвращаем min последних символов, если столько есть, иначе совпадения нет.

• Нет ни "^", ни "$". Возвращаем min любых символов (например первых) если есть, иначе совпадения нет.

P.S. Заметил, что не используется max, его можно использовать, чтобы прикрутить при желании нахождение всех совпадений.