Здравствуйте, Sinclair, Вы писали:
VD>>Я конечно все понимаю, но докапаться до == и = не достойно серьезного человека. Ссылка твоя не работат, ты хоть бы назвал бы имя товарища, я в будущем относился к его словам с осторожностью. S>Судя по тексту линка, это доклад некоего человека по фамилии Wirth. Я также могу догадаться, что его зовут Niklaus. См. http://www.cs.inf.ethz.ch/~wirth/
В общем какя-то Виртуальная личность.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, mihailik, Вы писали:
ДГ>>>интеграла Лебега от Римана — на примере функции Дирихле?
M>>Это как так? Дирихле не интегрируется Или это другой Дирихле?
M>>Дирихле(x) = 0, если x рациональное M>>Дирихле(x) = 1, если x иррациональное
ДГ>Дирихле не интегрируется по Риману, а по Лебегу — легко.
ДГ>Интеграл Римана бьет на отрезки ось X, и для каждого отрезка берет среднее значение функции. Чтобы это среднее значение существовало, функция должна быть непрерывно. Иными словами, интеграл Римана работает для непрерывных функций или функций с ограниченным набором точек разрыва (не помню точно, конечным или не более чем счетным).
Если быть точным, функция интегрируема по Риману на отрезке тогда и только тогда, когда она ограничена на этом отрезке и Лебегова мера точек её разрыва равна нулю. Теорема Дарбу, если мне память не изменяет.
ДГ>С другой стороны, интеграл Лебега бьет на отрезки ось Y, и для каждого отрезка подсчитывается мера множества попавших в нее точек. Так вот, мера Лебега нечувствительна к счетным множествам (счетные множества имеют меру ноль), а поскольку множество рациональных чисел счетно, то интеграл Лебега от функции Дирихле равен интегралу функции Y=1.
Здравствуйте, mihailik, Вы писали:
ДГ>>С другой стороны, интеграл Лебега бьет на отрезки ось Y, и для каждого отрезка подсчитывается мера множества попавших в нее точек.
M>Подлючий какой метод! Таки молодец Лебег, упёк.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Дарней, Вы писали:
Д>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>[/q] LVV>>>Класссс!!!!!
Д>>господа, ну сколько уже можно? Д>>ругать С — это пошло просто до безобразия Д>>тем не менее, им и его потомками пользовались, пользуются и будут пользоваться. Потому что ничего лучше пока не придумали. Языки, созданные теоретиками "на бумажке", почти никогда не оказываются востребованными — просто потому, что теоретики не имеют представления о реальных проблемах программирования и вместо этого борются с ветряными мельницами. А все разговоры о "порочном круге" — это просто паранойя. Появись язык, который реально, а не на словах лучше — все будут пользоваться именно им.
ДГ>Все это уже говорилось не раз. А C/C++ так прочно держится чисто по историческим причинам. Вон, на винде уже все под .NET толпами валят — видать он реально лучше. А unix как был изначально написан на C, так на C/C++ до сих пор и пишется.
Да я бы не сказал, что валят. Лучше он только для определённого круга задач.
ДГ>Ругать и обсуждать — разные вещи. А в языке действительно масса проблем. Если ты считаешь, что это не так, значит ты просто мало писал на нем и не пробовал другие языки. Попробуй поработать на Java: имхо он гораздо лучше чем C++ (сама идеология языка, сырые библиотеки не в счет), на столько же, насколько C++ лучше старого паскаля.
ДГ>Лично я думаю, что время C/C++ как языка для прикладных задач подходит к концу.
Как сказал Марк Твен, слухи о моей смерти сильно преувеличены.
ДГ>Он будет жить еще долго просто за счет *nix-ов и прочих многолетних наработок, но за время его существования программирование проделало очень большой путь, и синтез этого опыта требует принципиально новых технологий — на данный момент .NET, Java, потом наверняка войдут в обиход математически доказываемые системы, про которые упоминалось в статье-разборе полетов mission-critical глюков. На бедный C++ всего этого уже не навесить, и сфера его использования будет сужаться до низкоуровнего системного программирования в связке с asm.
Если исходить из существующей реальности, то даже если такие системы и будут созданы, что само по себе ещё та задача, пользоваться ими будет горстка профессионалов.
Вопрос на засыпку -- многие ли программисты знают, что такое интеграл Лебега?
1) По мелочи. Вирт -- типичный лузер. Статья его -- просто жалкий вопль человека, проигравшего конкурентную борьбу. Из серии -- гадкий Майкрософт завалил весь мир своими кривыми программами.
2) По серьёзней. Паскаль разрабатывался в своё время под конкретную технологию компиляции. С c помощью этой технологии откомпилировать нельзя. Вот по этой причине Пакскаль компилируется быстрее, зато люди предпочли писать программы на C. Вирт создал язык для машины, не для человека. Это вопрос не формальной строгости, а психологии восприятия. Вот поэтому он и проиграл.
3) Попробую сформулировать свою мысль. Не уверен, что делаю это вполне ясно.
Возьмем, для примера, современную математику. Математика НЕ строится на базе какого-то формального языка. Хотя технически это можно сделать, причем соответствующий язык будет попроще Паскаля.
Вот только данный путь почему-то не привлекает никого. Потому что если так работать, то доказать можно будет разве что 2+2=4. Не годится такой подход для сложных задач. Математики предпочитают работать с очень усложнённым и не формализованным языком(языками) для выражения своих мыслей. С++ до него ой как далеко (про остальных вообще помалкиваем в тряпочку). Если кто выдел хорошо изданные книги по современной математике -- обратите на количество разных шрифтов, которое там используется.
И в программировании мы наблюдаем то же самое. C++ гораздо более подходит для создания больших и сложных систем, чем всякие Жабы. И я думаю, дальше будет только хуже в этом смысле. Эволюция языков программирования будет идти в сторону сложности и меньшей формальности. Прямо в противоположном направлении, которое хочет тов. Вирт.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, Дарней, Вы писали:
INT>Ошибок не бывает, если их не вносить. Если язык предполагает потенциальную ошибку в каждой второй строчке, то не удивительно, что в одном из сотни таких мест ошибка реально появиться.
INT>Правильность доказывается по простому критерию — утверждение правильно, если его можно формально вывести из набора аксиом. Можно ошибиться при определении аксиом, но при выведении из них теорем просто нет места, где можно сделать ошибку.
INT>Все доказательства в automated proof system (ASP), грубо говоря, состоят из "унификаций" — подставления доказанный утверждений на место свободных переменных в других доказанных утверждений. "Автоматизация" при этом в первую очередь нужна не для поиска решений, а для исключения возможности ошибиться.
это всё замечательно звучит, но на практике люди имеют обыкновение ошибаться. Заниматься моделированием, составлением набора аксиом будут все те же люди. Вывод очевиден....
Здравствуйте, bkat, Вы писали:
B>В общем сверхзадача программирования — сделать так, чтобы программирование B>как род деятельности с участием человека исчезла бы совсем и стала бы ненужной
Здравствуйте, Дарней, Вы писали: Д>это всё замечательно звучит, но на практике люди имеют обыкновение ошибаться. Заниматься моделированием, составлением набора аксиом будут все те же люди. Вывод очевиден....
Видишь ли, шансов сделать ошибку тем меньше, чем меньше объем работы. Проверить корректность правил вывода достаточно легко, ибо их совсем немного. А дальше все происходит автоматически — ввели исходные аксиомы и получили заведомо правильные теоремы. Аксиом тоже относительно немного.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ш>1) По мелочи. Вирт -- типичный лузер. Статья его -- просто жалкий вопль человека, проигравшего конкурентную борьбу. Из серии -- гадкий Майкрософт завалил весь мир своими кривыми программами.
Точно! У меня тоже в голове вертелось сравнение с Микрософтом.
On Wed, 12 May 2004 01:20:38 GMT, Шахтер <forum@rsdn.ru> wrote:
> Здравствуйте, LaptevVV, Вы писали: > > LVV>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm > > 3) Попробую сформулировать свою мысль. Не уверен, что делаю это вполне > ясно. > Возьмем, для примера, современную математику. Математика НЕ строится на > базе какого-то формального языка. Хотя технически это можно > сделать, причем соответствующий язык будет попроще Паскаля.
можно я попридираюсь к мелочам?
выделенная фраза очень сильно меня смущает:
А как же теорема Гёделя? Что любая формальная система сложнее
арифметики Пеано с равенством обязательно содержит парадоксы?
как вы собираетесь компилировать код, который может содержать
противоречия?
Месье не понимет
Ш>Возьмем, для примера, современную математику. Математика НЕ строится на базе какого-то формального языка.
Математика строится на основе формального языка.
Ш>Хотя технически это можно сделать, причем соответствующий язык будет попроще Паскаля.
Он вобще состоит только из одного правили — правила вывода одних теорем из других методом подстановки своюодных переменных.
Ш>Вот только данный путь почему-то не привлекает никого.
Не знаю, привлекает или не привлекает, но _доказательства_ должны делаться только на нем. В _измышлениях_, разумеется, можешь пользоваться чем угодно.
Ш>Потому что если так работать, то доказать можно будет разве что 2+2=4.
ВСЕ теоремы доказываются только так. Если, конечно, доказываются.
Ш>Не годится такой подход для сложных задач.
Действительно сложные задачи решаются либо так, либо неправильно. Современное ПО как раз уперлось в предел сложности, который не перешагнуть без формального контроля правильности кода.
Здравствуйте, Шахтер, Вы писали:
Ш>1) По мелочи. Вирт -- типичный лузер. Статья его -- просто жалкий вопль человека, проигравшего конкурентную борьбу.
Сначала неплохо бы сделать столько, сколько Вирт, а уж потом ярлыки клеить.
Ш>Из серии -- гадкий Майкрософт завалил весь мир своими кривыми программами.
В "гадком Микрософте" сейчас работает много учеников Вирта, и влияние этой школы уже можно видеть в последних продуктах компании.
Ш>И в программировании мы наблюдаем то же самое. C++ гораздо более подходит для создания больших и сложных систем, чем всякие Жабы. И я думаю, дальше будет только хуже в этом смысле. Эволюция языков программирования будет идти в сторону сложности и меньшей формальности. Прямо в противоположном направлении, которое хочет тов. Вирт.
Вообще абсурд какой-то...
Чем сложнее язык, тем сложнее компилятор, тем дольше время компиляции, тем выше вероятность ошибки в самом компиляторе и отпимизаторе, тем выше вероятность ошибки программиста при чтении программы на такой языке, тем выше вероятность наличия "ловушек" в синтаксисе языка, тем дольше время поиска ошибок и отладки, тем дольше общее время разработки, тем выше себестоимость продукта...
Здравствуйте, Aquary, Вы писали:
A>кроме того, излишнее погружение в формальную сторону программирования (нотации и т.п.) — это тоже излишество, т.к. эта штука способна напугать многих школьников, которым интересно писать программы, но не интересно читать заумные работы профессоров... первокурснику и старшекласснику проще показать пару работающих примеров, а уже потом обучать его формальной стороне вопроса — так он, по крайней мере, будет знать, зачем всё это нужно.
Ну да, конечно: чукча — не читатель, чукча — писатель...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Шахтер, Вы писали:
Ш>2) По серьёзней. Паскаль разрабатывался в своё время под конкретную технологию компиляции. С c помощью этой технологии откомпилировать нельзя. Вот по этой причине Пакскаль компилируется быстрее, зато люди предпочли писать программы на C. Вирт создал язык для машины, не для человека. Это вопрос не формальной строгости, а психологии восприятия. Вот поэтому он и проиграл.
Ну, это просто "брехня"!
Очень многие компиляторы Си (ну хотя бы lcc, на вскидку, из "современных"), включая самый первый компилятор Си, написанный Ритчи, созданы по той же самой "технологии компиляции".
Я понимаю, что Вы имеете в виду различие между LL- и LR-грамматиками, но, однако, факты именно таковы.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
ДГ>Дирихле не интегрируется по Риману, а по Лебегу — легко.
Если методы функционального анализа перенести на дискретные данные то получим логику второго порядка. Которая неполна, противоречива и т.д. и т.п. Красивые идеи и языки в том числе не соответствуют действительности. Красота в том, что некрасивая действительность должна описываться некрасивыми программами. А высокоумные вещи надо знать чтобы во время работы не оторваться от действительности. Если вдруг нашел простое и красивое решение проблемы, значит что-то не понимаешь. Скорее всего все его рассматривали и отказались, иначе ты бы его уже давно знал.
Программы вообше есть двух видов: системные и прикладные. Кроме области у них еще масса отличий. Их разнообразие, требуемая скорость разработки, выделяемые на разработку ресурсы. Системные всегда будут работать по дедуктивной логике, она быстра и контролируема. Этими средствами специалисты создат программы-машины.
А прикладные будут смещаться к семантическому выводу. Программа будет содержать много избыточной информации благодаря чему ошибки исключаются что называется "практически". Уже классический прием это бухгалтерский баланс, двойная запись и сопоставление итогов. Это уже не проектирование машин, тут более интеллектуальные цели и должны быть более интеллектуальыные средства. И нужно это не специалистам, а "массам".
M>>Подлючий какой метод! Таки молодец Лебег, упёк.
Ш>???
Ну, мы такого в школе не проходили.
А вообще я люблю всякие антигуманные методы доказательства. Ну, чтобы мозги сами за себя спотыкались, или же неконструктивные доказательства вроде Канторовской диагонали там.
LVV>А как же теорема Гёделя? Что любая формальная система сложнее LVV>арифметики Пеано с равенством обязательно содержит парадоксы? LVV>как вы собираетесь компилировать код, который может содержать LVV>противоречия?
А как он сейчас компилируется? Паскаль ведь включает в себя арифметику, то есть под акисомы Пеано спокойно подпадает
Ш>>1) По мелочи. Вирт -- типичный лузер. Статья его -- просто жалкий вопль человека, проигравшего конкурентную борьбу. K_O>Сначала неплохо бы сделать столько, сколько Вирт, а уж потом ярлыки клеить.
Если бы Вирт действовал так, как ты требуешь, у нас бы сейчас не было Паскаля.
Здравствуйте, Kh_Oleg, Вы писали:
Ш>>И в программировании мы наблюдаем то же самое. C++ гораздо более подходит для создания больших и сложных систем, чем всякие Жабы. И я думаю, дальше будет только хуже в этом смысле. Эволюция языков программирования будет идти в сторону сложности и меньшей формальности. Прямо в противоположном направлении, которое хочет тов. Вирт. K_O>Вообще абсурд какой-то... K_O>Чем сложнее язык, тем сложнее компилятор,
Да. K_O>тем дольше время компиляции,
Нет. C# сложнее, чем C++, а время компиляции программы на C# ниже. Время компиляции очень слабо связано со сложностью языка.
Уточню: под сложностью языка подразумевается сложность грамматики и количество зарезервированных слов. K_O>тем выше вероятность ошибки в самом компиляторе и отпимизаторе,
Да. Абсолютно верно. K_O>тем выше вероятность ошибки программиста при чтении программы на такой языке,
Нет. Пара примеров. Ассемблеры очень просты, как языки, но читать их сложнее самых сложных языков вроде C#, Java, C++. С#, опять же, сложнее C++, но читать программы на C# в общем случае легче. LISP — язык элементарен, но читать сложно. Временами, очень сложно. Forth — аналогично. Можно продолжить. K_O>тем выше вероятность наличия "ловушек" в синтаксисе языка,
Это вроде if (a = b) в C/C++? K_O>тем дольше время поиска ошибок
C#/Java => C++ — где дольше время поиска ошибок? K_O>и отладки,
C#/Java => C++ — ... K_O>тем дольше общее время разработки,
C#/Java => C++ K_O>тем выше себестоимость продукта...
Не правда ваша. Себестоимость продукта зависит не от сложности языка, а от человекочасов, потраченных на ее написание, отладку, введение в эксплуатацию, документирование, поддержку, маркетинг (опционально) и т.д. и т.д.
Или это другой Дирихле?
