Можно для джунов, не особо знакомых с терминологией, пояснить. Вот я спускаюсь со склона, лыжи под каким-то углом. Я частично срываю снег и слегка перемещаюсь горизонтально. На крутых (для меня) склонах на этот срыв (торможение) тратится столько энергии, что ноги болят аццки. Что я делаю не так?)
Также обратил внимание, что многие летают и вроде как притормаживают, как будто контролируют скорость. Попробовал также и понял что контроль скорости осуществляется тупо за счёт сопротивления воздуха, т.е когда стена воздуха не даёт тебе разогнаться до бесконечности. Это я не считаю контролем.
Короче, если я применяю значительные усилия на срыв снега, то это из-за того что я ламак, а не хиляк?

Автор напоминает чем-то dz - тот долго разрабатывал и толкал свою "вечную ос", не знаю чем все закончилось, но ничего о ней уже давно не слышал.

Офтоповый вопрос: вы стрелочки с Клавы набираете или откуда-то копируете? Когда мне в тексте (программы) нужна стрелочка, я всегда гуглю utf8 arrow. А каменте на хабре написал бы просто ->

Я в 2014м небольшую статейку написал на этот счёт. Будет как дополнение к этой: https://habr.com/ru/post/227021/

Вам надо regexp подучить

Вы забыли добавить, что с "Руссиновичем над одним проектом работали"

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

$s = "This is a <b>test</b>!";
$s =~ m|<b>(.*?)</b>|;
print $1; # печатает test

Здесь, как я говорил, лучше не использовать сущность "найденный фрагмент" и заглядывания вперед/назад, а проще применить группировку ($1). Пример простой, а вот с заменой немногие, не имея опыта, догадатся сделать так:

# заменим "test" или "bug" на "code" только если впереди стоит фраза
# "this is a " или "that is a "
$s =~ s/(this|that) is a (test|bug)/$1 is a code/;
# или так
$s =~ s/(this is a|that is a) (test|bug)/$1 code/;
# добавим пробелы вокруг text в <любой tag>text</любой tag>
$s =~ s|(<[^>]+>)(.*?)(</[^>]+>)|$1 $2 $3|;

Если человек понимает больше чем час изучения регулярных выражений, во втором примере я ему еще и предложу использовать \1. За "более боевыми" примерами надо лезть в код проектов и находить такие пограниченые варианты, но мне кажется этого итак достаточно, чтобы понять о чем речь. Если кому-то мой вариант менее понятный чем заглядывания - ради бога, я не расстроюсь, что кому-то он не подходит.

Хорошо, сегодня буду за компом, напишу. С мобилы не очень удобно регулярки писать

Я же написал "почти все случаи". И перед тем как нажать на сабмит, подумал "но все равно отпишется человек, который найдёт контр пример". Очевидно, что раз фича есть, значит скорее всего от неё будет польза. Мой совет основан на опыте. Причём не только личном. Это и личные обращения" помоги составить регулярку, влом доки читать" и код ревью. Я лишь советую как облегчить себе жизнь. 99% практических регулярок оно покрывает

20 лет пишу регулярки (т.к поддерживаю несколько проектов на perl, хотя основной язык python) и могу дать один совет, который облегчит восприятие и логику регулярок: не пользутесь фичами с заглядывания вперед/назад. Да, призыв не использовать функционал звучит странно. Но столько людей спотыкаются в них и регулярно обращаются к документации чтобы освежить в памяти именно этот момент.
Чем же их заменить? почти все случаи заменяются на такие приемы:
1) захватить в (блаблаблла) то, что должно присутствовать в тексте и не должно быть изменено, после чего этот же фрагмент вставить в результат как $1 ($2 и тд)
2) использовать [^чего_не_должно_быть]
все это читается на раз-два, в отличие от всяких (?<=Y)X