Здравствуйте, desperado_gmbh, Вы писали:

_>Ага, система доказательства, умеющая доказывать только одну теорему — что программа синтаксически правильна. Она даже не может доказать или опровергнуть, что при выполнении не возникнет undefined behavior и что выполнение вообще завершиться.

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

INT>>Между прочим, ты не сравнивал Hol, Isabella и Coq? В чем они отличаются и насколько они совместимы?

_>Я работал только с Coq. А у кого-нибудь еще есть windows-версия?

У HOL есть. Isabella кто-то компилил под Cygwin и даже описал, как это делается, но у меня сходу не получилосб. А жаль, она мне понравилось использованием более переносимой нотации.

INT>>Значит, еще не известно, правильны они или нет.

_>Это уже вопрос принципов научного познания. Физику с химией, например, вообще формализовать нельзя (не ту часть, где расчеты — это по сути математика, а ту часть, где эксперименты, подтверждающие законы), но без них компьютер работать не будет и никаких теорем не докажет.

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

Здравствуйте, INTP_mihoshi, Вы писали:

_>>Ага, система доказательства, умеющая доказывать только одну теорему — что программа синтаксически правильна. Она даже не может доказать или опровергнуть, что при выполнении не возникнет undefined behavior и что выполнение вообще завершиться.
INT>Но тем не менее это доказывает, что ASP уже давно широко используются, хотя и в сильно (слишком) урезанном виде.

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

_>>Это уже вопрос принципов научного познания. Физику с химией, например, вообще формализовать нельзя (не ту часть, где расчеты — это по сути математика, а ту часть, где эксперименты, подтверждающие законы), но без них компьютер работать не будет и никаких теорем не докажет.
INT>Согласен, в любом случае все сводится к принципу "хрен знает, но до сих пор работало". Даже, если речь идет о том, взойдет ли солнце завтра

Между "хрен знает, но до сих пор работало" и научным познанием огромная пропасть.

Здравствуйте, desperado_gmbh, Вы писали:

INT>>Но тем не менее это доказывает, что ASP уже давно широко используются, хотя и в сильно (слишком) урезанном виде.

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

Та "половина языка", которую я имел в виду нужна не для того, чтобы скомпилировать, я для того, чтобы выявлять ошибки дизайна на этапе компиляции. Ограничители доступа к членам класса (private/public/protected/friend etc.), константные методы, различные способы приведения типов (*_cast), чисто виртуальные методы, объявления исключений, бросаемых функцией не нужны для компиляции, но введены в язык для возможности формализации и проверки правильности программы.

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

_>Между "хрен знает, но до сих пор работало" и научным познанием огромная пропасть.
Научное познание сводится к тому, чтобы свести количество "ХЗНДР" к минимуму, систематизировать и уметь на их основе что-то изучать и прогнозировать

Здравствуйте, SWW, Вы писали:

kuj>>Рецептов избавления много и существуют они далеко не первый год. Просто Вы, наверное, ничего кроме пары императивных языков вроде C/C++/Pascal не видели. Например, все вышеуказанное в .NET языках в принципе не возможно (кроме как по вине ошибки в JIT-компиляторе или сборщике муссора). А сборщики муссора существовали еще в первых версиях LISP (который, кстати, во много раз старше C/C++/Pascal).

SWW>Есть мнение, что наличие сборщика мусора расслабляет программиста, он относится к программе легкомысленно, что приводит к появлению программ с уродской архитектурой.
Напротив, дает время программисту на создание более тщательно продуманной архитектуру.
SWW>А отсутствие сборщика мусора заставляет программиста точно представлять себе сроки жизни каждого объекта, благодаря чему он тщательнее продумывает архиректуру своей программы что в конечном итоге идет ему на пользу.
Более тщательно (а иногда и не очень-то более) продумывает механизмы распределения такого ресурса, как память, что к архитектуре приложения не имеет никакого абсолютно отношения. Зато времени на продумывания архитектуры остается меньше. Впрочем, при наличии smart pointers и умении правильно ими пользоваться в C++ эта проблема более-менее решается.

SWW>>>Какие принципиальные новшества нужны для того, чтобы программист не ошибся, например, с выходом индекса за пределы массива?
kuj>>Проверка на выход за границы массива существовала еще в Delphi. В .NET ественно она тоже существует.
SWW>Так вопрос не в том, чтобы вбить проверку при каждом обращении к массиву, а в том, как добиться, чтобы программист написал программу, в которой никогда не происходит такой выход! Ну не может это компилятор в принципе, какие языки ни сочиняй.
Да Вы, оказывается, философ. Да, мир неидеален и никогда таковым не станет. Именно для этого выдумываются методы автоматического управления ресурсами.

SWW>Да, паскаль проверяет каждое обращение и при ошибке вывыливается, вежливо сообщив пользователю об ошибке в программе. Много ли радости от этого пользователю?
Ага, лучше, наверное, чтоб вываливался, не сообщив. Тогда не только пользователю, но и разработчику придется локти кусать...

Здравствуйте, Дарней, Вы писали:


kuj>>Наверное, покажусь неоригинальным, но C во многом безобразный язык. И == это самое меньшее, к чему можно было прицепиться. Впрочем, Pascal по-моему еще более безобразный язык.
Д>про Паскаль согласен. Вспоминаю про := и бегины с ендами, и сразу думаю "и эти люди запрещают мне ковыряться в носу?!"
Бегины с эндами это мелочь. Если бы проблема была только в этом, то я бы не назвал паскаль безобразным языком.

Д>>>тем не менее, им и его потомками пользовались, пользуются и будут пользоваться. Потому что ничего лучше пока не придумали. Языки, созданные
kuj>>Э-э, шутить изволите? Придумали. При чем, еще до появления C.
Д>а можно с этого места и подробнее?
Можно, но только применительно к конкретным задачам.

kuj>>А реальные проблемы программирования на C/C++ возникают, в первую очередь, из-за самого языка. Начиная от банального if (a = b), и заканчивая порчей указателей, утечками памяти и прочими-прочими радостями. Да и сам по себе императивный подход к программированию удобен далеко не всегда. Временами, императивный подход очень сильно мешает.
Д>я совсем не это имел в виду.
А что Вы имели в виду?

kuj>>Один лемминг, что примечательно, ошибается куда реже миллионов.
Д>вот как? очень интересная теория
Естественно. Толпа существо неразумное.

kuj>>P.S. Запомните: язык для задачи, а не задача для языка.
Д>хто бы спорил. вот современные задачи и породили C с его потомками
Современные породили Java/.NET Languages.

Здравствуйте, mister-AK, Вы писали:

kuj>>Впрочем, Pascal по-моему еще более безобразный язык.
MA>странно
А что странного? C++ язык безобразный, но он хоть позволяет родными средствами прикрыть бОльшую часть срамоты. Паскаль не дает и этого.

Д>>>тем не менее, им и его потомками пользовались, пользуются и будут пользоваться. Потому что ничего лучше пока не придумали. Языки, созданные
kuj>>Э-э, шутить изволите? Придумали. При чем, еще до появления C.
MA>и что это за язык и какой из них красивее?
См. мое предыдущее сообщение.

Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>тем дольше время компиляции,
kuj>>Нет. C# сложнее, чем C++, а время компиляции программы на C# ниже.
kuj>>Время компиляции очень слабо связано со сложностью языка.
K_O>Неправильно оценивать сложность языка только количеством ключевых слов.
А где я оценивал сложность языка только количеством ключевых слов?
K_O>В C# разве есть шаблоны в том виде, в каком они есть в C++?
Нет. Пока нет.
K_O>Разве есть этот отстой в виде обычных, const, volatile и const volatile методов? То же и про переменные.
K_O>А множественное наследование для классов?
K_O>Эти "фичи" на несколько порядков усложняют компилятор.
Преувеличиваете. В противовес можно назвать: properties, attributes, delegates, enumerations, arrays, SEH.
Одним словом, как минимум парсер C# сложнее парсера C++ — сравните грамматики этих языков.

K_O>>>тем дольше время поиска ошибок
kuj>>C#/Java => C++ — где дольше время поиска ошибок?
K_O>В шаблонах никогда ошибок не искал? Компилятор всегда внятно может сказать, что и где ему не понравилось?
Так и я о том, что в C#/Java с этим гораздо проще. А ошибки в шаблонах это мелочь в сравнении с порчей указателей, утечками памяти, выходом за границы массива и т.д. и т.п.

K_O>>>и отладки,
kuj>>C#/Java => C++ — ...
K_O>См. предыдущий пункт.

K_O>>>тем дольше общее время разработки,
kuj>>C#/Java => C++
K_O>На C++ время разработки на порядки дольше.
Может и не на порядки, но дольше. Факт. С этим, собственно, никто и не спорил.
K_O>Из-за времени компиляции.

K_O>Много ты наотлаживаешься, когда проект собирается 45мин. ?
Да Вы шутник...

K_O>>>тем выше себестоимость продукта...
kuj>>Не правда ваша. Себестоимость продукта зависит не от сложности языка, а от человекочасов, потраченных на ее написание, отладку, введение в эксплуатацию, документирование, поддержку, маркетинг (опционально) и т.д. и т.д.
K_O>документирование, поддержку, маркетинг (опционально) — это везде одинаково,
Документирование и маркетинг в принципе одинаково. Поддержка программ, использующих управляемый код, обычно проще.
K_O>а вот "человекочасы, потраченных на ее написание, отладку," напрямую зависят от сложности языка
От сложности языка нет прямой зависимости. Еще раз: сравниваем сложность ассемблера (например, x86, положим, MASM), Forth, Lisp.. и того же C#.
K_O>и времени компиляции.
А полный ребилд проекта все-равно делается не так уж часто. Так что от времени компиляции себестоимость зависит очень и очень опосредственно. Тут точно нет прямой зависимости.

Здравствуйте, mihailik, Вы писали:

MA>>А кто бы был? Ньютон или Декарт?

M>Кругом была бы одна Ява. И Бабаян пророк её.

M>

чуствую — цивилизация многое упустила!

представляю! одна Ява , никаких Галапагосов и Гавай и тем более Австралии нема на горизонте.

фильм похожий какой-то краем глаза однажды видал, кажись называется "Водный мир"...

Здравствуйте, Дарней, Вы писали:

Д>>>тем не менее, им и его потомками пользовались, пользуются и будут пользоваться. Потому что ничего лучше пока не придумали. Языки, созданные
kuj>>Э-э, шутить изволите? Придумали. При чем, еще до появления C.
Д>а можно с этого места и подробнее?
kuj>>P.S. Запомните: язык для задачи, а не задача для языка.
Д>хто бы спорил. вот современные задачи и породили C с его потомками

Кстати, очень рекомендую для самообразования поразбираться немного с O`Caml.

Здравствуйте, beretta, Вы писали:

B>Это у них ФЯ, а кто мне скажет что преподают сейчас в наших школах?

В школах у нас обычно в плане IT считай что вобще ничего не преподают, а в институте у нас был пролог.

Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>тем выше вероятность наличия "ловушек" в синтаксисе языка,
kuj>>Это вроде if (a = b) в C/C++?
K_O>ага, или double d = 3,1415;

Приведённая ошибка — лишь дело привычки — не более. Посему некорректна.

K_O>>>тем дольше общее время разработки,
kuj>>C#/Java => C++
K_O>На C++ время разработки на порядки дольше. Из-за времени компиляции. Много ты наотлаживаешься, когда проект собирается 45мин. ?

Для этого есть IncrediBuild, который мы с успехом используем и который снижает время компиляции с 45 до 10 — 15 минут. Конечно до скорости Delphi ему далеко, это не идеальное но приемлимое решение проблемы. Тем более что ты rebuild ты запускаешь не так часто, а простой build идёт гораздо быстрее.

Здравствуйте, lightSource, Вы писали:

K_O>>>>тем выше вероятность наличия "ловушек" в синтаксисе языка,
kuj>>>Это вроде if (a = b) в C/C++?
K_O>>ага, или double d = 3,1415;

S>Приведённая ошибка — лишь дело привычки — не более. Посему некорректна.

Зато "ловушка" вполне корректна. Подобных граблей в C/C++ раскидано великое множество. Поэтому без опыта в C/C++ делать нечего.

Здравствуйте, AndrewVK, Вы писали:

B>>Это у них ФЯ, а кто мне скажет что преподают сейчас в наших школах?
AVK>В школах у нас обычно в плане IT считай что вобще ничего не преподают, а в институте у нас был пролог.
LISP (и вариации на тему AutoLISP) тоже сейчас преподают, на сколько я знаю. Правда, OCaml, как ФЯ, поинтереснее будет.

Здравствуйте, SWW, Вы писали:

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

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

Следует выбрать минимальное множество языков, максимально отображающих каждую современную концепцию программирования и преподавать их параллельно. Императивное процедурное — паскаль или бейсик (скорее бейсик); императивное ООП — Java, C#, VB.NET, smalltalk, Object Pascal (какой-то из первых трех предпочтительнее); функциональное — OCaml, ML, LISP (OCaml предпочтительнее); декларативное — пожалуй, Prolog без вариантов. После основ совсем неплохо ввести отдельный курс по патернам проектирования, по структурам данных и основным алгоритмам (сортировки, поиск, регулярные выражения, списки, деревья, стеки, деки, очереди и т.д.). Затем можно и более специфичное: БД, сети, распределенные системы, компиляторы, компьютерная графика (база, OGl, D3D) и т.д. и т.п.

Hello, kuj!
You wrote on Fri, 14 May 2004 16:55:13 GMT:

k> attributes, delegates, enumerations, arrays, SEH. Одним словом, как
k> минимум парсер C# сложнее парсера C++ — сравните грамматики этих языков.

Сравните до кучи еще и disambiguation rules, которые из парсера C++ делают полный кошмар.

Best regards,
Sergey.

Здравствуйте, lightSource, Вы писали:

S>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>>тем выше вероятность наличия "ловушек" в синтаксисе языка,
kuj>>>Это вроде if (a = b) в C/C++?
K_O>>ага, или double d = 3,1415;

S>Приведённая ошибка — лишь дело привычки — не более. Посему некорректна.
Приведенная ошибка — результат несоответствия ЯП и человеческого языка. Приведенная ошибка — это маразм компилятора, который проглатывает выражения типа:

1415;

Что означает эта конструкция?

K_O>>>>тем дольше общее время разработки,
kuj>>>C#/Java => C++
K_O>>На C++ время разработки на порядки дольше. Из-за времени компиляции. Много ты наотлаживаешься, когда проект собирается 45мин. ?

S>Для этого есть IncrediBuild, который мы с успехом используем и который снижает время компиляции с 45 до 10 — 15 минут. Конечно до скорости Delphi ему далеко, это не идеальное но приемлимое решение проблемы. Тем более что ты rebuild ты запускаешь не так часто, а простой build идёт гораздо быстрее.

Мы тоже им пользуемся, но перед линковкой (20 мин.) IncrediBuild пасует.

Здравствуйте, SWW, Вы писали:

kuj>>Вы не путайте обучение кодированию на конкретном языке программирования с обучением, собственно, самому программированию, которое, вообще говоря, в идеале не должно привязываться к конкретному языку программирования.
SWW>Обучение самому программированию? Вопрос, конечно, интересный и даже актуальный — но как учить самому программированию не изучив хотя бы один язык программирования? Как можно учить столяра делать мебель, не научив его пользоваться ножовкой и рубанком?
Следует использовать абстрактные ножовку и рубанок.

Здравствуйте, kuj, Вы писали:

kuj>Зато "ловушка" вполне корректна. Подобных граблей в C/C++ раскидано великое множество. Поэтому без опыта в C/C++ делать нечего.

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

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Здравствуйте, lightSource, Вы писали:

S>>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>>>>тем выше вероятность наличия "ловушек" в синтаксисе языка,
kuj>>>>Это вроде if (a = b) в C/C++?
K_O>>>ага, или double d = 3,1415;

S>>Приведённая ошибка — лишь дело привычки — не более. Посему некорректна.
K_O>Приведенная ошибка — результат несоответствия ЯП и человеческого языка. Приведенная ошибка — это маразм компилятора

Как будто в Паскале нет ничего похожего и он являет собой образец для подражания. Если нужен естественноподобный язык — пиши на SPL(Shakespeare Programming Language). В любом языке, даже естественном есть свои правила, если эти правила не соблюдать — далеко не уедешь.

K_O>

K_O>1415;
K_O>

K_O>Что означает эта конструкция?

Не вырывай из контекста а рассматривай в целом 3, 1415 — а вот это уже перечисление, список если позволите — вполне определённая языковая конструкция. Если тебе непривычно — не говори что неудобно.

K_O>>>>>тем дольше общее время разработки,
kuj>>>>C#/Java => C++
K_O>>>На C++ время разработки на порядки дольше. Из-за времени компиляции. Много ты наотлаживаешься, когда проект собирается 45мин. ?

S>>Для этого есть IncrediBuild, который мы с успехом используем и который снижает время компиляции с 45 до 10 — 15 минут. Конечно до скорости Delphi ему далеко, это не идеальное но приемлимое решение проблемы. Тем более что ты rebuild ты запускаешь не так часто, а простой build идёт гораздо быстрее.

K_O>Мы тоже им пользуемся, но перед линковкой (20 мин.) IncrediBuild пасует.
Ещё раз повторюсь, ты rebuild не так часто запускаешь.

Здравствуйте, lightSource, Вы писали:

S>>>Приведённая ошибка — лишь дело привычки — не более. Посему некорректна.
K_O>>Приведенная ошибка — результат несоответствия ЯП и человеческого языка. Приведенная ошибка — это маразм компилятора

S>Как будто в Паскале нет ничего похожего и он являет собой образец для подражания.
Вот что сказал компилятор Delphi, на эту же конструкцию:
[Error] Unit1.pas(65): Statement expected, but expression of type 'Integer' found

S>Если нужен естественноподобный язык — пиши на SPL(Shakespeare Programming Language). В любом языке, даже естественном есть свои правила, если эти правила не соблюдать — далеко не уедешь.
Нужен читабельный язык, когда интуитивно понятно, что здесь написано. Когда я впервые увидел этот прикол с числом Пи, мне потребовалось целых полминуты, чтобы понять, где здесь ошибка. И то, только потому, что я знал, что здесь ошибка есть. А попадись такой код в реальном проекте — пропущу, даже не обратив внимания, потому как выглядит он, на первый взгляд, вполне корректно, а при беглом просмотре точка от запятой не сильно отличается.

K_O>>

K_O>>1415;
K_O>>

K_O>>Что означает эта конструкция?

S>Не вырывай из контекста а рассматривай в целом
А я не вырываю из контекста, это вполне компиляемая конструкция, сам попробуй. Вот мне и непонятно, что она означает?

S> 3, 1415 — а вот это уже перечисление, список если позволите — вполне определённая языковая конструкция. Если тебе непривычно — не говори что неудобно.
Да!!! Мне, знаете ли, непривычно, когда "перечисление, список если позволите" приваивается переменной типа double!

S>>>Для этого есть IncrediBuild, который мы с успехом используем и который снижает время компиляции с 45 до 10 — 15 минут. Конечно до скорости Delphi ему далеко, это не идеальное но приемлимое решение проблемы. Тем более что ты rebuild ты запускаешь не так часто, а простой build идёт гораздо быстрее.

K_O>>Мы тоже им пользуемся, но перед линковкой (20 мин.) IncrediBuild пасует.
S>Ещё раз повторюсь, ты rebuild не так часто запускаешь.
Я не понял, ты что ли рядом сидишь, коли знаешь, как часто мы rebuild запускаем? Так вот, говорю, обычная отладка — найти в отладчике проблему, исправить пару строчек кода в одном файле и снова собрать проект (build, а не rebuild) — занимает 25 мин.
5 мин — компиляция на IncrediBuilde, 20 мин — линковка.