LINUX.ORG.RU

[ЖЖ] *морфизм, Haskell & Lisp

 


3

1

Вот все праздники разбирался с Template Haskell, квазицитированием, SYB и ghc7, не забывая такие важные вещи как распитие спиртных напитков и игру в FreeCiv :)

И вот какая идея мне пришла в голову... Катаморфизм ведь — штука всеобъемлющая, и если лисперы могут называть свои S-выражения алгебраическими типами данных, то почему же мы не можем называть алгебраические типы данных S-выражениями?

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

Единственное, «но» в подходе лисп-систем к компиляции, там компилятор «внутри», а не «с боку» как в более традиционных подходах. А так, работы ведутся, та же Java, та же Scala позволяет вмешиваться в работу компилятора. А в GHC есть Template Haskell, который идеологически близок к лисповским макросам, с той только разницей, что они стоят по разные стороны относительно катаморфизма: лисп как списки, хаскель как алгебраические типы с соответствующей типизацией.

В ООП языках все еще интереснее, там для реализации лисповского подхода нужно две вещи: а) классы должны быть объектами первого класса; б) должен быть способ узнавать конкретный тип объекта в рантайме. В Яве есть и первое (на худой конец в рамках JVM), и второе. В С++ есть RTTI, а вот с первым дела обстоят вроде бы не очень, хотя Александреску в своей книге показывал, вроде бы, как можно генерить иерархию классов с помощью шаблонов. Про Scala, вообще молчу, там алгебраические типы «из коробки» имеются.

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

★★★★★

Ответ на: комментарий от www_linux_org_ru

Да, я видел другие языки и сужу не только по C++, но...

Если вернутся к обсуждаемой ситуации: при отключённом интернете прога валилась с сообщением о вызове несуществующего метода. В принципе, ситуации аналогична «перерубили сетевой кабель топором». Для того, что бы корректно обрабатывать подобные ситуации необходимо что бы разработчик проанализировал подобный вариант и расставил специальные обработчики. Иначе, прога будет валиться с тем или иным сообщением. И никакая проверка типов не способна гарантировать корректную работу программы при перерубании провода если разработчик не реализовал соответствующую логику.

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

archimag ★★★
()
Ответ на: комментарий от archimag

> И никакая проверка типов не способна гарантировать корректную работу программы при перерубании провода если разработчик не реализовал соответствующую логику.

да

В данном случае разработчики этого не сделали.

да, но не только

Всё что было нужно - это запустить свой софт без интернета и они тут же увидели бы проблему.

нет

все что было нужно — нормальная система типов; компилятор бы не пропустил исходную прогу, спросив «а че ты будешь делать, если этот метод вернет none?» (или че там вместо нулл)

конечно, ленивый программер мог бы написать заглушку, но осталось бы FIXME/TODO, либо прога ловила исключение на верхнем уровне и писала че-то внятное «сорри, нет инета... работать не буду», а не стэктрейс.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> ну так можно отвлечься немного и все же выяснить, колько и каких

тестов надо написать, чтобы 100% быть уверенным, что нигде не

вызывается неопределенная функция



Гарантировать этого, конечно, нельзя. В динамических языках и не нужно.

archimag ★★★
()
Ответ на: комментарий от archimag

> Гарантировать этого, конечно, нельзя. В динамических языках и не нужно.

Это ты к тому, чтобы ловить исключение «вызов неизвестного метода» и юзать к своей выгоде?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> а че ты будешь делать, если этот метод вернет none?

Интересный момент. Это называется стратегия обработки ошибок. Сейчас используется в основном два механизма для сообщений об ошибках: коды ошибок и исключения. Ты о каком варианте? Что должна делать функция в случае ошибки, возвращать специальное значение или подымать исключение? И как это должно соотносится с системой типов?

archimag ★★★
()
Ответ на: комментарий от archimag

Покажи хоть один eDSL, который ты написал.

Я вижу только бредятину и отговорки в стиле «сам дурак».

Пока что факты такие:

1) Ты абсолютно не разбираешься в [e]DSL - ни в методах их построения, ни в практике их применения.

2) Ты не разбираешься в макросистеме CL, несмотря на то, что она довольно проста, а по факту, вообще избегаешь ее, боишься ее использовать. Отчасти потому, что прочитал один не очень компетентный пост-нытье, не разобрался в вопросе, но зато проникся авторитетом автора(не будем упоминать этологию всуе, так и быть).

3) Ты не разбираешься в макросистемах R5RS и Racket, скорее всего ты их в глаза не видел

4) Ты понятия не имеешь о том, что такое Template Haskell. Поскольку ты не разбираешься в макросистемах уровнем выше препроцессора Си, настоящие достоинства и недостатки TH ты понять не в состоянии, и привлекает тебя из TH только terseness синтаксиса(которую ты принимаешь за conciseness, и, как следствие, за большую выразительность).

5) Ты невыразимо туп. Ох! Я не мог этого не сказать.

И не надо ко мне на «вы»(на «Вы» тоже не надо) - это только показывает, насколько низок твой культурный уровень. Обращение на «[Вв]ы» в контексте современной культуры это провинциальное мещанское лицемерие.

anonymous
()
Ответ на: комментарий от archimag

> Интересный момент. Это называется стратегия обработки ошибок. Сейчас используется в основном два механизма для сообщений об ошибках: коды ошибок и исключения. Ты о каком варианте? Что должна делать функция в случае ошибки, возвращать специальное значение или подымать исключение? И как это должно соотносится с системой типов?

Я об обоих. Их оба можно сделать полностью проверяемыми компилятором... хотя есть нюансы.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Это ты к тому, чтобы ловить исключение «вызов неизвестного метода»

и юзать к своей выгоде?


Нет, я к другому. В CL вызов несуществующий метод в обычном коде вызовет предупреждение компилятора, а нормальные разработчики обычно стараются, что бы никаких предупреждений не было. Так что основная проблема это funcall или apply. И тут есть две ситуация. Первая - по логике данный вызов должен безусловно быть и тогда разработчик должен убедиться что он есть, непосредственным запуском кода и/или написание тестов. Вообще, в таком случае что бы где-то был вызов несуществующего метода и что бы это прошло через тесты и через простое тестирование работоспособности приложения - я такого никогда не видел. Вторая - метода действительно может не быть и разработчик знает об этом на этапе разработки, тогда он должен предусмотреть адекватную реакцию, ибо это есть часть логики программы.

archimag ★★★
()
Ответ на: комментарий от www_linux_org_ru

> Их оба можно сделать полностью проверяемыми компилятором...

хотя есть нюансы.


Да ну? Только проблема ведь в другом. Мне приходилось работать с API, который надо было очень часто вызывать и в котором каждый вызов возвращал код ошибки, который надо было проверять. Ошибки при этом реально случались часто, так что это не было пустой формальностью. Не проверил ошибку, не среагировал на неё правильно и всё, система поплыла в непредсказуемое поведение. Когда я пришёл в проект основная часть кода это была обработка ошибок, разработчики не вылазили из отладчика и всё равно не могли добиться стабильной работы софта. Я к тому, что писать абсолютно корректный код бывает черезвычайно тяжело и затраты просто того не стоят.

archimag ★★★
()
Ответ на: комментарий от anonymous

> Покажи хоть один eDSL, который ты написал.

Мой код здесь: http://github.com/archimag, если способны читать код, то без труда найдёте там DSL, eDSL, а также широкое использование макросистемы в различных вариантах.

Ты невыразимо туп.


Конечно. Я рад, что вы нашли ещё одну возможность сказать мне это. Мне нравится доставлять людям радость.

archimag ★★★
()
Ответ на: комментарий от archimag

> где результат по определению логически выводим из исходных данных.

Вы забываете, что является результатом в математике. Там результат - это не теорема (которая сама по себе никому не нужна), а само ее доказательство, и методы, созданные специально для этого доказательства. Или какие-то способы нетривиального использования уже существующих методов. Это ниоткуда не выводится.

anonymous
()
Ответ на: комментарий от anonymous

> TH с макросами CL и рядом не стоял. Максимум - рядом со схемовскими.

Мне интересно, хоть один адепт общемакросов ознакомился с другими макросистемами, прежде чем делать такие вот икспертные заявления? Практика показывает, что нет. Господа, ну не позорьте вы CL своими безграмотными высерами.

anonymous
()
Ответ на: комментарий от Waterlaz

> Ты просто плохо знаешь физику и главное, чем занимаются многие физики.

Когда физика отрывается от эксперимента - она становится разделом математики :)

anonymous
()
Ответ на: комментарий от anonymous

> 3) Ты не разбираешься в макросистемах R5RS и Racket, скорее всего ты их в глаза не видел

4) Ты понятия не имеешь о том, что такое Template Haskell.

Лавсан, ну ты же тоже в этом не разбираешься.

Покажи хоть один eDSL, который ты написал.

Так сколько строк занимает реализация loop в cl?

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>ммм... как ты сделаешь композицию функций в си без модификации исполняемого кода?

Функция берет два указателя на функцию, возвращает третий. Можно засунуть два указателя в структуру и специальным образом обрабатывать. Естественно композиция будет полностью ad-hoc. Можно написать библиотеку, хотя тут никакой статический проверки не будет.

Вот только зачем?

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

> Функция берет два указателя на функцию, возвращает третий.

Третий указатель на что? Лямбд в си нету. Так что сначала придется сделать лямбды и замыкания через структуры.

anonymous
()
Ответ на: комментарий от archimag

>и в котором каждый вызов возвращал код ошибки, который надо было проверять

А вот в это-то и была главная ошибка разработчиков. Они элементарно за деревьями леса на заметили.

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

А то начинается: процедура проверяет свои параметры на корректность, процедура пытается «исправить» свои параметры, процедура все-равно фейлит, процедура пытается исправить последствия своего фейла, процедура все-равно дохнет. В логику вызывающей процедуры добавляется еще одно измерение, учитывающее то, что вызываемая процедура может сфейлить. Код превращается в аццкую лесенку ажурной формы. ПОТОМУ ЧТО Б... РАЗРАБОТЧИКИ СМЕШАЛИ ЛОГИКУ КОМБИНАЦИИ И ЛОГИКУ ПРЕДМЕТНОЙ ОБЛАСТИ. И ессно, они в отладчике будут жить. И все ресурсы будут направлены на поддержание работы кода. Постоянными пинками.

Так вот, поэтому и нужны комбинаторы в программе. Они берут на себя логику связывания, и как только кто-то из цепочки сфейлит, комбинатор перестанет работать и последнее фейловое значение придет (если придет конечно) нужному обработчику. Кстати схожим образом работает try-catch, правда он явно вмешивается в поток, из-за чего приходится держать секцию finally. Показателен ерланг, в случае возникновения ошибки соответствующий процесс умирает, и далее по цепочке умирают все вызывающие процессы, пока не наткнуться на соответствующий процесс-супервизор, который знает как бороться с фейлами.

Так что ошибки должным образом умеет обрабатывать не только CL. Кстати, как я понимаю там именно в случае фейла какой-то формы блокируется дальнейшее вычисление S-выражения, до тех пор пока поток не дойдет до соответствующего обработчика, разве не так?

Macil ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Третий указатель на что?

На третью функцию, написанную ручками. Или сделанную через макросы. Сказал же что будет полный ad hoc. ;))

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

На третью функцию, написанную ручками. Или сделанную через макросы.

Ну это не будет работать. Например есть у нас функция add, которая добавляет единицу к аргументу, тогда что-нибудь вроде:

f = add;
for (i = 0; i < n; i++) f = compose(add, f);
f(0);
Сразу обламывается.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> отсутствие типа «не-нулл-указатель-на...»

Скорее, «инициализированный/неинициализированный укаазтель на...».

one_more_hokum ★★★
()
Ответ на: комментарий от www_linux_org_ru

> все что было нужно — нормальная система типов; компилятор бы не пропустил исходную прогу, спросив «а че ты будешь делать, если этот метод вернет none?» (или че там вместо нулл)

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

one_more_hokum ★★★
()
Ответ на: комментарий от www_linux_org_ru

>А как это могло вы выглядеть «правильно»? Приведи пример.

Да также и будет «правильно», как и в любом ООП-языке! С одним «но». Мы уберем требование реализации всего интерфейса, поскольку нам не нужно больше выполнять LSP.

Macil ★★★★★
() автор топика
Ответ на: комментарий от one_more_hokum

>Интересно, какие границы применимости имеет этот вывод?

Да, мне это тоже интересно.

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

> Они берут на себя логику связывания, и как только кто-то из цепочки

сфейлит, комбинатор перестанет работать и последнее фейловое значение

придет (если придет конечно) нужному обработчику



Я не совсем понял, что из этого следует и совсем не понял, как это применить на практике для работы с C-API.

Кстати схожим образом работает try-catch, правда он явно вмешивается

в поток, из-за чего приходится держать секцию finally.



Не понял, С++ прекрасно живёт без finally, так что дело не в этом.

Так что ошибки должным образом умеет обрабатывать не только CL


Да я вообще говорил не о CL, а о том, что написание абсолютно корректных программ в реальности дело очень тяжёлое и если компилятор будет обязательно требовать обработки всех возможных ошибок, то программировать на таком языке чрезвычайно тяжело. Может для ядреных станций так и надо, но в практике большинства - нет.

archimag ★★★
()
Ответ на: комментарий от archimag

>как это применить на практике для работы с C-API

C чистым C-API никак. Писать обертку только. Что собственно и делается. Причем иногда писать ее приходится с двух сторон: со стороны целевого языка и со стороны C. Например, в ерланге.

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


Я кажется написал что это наивный подход и ведет он тупик.

Я не совсем понял, что из этого следует


Я даже не знаю как тебе объяснить... Ты представляешь как работает хаскельный >> ?

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

> Я кажется написал что это наивный подход и ведет он тупик.

Тогда я вообще не понял, что именно вы хотите сказать. Началось всё с того, что была сказана мысль, что мол «правильная статическая типизация» должна это делать.

archimag ★★★
()
Ответ на: комментарий от archimag

>«правильная статическая типизация» должна это делать.

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

Можно много и долго объяснять «зачем и почему», но thesz'у этого сделать не удалось, а мне уж и подавно, так что и не буду больше пытаться. Не хочешь - не надо.

Macil ★★★★★
() автор топика
Ответ на: комментарий от Macil

> Короче, пойми как работает комбинатор >>

Вы можете просто на пальцах попытатся объяснить, как он ГАРАНТИРУЕТ корректную работу сетевого приложения при перерубании сетевого кабеля топором? Велось обсуждение именно этой ситуации.

archimag ★★★
()
Ответ на: комментарий от Macil

> почему он не может работать без статической типизации

Потому что сможет. Это свойство всех любителей хаскеля - все, что невозможно в хаскеле, объявляется невозможным в принципе. Вот нельзя в хаскеле сделать >>, если убрать статическую типизацию - значит нигде нельзя сделать аналог >> без статической типизации. Хотя на самом деле все элементарно - достаточно заметить, что >>= - это всего-навсего переопределенный apply, значит если мы редуцируем код до вида, в котором все вхождения apply явны (что легко делается при помощи dsl, кстати в том же хаскеле с монадами тоже работают при помощи заранее заданного dsl), то мы можем заменить apply на фунарг. тогда мы можем спокойно писать монадический код, в результате получить параметризованную монадой функцию, а потом когда надо этот код исполнить - подставлять нужную монаду.

anonymous
()
Ответ на: комментарий от Macil

> Задача любой логической единицы программы в случае возникновения ошибки только одна: сдохнуть как можно быстрее. В надежде на то, что где-то «ниже по течению» ошибку смогут обработать.

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

как только кто-то из цепочки сфейлит, комбинатор перестанет работать и последнее фейловое значение придет (если придет конечно) нужному обработчику.

Ты как будто пытаешься дискредитировать идею комбинаторов.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ты как будто пытаешься дискредитировать идею комбинаторов.

П-р-р-рошу подняться на трибуну!

Macil ★★★★★
() автор топика
Ответ на: комментарий от archimag

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

эдак ты договоришься и до того, что в экспериментальной физике тоже нет творчества ибо тоже выводимо. Творчество в математике есть, и заключается в выборе подхода и метода, как и в постановке эксперимента. Ту же теорему Ферма (великую) несколько раз доказывали, а теорему Пифагора раз 200. Что это, как не творчество?

Собственно, эта самая «не уникальность» результата многократно и наблюдалась на практике.


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

anonymous
()
Ответ на: комментарий от archimag

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

ключевое слово «для выбранного диапазона и выбранного эксперимента». Чем обусловлен выбор? В том числе задачей и теорией, методом.

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

вернулись к тому, от чего пришли: модель описывает эксперимент, который выбран исходя из теории и её логики. Была бы другая теория — был бы другой выбор и другая модель. А из чего следует выбор именно этой теории? Из другого эксперимента и другой модели, из другой теории. И так далее. То есть выбор не произволен, а опять таки зависит от некоторой глобальной охватывающей «теории всего».

anonymous
()
Ответ на: комментарий от anonymous

> Ту же теорему Ферма (великую) несколько раз доказывали

А не пойти-ка вам подальше с такой икспертизой?

anonymous
()
Ответ на: комментарий от anonymous

> Ту же теорему Ферма (великую) несколько раз доказывали, а теорему

Пифагора раз 200. Что это, как не творчество?


Вы можете сесть и придумать своё доказательство и с очень большой вероятностью обнаружите потом его среди этих 200. Т.е. результат повторяем, другой человек может получить точно такой же результат. А результат творчества уникален, его не может повторить другой человек.

Я примерно так готовился к эзаменам по матану. Брал билеты, читал вопросы, находил определение теоремы и пытался самостоятельно доказать. Обычно у меня это получалось (за редкими исключениями) и я понимал, что смогу снова повторить доказательство в условиях экзамена. И я переходил дальше. На экзамене я придумывал доказательства снова и у преподователя не возникало вопросов, он знал это доказательство, ибо я просто, сам того не зная, повторял то, что было сделано до меня. Точнее, я на самом деле заранее знал, что хотя и придумываю доказательство сам, но ничего оригинального при этом не создаю.

Что это, как не творчество?


Хм, мыслительная деятельность?

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

творчества.



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

archimag ★★★
()
Ответ на: комментарий от anonymous

> модель описывает эксперимент, который выбран исходя из теории

и её логики.


Угу, почитайте историю созданию СТО.

то есть выбор не произволен, а опять таки зависит от некоторой

глобальной охватывающей «теории всего».



Вы с такой знакомы?

archimag ★★★
()
Ответ на: комментарий от archimag

> Вы можете сесть и придумать своё доказательство и с очень большой вероятностью обнаружите потом его среди этих 200.

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

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

С этого и надо было начинать. Не стоит делать какие-то выводы о математике, исходя из стандартного курса матана, он же заточен специально под обучение неофитов. Подавляющее большинство теорем там очевидно, доказывается очевидным способом и единственная сложность - изложить это решение формально строго. За тем студентов и заставляют учить эти теоремы - чтобы они поднатаскались в использовании формализмов. Творчество здесь именно в том, чтобы создать этот формализм. Исчисление бесконечно малых существовало более сотни лет, прежде чем придумали, как его можно формализовать. И, кстати, насчет повторного результата - вот тот же матан, фактически, придуман дважды. ньютоном и Лейбницем. Но ничего, что это _разный_ матан? Да, результаты эквивалентны, но мы и по сю пору пользуемся матаном Ньютона, а то, что пытался создать Лейбниц, получилось обосновать лишь недавно с появлением нестандартного анализа. Или оставим матан - откройте учебник по алгебре. Видите там - «группы», «кольца», «поля»? Вы думаете, эти понятия боженька дал? Нет, их тоже придумали, и это было весьма нетривиально. Более того - исследования Галуа вообще не были поняты современниками, натурально. Ну о каком повторении речь, приходит в академию наук готовая работа ее читают, и выносят вердикт «нет, это плохая математика, негодная, идите к черту»? И только потом, уже после смерти автора ВНЕЗАПНО оказывается, что ага. Просвещайтесь, короче, и не несите больше чушь.

anonymous
()
Ответ на: комментарий от anonymous

> Угу, почитайте историю созданию СТО.

СТО была создана из-за того, что уравнения Максвелла не соответствовали эксперименту (не были инвариантны относительно преобразований Галилея). И как это противоречит процитированным вами словам?

anonymous
()
Ответ на: комментарий от anonymous

> И как это противоречит процитированным вами словам?

Набор экспериментальных данных, на которых была основанна СТО, был получен вовсе не под влиянием СТО. Эксперименты, спроектированные именно под влиянием СТО стали проводиться фактически только после 1917 года.

archimag ★★★
()
Ответ на: комментарий от archimag

Блин, разберитесь с понятием творчества.

Заглянем в википедию:

Творчество — процесс человеческой деятельности, создающий качественно новые материальные и духовные ценности или итог создания субъективно нового. Основной критерий, отличающий творчество от изготовления (производства) — уникальность его результата. Результат творчества невозможно прямо вывести из начальных условий. Никто, кроме, возможно, автора, не может получить в точности такой же результат, если создать для него ту же исходную ситуацию. Таким образом, в процессе творчества автор вкладывает в материал некие несводимые к трудовым операциям или логическому выводу возможности, выражает в конечном результате какие-то аспекты своей личности. Именно этот факт придаёт продуктам творчества дополнительную ценность в сравнении с продуктами производства.

и чему здесь математика не удовлетворяет?

anonymous
()
Ответ на: комментарий от archimag

> Набор экспериментальных данных, на которых была основанна СТО

СТО основана на одном конкретном наблюдении - динамика процесса не зависит от системы отсчета. Ваша логика меня просто удивляет. По-вашему вот нечего было делать физикам, они сели и решили - а чего бы нам не сделать новую теорию? Так?

anonymous
()
Ответ на: комментарий от anonymous

> СТО основана на одном конкретном наблюдении

Ой, наврал. Еще уравнения Максвелла - они ведь тоже получены экспериментально. Но все равно 1917 годом тут и не пахнет.

anonymous
()
Ответ на: комментарий от anonymous

> чему здесь математика не удовлетворяет?

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

archimag ★★★
()
Ответ на: комментарий от archimag

Любой математический результат является повторяемым.

Да где же он повторяем? То есть, по-вашему, если взять прорву математиков, то рано или поздно кто-то из них придумает, например, топологию или теорию групп в том виде, как они сейчас есть? А если обезьяну посадить за печатную машинку - то она когда-нибуь напишет «Войну и мир», ага.

anonymous
()
Ответ на: комментарий от anonymous

> СТО основана на одном конкретном наблюдении - динамика процесса

не зависит от системы отсчета.


Вы сказали что-то очень мутное. Кроме того, всё как раз наборот, ведь очень даже зависит, это же - теория ОТНОСИТЕЛЬНОСТИ! )

К созданию СТО привело наличие экспериментальных данных, которые ставились в рамках обоснования теории эфира и которые совершенно не укладывались в данную теорию. Что привело к созданию совершенно неожиданной теории, которая просто противоречит нашему здравому смыслу, но которая удивительным образом объяснила всё и дала верные предсказания.

archimag ★★★
()
Ответ на: комментарий от archimag

> Вы сказали что-то очень мутное. Кроме того, всё как раз наборот, ведь очень даже зависит, это же - теория ОТНОСИТЕЛЬНОСТИ! )

Именно что не зависит. Теория ОТНОСИТЕЛЬНОСТИ, потому что принцип ОТНОСИТЕЛЬНОСТИ - который как раз и гласит, что во всех инерциальных СО физические процессы протекают одинаково :) А из уравнений Максвелла следовало, что как раз-таки по-разному. Значит что? Либо гонят уравнения Максвелла, либо преобразования Галилея.

anonymous
()
Ответ на: комментарий от anonymous

> потому что принцип ОТНОСИТЕЛЬНОСТИ - который как раз и гласит, что

во всех инерциальных СО физические процессы протекают одинаково :)


Черт, затрудняюсь как-то трактовать ваши слова. СТО гласит об инвариантности законов природы относительно преобразований Лоренца.

archimag ★★★
()
Ответ на: комментарий от archimag

>Вы можете сесть и придумать своё доказательство и с очень большой вероятностью обнаружите потом его среди этих 200. Т.е. результат повторяем, другой человек может получить точно такой же результат. А результат творчества уникален, его не может повторить другой человек.

Я примерно так готовился к эзаменам по матану. Брал билеты, читал вопросы, находил определение теоремы и пытался самостоятельно доказать. Обычно у меня это получалось (за редкими исключениями) и я понимал, что смогу снова повторить доказательство в условиях экзамена. И я переходил дальше. На экзамене я придумывал доказательства снова и у преподователя не возникало вопросов, он знал это доказательство, ибо я просто, сам того не зная, повторял то, что было сделано до меня. Точнее, я на самом деле заранее знал, что хотя и придумываю доказательство сам, но ничего оригинального при этом не создаю.

Ну и? Эти доказательства похожи ни чуть не больше, чем два портрета друг на друга. И там и там человек.

Waterlaz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.