Как стать автором
Обновить

Комментарии 51

Кроме предметной области нужно учитывать и другие факторы, например порог входа и масштабируемость. Удачные системы в одной предметной области могут быть совершенно разные, если одна рассчитана на не квалифицированного индивидуального пользователя, а другая на транснациональные корпорации. Первая может вообще не требовать инсталляции и конфигурирования, а вторая — целого штата только для запуска.
Кажется, что корень всех зол в том, что мы (разработчики ПО) не умеем произвольно взятую задачу «правильно» декомпозировать на модули. Всякие умные подходы вроде ООП, MVC, DDD, Viper и т.п. не особо в этом помогают. Если представить все варианты реализаций требований как множество, то похоже, в этом множестве лишь немногие точки отвечают «хорошей» системе. В итоге три варианта:
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.

Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.
IMHO — пункт «1.» (дорога к нему лежит через все последующие пункты).
«правильность» она тоже разная бывает, что порождает как минимум четвёртый вариант: система создана «правильной» в краткосрочной перспективе, но потенциала развития в долгосрочной нет или он сильно ограничен.
Все здоровые люди похожи друг на друга, каждый больной человек болен по-своему?
С точки зрения медицинского страхования все здоровые (на данный момент) принадлежат к одному кластеру, а больные разбиваются в кластеры в зависимости от диагноза и небольшого ряда других параметров.
В статьях из области биологии и медицины много упоминаний о Принципе Анны Карениной.
Я для себя давно ещё так сформулировал (на примере хранимых процедур сервера БД):

Процедура может вернуть различные коды возврата (не равные нулю) в случае каких-либо ошибок, так как причин возникновения ошибок — множество.
В случае успешной отработки (без ошибок) процедура вернёт код возврата равный нулю (т.е. вариант успешной отработки один; а число «ноль» — также уникальное в своём роде).

Итогом работы программистов является код. Его качество напрямую зависит от "качества" собственно программиста. Следовательно, исследовать нужно причины, а не следствия. Личности, команды и их подготовку, а не их продукты.


В статье же постулируется банальность. Вероятность совпадения двух и более положительных исходов равна произведению вероятностей. А так как отдельные вероятности всегда меньше 1 вывод очевиден… Хоть Карениной, хоть аттрактором это называйте ;)

НЛО прилетело и опубликовало эту надпись здесь
{краткое нестрогое ночное замечание от невыспавшегося радиофизика}
Проиллюстрируем поведение диссипативных динамических систем (между людьми есть «притяжение»).
<> Трудно иметь дело с негрубыми динамическими системами. Бесконечно малое изменение
параметров приводит к качественному изменению динамики, к другому аттрактору, другому «результату». Случай «вздорного» супруга, нестабильности психики или соматики. Не будем рассматривать, как предположительно не соответствующий счастливой семье.
<> С грубыми — существенно легче. Параметры можно «немного» изменить, а режим останется качественно неизменным.
<> Если грубая система существенно диссипативна — начальные условия («детали» встречи) и внешние воздействия играют малое значение в в наблюдаемом эксперименте, «быстро забываются», и аттрактор быстро достигается во временной реализации.
<> Если это не так, и степень сжатия элемента объема фазового пространства невелика,
приближение к аттрактору будет медленным.
— — — — — После введения, переформулируем эффект АК:
<> Мы неявно постулируем существование класса подобных семей, которые можно классифицировать как счастливые (единый аттрактор или множество некоторым образом «подобных» аттракторов).
<> {наблюдаемый режим}
Каждая счастливая семья — на неком аттракторе, который занимает малую область фазового пространства. Наблюдаемый режим семьи «ограничен». Несчастливые — в более «объемной» области наблюдаемых переменных, поведение может быть более разнообразным в каждом рассматриваемом случае. Также выше введен постулат о подобии режимов, свойство «счастье».
<> {параметры}
Внутренние характеристики каждой семьи (параметры) принадлежат множеству, соответствующему данному аттрактору «счастливая семья». В соответствии с постулатом «счастья», по-видимому, множества параметров подобны, или принадлежат одному общему множеству.
<> При анализе истории развития отношений счастливых семей, мы возможно, также обнаружим, что есть общность деталей их встречи (в каждом случае начальные условия принадлежат бассейну притяжения. Бассейны притяжения счастливых семей в первом приближении можно считать «подобными» ).

Каждый довоенный шаг участников Первой мировой кажется логичным и взвешенным, но в совокупности они привели к большой войне. Теперь я знаю как это называется. Раньше я называл это фразой из Летова (той, где всё летит в область неустойчивости). Ситуация, где любые логичные улучшения в конечном итоге ведут в пропасть. Здоровская статья, спасибо!

Либо действия некоторых участников были недостаточно продуманными, либо война и была целью некоторых, либо в целом ситуация в Европе тех лет наиболее легко могла разрешиться именно войной (по аналогии с термодинамикой — система без притока энергии сама приходит к состоянию термолинамического равновесия)

Вероятно тут совокупность из всех трёх факторов. С другой стороны, если бы кто-то смог оценить результаты войны, энтузиазм многих зачинщиков поубавился бы.
НЛО прилетело и опубликовало эту надпись здесь
Эта ветка комментариев уже довольно далеко отошла от направления основной статьи, но весьма интересная. Насколько я могу судить, история только начинает использовать количественные модели и думать об их адекватности, сложности, непротиворечивости, значимости параметров и т.д. Без них споры историков сводятся к обсуждению только пары аспектов, возможно не самых важных. Например, историки крайне мало говорят об использованных в том или ином историческом процессе финансовых и материальных ресурсах.
НЛО прилетело и опубликовало эту надпись здесь
Вы действительно посмотрели по-верхам. Принцип придуман не мной. Погуглите на английском, почитайте соответствующую статью в Википедии.
Существует ли принцип или нет, каждый решает для себя. Я считаю что он стоит в ряду с другими философскими принципами типа перехода количества в качество.
В каком-то смысли это мета-принципы, которые можно конкретизировать для конкретных областей. Я попытался сделать это для ИТ и программирования.
Кстати, а обсуждении ангоязычного варианта статьи были очень любопытные выходы. В одном из форумов пришли к заключению о необходимости референтных моделей для предметных областей и типовых процессов.
Про ITIL не знаю, но одна фирма поблагодарила меня и сообщила о расширении своего материала иныормацией об этом принципе.
А что вы конкретно понимали в «копанием» ITL и т.д.?
НЛО прилетело и опубликовало эту надпись здесь
Я не думаю, что используемый вами стиль диалога и способ аргументации способствует развитию интересных дискуссий.
Очевидно, Вы относитесь как и примерно 11% процентов участвующих в опросе к скептикам относительно существования Принципа Анны Карениной.
Это Ваш личный выбор, стоит ли прислушиваться к позиции большинства коллег (по крайней мере из усастников опроса).
я бы дополнил принцип Анны К. принципом Шрека (с уточнениями от Ослика):
Людоеды ИТ технологии и решения — как лук.
— Воняют?
— Да нет.
— От них все плачут?
— Нет.
— Если их оставить на солнце, то они темнеют и покрываются пятнами?
— Нет! Я говорю про слои! И у тех и у других есть слои, понятно?
— У тортов тоже есть слои! Значит, ты ИТ — как торт? »
Шрек (Shrek)

Следуя этой логике, если у систем с САК есть общие признаки, то они одинаково неустойчивы. Это несколько противоречит идее статьи о том, что устойчивость имеет ряд общих признаков, позволяющих ей быть устойчивой. А у неустойчивой системы нет общих признаков, которые позволяли бы ей быть неустойчивой.

Есть общие принципы и устойчивости и неустойчивости. Система одновременно может быть и устойчива и неустойчива (по разным «направлениям»). И можно рассматривать общие характеристики сложной динамики подобных систем.
Управление подобными системами рассматривает направление «управление хаосом»
Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент.

Именно этим принципом на моей памяти руководствывались все менеджеры, выбирая Oracle (ведь большинство успешных компаний юзает эту СУБД). Других аргументов не было. В итоге мы приходим к некоторому стадному эффекту.

Еще можно притянуть к статье принцип оптимальности/эффективности по Парето, когда система как целое не «убыточна» в широком смысле, но улучшение параметров какой-либо из компонент системы может обернуться негативно для остальных элементов.
притянуть в статью можно все что угодно,
один автор недавно притянул джеб кличко как новую методологию управления проектом и линейной деятельностью.
для писателя- это полезно, набивает руку писать тексты.
вопрос в том — а какой инструмент дает чтение такой статьи читающему? Какие задачи он после прочтения станет решать по другому? что это дает его мировоззрению?
не заценили выше принцип Шрека, хорошо — есть у меня и еще:
если вам не на чем больше прокрастинировать, как на подобных статьях — то… прокрастинируйте на здоровье. если уж все равно заняться больше нечем достойным.
принцип школьника — необходимо занимать свое мышление ЧЕМ НИБУДЬ, вдруг что-то из этого (тригонометрия или толстый роман Толстого) окажется когда-нибудь полезным. а не окажется — ну и хрен с ним мы не спешим, будем ждать вдруг окажется.
Немецкие менаджеры очень любят такую формулировку Принципа Паретто: «80% функциональности можно разработать за 20% бюджета». В соответствии с этим принципом начинают с самых «дешевых но сердитых» фичей. Такая «жадная» стратегия выбора фич часто приводит очень печальным результатам. Берлинский аэропорт и Гамбургская Опера тому примеры. Хотя конечно без коррупции там тоже не обошлось, имхо.
Но всё же это другая тема, имхо.
Принцип Паретто не имеет отношения к статье. Однако же так называемая «оптимальность по Паретто» вполне
НЛО прилетело и опубликовало эту надпись здесь
Вы посоветуйте своей знакомой прочитать вот эту статью в немецкоязычной Википедии. Стоило здание в итоге в 3.5 раз дороже, чем договаривались вначале. Строили его на 7 лет дольше запланированного. С помпой сдали, но после нескольких переломанных зрителями костей закоыли на ремонт. Он по сей день интенсивно ведётся в некоторых местах здания. Это я на этой неделе по телевизору слышал.
С математикой Ваша знакомая явно не в ладах. Посчитайте сами, как при паре не очень больших концертных залов, гостинице и нескольких ресторанах внутри здания можно за год заработать около 800 миллионов евро. Правда жизни такова, что город расчитывает за 20 лет отдать взятые под строительство кредиты. При этом город взял на себя много непрямых расходов по эксплуатации здания. Но знатоки относятся к этим расчётом очень скептически. И немецкое общество налогоплательщиков остро этот прект критикует.
Городской совет особенно и не возражает. Говорит что строительство затеяно из престижа, чтобы у города был символ, как у Парижа его знаменитая башня.
Вот в чём Ваша знакомая права — это с названием. Официальное название строения — Elbphilharmonie. Но в народе и даже по телевизору его всё-же часто называют оперой.
НЛО прилетело и опубликовало эту надпись здесь
Попробую продолжить правильную мысль andreyverbin – и чуть более расширенно описать факторы, благодаря которым, на мой взгляд (цитата) «Все удачные системы одной и той же предметной области похожи друг на друга». Понимаю, что сейчас выступлю в роли Кэпа. Но оно работает. Хотя, к сожалению, об этих простейших вещах часто забывают, что и порождает пресловутый САК…

1) Разработка «сверху вниз». Сначала проектирование «на бумаге» чёткой архитектуры проекта, проработка возможностей масштабирования, выбор инструментария и т.д. Только потом непосредственная разработка.
Этим должны заниматься разные люди. «Стратеги» определяют общий план (не вдаваясь в частности), «тактики» определяют методы его реализации (при необходимости указывая «стратегам» на эти самые частности). Сообща вырабатывают наиболее оптимальные решения, тем самым страхуя друг друга от ошибок проектирования и/или реализации. Поэтому в проекте критически важно наличие специалистов обоих типов.
В противном случае чаще всего получается печально знаменитый «индусский код», в процессе отладки которого ошибки могут множиться как головы Лернейской гидры – на месте одной пофиксенной появляются две новые…

2) В команде обязательно должен быть хотя бы один аналитик с так называемым «негативным мышлением», способный думать на несколько шагов вперёд. Который, конечно же, дико замучает всех своими опасениями – но зато с высокой долей вероятности «предскажет» все возможные риски, подводные камни и прочие слабые места.
Не в обиду (и не в упрёк) будет сказано, но непосредственные разработчики нередко просто физически неспособны на подобный критический анализ всего проекта, будучи полностью загружены решением локальных технических задач.

3) По возможности ограничить использование в крупных проектах сторонних библиотек и компонентов. Согласен, что писать самим нередко дольше и сложнее. Но в своём коде всегда проще разобраться и найти проблемные места. Кроме того, в этом случае можно будет с самого начала «заточить» все необходимые модули конкретно под архитектуру текущего проекта.
Впрочем, этот пункт сугубо ИМХО. Ситуации бывают разные.

4) И, наконец – грамотный менеджмент проекта, с чётко выстроенной иерархией и чётко прописанными должностными обязанностями.
Чтобы разработчики, с одной стороны, не метались между разнородными (и порой противоречащими друг другу) указаниями и комментариями различных начальственных инстанций, а с другой стороны – и не были предоставлены сами себе, действуя «кто в лес, кто по дрова».
Причём, все обсуждения желательно фиксировать в письменном виде – хоть в тех же мессенджерах. Увы, необходимая бюрократия. Но она значительно снижает риск появления «ничейных» ошибок (поиск которых в крупных проектах подобен поиску иголки в стоге сена). Поскольку всегда можно поднять «логи» всех указаний/комментариев – за счёт чего гораздо проще выследить всю цепочку ошибочных решений. На всякий случай, уточню: это не с целью «поиска крайнего», а именно с целью локализации проблемных участков проекта.

Вот как-то так видится…

P.S. К слову, в продолжение темы безвременно усопшей госпожи Карениной (а также в тон статье), многое из вышеперечисленного применимо и наоборот – к человеческим отношениям. Круг замкнулся. ))
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ценное дополнение к статье. Я думаю, общепризнанные философские принципы типа «Переход количества в качество», «Единство и борьба противоположностей» а также менее признанные типа «Принципы Анны Карениной» или упоминавшегося в одном из комментариев «Принципа Паретто» относятся ко второй категории. Они имеют очевидную предсказательную способность, но их границы определения очень трудно определить.

Причем теория о наличии двух видов теорий относится, по-моему, ко второму виду (шутка)


Время от времени и правда появляется желание все взять и обобщить.

Не все неустойчивое плохо и не все устойчивое хорошо.

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


Автор статьи немного не понял смысла сказанного в книге.
Арнольд как раз говорил о том что хождение по бревнышку — является пределом устойчивости, за границей которого находится канава. То есть свалиться в канаву с бревна у нас больше шансов, чем пройти по бревну невредимым.
Сначала я в конце цитируемого предложения поставил смайлик, но потом его удалил, вспомнив что на Хабре они не приветствуются. Так или иначе, это была попытка немного пошутить по ходу повествования. Но и в этой шутке есть доля правды. Я сравниваю на самом деле два состояния: движение по бревну и лежание в канаве. Вы же сравниваете шансы свалиться и не свалиться. Т.е. — наши высказывания друг-другу не протвиворечат, поскольку речь идет о разных сравнениях.
Прочитал с удовольствием! ИМХО статья есть иллюстрация к понятию энтропии.
Как раз в ИТ наблюдается обратное — схожие проблемы успешно решаются совершенно разными способами.
Задумался, а не является ли вариантом «Принципа Анны Карениной» старая сентенция: «Лучшее враг хорошего». Все «хорошее» более однородно чем «лучшее».
Я попытался в своей статьи оттолкнутся от филослфской части Принципа Анны Карениной и перейти к его конкретным проявлениям в области программирования и ИТ. Движение в противоположном направлении чревато издишним обощением у которого, как отметил PerlPower очень низкая предсказательная способность. Такие обощения описываются в частности фразами народной мудрости, фольклёром и т.д.
В общем — я думаю в определённом контексте Ваше утверждение верно.
С многими тезисами из статьи достаточно часто сталкиваюсь.

Принцип Анны Карениной верен только при очень упрощенной модели.
Причем, если упрощать "каждая несчастливая семья несчастлива по-своему" тем же способом, которым было получено "все счастливые семьи похожи друг на друга", то получится "все счастливые похожи друг на друга, все несчастливые похожи друг на друга".


Изложение принципа в приложении к одомашниванию тоже некорректно.
Одомашнивались животные очень по разному.
Сравните кошку и собаку и их контракты на жизнь рядом с человеком.
А если упрощать, то не одомашниваемые тоже "одинаковые". Для них просто не нашлось подходящего контракта с человеком (подходящего человеку, конечно).


В реальности же можно говорить об ограниченном количестве приемлемых известных решений (то самое "одинаковое счастье" в терминах принципа Анны Каренниной).
Но однажды находится кто-то, кто находит новое решение и открывает "новый способ быть счастливым", расширяя список решений. Но люди стремятся к упрощению, и принимая новое решение забывают о чем-то старом. А потому новый способ может оказаться как действительно новым, так и давно забытым старым.
А еще хуже, когда следуя принципу Анны Карениной всех загребают под одну гребенку, объявляя что-то одно верным и каноническим, а все остальное ересью, не признавая счастье тех, кто продолжает быть счастливым "неправильно". Но те, кто вроде должен быть одинаково счастливым, частенько оказываются по разному несчастными, пытаясь следовать "единственно правильному решению проблемы счастья".

Я не согласен со всеми Вашими заявлениями.
1) Принцип Анны Карениной это по-сути модель. Любая модель проще описываемой реальности. Если речь идёт о динамических системах, интересен аспект предсказательной способности модели. А она может быть и отрицательная и положительная.
2) Термин «одомашнивание животных» я использовал строго в соответствии с цитируемой книгой. Если Вы эту книгу не читали, очень советую прочитать. Если Вы под одомашниванием понимаете что-то другое, чем в книге, то сначала надо договориться о терминах. И только потом заявлять о правильности или неправильности.
3) Принцип Анны Карениной — это инструмент. Им можно пользоваться или не пользоваться. Можно пользоваться неправильно, «загребая всех под одну гребёнку».

Проблема в формулировке принципа, который провозглашается вне модели (сначала принцип, а только потом модель, соответствующая этому принципу). Формулировка слишком однозначна и не показывает цели моделирования.
Если бы формулировка была такой: "Все несчастные семьи несчастливы по своему, а счастливые нас не особо интересуют", претензий бы не было.

Боюсь что поздно выставлять претензии к автору цитаты про счастливые и несчастливые семьи (Шутка)
Если сторонняя оценка показателей «системы» плохая (у Анны она сначала была), то энергичное исправление видимых ошибок без объективной внешней оценки приводит к появлению новых, то есть «система» забуксовала в своей субъективности, поэтому следовало бы начать объективно разбираться с того места, когда показатели были относительно хорошие.
Так как все удачные «системы» одной и той же предметной области похожи друг на друга по объективным показателям во времени, то и каждая «система» может быть проблемная по своим субъективным показателям.
Проблемы могут возникать из-за решения лиц привлечь работников низкой квалификации с «экспериментальными» решениями, которые «проникают» в открытую и ослабленную «систему» из-за необходимости ее большей устойчивости во времени при осознаваемом обоюдном риске и энтузиазме получить эффект решения проблемы, а только потом оценку результатов (принцип «эксперимента").
Но итоге «система» выживет только так: объективная оценка — «высокая» квалификация – устойчивость системы с оценкой рисков – показатели – оценка показателей.
То есть Принципа Анны Карениной может и существует, но как недооценка или переоценка объективных показателей во времени, то есть как неудачный «эксперимент» с суммой субъективных оценок. Но остается «открытым» вопрос: нужны ли кому-то такие эксперименты?
Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в неустойчиво-хорошей части мира), вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.

… вам можно примерять лавры чудотворца. Вы умудрились устойчиво-плохую систему запихать в неустойчиво-хороший квадрант.
Ну или злого гения.

Спасибо за комплимент. Позвольте и мне. Более тридцати тысяч прочитали, а Вы первый обратили внимание и сообщили об опечатке. Я её исправил.
В музыке есть такое понятие как мейнстрим. В отличие от других направлений, мейнстрим, в среднем, не противоречит радикально вкусам большинства, подходит под большинство ситуаций и при этом не вызывает ощущения сильного диссонанса, тогда как андеграунд сцена, классическая или этническая музыка, например, подходят чаще только под конкретные ситуации, и, к тому же, имеют как своих отдельных ценителей, так и ярых противников, для которых большая часть того или иного жанра является явно неприемлимой для восприятия. Всё дело в природе мейнстрима, который постоянно вовлекает в своё звучание и мисседж отдельные элементы, наиболее удачные, с точки зрения восприятия окружающими, из других стилей и жанров. Эти элементы соответствуют конкретному культурному «состоянию», в котором они звучат уместно (современно, модно). Также из мейнстрима удаляются «устаревшие» элементы, по тем же критериям, соответственно. Что характерно, другие стили также не стоят на месте и, вместе со своим развитием, часто плодят новые жанры. И, не стоит забывать, что отброшенные прежде музыкальные элементы часто находят себе вторую жизнь как в новых для них стилях, так и возвращаясь в старые, уже после, и в других сочетаниях, порождая новое общее звучание и мисседж. То есть, получается одна стабильная линия, которая хоть и устойчивая, но достигающая эту самую устойчивость за счет своей непрерывной изменчивости, и, множество менее стабильных, часто сильно флуктирующих, но вместе с тем порождающих нужные мутации, в том числе и для «стабильной».
Это я к чему — а к тому, что Принцип Анны Карениной, безусловно есть и в IT, и в других сферах, но нужно понимать, что делая что-то похожим на удачную систему, мы получаем тот же мейнстрим, который также будет хорошо сконфигурирован и использующим best practicies, актуальными прежде всего на текущий момент времени в текущей среде. Используя же экзотику, шанс нарваться на неработающий где-то приём возрастает пропорционально её экзотичности. Однако, именно экзотичность привносит что-то новое в среду, меняя её и открывая дорогу как новым приёмам, так и старым, незаслуженно забытым ранее (или точнее заслуженно, но на тот момент времени). Часто экзотика просто опережает своё время, находя применение только в, уже, другой среде. Поэтому, естественно, всегда, самым надежным и гарантированно работающим будет способ максимально близкий к успешному в данный момент времени. Но время течет, меняется среда — меняется способ, и, через n-ое количество лет, возможно никто и не подумает решать ту или иную задачу так, как сейчас может казаться безальтернативным.
Поэтому, понимание текущей среды и динамики её развития позволит как внедрять в свои системы «правильную» экзотику, так и задавать, тем самым, «моду» на мейнстрим.
Я с Вами несогласен. Ваша аналогия не верна, как мне кажется. Музыкальное направление Рэп наверное было бы поднято насмех лет 30-50 назад. Тогда в моде были (в Европе) Диско, итальянцы, потом Техно. Сейчас они не в «майнстрим». А плохо спроектированный самолет, реактор или система обслуживания склада из тех лет сломался бы и тогда и сейчас.
Другими словами: технические законы не зависят от времени в отличие от привязанностей публики в той или иной точке нашего земного шарика.
Про музыку: есть такое явление, как возврат моды — тогда вспоминаются 60-е, 70-е, 80-е и иногда частично переносится звучание от туда, но с новым оттенком. Как самый простой пример ремейки старых композиций.
А касательно плохоспроектированного — почему речь должна идти именно о плохоспроектированном. Можно допустим построить концепт самолёта, такой, для прочности которого нужны другие материалы, недоступные сейчас. Он не сможет летать сейчас так как хотелось бы, но сможет потом.
Если мы говорим о фундаментальных законах физики, то да, они зачастую неизменны, но и в них иногда вносятся поправки временем, как в закон всемирного тяготения Ньютона например. А если говорить о среде, тут дело другое — сейчас мы летаем на самолётах, но кто сказал, что потом не будем летать на условных летающих тарелках с антигравитационной тягой, а не турбореактивной и какие-то инженерные идеи пригодятся для них, а какие-то канут в лету, а может так станется, что вспомнится какая-то ранее забракованная идея, которая вполне будет уживаться в рамках полётов на летающих тарелках. Вопрос во взятом масштабе.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.