Применимость математики

> мой тезис прост: если задача решается интуитивно - это прекрасно, но этого совершенно недостаточно, требуется строгое доказательство, ибо «интуитивное решение», сколь гениальным оно бы ни было бы, даёт на выходе лишь гипотезу

«Строгое доказательство» мы можем получить только тогда, когда посмотрим на результат (взошло Солнце или нет). Мы всегда получаем доказательство с той или иной степенью строгости, которая нас удовлетворяет - либо не удовлетворяет. Конечно, если степень строгости, которую предоставляет нам интуиция, нас не удовлетворяет (задача предполагает слишком сильные риски, чтобы полагаться на интуицию, например), то нам следует использовать другие способы решения. Я с этим не спорил, более того - сам об этом говорил в самом начале.

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

а, ну тогда иди наблюдай за орбитами электоронов

На научном симпозиуме общаются при помощи пространных намеков, всячески избегая говорить конкретику?

с т.з. пресловутого пятиклассника - вне всякого сомнения

> И у тебя есть вся информация вселенной, Господи?

Вот мы и подходим к главному. Не важно, где информация находится ДО проведения эксперимента, главное, что _у нас_ ее нет. А вот после эксперимента - у нас информация есть. Например, о существовании вывода математического утверждения.

Это пространный намек на то, что не просил? Или как? Ну может не ты, кто-то другой. Чего ты то тогда влез?

вот до чего доводит поедание мелков против тараканов

//деменция, как она есть

> а, ну тогда иди наблюдай за орбитами электоронов

В науке нам не нужна максимальная строгость, нам нужна строгость, которая приносит гарантированный профит (повторяемость результата). Вот и все.

> с т.з. пресловутого пятиклассника - вне всякого сомнения

Я думаю, это не так с точки зрения кого угодно.

> А вот после эксперимента - у нас информация есть. Например, о существовании вывода математического утверждения.

Тупой, ну как есть тупой.

У нас есть ВСЯ информация, которую можно получить внутри математической теории. Эта информация - аксиоматика теории. Выводы информации не добавляют.

«Строгое доказательство» мы можем получить только тогда, когда посмотрим на результат (взошло Солнце или нет).

встающее солнце - это прекрасно, проблема в другом, как, например, Вы собираетесь подтвердить наблюдениями образование кварк-глюонной плазмы после некоего события, произошедшего всего-то с десяток миллиард лет тому назад?

если степень строгости, которую предоставляет нам интуиция, нас не удовлетворяет

повторюсь: в результате срабатывания интуиции мы можем получить лишь гипотезу, которая нас в подвешенном состоянии никак не устраивает

Вы хоть какое-то отношение к науке имели, хоть кода-нибудь вообще? похоже, что - нет

> наблюдай за орбитами электоронов

В науке нам [..] нужна строгость, которая приносит [..] повторяемость результата [..]

тред полный угарщиков :)

Я думаю, это не так с точки зрения кого угодно.

я ж ведь сейчас пруф попрошу, строгое математическое доказательство, что с точки зрения «кого угодно»

> Физика, Проектирование электронной аппаратуры

математики все меньше и меньше

Вы ничего не путаете? Вот тут как раз математики становится все больше.

Программирование

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

Экономика, Менеджмент.

Варианты «там адепты все тупее и тупее» не рассматриваются.

Тогда вариантов нет.

Вместо того, чтобы пилить алгоритмы,

бизнес-логику,

Бизнес-логика тоже алгоритмика, только специфическая.

«Пилить алгоритмы» - просто нет такой задачи в бизнес-программировании, зачем их пилить - они простые. Проблема как бы не в алгоритмах, а в том как все работает вместе, в системе как конечном результате. Управление сложностью, системная инженерия и т.д.

>> Программирование

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

А возможна ли она вообще на таких изначально некрасивых задачах?

Вот jtootf тут угощал нас катаморфизмами, но имеют ли они практическую применимость в задаче написания мощного и безглючного движка магазина, например?

Чтобы стрелочками теории категорий можно было гарантировать, что пользователь при любых раскладах и действиях не окажется в безвыходной ситуации?

И как будет выглядеть процесс написания такой программы, на каком языке? Можно ли будет описать все функционально, а потом перевести в PHP, допустим?

> зачем их пилить - они простые.

Разные бывают. Но сложные действительно редко.

Управление сложностью, системная инженерия и т.д.

Т.е. для самых сложных и важных задач математика то как раз и не очень то и нужна.

> зачем их пилить - они простые.

Если что, я это и имел в виду под «отсутствием алгоритмов».

Собственно, о чем я и говорил - на большинстве современных программерских задач математика совсем не нужна. Но это не значит, что на всех. Лично я - счастливый «алгоритмополильщик».

> Лично я - счастливый «алгоритмополильщик».

Или несчастный тупокодер? ;)

Увы, я больше работаю с математическими пакетами, нежели что-то кодирую.

Чтобы стрелочками теории категорий можно было гарантировать, что пользователь при любых раскладах и действиях не окажется в безвыходной ситуации?

Все эти стрелочки с монадами по сути паттерны микродизайна. Только вот паттерны не имеют отношения ни к управлению сложностью, ни к формальной верификации, ни к моделированию домена.

Вообще для моделирования домена есть вон IDEF. Функциональный подход «в тупую» ничуть не лучше процедурного, можно только IDEF0 реализовать. Конечно можно построить какую-то систему моделирования на основе ФП, но опять же стрелочки с катаморфизмами «не про то».

А, ну это просто другой вид деятельности. Который к программированию относится достаточно условно. Да, программисты в том числе могут решать и всякие алгоритмические/расчётные/и т.п. задачи. При этом обычно требуется более высокий уровень математической подготовки, а чисто программистские навыки (борьба со сложностью, модульностью и т.п.) находятся на втором плане. Схожая ситуация с разработчиками железа, который пишут для него всякие драйвера - смотреть на их код без слёз обычно нельзя.

>>Вообще для моделирования домена есть вон IDEF

Стоп, а как сам IDEF-то как-то позволяет обкатать систему, описанную с его помощью? Есть ли там какой-то формализм, помогающий доказывать безглючность? Или это тупо для описания, а баги отлавливаются прогонами самой программы?

Очень хороший вопрос :) Подразумевается, что специалист из предметной области или аналитик валидирует IDEF модель, на глаз естественно. А верификация (соответствие системы спецификации) происходит конечно ручным тестированием. Но это недостатки IDEF, а не моделирования вообще. Да, вот на таком убогом уровне находится разработка прикладухи, и даже на хаскеле.

> а чисто программистские навыки (борьба со сложностью, модульностью и т.п.)

Как раз борьба со сложностью - работа таких как я. Или вы имели в виду какую-то другую сложность?

Цели чисто программерских навыков - это понятность, масштабируемость, поддерживаемость кода и т.п. В общем, то, что обычно не беспокоит математиков.

Т.е. для самых сложных и важных задач математика то как раз и не очень то и нужна.

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

> Или вы имели в виду какую-то другую сложность?

Я имею в виду сложность программной системы, с которой нужно бороться и оставлять систему простой.

> Сложные и важные задачи отличаются комплексным подходом

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

По вашему, задача сложная, если неизвестны к ней подходы? Это называется малоизученностью. Может настолько сложного там ничего и нет, просто время решения еще не пришло. И через N лет даже быдлокодер сможет с успехом это применять.

с которой нужно бороться и оставлять систему простой.

Вот тут мне, кажется, есть доля лукавства. Простота не есть цель, а средство. Цель - управлять системой. Если у нас нету формальных методов, то управлять мы можем только тем, что понимаем интуитивно. В таком случае система не может быть сложнее той, что понимает разработчик интуитивно. От туда бешеный спрос на программистов-гениев. Если брать ту же механику, то инженер может спроектировать сколь угодно сложное строение, один фиг CAD сама все просчитает и сообщит, если конструкция не надежная.

> Если брать ту же механику, то инженер может спроектировать сколь

угодно сложное строение, один фиг CAD сама все просчитает и сообщит,

если конструкция не надежная.

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

> а, ну тогда иди наблюдай за орбитами электронов

Есть проблема — существующие методы наблюдения могут выдать такое:

фото раз и фото два

P.S. Это не фейк и не фотошоп. Это роллинг шаттер

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

> Но мы можем избегать сложных задач за неимением способа их решить

Э, меня на совещание переставали брать, из-за того, что я брался всё сделать )) Отказ от разных сложных задач является типичным для IT-отделов. Но я не об этом. Я именно о необходимости делать системы максимально простыми. Просто, это очень сложно, очень сложно оставлять систему простой. Это требует глубокого анализа и понимания, предвидения и т.п. Найти просто решение часто оказывается очень сложно.

Да, с этим я согласен и даже пропагандирую :)

> а, ну тогда иди наблюдай за орбитами электронов

Есть проблема — существующие методы наблюдения могут выдать такое:

это был сарказм

Э, меня на совещание переставали брать, из-за того, что я брался всё сделать ))

Гы. Менеджмент, фигли. )

> это был сарказм

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