Re[11]: Статья Н.Вирта: взгляд из Зазеркалья - Философия программирования

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

F>Вот здесь http://www.citforum.ru/programming/digest/wirth/ опубликован конспект новой статьи Н.Вирта. Довольно интересно, хотя и спорно (например, Вирт предлагает по сути отказаться от использования деревьев при организации symbol tables в компиляторах). Остроумна критика операторов ++/-- (Вирт считает, что это уродство). В общем — стоит, наверное, обратить внимание

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

На улице XXI век. Человечество уже способно особо не напрягаясь послать ракету к Плутону.
Будущее уже настало! Прямо сейчас.
Количество и разнообразность исследований в computer science настолько большое, что я даже не могу охватить все это взглядом.
Просто поищите в любимом поисковике "computer science grants".

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

C++ -- хороший язык.
Unix -- хорошая операционная система.
Синтаксического оверхеда не существует.
...

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

И вместо того, чтобы в сотый раз заводить флейм -- найдите интересный проект и присоеденяйтесь к нему.
Пользы и вам, и всему человекчеству, и прогрессу будет значительно больше.

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

sch>И вместо того, чтобы в сотый раз заводить флейм -- найдите интересный проект и присоеденяйтесь к нему.
sch>Пользы и вам, и всему человекчеству, и прогрессу будет значительно больше.
Опаньки ! И не подозревал, что ссылка на статью Вирта (как бы Вы лично не относились к высказынным в нем мыслям — я, кстати, в своем посте сказал, что его статья спорна) это флейм

Я всего лишь дал ссылку, а вот флейм это как раз ответы, подобные Вашему. Простите великодушно, коли обидел

F>Опаньки ! И не подозревал, что ссылка на статью Вирта (как бы Вы лично не относились к высказынным в нем мыслям — я, кстати, в своем посте сказал, что его статья спорна) это флейм

Я всего лишь дал ссылку, а вот флейм это как раз ответы, подобные Вашему. Простите великодушно, коли обидел

Нет уж позвольте.
Я свои доводы высказал.
Если у вас есть свои доводы -- говорите.
Если нет -- то не засоряйте форум.

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

F>Опаньки ! И не подозревал, что ссылка на статью Вирта ... это флейм

Таково уж содержание статей г. Вирта, что ничего кроме флейма не вызывает

... << RSDN@Home 1.1.4 stable rev. 510>>

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

F>>Опаньки ! И не подозревал, что ссылка на статью Вирта (как бы Вы лично не относились к высказынным в нем мыслям — я, кстати, в своем посте сказал, что его статья спорна) это флейм

Я всего лишь дал ссылку, а вот флейм это как раз ответы, подобные Вашему. Простите великодушно, коли обидел

sch>Нет уж позвольте.
sch>Я свои доводы высказал.
sch>Если у вас есть свои доводы -- говорите.
sch>Если нет -- то не засоряйте форум.
Некогда. Мне статья понравилась, хотя (повторюсь !!!) и не бесспорна. Вы предлагали присоединиться к проекту, а не разводить флейм. Чудное совпадение: у меня как раз в работе очередной проект

Ассемблер не ждет — надо работать

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

F>Вот здесь http://www.citforum.ru/programming/digest/wirth/ опубликован конспект новой статьи Н.Вирта. Довольно интересно, хотя и спорно (например, Вирт предлагает по сути отказаться от использования деревьев при организации symbol tables в компиляторах).
Ну я бы не сказал что это переворот в науке. Мелкие частности.

F>Остроумна критика операторов ++/-- (Вирт считает, что это уродство).
Я тоже.
Единственное что мне не понравилось в статье, это про знак :=. Немного не понравилось про switch. Остальное вполне правильно.

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

F>В общем — стоит, наверное, обратить внимание

Лично мне понравилось. Причем, несколько моментов.

Во-впервых, некоторые высказывания Вирта интересным образом перекликаются с некоторыми темами в "Философии программирования". Вот, например,

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

и обсуждения Адаптированный алгоритм Эрли — описание, Идеальный парсер, Theory and Techniques of Compiler Construction

Или

Фантазии компьютерных ученых в 1960-е гг. не знали границ. Вдохновленные успехом в направлениях автоматического синтаксического анализа и генерации анализаторов, некоторые исследователи предложили идею гибких или, по крайней мере, расширяемых языков, представляя, что программе будут предшествовать синтаксические правила, которыми будет руководствоваться общий синтаксический анализатор при ее анализе. Более того, синтаксические правила можно было рассыпать повсюду в тексте...
...Полностью затиралась та идея, что языки служат общению людей, поскольку теперь, очевидно, можно было определять язык "на лету". Однако трудности, возникающие при попытке определить смысл приватных конструкций, быстро разрушили эти большие ожидания. Вследствие этого, быстро увяла и занимательная идея расширяемых языков.

и предположение, что в будущем DSL-ями будет отводиться большее внимание (например, как здесь).

Или вот еще:

Много лет спустя некоторые разработчики все чаще стали утверждать, что функциональные языки являются наилучшим средством для введения параллелизма — хотя было бы более уместно сказать "для облегчения работы компиляторов по определению возможностей распараллеливания программ". Вообще-то относительно несложно определить, какие части выражения могут вычисляться параллельно. Более важно то, что параллельно могут вычисляться параметры вызываемой функции, если запрещены побочные эффекты — которые не могут возникать в истинно функциональном языке. В то время, как это обстоятельство может быть истинным и, возможно, минимальным преимуществом функциональных языков, объектно-ориентированный подход предлагает более эффективный способ хорошего использования параллелизма, когда поведение каждого объекта представляется в виде отдельного процесса.

и Concurrent и Distributed Programming

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

Не раслаблятья. И постоянно изучать что-нибудь новое. Или насаждать это новое, чтобы другие изучали

А вообще, больше всего мне понравилось одно, но очень емкое, предложение:

Никогда программы не содержат так мало ошибок, как при отсутствии каких-либо средств отладки.

Молодец, Вирт! Лучше не скажешь!

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

F>>Остроумна критика операторов ++/-- (Вирт считает, что это уродство).
GZ>Я тоже.
Обоснуй почему это уродство... Только тем, что можно писать x+++y ? Тогда русский язык с его "Казнить нельзя помиловать" тоже есть уродство. Запятая надо что понять смысл? Точно так же простой пробел исправит непонятки: x++ +y или x+ ++y

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

F>>>Остроумна критика операторов ++/-- (Вирт считает, что это уродство).
GZ>>Я тоже.
CC>Обоснуй почему это уродство... Только тем, что можно писать x+++y ? Тогда русский язык с его "Казнить нельзя помиловать" тоже есть уродство. Запятая надо что понять смысл? Точно так же простой пробел исправит непонятки: x++ +y или x+ ++y
Когда быстро читаешь текст, подобные операции малозаметны. И всегда приходится дополнительно задумываться, чтобы это значило. Что сначало приплюсовало, или что-то другое. Поэтому я очень редко их вставляю не на новой строке. И пользуюсь только x++; Выражения типа while(*x++==*y++) для меня слишком сложны. Такой я глупый программист.

... зловещий облик низкоуровневого языка C ...

Браво Вирту и переводчику! Пять минут здорового смеха.

Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.

Я не понял выделенного, что значит вековая традиция в его понимании? Сколько лет coputer science (ну или хотя бы слову предикат)?
На мой взгляд знак "=" как раз понятен.
Например:
E=mc^2
F=ma

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

E>

E>Фантазии компьютерных ученых в 1960-е гг. не знали границ. Вдохновленные успехом в направлениях автоматического синтаксического анализа и генерации анализаторов, некоторые исследователи предложили идею гибких или, по крайней мере, расширяемых языков, представляя, что программе будут предшествовать синтаксические правила, которыми будет руководствоваться общий синтаксический анализатор при ее анализе. Более того, синтаксические правила можно было рассыпать повсюду в тексте...
E>...Полностью затиралась та идея, что языки служат общению людей, поскольку теперь, очевидно, можно было определять язык "на лету". Однако трудности, возникающие при попытке определить смысл приватных конструкций, быстро разрушили эти большие ожидания. Вследствие этого, быстро увяла и занимательная идея расширяемых языков.

E>и предположение, что в будущем DSL-ями будет отводиться большее внимание (например, как здесь).

С чего она увяла? Наоборот, изменяемость языка одна из очень мощных и интересных фич. И трудности синтаксического анализа не сильно мешают. Ну в самом деле, какие могут быть трудности с анализом в Лиспе?

E>Или вот еще:
E>[q]
E>Много лет спустя некоторые разработчики все чаще стали утверждать, что функциональные языки являются наилучшим средством для введения параллелизма — хотя было бы более уместно сказать "для облегчения работы компиляторов по определению возможностей распараллеливания программ". Вообще-то относительно несложно определить, какие части выражения могут вычисляться параллельно. Более важно то, что параллельно могут вычисляться параметры вызываемой функции, если запрещены побочные эффекты — которые не могут возникать в истинно функциональном языке. В то время, как это обстоятельство может быть истинным и, возможно, минимальным преимуществом функциональных языков, объектно-ориентированный подход предлагает более эффективный способ хорошего использования параллелизма, когда поведение каждого объекта представляется в виде отдельного процесса.

Ну-ну. Только лучший язык со встроенным параллелизмом в данное время функциональный Erlang, а объектно-ориентированных языков что-то не видно.

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

ну раз уж пошла такая пьянка....

(перезаряжая дробовик)

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

Чушь, чушь и еще раз — чушь! У человека нет в голове ни LL, ни LR парсера. Он распознает конструкции языка с помощью механизмов распознавания образов, которые пока толком никому не понятны. Ясно только одно — они не имеют абсолютно ничего общего с последовательным чтением текста буква за буквой.
Человек прекрасно понимает конструкции, которые ставят в затруднение компилятор (многократно приводившийся пример с vector<vector<int> > и лишним пробелом). С другой стороны, у человека вызывают затруднение конструкции, которые для компилятора ясны как день (опять же, многократно приводившийся пример с совершенно неудобочитаемой LL(1) грамматикой регэксов)

E>

E>Фантазии компьютерных ученых в 1960-е гг. не знали границ. Вдохновленные успехом в направлениях автоматического синтаксического анализа и генерации анализаторов, некоторые исследователи предложили идею гибких или, по крайней мере, расширяемых языков, представляя, что программе будут предшествовать синтаксические правила, которыми будет руководствоваться общий синтаксический анализатор при ее анализе. Более того, синтаксические правила можно было рассыпать повсюду в тексте...
E>...Полностью затиралась та идея, что языки служат общению людей, поскольку теперь, очевидно, можно было определять язык "на лету". Однако трудности, возникающие при попытке определить смысл приватных конструкций, быстро разрушили эти большие ожидания. Вследствие этого, быстро увяла и занимательная идея расширяемых языков.

E>и предположение, что в будущем DSL-ями будет отводиться большее внимание (например, как здесь).

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

E>Или вот еще:
E>[q]
E>Много лет спустя некоторые разработчики все чаще стали утверждать, что функциональные языки являются наилучшим средством для введения параллелизма — хотя было бы более уместно сказать "для облегчения работы компиляторов по определению возможностей распараллеливания программ". Вообще-то относительно несложно определить, какие части выражения могут вычисляться параллельно. Более важно то, что параллельно могут вычисляться параметры вызываемой функции, если запрещены побочные эффекты — которые не могут возникать в истинно функциональном языке. В то время, как это обстоятельство может быть истинным и, возможно, минимальным преимуществом функциональных языков, объектно-ориентированный подход предлагает более эффективный способ хорошего использования параллелизма, когда поведение каждого объекта представляется в виде отдельного процесса.

как всё-таки удивительно узнать, что возможность переложить часть работы по распараллеливанию программ на компилятор — это "минимальное преимущество", а вот возможность делать всё самому и вручную — это "более эффективный способ хорошего использования параллелизма"

... << RSDN@Home 1.1.4 stable rev. 510>>

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

Во, блин. Хорошо что многие не были так гениальны как Вирт и мир все же увидел, выпендрежи Александреску, макросы Лисап и в итоге Nemerel.

ЗЫ

Вообще дедуле уже явно пора на пенсию. Криатива у него как грится...

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Q>Ну-ну. Только лучший язык со встроенным параллелизмом в данное время функциональный Erlang, а объектно-ориентированных языков что-то не видно.

Как же? А Эктив Оберон?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Д>(опять же, многократно приводившийся пример с совершенно неудобочитаемой LL(1) грамматикой регэксов)

Грамматика регекспов не LL(1). Это нерекурсивная грамматика. Так что она куда проще.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Q>С чего она увяла? Наоборот, изменяемость языка одна из очень мощных и интересных фич. И трудности синтаксического анализа не сильно мешают. Ну в самом деле, какие могут быть трудности с анализом в Лиспе?

Имхо, в основном, под трудностями Вирт подразумевал трудности воспрятия подобных вещей программистом, а не транслятором. Учитывая, что на Лиспе программируют гораздо меньше, чем на C/C++/Java/C# с этим сложно не согласиться.

Q>Ну-ну. Только лучший язык со встроенным параллелизмом в данное время функциональный Erlang, а объектно-ориентированных языков что-то не видно.

А почему параллелизм должен быть встроенным в язык? Думаю, что программ, использующих распараллеливание работы, и написанных на C++/Java гораздо больше, чем на Erlange-е. Вот, один пример того, как это может быть сделано.

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

E>>и предположение, что в будущем DSL-ями будет отводиться большее внимание (например, как здесь).

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

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

Д>как всё-таки удивительно узнать, что возможность переложить часть работы по распараллеливанию программ на компилятор — это "минимальное преимущество", а вот возможность делать всё самому и вручную — это "более эффективный способ хорошего использования параллелизма"

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

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

VD>Во, блин. Хорошо что многие не были так гениальны как Вирт и мир все же увидел, выпендрежи Александреску, макросы Лисап и в итоге Nemerel.

Наверное, в обратной последовательности: макросы Лиспа, выпендрежи Александреску и, в итоге, Nemerle.

Слушай, Влад, ты в последнее время так часто поминаешь Scala и Nemerle, что я не понимаю: C# -- он что, уже отстойный язык? Будущее за Nemerle?

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

MS>

MS>Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.

MS>Я не понял выделенного, что значит вековая традиция в его понимании? Сколько лет coputer science (ну или хотя бы слову предикат)?
MS>На мой взгляд знак "=" как раз понятен.
MS>Например:
MS>E=mc^2
MS>F=ma

Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.

В С++ же выражение
x = y;
означает действие по приведению значения х в состояние, когда оно будет равным у.

Второе. В любой мат. формуле, если справедливо E=mc^2, то верно будет и mc^2=E. А в С++ x=y; это не то же самое, что y=x;
Присваивание — это не выражение равенства, а приведение в нему, то есть активная и несимметричная операция.

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

VD>Грамматика регекспов не LL(1). Это нерекурсивная грамматика. Так что она куда проще.

Ну как же не рекурсивная? Ведь операторы РВ применяют к самим РВ. Напрмиер, постфиксный оператор Клини "*" имеет в качестве аргумента именно регулярное выражение. Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*... Это рекурсия в чистом виде. Доказать, что язык РВ сам не является регулярным языком очень просто, достаточно воспользоваться леммой о накачке. Являетс ли язык РВ LL(1)-языком? Уверен что да. Пару месяцев назад построил как раз такую грамматику и написал распознаватель, работающий методом рекурсивного спуска и выбирающий альтернативу на основе просмотра следующего символа. А значит, это именно LL(1)-грамматика.

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

E>Имхо, здесь будет классический пример развития истории по спирали. В очередной раз попробуют DSL (на новом уровне развития технологии), поймут, что ничего хорошего не вышло. Забудут лет на ...надцать. Затем опять поробуют на новом уровне развития техники и т.д.

ну если по спирали, значит то же самое можно сказать про любую другую технологию

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

Д>ну если по спирали, значит то же самое можно сказать про любую другую технологию

Любую другую, про которую переодически вспоминают. От процедурного, структурного и объектно-ориентированного программирования, почему-то так просто не отказываются. А, например, про кодогенерацию то вспоминают, то забывают.

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

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

K_O>Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.

K_O>В С++ же выражение
K_O>x = y;
K_O>означает действие по приведению значения х в состояние, когда оно будет равным у.

K_O>Второе. В любой мат. формуле, если справедливо E=mc^2, то верно будет и mc^2=E. А в С++ x=y; это не то же самое, что y=x;
K_O>Присваивание — это не выражение равенства, а приведение в нему, то есть активная и несимметричная операция.

Со всем вышесказанным согласен.
Однако стоит отметить, что в тех-же мат. формулах операции присваивания также обозначаются "=".
"Пусть D=sqrt(b^2-4ac), тогда ..."

По поводу симметиричности:
как часто вы говорите что "3.1415192 равно пи", вместо "пи равно 3.141592"

Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

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

MS>По поводу симметиричности:
MS>как часто вы говорите что "3.1415192 равно пи", вместо "пи равно 3.141592"

На самом деле ни то, ни другое не верно, т.к. 3.141592 -- это результат округления числа пи.

MS>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

Да что к ':=' прицепились? Вирт, вероятно, был в большей степени математиком вначале, чем программистом. Поэтому для него '=' -- это равенство, а не присваивание. Он так был воспитан. А я, например, изучать программирование начал раньше, чем высшую математику. Поэтому я совершенно спокойно принимаю в качестве присваивания как '=', так и ':='. Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно. Здесь дело привычки, кто к чему привык в детстве.

Ну есть и дедушки такой пунктик по поводу ':='. Ну и ладно, вполне безобидная придурь.

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

Q>>С чего она увяла? Наоборот, изменяемость языка одна из очень мощных и интересных фич. И трудности синтаксического анализа не сильно мешают. Ну в самом деле, какие могут быть трудности с анализом в Лиспе?

E>Имхо, в основном, под трудностями Вирт подразумевал трудности воспрятия подобных вещей программистом, а не транслятором.

Скорее всего. Например, в ST-74 язык потока сообщений можно было менять для каждого отдельного класса(!), но после накопления некоего опыта, от этого отказались, из-за сложности поддержания и сопряжения "разноязыковых" классов.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Любую другую, про которую переодически вспоминают. От процедурного, структурного и объектно-ориентированного программирования, почему-то так просто не отказываются. А, например, про кодогенерацию то вспоминают, то забывают.

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

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

А я не уверен, что для распараллеливания такой задачи вообще нужны какие-то особые инструменты

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

Д>А я не уверен, что для распараллеливания такой задачи вообще нужны какие-то особые инструменты

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

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

E>Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно.

Ещё бывает (в оберонах) дважды перечеркнутое равно #

WHILE (list # NIL) & (list.head # obj) DO list := list.tail END

E>>Меня больше беспокоило, что неравенство в программировании -- это '<>' или '!=' (или что там еще бывает), а в математике -- перечеркнутое равно.

СГ>Ещё бывает (в оберонах) дважды перечеркнутое равно #

СГ>WHILE (list # NIL) & (list.head # obj) DO list := list.tail END

В целом, и "#" и "!=" — попытки изобразить все тот же знак

Правда, у решетки есть минус — в английском (американском?) — это устоявшийся символ слова "номер"

... << RSDN@Home 1.2.0 alpha rev. 619>>

F>Остроумна критика операторов ++/-- (Вирт считает, что это уродство). В общем — стоит, наверное, обратить внимание

Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами. Если бы Вселенная была бы устроена на принципах милосердия, то Java и аналог C# имели бы синтаксис Паскаля — как дань проделанному титаническому труду. Но наша Вселенная не устроена на принципах милосердия.

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

>А почему параллелизм должен быть встроенным в язык? Думаю, что программ, использующих распараллеливание работы, и написанных на C++/Java гораздо больше, чем на Erlange-е.

E>Смотря что мы понимаем под распараллеливанием. Если я пишу for(...) и какой-то умный инструмент понимает, как запустить этот for в параллель на нескольких процессорах -- это одно. А если я делаю, например, текстовый редактор и хочу, чтобы автосохранение выполнялось в фоне, параллельно редактированию, то здесь совсем другое. И я не уверен, что для текстового редактора нужен инструмент на основе функционального языка.

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

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

M>попытки изобразить все тот же знак

Система программирования Mathematica отличилась тем, что неравенство обозначается именно так как в математике:

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

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

Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?

Тем не менее, у меня есть мнение, что далеко не все представляют, как легко многозадачность может выглядеть в том же C++. Я не про распараллеливание вычислений, а об организации многопоточности (да и многопроцессовости тоже).

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

M>>попытки изобразить все тот же знак

СГ>Система программирования Mathematica отличилась тем, что неравенство обозначается именно так как в математике:

СГ>

Ндяяя... Вводится или дополнительным кликом по тулбару или комбинацией клавиш, я так понимаю.

Это мне напоминает мою первую книжку по Турбо Паскалю. Десять глав, по-моему было. Из них девяь — все нормально. В десятой объяснялись указатели... Указатели обозначались знаком "вертикальная стрелочка вверх"

То есть не "^", а натурально

В общем, указатели я выучил только в С++

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

MS>Однако стоит отметить, что в тех-же мат. формулах операции присваивания также обозначаются "=".
MS>"Пусть D=sqrt(b^2-4ac), тогда ..."

Это не присваивание. Указанную запись можно рассматривать как введение в констекст нового уравнения D = sqrt(b^2-4ac). Ничто не мешает мне записать "пусть справедливо равенство a+b=b+c", или что-то в этом роде. Вообще в математике отсутствует понятие присваивания, оно там избыточно и является частным случаем уравнения.

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

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

E>>Если язык ставит в затруднение анализаторы, то он определенно затруднит и человека. Многие языки были бы более понятными и чистыми, если бы разработчики вынуждались использовать более простой метод синтаксического анализа.
Д>Чушь, чушь и еще раз — чушь! У человека нет в голове ни LL, ни LR парсера. Он распознает конструкции языка с помощью механизмов распознавания образов, которые пока толком никому не понятны. Ясно только одно — они не имеют абсолютно ничего общего с последовательным чтением текста буква за буквой.
Это правда, но я бы не был столь категоричен

Помимо всего прочего, при работе за компьютером для меня важно знать, как компьютер будет выполнять мои команды. Особеннно в том случае, когда получаемый результат не совпадает с ожидаемым. Выражение vector<vector<int>> для меня интуитивно понятно, но моя задача исправить ошибку.

Д>как всё-таки удивительно узнать, что возможность переложить часть работы по распараллеливанию программ на компилятор — это "минимальное преимущество", а вот возможность делать всё самому и вручную — это "более эффективный способ хорошего использования параллелизма"

Возможно следует понять как: " в случае, когда параллелилизм нужен как кровь из носу, то, что может предложить компилятор редко когда оказывается удовлетворительным результатом. А вот человеку выполнить эту работу не сложно и с большим эффектом".

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

MS>Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами.

Ну думаю... Скорее всего истина в другом. Вирт имеет академическое образование, зарекомендовал себя также и как практик (реализовать с нуля систему Оберон за год сможет не каждый посетитель форума). Тоном фанатика, узрившего божий свет, он пытается донести его искру в массы. Но к его мнению не прислушиваются в IT индустрии.

Некоторые замечания:

1. Допустим в наше время некая фирма решила разработать систему, подобную Oberon. Думаю, что на базе тех же Java и C# ресурсы проекта будут гораздо больше, чем три человеко-года.
2. Язык Oberon имеет своих фанатиков, но в то же время это результат работы двух человек. Сейчас Oberon сравнивается с Java, C#. Интересно, какие команды разработчиков делает эти языки?
3. Вирт рекомендует свой путь основываясь на своем опыте. Совсем не факт, что его опыт можно будет перенести на коммандную разработку. Да и надо ли? Сейчас проекты в IT индустрии требуют больших команд и приносят больших денег. Что будет, если для выполнения проектов понадобится 2-3 грамотных человека??? Куда прихлебников девать???

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

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

VD>>Грамматика регекспов не LL(1). Это нерекурсивная грамматика. Так что она куда проще.

M>Ну как же не рекурсивная? Ведь операторы РВ применяют к самим РВ. Напрмиер, постфиксный оператор Клини "*" имеет в качестве аргумента именно регулярное выражение.

Ну, скажем так. Это концевая рекурсия, или цикл. Главное, что нельзя сделать правило которое мызвать рекурсивно.

M> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*...

Дык это не рекурсия — это просто именно что "вложенные вызвоы".

Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.

M> Это рекурсия в чистом виде. Доказать, что язык РВ сам не является регулярным языком очень просто, достаточно воспользоваться леммой о накачке. Являетс ли язык РВ LL(1)-языком? Уверен что да. Пару месяцев назад построил как раз такую грамматику и написал распознаватель, работающий методом рекурсивного спуска и выбирающий альтернативу на основе просмотра следующего символа. А значит, это именно LL(1)-грамматика.

Негулярные выражения несомненно можно распозновать LL(1)-парсерами. Но в приципе они для этого несколько избыточны. Можено жить проще.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Слушай, Влад, ты в последнее время так часто поминаешь Scala и Nemerle, что я не понимаю: C# -- он что, уже отстойный язык? Будущее за Nemerle?

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

Приемущество C# на сегодня слишком велики, чтобы Scala и Nemerle были ему конкурентами. Для C# есть рефакторинг, отличная интеграция с IDE, поддержка MS и пиар. Без всего этого успех языка не мыслим.

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

Как ты понимашь, дотнет мне в приципе ближе. А Scala больше ориентирована на Яву. Так что Nemerle для меня ближе, хотя надо признать, что некоторые вещи в Scala-е сделаны просто здорово (например, ковариантность для дженерик-коллекций). С другой стороны Nemerle больше заточен на получение всокопроизводитешьного кода, что делает его отличным притендентом на место убийцы С++

.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

K_O>Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.

Ага. И читать ее как "E == mc^2" это просто полный бред. Так что Вирт как всегда выдает желаемое за действительное.

Рельно "=" в математике и в императивных языках это совсем разные вещи. Похоже у них только начертание. Оно и не мудренно. Матетатика дераративна по своей сути, а ИЯ императивны по орпделению.

Если уж говорить о схожести, то ближе всго "=" используется в ФЯ.

K_O>В С++ же выражение
K_O>x = y;
K_O>означает действие по приведению значения х в состояние, когда оно будет равным у.

А в Обероне сравнение, что тоже не отражает исходной сути знакка "=".

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

Оно не более логично, и не менее логично. Это просто соглашение языка. С++ != математике! Вот и все!

А слова Вирта — это просто оправдание своей "хорошей идеи" которая не была принята практическими программистами.

Большинство современных языков используют именно "=" и их пользователи решительно не испытывают от этого проблем.

Проблемы от "=" есть только в С и С++ авторы которых были не соль дальновидны, чтобы предвидеть тот факт, что люди будут опечатываться в операторе if и писать вместо "==" "=".

Данная проблема устраняется двумя путями:
1. Введением более строкой типизации. Так сделано в C#. В нем никакое выражение отличное от булева не может приводиться к bool, а if всгда проверяет только булевы выражения. При этом проблемы все же возможны если оператор присвоения использовать для булевых переменных, но это не встречается на практике, так как сравнение с булевыми константами редко бывает осмысленно.
2. Запретом присвоений внутри выражений. Собственно Вирт и пользуется этим способом только зачем-то еще и синтаксически отделяет присвоение от сравнения. Между тем это не обязательно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>>Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами.
M>Ну думаю... Скорее всего истина в другом. Вирт имеет академическое образование, зарекомендовал себя также и как практик (реализовать с нуля систему Оберон за год сможет не каждый посетитель форума).
Знаем мы как пишут Оберон системы... читай Священная корова Оберона (специально для СГ). до просветления.
M>Тоном фанатика, узрившего божий свет, он пытается донести его искру в массы. Но к его мнению не прислушиваются в IT индустрии.
Индустрия рубит бабло. И индустрии наплевать на все что не помогает рубить бабло.

M>1. Допустим в наше время некая фирма решила разработать систему, подобную Oberon. Думаю, что на базе тех же Java и C# ресурсы проекта будут гораздо больше, чем три человеко-года.
Ну ни одна вменяемая контора не станит разрабатывать клон Оберон системы. Ибо это просто пустая трата денег.
А если делать все как следут то действительно нужно гораздо больше ресурсов.
M>2. Язык Oberon имеет своих фанатиков, но в то же время это результат работы двух человек. Сейчас Oberon сравнивается с Java, C#. Интересно, какие команды разработчиков делает эти языки?
Про жабу ничего не знаю но есть слухи что C# делают 4 человека.
M>3. Вирт рекомендует свой путь основываясь на своем опыте. Совсем не факт, что его опыт можно будет перенести на коммандную разработку. Да и надо ли? Сейчас проекты в IT индустрии требуют больших команд и приносят больших денег. Что будет, если для выполнения проектов понадобится 2-3 грамотных человека??? Куда прихлебников девать???
Если ты думаешь что бизнес найдя технологию которая в место 100 человек позволит задействовать 2-3 пусть и болие дорогих хоть секунду будет колебатся перед тем как выкинуть на улицу кучу нахлебников которым нужно платить деньги то поверь мне ты очень сильно заблуждаешься. От сюда вывод что опыт Вирта не дает никаких преймуществ по сравнению с тойже Жабой или C#.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

M>> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*...
VD>Дык это не рекурсия — это просто именно что "вложенные вызвоы".
VD>Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.
Ты не понял. Регулярные выражения не имеют рекурсии на то они и ругулярные выражения.
Но само регулярное выражение(а не ту строку которое оно описывает)без рекурсии в общем случае распознать не возможно.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

VD>Проблемы от "=" есть только в С и С++ авторы которых были не соль дальновидны, чтобы предвидеть тот факт, что люди будут опечатываться в операторе if и писать вместо "==" "=".

И компиляторы тут же выдают при этом warning, который обычно приравнивается к error. Так что не вижу здесь проблемы, равно как и осуждаю практику в виде:

if (2 == x) ;

VD>1. Введением более строкой типизации. Так сделано в C#. В нем никакое выражение отличное от булева не может приводиться к bool, а if всгда проверяет только булевы выражения. При этом проблемы все же возможны если оператор присвоения использовать для булевых переменных, но это не встречается на практике, так как сравнение с булевыми константами редко бывает осмысленно.

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

Object o = null;
if (o <> null) ;

Гораздо быстрее и без потери понятности (при наличии соглашений) можно писать

if (o) ;

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

WH>Ты не понял. Регулярные выражения не имеют рекурсии на то они и ругулярные выражения.
WH>Но само регулярное выражение(а не ту строку которое оно описывает)без рекурсии в общем случае распознать не возможно.

А причем, кстати, тут само РВ?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>а Паскаль пытается реанимировать только сам Вирт с апостолами.

Ради справедливости нужно вспомнить о Дельфи.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MS>

MS>Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.

А в физике это явно не присваивание букве E значения mc^2 ... В математике и физике знак '=' используется в качестве тождественности выражений. Скорее всего здесь хромает перевод и 'сравнение на равенство' = 'тождественность', что и подтверждает продолжение фразы.
Кстати очень сложно привыкать к этому различию, так что я склонен считать что Вирт тут прав, а также правы те кто ввели оператор :=.

C Уважением, Andir!

... << RSDN@Home 1.2.0 alpha rev. 635>>

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

M>Это правда, но я бы не был столь категоричен

M>Возможно следует понять как: " в случае, когда параллелилизм нужен как кровь из носу, то, что может предложить компилятор редко когда оказывается удовлетворительным
M> результатом. А вот человеку выполнить эту работу не сложно и с большим эффектом".

не сложно? если речь идет о реальном распараллеливании задачи, а не простом "сделать фоновый поток, чтобы он чего-нибудь обновлял", то совсем наоборот — сложно, очень сложно!
в любом случае, иметь хоть какую-то помощь от компилятора — это намного лучше, чем делать всё только вручную

... << RSDN@Home 1.1.4 stable rev. 510>>

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

VD>Ну, скажем так. Это концевая рекурсия, или цикл. Главное, что нельзя сделать правило которое мызвать рекурсивно.

Разве здесь концевая рекурсия? Ведь сначала мы должны распознать регулярное выражение, а только затем посмотреть, применяется ли к нему постфиксный оператор *. Или другой постфиксный оператор, + например. Или префиксный оператор. Рекурсия в языке регулярных выражений — это свойство самого языка безотносительно того, каким формализмом мы это свойство описываем. Свойство таково, приведу здесь часть индуктивного (читай рекурсивного) определения регулярного выражения:

1. РВ есть атомарное РВ, т.е. символ является РВ.
2. РВ есть РВ *, РВ +, РВ ? n и т.д.

Вот это свойство языка, где бы мы его не описывали, всегда будет обрабатываться циклическим процессом. Т.е. анализируя РВ мы снова должны будем прийти к этому анализу, но с другими параметрами. Вообще, это отличительное свойство формальных языков от естественных, повторяющиеся процессы. Или можно сказать так: отличие неживого от живого. Итак, мы имеем циклический процесс как свойство синтаксиса языка РВ. Причем я здесь совсем не говорю о семантике языка РВ, т.е. о том .что выражения этого языка значат. На сейчас важны только его синтаксические конструкции. Существуют разного рода формализмы для описания формальных языков, в частности, для описания КС-языков, таких как язык РВ. Наиболее популярны среди программистов те, которые описывают язык как вычислительный процесс, так как задача программиста — это построение вычислительного процесса, моделирующего логику программной модели. Для анализа РВ, в частности, можно применить два подхода:

1. Построить КС-грамматику, описывающую данный язык и все его свойства.
2. Построить распознаватель на основе магазинного автомата, распознающий РВ и только их.

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

РВ --> РВ *
РВ --> РВ +
РВ --> РВ ?

и т.д.

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

M>> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*...
VD>Дык это не рекурсия — это просто именно что "вложенные вызвоы".
VD>Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.

Честно говоря, совсем не понял, что здесь имелось ввиду. Вложенные скобки — часть синтаксиса языка РВ, например (((a)b*)).

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

MS>>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

VD>Оно не более логично, и не менее логично. Это просто соглашение языка. С++ != математике! Вот и все!

Согласен, но тем не менее изучение языка это легче не делает. Ведь человек интуитивно воспринимает семантику символа = так, как его учили с детства. А учили его математике, а не программирвоания. А там вообще при записи подразумевается именно равенство. Поэтому изучающему трудно перестроится. Тем самым создаются дополнительные барьеры на пути неофита. Что по мне, так мне и := не нравится тоже. Логично было бы использовать кнтовскую нотацию <-. Вот здесь как раз все кажется понятно.

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

MS>Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи...

Все же Вирт является первым разработчиков компилятора языка Паскаль. Если это не практика программирования, то что тогда?

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

VD>А в Обероне сравнение, что тоже не отражает исходной сути знакка "=".

Чего-то я не понял юмора. Как раз таки в паскалях, модулах, оберонах "=" есть "равно", а не "присвоить".

mefrill,

M>Логично было бы использовать кнтовскую нотацию <-. Вот здесь как раз все кажется понятно.

А ещё лучше символ 8592:

a ← 10;

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

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

Мир несовершенен

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

Д>не сложно? если речь идет о реальном распараллеливании задачи, а не простом "сделать фоновый поток, чтобы он чего-нибудь обновлял", то совсем наоборот — сложно, очень сложно!
Ну... реальный пример: Fritz и Deep Fritz. Распараллеливание в данном случае не сложно.

Д>в любом случае, иметь хоть какую-то помощь от компилятора — это намного лучше, чем делать всё только вручную

А можешь кинуть ссылку на результаты исследований, что это приводит к выигрышу производительности. Или выигрыш только в "теории"?

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

WH>Если ты думаешь что бизнес найдя технологию которая в место 100 человек позволит задействовать 2-3 пусть и болие дорогих хоть секунду будет колебатся перед тем как выкинуть на улицу кучу нахлебников которым нужно платить деньги то поверь мне ты очень сильно заблуждаешься. От сюда вывод что опыт Вирта не дает никаких преймуществ по сравнению с тойже Жабой или C#.

Во-первых, это не выгодно разработчикам сред для программирования. 100 копий VS.NET или BDS или 2-3 есть разница в прибыли??? Во-вторых, чем больше сумма проекта, тем по большому счету всем выгоднее. Для заказчика в IT одтеле это больший вес и большее влияние. Больше з/п в конце концом потому как больше сумма денег, больше ответственность, ... В нашей среде это откаты

Для исполнителей те же принципы

К тому же уволить 100 сотрудников это большой гемор. И т. д. и т. п. Тут я не раздедяю эту точку зрения

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

M>Во-первых, это не выгодно разработчикам сред для программирования. 100 копий VS.NET или BDS или 2-3 есть разница в прибыли???
А кого это волнует кроме разработчиков сред программирования?
M>Во-вторых, чем больше сумма проекта, тем по большому счету всем выгоднее.
А как сумма проекта зависит от колличества программистов?
M>Для заказчика в IT одтеле это больший вес и большее влияние. Больше з/п в конце концом потому как больше сумма денег, больше ответственность, ... В нашей среде это откаты

И какое отношение это имеет к колличеству программистов?
M>Для исполнителей те же принципы

К тому же уволить 100 сотрудников это большой гемор. И т. д. и т. п.
Если мастодонт не уволит сотню нахлебников то его порвет стартап который наймет 2-3 человека и за счет меньших издержек предложит большие откаты...
M>Тут я не раздедяю эту точку зрения

Это твое право.

Это с точки зрения бизнеса.

А теперь с точки зрения программирования: посмотри на C# и на Oberon и скажи в чем преймущества Oberon'а перед C#?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>А теперь с точки зрения программирования: посмотри на C# и на Oberon и скажи в чем преймущества Oberon'а перед C#?

В такой постановке этот вопрос напоминает: "посмотри на арбуз и свинной хрящик и скажи, в чем преимущества арбуза перед свинным хрящиком?".

Может стоит детализировать этот вопрос предметными областями? Например:
-- в Web-программировании;
-- в разработке (к примеру) офисного пакета;
-- в разработке системы управления движением транспорта в метрополитене;
-- в разработке встроенного ПО для промышленного робота;
-- в разработке ПО для математических расчетов.

То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения. Мне рассказывали о вариантах Unix-а для специализированных компьютеров, на которых не было ничего, кроме C и чудом портированного туда Python-а. И люди работали там нормально, не испытывая никаких комплексов и даже уходить не хотели не смотря на разные выгодные предложения. Вполне могу себе представить системы, где нет ничего, кроме Oberon-а. И задачи, которые решаются на этих системах. Это свой рынок. Со своими законами. И кто-то там работает и, думаю, чувствует себя вполне нормально.

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

E>То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения.
Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону.
E>Мне рассказывали о вариантах Unix-а для специализированных компьютеров, на которых не было ничего, кроме C и чудом портированного туда Python-а. И люди работали там нормально, не испытывая никаких комплексов и даже уходить не хотели не смотря на разные выгодные предложения.
E>Вполне могу себе представить системы, где нет ничего, кроме Oberon-а. И задачи, которые решаются на этих системах. Это свой рынок. Со своими законами. И кто-то там работает и, думаю, чувствует себя вполне нормально.
Это их проблемы. И к данному разговору это отношения не имеет. Вирт думает что Оберон панацея для мейнстима но он не понимает что Оберон по сравнению с Жабой или с C# ничего не дает.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

E>>То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения.
WH>Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону.

Извини, значит я не понял. Меня вот что смутило:

Индустрия рубит бабло. И индустрии наплевать на все что не помогает рубить бабло.

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

WH>Вирт думает что Оберон панацея для мейнстима но он не понимает что Оберон по сравнению с Жабой или с C# ничего не дает.

В статье Вирта я утверждения о том, что Оберон является панацей для мейнстрима не видел.

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

WH>Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону.

Извини за назойливость, но мне действительно интересно, считаешь ли ты, что C# однозначно имеет преимущества перед Oberon во всех перечисленных мной областях?

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

E>Извини за назойливость, но мне действительно интересно, считаешь ли ты, что C# однозначно имеет преимущества перед Oberon во всех перечисленных мной областях?
С точки зрения языка оберон и C# 1.1 примерно равны. Но если сравнивать с C#2 то тут Оберон проигрывает в чистую.
E>-- в Web-программировании;
C# рулит. ASP.NET, ADO.NET и еще куча библиотек не достапных оберону. Также у .NET рантайм гораздо богаче. Плюс мощьные срездства разработки которые тоже очень облегчают работу.
E>-- в разработке (к примеру) офисного пакета;
C# рулит. Таже фигня что и ВЕБом.
E>-- в разработке системы управления движением транспорта в метрополитене;
И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше.
E>-- в разработке встроенного ПО для промышленного робота;
Опять таки никаких преймуществ у оберона я тут не вижу. Особенно если в этого робота воткнуть что-то типа Singularity.
E>-- в разработке ПО для математических расчетов.
Тут и Оберон и C# пока что с треском сольют Intel C++ compiller'у. Но если МС для .NET делает оптимизатор который с большой вероятностью таки догонит а то и перегонит интеловский компилятор то разработчики оберона уверены что оптимизитор им не нужет ибо на оберн-ос нет тормозной аппаратной защиты и там все работает быстро

. Причем когда МС доведет до промышленного состояния Singularity там не будет тормозной аппаратной защиты и в отличии от оберон-ос с безопасностью тоже все в порядке ибо прагматики из МС в отличии от романтиков из ETH понимают что сейчас существует огромное колличество людей которые спят и видят как бы стащить чужую информации или обрушить чужой сервер.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

E>>-- в Web-программировании;
WH>C# рулит. ASP.NET, ADO.NET и еще куча библиотек не достапных оберону. Также у .NET рантайм гораздо богаче. Плюс мощьные срездства разработки которые тоже очень облегчают работу.

+1

E>>-- в разработке (к примеру) офисного пакета;
WH>C# рулит. Таже фигня что и ВЕБом.

+1

E>>-- в разработке системы управления движением транспорта в метрополитене;
WH>И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше.

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

E>>-- в разработке встроенного ПО для промышленного робота;
WH>Опять таки никаких преймуществ у оберона я тут не вижу. Особенно если в этого робота воткнуть что-то типа Singularity.

-1
См. предыдущий пункт. Singularity в промышленной эксплуатации нет. Oberon есть. Уже одно это выводит C# из рассмотрения, если на целевой платформы нельзя запустить Windows или, хотя бы, Mono. Но и тогда придется решать вопросы со сборкой мусора, например.

E>>-- в разработке ПО для математических расчетов.
WH>Тут и Оберон и C# пока что с треском сольют Intel C++ compiller'у.

-1
Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).

Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут

eao197 wrote:
> Дело не в скорости самой программы, а в том, насколько удобнее будет
> программитам-математикам писать программу на этих языках. Делать расчеты
> на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++
> и рулил, сам сталкивался).
Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.

Posted via RSDN NNTP Server 2.0

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

WH>С точки зрения языка оберон и C# 1.1 примерно равны. Но если сравнивать с C#2 то тут Оберон проигрывает в чистую.

Ага, щаз...

Сравним C#2 и C#1:

Что добавили:
1) Генерики — синтаксический сахар над copy/paste.
2) Так называемые "анонимные методы" — есть просто синтаксический сахар над вложенными процедурами. (Вложенные процедуры еще в паскале были)
3) Автотипы — чистейший синтаксический сахар.

Что так и осталось по прежнему:
1) Struct как нельзя было расширять (наследовать) — так и осталось нельзя. (В Обероне value типы — расширяемы)
2) Массивы как были ссылочными — так и остались ссылочными. (В Обероне массивы — value типы)
3) Модулей как не было — так и не появилось (class library можно только загружать, но нельзя выгружать, т.е. class library — не модули).

Итог
Добавили только сахар. Принципиальных изменений вносить не стали.

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

E>>>-- в разработке системы управления движением транспорта в метрополитене;
WH>>И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше.
E>+-
E>Имхо, в таких задачах средства разработки и библиотеки большой роли не играют.
Не согласен.
E>Здесь большее значение приобретает простота и предсказуемость языка, среды исполнения.
А что у C# с этим какието проблемы?
E>А так же наличие инструментов для тех платформ на которых будет работать эта система.
А на каких платформах это будет работать?
В любом случае если мне понадобится надежность любой ценой то я возьму функциональный язык.

E>См. предыдущий пункт. Singularity в промышленной эксплуатации нет. Oberon есть. Уже одно это выводит C# из рассмотрения, если на целевой платформы нельзя запустить Windows или, хотя бы, Mono. Но и тогда придется решать вопросы со сборкой мусора, например.
В любом случае оберон выдет из расмотреня еще раньше ибо это академическая поделка.
Опять же смотри више там где нужна надежность использовать имеперативные языки глупость.

E>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).
Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?

E>Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут

Этим занимаются какбы совсем разные подразделения МС...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

C>Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.

Да бог его знает. Я расчетами занимался в университете, поскольку специализировался на кафедре Вычислительной Математики и Программирования.
Так у меня сложилось впечатление, что Фортран берет большим количеством готовых библиотек, а скорость берется из-за его низкоуровневости.
Но преподаватели говорили, что удобнее всего для вычислений им использовать как раз Паскаль -- алгоритмы на нем гораздо проще делать, чем на Фортране, а по скорости не сильно уступают. А наличие встренных масивов с контролем выхода за диапазоны, строгая типизация и пр. просто на порядки повышает комфортность программирования (по сравнению с C).

Здравствуйте, Сергей Губанов, Вы писали:

СГ>2) Так называемые "анонимные методы" — есть просто синтаксический сахар над вложенными процедурами. (Вложенные процедуры еще в паскале были)

Кстати в обероне можно вернуть указатель на локальную функцию?

eao197 wrote:
> C>Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.
> Да бог его знает. Я расчетами занимался в университете, поскольку
> специализировался на кафедре Вычислительной Математики и Программирования.
> Так у меня сложилось впечатление, что Фортран берет большим количеством
> готовых библиотек, а скорость берется из-за его низкоуровневости.
Ну да, оптимизаторы для Фортрана — пожалуй самые лучшие. Это же простой
язык, без рекурсии (точнее она есть, но в новых версиях Фортрана, а
поэтому не всегда используется).

> Но преподаватели говорили, что удобнее всего для вычислений им
> использовать как раз Паскаль -- алгоритмы на нем гораздо проще делать,
> чем на Фортране, а по скорости не сильно уступают. А наличие встренных
> масивов с контролем выхода за диапазоны, строгая типизация и пр. просто
> на порядки повышает комфортность программирования (по сравнению с C).
А у вас математики что-то знают, кроме Паскаля? Я удивлен.

Еще очень активно, кстати, используется Ява.

Posted via RSDN NNTP Server 2.0

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

WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?

Легко.
Ткачёв думаете просто так что ли перешёл на Оберон/Компонентный-Паскаль?

Оберон в версии CP и BlackBox выбран в качестве инструментария для всех проектов на основе ~25-летнего опыта использования в данном направлении самых разных подходов и анализа ошибок.

Фишка в том, что алгоритм расчёта может быть чрезвычайно сложен.
Правильно реализовать чрезвычайно сложный алгоритм на языке C++ гораздо сложнее чем на Oberon/Component Pascal, которые имеют сборщик мусора.

Доктор физико-математических наук Фёдор Васильевич Ткачёв приводит следующий пример.
Он в BlackBox на Component Pascal реализовал алгоритм за 3 месяца.
Его конкурент решал ту же самую задачу на С++ 3 года.
В результате, программа Ткачёва на Component Pascal оказалась в 8 раз быстрее программы на С++ и работала правильно, в то время как программа на С++ работала нестабильно, падала, страдала утечками памяти и т.п. Обвинить конкурента в криворукости нельзя — он действительно классно знает С++. Просто алгоритмы очень сложные — надо интенсивно работать с гигабайтными динамическими структурами.

http://blackbox.metasystems.ru/index.php?option=com_content&task=view&id=15&Itemid=15

Другие проекты:
http://blackbox.metasystems.ru/index.php?option=com_content&task=blogcategory&id=6&Itemid=17

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

E>>Здесь большее значение приобретает простота и предсказуемость языка, среды исполнения.
WH>А что у C# с этим какието проблемы?

Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится?

Помнится, здесь была большая тема про сборку мусора в real-time системах. И приводилась ссылка на компанию, которая продавала программно-аппаратный комплекс, разработанный на основе Oberon.

E>>А так же наличие инструментов для тех платформ на которых будет работать эта система.
WH>А на каких платформах это будет работать?

Например, на QNX, VxWorks, LynxOS, OS-9, или любой другой из этих.

WH>В любом случае если мне понадобится надежность любой ценой то я возьму функциональный язык.

Опять же, если он будет в наличии.

WH>Опять же смотри више там где нужна надежность использовать имеперативные языки глупость.

Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности.

WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?

Оговорюсь, не по скорости, а по удобству для программистов-математиков. А где -- например, при расчете надежности ленточных фундаментов методом конечных элементов, при расчете распределения температуры на лопастях турбин методом граничных элементов, при расчетах надежности конструкций методом конечных разностей, при реализации расчетов оптимизации чего-нибудь различными вариантами методов оптимизации (того же симплекс метода, к примеру). Поскольку я специализировался на кафедре Вычислительной Математики и Программирования, могу утверждать, что математики предпочитали пользоваться Паскалем, а не C++.

Сергей Губанов wrote:
> Что добавили:
> 1) Генерики — синтаксический сахар над copy/paste.
Бред. Генерики никоим образом не являются заменой cut&paste, а заменой
явных приведений типов. Но Оберону это пофиг — в нем есть одна
генерик-коллекция (массив), которой они гордятся.

> 2) Так называемые "анонимные методы" — есть просто синтаксический сахар
> над вложенными процедурами. (Вложенные процедуры еще в паскале были)
Неверно. Анонимные методы являются синтаксическим сахаром методами +
делегатами.

> 3) Автотипы — чистейший синтаксический сахар.
Но их нет в Обероне.

> Что так и осталось по прежнему:
> 1) Struct как нельзя было расширять (наследовать) — так и осталось
> нельзя. (В Обероне value типы — расширяемы)
А вот это как раз с помощью сахара делается:

struct base
{
    int a,b,c;
};
struct child
{
    base _base;
    int d,e,f;
};

> 3) Модулей как не было — так и не появилось (class library можно только
> загружать, но нельзя выгружать, т.е. class library — не модули).
Для модулей собираются добавить GC. То есть неиспользуемые сборки будут
просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это
вполне безопасно (а в Java уже лет 5 код классов собирается GC).

Posted via RSDN NNTP Server 2.0

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

E>>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).

Пробовали ли вы закодировать простейшее выражение с комплексными числами на голом C?

WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?

Я не знаю, что такое Оберон, но однозначно могу сказать, что на комплексных числах Фортран кроет С++ по скорости. И иначе быть не может, поскольку комплексные числа — это встроенный тип в Фортране и оптимизатор все про них знает. А в C++ это некий класс, просто класс. Класс как класс и всех делов. Возможно, что и с Паскалями-Оберонами нечто похожее.

E>>Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут

WH>Этим занимаются какбы совсем разные подразделения МС...

А нам-то что от этого? MS он и есть MS.

Еще не хватало вникать в организацию ихней структуры.
Помню во времена NT-4 было много визга про супер-систему под кодовым названием "Cairo", которую потом похерили и вместо нее выпустили полуфабрикат Chicago. Занимались разные подразделения...

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

_>Кстати в обероне можно вернуть указатель на локальную функцию?

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

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

C>А у вас математики что-то знают, кроме Паскаля? Я удивлен.

Знали. 12-13 лет назад. И давали нам возможность выбирать язык реализации (Pascal, C, C++). Я предпочитал C++. Хотя на пятом курсе как-то специально сделал все лабы по спецкурсу по методам принятия решений (или методам оптимизации, не помню точно) на Turbo Pascale-е, поскольку расчеты действительно было проще на Паскале делать.

Что сейчас -- даже не представляю. Вероятно, большинству пришлось от Паскаля отказаться.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>В результате, программа Ткачёва на Component Pascal оказалась в 8 раз быстрее программы на С++ и работала правильно, в то время как программа на С++ работала нестабильно, падала, страдала утечками памяти и т.п. Обвинить конкурента в криворукости нельзя — он действительно классно знает С++. Просто алгоритмы очень сложные — надо интенсивно работать с гигабайтными динамическими структурами.
Код программы на С++ в студию. А мы уже решим на сколько хорошо автор знает программирование вобще и С++ в частности.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

eao197 wrote:
> Помнится, здесь была большая тема про сборку мусора в real-time
> системах. И приводилась ссылка на компанию, которая продавала
> программно-аппаратный комплекс, разработанный на основе Oberon.
Я спросил у знакомых real-time'щиков. Про Обероновые системы они ничего
не слышали вообще (как и про сам Оберон).

Из наиболее близкого — Inferno VM. Там использовался Паскаль-подобный
язык, но это далеко не Оберон. Компания появилась в конце 90-х и продает
встраиваемые системы, не очень успешно.

Posted via RSDN NNTP Server 2.0

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

E>>>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).

MS>Пробовали ли вы закодировать простейшее выражение с комплексными числами на голом C?

А работу с разреженными матрицами на Паскале?

Как раз из-за таких вещей я предпочитал C++.

McSeem2 wrote:
> E>>Дело не в скорости самой программы, а в том, насколько удобнее будет
> программитам-математикам писать программу на этих языках. Делать расчеты
> на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++
> и рулил, сам сталкивался).
> Пробовали ли вы закодировать простейшее выражение с комплексными числами
> на голом C?
No problem:

complex double square_d(complex double a)
{
    return (a * a);
}

(это С99)

> Я не знаю, что такое Оберон, но однозначно могу сказать, что на
> комплексных числах Фортран кроет С++ по скорости. И иначе быть не может,
> поскольку комплексные числа — это встроенный тип в Фортране и
> оптимизатор все про них знает. А в C++ это некий класс, просто класс.
Ну не совсем так. Intel C++, например, знает про комплексные числа из
стандартной библиотеки и использует для них специальные оптимизации.

Posted via RSDN NNTP Server 2.0

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

C>Для модулей собираются добавить GC. То есть неиспользуемые сборки будут
C>просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это
C>вполне безопасно (а в Java уже лет 5 код классов собирается GC).

Как интересно GC должен решить задачу о возможности выгрузки вот такого модуля:

MODULE M;

  VAR a*: INTEGER;

END M.

или на C#:

public sealed class M
{
  private M ()
  {
  }

  public static int a;
}

Допустим количество ссылок на модуль M сейчас равно нулю. Значит его уже можно выгружать, да?

А вот и нельзя!!!
Вдруг через 3 часа в систему будет загружен некий другой модуль, который захочет считать значение переменной M.a???? И что он прочтёт??? Если модуль M будет выгружен, а потом опять загружен, то M.a будет равно 0.

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

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

E>Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится?
А в Обероне уже нет сборщика мусора?
E>Помнится, здесь была большая тема про сборку мусора в real-time системах. И приводилась ссылка на компанию, которая продавала программно-аппаратный комплекс, разработанный на основе Oberon.
И в чем проблема посадить C# на сборщик мусора работающий в реальном времени?

E>Например, на QNX, VxWorks, LynxOS, OS-9, или любой другой из этих.
А оберон на них есть?

E>Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности.
Ты думаешь это хорошо?

E>Оговорюсь, не по скорости, а по удобству для программистов-математиков. А где -- например, при расчете надежности ленточных фундаментов методом конечных элементов, при расчете распределения температуры на лопастях турбин методом граничных элементов, при расчетах надежности конструкций методом конечных разностей, при реализации расчетов оптимизации чего-нибудь различными вариантами методов оптимизации (того же симплекс метода, к примеру). Поскольку я специализировался на кафедре Вычислительной Математики и Программирования, могу утверждать, что математики предпочитали пользоваться Паскалем, а не C++.
Исключительно по тому что они привыкли к Паслаю и ничего не знают о С++. Да и опять же математикам должны быть ближе функциональные языки.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Нет конечно. Точно так же как нельзя вернуть адрес любой локальной сущности.
Это не настолько очевидно. В современных языках это можно. В том же Шарпе, например. Только не адрес, а объект — функция + замыкание.
СГ>Вложенная процедура живет в контексте процедуры её вызвавшей и имеет доступ к её локальным переменным. Поэтому снаружи её вызывать нельзя. Раз нельзя, то и указатель на неё получить нельзя.
Так а в чем ее смысл? Главное в анонимных методах, лямбда функциях и всех их родственниках — это то, что они хранят замыкание — контекст, в котором их вызвали. В Шарпе, насколько я видел, анонимные методы применяют для создания однострочных коллбэков. А в Обероне так можно?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Я спросил у знакомых real-time'щиков. Про Обероновые системы они ничего
C>не слышали вообще (как и про сам Оберон).

Да этих real-time систем как грязи.
А вот о чем я говорил: http://www.rsdn.ru/Forum/Message.aspx?mid=1268451&only=1

Сергей Губанов wrote:
> WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по
> сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?
> Легко.
> Ткачёв думаете просто так что ли перешёл на Оберон/Компонентный-Паскаль?
Может из-за того, что не смог освоить альтернативы?

> Фишка в том, что алгоритм расчёта может быть чрезвычайно сложен.
> Правильно реализовать чрезвычайно сложный алгоритм на языке C++ гораздо
> сложнее чем на Oberon/Component Pascal, которые имеют сборщик мусора.
1. Сборщик мусора (причем не хуже Обероновского) к С++ прикручивается за
5 минут. Не верите? Давайте поспорим.
2. Перегрузка операторов в С++ позволяет записывать многие алгоритмы
_гораздо_ красивее Оберона.

> Он в BlackBox на Component Pascal реализовал алгоритм за 3 месяца.
> Его конкурент решал ту же самую задачу на С++ 3 года.
"Один журнал погружаем в серную кислоту, а TV Park в дистиллированую
воду. Видите? С TV Park'ом ничего не случилось!" (с) реклама.

> Обвинить конкурента в криворукости нельзя — он действительно классно
> знает С++.
Да-да. Мы уже, кажется, смеялись над примерами его знаний.

Posted via RSDN NNTP Server 2.0

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

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

E>Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?

Ада, Оккам, Симула.

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

M>Это мне напоминает мою первую книжку по Турбо Паскалю. Десять глав, по-моему было. Из них девяь — все нормально. В десятой объяснялись указатели... Указатели обозначались знаком "вертикальная стрелочка вверх"

То есть не "^", а натурально

Тебя, наверное, нагло обманули. Это была книжка по просто Паскалю.

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

WH>Код программы на С++ в студию.

Недождётесь...

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

E>>Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится?
WH>А в Обероне уже нет сборщика мусора?

Дык, вроде, эту проблему уже решили: http://www.rsdn.ru/Forum/Message.aspx?mid=1268451&only=1

WH>И в чем проблема посадить C# на сборщик мусора работающий в реальном времени?

В том, что этого еще нет. Или уже есть?

WH>А оберон на них есть?

Там, я думаю, нет. Уто у Сергея Губанова нужно спрашивать, где есть Оберон.
А вот где есть C# и так понятно. Я не в обиду C#, просто думаю, что встраиваемые системы вряд ли когда-нибудь на C# будут делать. Хотя бы потому, что там уже, кроме C и C++, еще и J2ME есть.

E>>Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности.
WH>Ты думаешь это хорошо?

Не мне решать, хорошо это или нет. Так есть. И с этим нужно считаться.

WH>Да и опять же математикам должны быть ближе функциональные языки.

Математикам, имхо, должна быть ближе математика. Как я смог заметить, нельзя от них требовать досканального знания особенностей языка. И, поэтому, чем более тривиальный язык, тем лучше. Поэтому C++ со своими заморочками многим не подходил.
А вот устроят ли математиков функциональные языки по скорости работы кода -- это большой вопрос. Особенно в числодробительных областях.

Здравствуйте, Сергей Губанов, Вы писали:

WH>>Код программы на С++ в студию.
СГ>Недождётесь...

Тогда я делаю единственно возможной в этой ситуации вывод: Все это не болие чем маркетинговый бред.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

E>Математикам, имхо, должна быть ближе математика. Как я смог заметить, нельзя от них требовать досканального знания особенностей языка. И, поэтому, чем более тривиальный язык, тем лучше. Поэтому C++ со своими заморочками многим не подходил.
E>А вот устроят ли математиков функциональные языки по скорости работы кода -- это большой вопрос. Особенно в числодробительных областях.
ML и его вариации очень хорошо поддаются оптимизации.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Сергей Губанов wrote:
> _>Кстати в обероне можно вернуть указатель на локальную функцию?
> Нет конечно. Точно так же как нельзя вернуть адрес любой локальной сущности.
> Вложенная процедура живет в контексте процедуры её вызвавшей и имеет
> доступ к её локальным переменным. Поэтому снаружи её вызывать нельзя.
> Раз нельзя, то и указатель на неё получить нельзя.
А почему бы и нет? В Lisp'е и JavaScript есть continuation'ы — то есть
можно передать снимок состояния как обычное значение.

Posted via RSDN NNTP Server 2.0

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

WH>Все это не болие чем маркетинговый бред.

То есть кто-то пытается продать BlackBox?

Вообще-то он бесплатный и с открытым исходным текстом...

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

WH>Код программы на С++ в студию. А мы уже решим на сколько хорошо автор знает программирование вобще и С++ в частности.

+1

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

eao197 wrote:
> C>А у вас математики что-то знают, кроме Паскаля? Я удивлен.
> Знали. 12-13 лет назад.
Так бы сразу и сказали. Тогда действительно особого выбора не было, а
Turbo Pascal был вполне адекватен.

> Что сейчас -- даже не представляю. Вероятно, большинству пришлось от
> Паскаля отказаться.
Знаю нескольких исследователей, двое пишут на Mathematica, один на С++ с
использованием VTK.

Posted via RSDN NNTP Server 2.0

Сергей Губанов wrote:
> C>Для модулей собираются добавить GC. То есть неиспользуемые сборки будут
> C>просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это
> C>вполне безопасно (а в Java уже лет 5 код классов собирается GC).
> Как интересно GC должен решить задачу о возможности выгрузки вот такого
> модуля
Очень просто. Строим граф зависимостей кода, как только класс M попадает
в изолированый подграф — выгружаем его.

Собственно, так и работает обычный GC.

> Допустим количество ссылок на модуль M сейчас равно нулю. Значит его уже
> можно выгружать, да?
Да.

> Вдруг через 3 часа в систему будет загружен некий другой модуль, который
> захочет считать значение переменной M.a???? И что он прочтёт??? Если
> модуль M будет выгружен, а потом опять загружен, то M.a будет равно 0.
Ну и держите ссылку на этот модуль явно. Какие проблемы?

> Модули нельзя выгружать "автоматически". Их можно выгружать только по
> явной просьбе.
По явной просьбе их тоже выгружать нельзя.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Сергей Губанов, Вы писали:

WH>>Все это не болие чем маркетинговый бред.
СГ>То есть кто-то пытается продать BlackBox?
СГ>Вообще-то он бесплатный и с открытым исходным текстом...
Не обязательно продать. А впарить с теми или иными целями. Какие цели у того кто это говорит я не знаю.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

C>А почему бы и нет? В Lisp'е и JavaScript есть continuation'ы — то есть
C>можно передать снимок состояния как обычное значение.
Это даже в C#2 можно... а в мегакрутом обероне нельзя...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

M>Разве здесь концевая рекурсия?

Я вел речь не о грамматике регекспов, а о грамматике описываемой регексами.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

MS>>>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

M>Логично было бы использовать кнтовскую нотацию <-. Вот здесь как раз все кажется понятно.

<- тоже подошел бы. Но и с = проблем нет. Ну, нет, и все.

Проблема именно в реализации С и С++. Там эти операторы приводят к проблемам. Но как тут правильно заметили современные компиляторы зачастую от них уберегают.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>А ещё лучше символ 8592:
LCR>

LCR>a ← 10;
LCR>

Вот, можешь поглядеть насколько это лучше.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Чего-то я не понял юмора. Как раз таки в паскалях, модулах, оберонах "=" есть "равно", а не "присвоить".

Не равно, а проверка на равенство, то есть предикат. А исходное значение "=" — это задание отношения равенства. То есть скорее ассерт, если говорить в терминах императивного языка.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

C>Ну и держите ссылку на этот модуль явно. Какие проблемы?

Кто будет исполнять функцию первородной держалки?
Один модуль держит другой, а его третий и т.д., а конец где? Главный-то корень???

Сергей Губанов wrote:
> C>Ну и держите ссылку на этот модуль явно. Какие проблемы?
> Кто будет исполнять функцию первородной держалки?
> Один модуль держит другой, а его третий и т.д., а конец где? Главный-то
> корень???
В начале стека каждого потока.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Сравним C#2 и C#1:

СГ>Что добавили:
СГ>1) Генерики — синтаксический сахар над copy/paste.
Вот это знойно. Это на пять.

Мощно задвинул. Долго не мог прочухаться.

СГ>2) Так называемые "анонимные методы" — есть просто синтаксический сахар над вложенными процедурами. (Вложенные процедуры еще в паскале были)
Тоже неплохо. Прямо таки сегодня день классный. Особенно если учитывать что так называемые "анонимные методы" можно передавать в другие функции и объекты, и точно так же возвращать.

СГ>3) Автотипы — чистейший синтаксический сахар.
Понятно. Теперь осознал.

СГ>Что так и осталось по прежнему:
СГ>1) Struct как нельзя было расширять (наследовать) — так и осталось нельзя. (В Обероне value типы — расширяемы)
Ну отчего же, можно. Только не другие типы, а интерфейсы.

СГ>(В Обероне массивы — value типы)
Это еще почему?

СГ>3) Модулей как не было — так и не появилось (class library можно только загружать, но нельзя выгружать, т.е. class library — не модули).
Ну смотря как ты будешь загружать. Коли в домен, то можно и выгрузить. Или например воспользоваться JScript.NET. Там таких проблем вообще не присутсвует.

СГ>Итог
СГ>Добавили только сахар. Принципиальных изменений вносить не стали.
Ну-ну. Кому сахар, а кому и горчица.

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

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

C>>Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.

E>Да бог его знает. Я расчетами занимался в университете, поскольку специализировался на кафедре Вычислительной Математики и Программирования.
E>Так у меня сложилось впечатление, что Фортран берет большим количеством готовых библиотек, а скорость берется из-за его низкоуровневости.
E>Но преподаватели говорили, что удобнее всего для вычислений им использовать как раз Паскаль -- алгоритмы на нем гораздо проще делать, чем на Фортране, а по скорости не сильно уступают.

А какого мнения они о MATLAB? Мне он нравится

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

MS>А нам-то что от этого? MS он и есть MS.

Еще не хватало вникать в организацию ихней структуры.
MS>Помню во времена NT-4 было много визга про супер-систему под кодовым названием "Cairo", которую потом похерили и вместо нее выпустили полуфабрикат Chicago. Занимались разные подразделения...
Нее. Судя по некоторым blob'ам дело Cairo живет и процветает. здесь
Если считать что прошло больше 10 лет, то Singalutary выйдет в ....

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

WH>Не обязательно продать. А впарить с теми или иными целями. Какие цели у того кто это говорит я не знаю.

+1 за бдительность. Знаю я эту секту. Сначала в Чёрную Коробку посадят, потом появится отвращение к оператору "++", а там и дойдёт до того, что Вирта папой будеш называть.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>А почему бы и нет? В Lisp'е и JavaScript есть continuation'ы — то есть
C>>можно передать снимок состояния как обычное значение.
WH>Это даже в C#2 можно... а в мегакрутом обероне нельзя...

Это обсасывали уже много раз. Никаких продолжений в C# нет. А то что есть это банальное надувательство

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Сергей Губанов, Вы писали:

C>>Ну и держите ссылку на этот модуль явно. Какие проблемы?

СГ>Кто будет исполнять функцию первородной держалки?
СГ>Один модуль держит другой, а его третий и т.д., а конец где? Главный-то корень???

А лепо ли заниматься умолчаниями?

Состояние модуля (хранимое в его статических переменных) делает этот модуль, фактически, синглетоном.
У синглетонов могут быть разные политики времени жизни: как минимум,
— феникс
— от начала до конца (можно сделать с помощью феникса, зацепив объект за главную активность программы)

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

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>Не обязательно продать. А впарить с теми или иными целями. Какие цели у того кто это говорит я не знаю.

ANS>+1 за бдительность. Знаю я эту секту. Сначала в Чёрную Коробку посадят, потом появится отвращение к оператору "++", а там и дойдёт до того, что Вирта папой будеш называть.

Кстати, Андрей, а со Smalltalk-ом такого не происходит? А то я уже почти выкроил время что бы поизучать, а вдруг там такой же эффект?

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

VD>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Чего-то я не понял юмора. Как раз таки в паскалях, модулах, оберонах "=" есть "равно", а не "присвоить".

VD>Не равно, а проверка на равенство, то есть предикат. А исходное значение "=" — это задание отношения равенства. То есть скорее ассерт, если говорить в терминах императивного языка.
Это лучше всего описывается в логических языках. Это утверждение.

Кодт wrote:
> Состояние модуля (хранимое в его статических переменных) делает этот
> модуль, фактически, синглетоном.
> У синглетонов могут быть разные политики времени жизни: как минимум,
> — феникс
> — от начала до конца (можно сделать с помощью феникса, зацепив объект за
> главную активность программы)
Кстати, в Java именно "фениксовые" классы и есть по умолчанию, что
закреплено в спеке на JVM.

Фениксовые синглотоны в Java можно преобразовать в более устойчивые с
помощью своего classloader'а — достаточно чтобы он держал в себе ссылки
на загруженные классы. То же самое можно сделать и в .NET.

Posted via RSDN NNTP Server 2.0

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

E>>Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?

К>Ада, Оккам, Симула.
Active C++ еще есть. Сам, правда, не видал. Но слышал.

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

К>>Ада, Оккам, Симула.
GZ>Active C++ еще есть. Сам, правда, не видал. Но слышал.

Он, кажется, уже не развивается. Да и экспериментальные поделки не интересны.

M>>Это мне напоминает мою первую книжку по Турбо Паскалю. Десять глав, по-моему было. Из них девяь — все нормально. В десятой объяснялись указатели... Указатели обозначались знаком "вертикальная стрелочка вверх"

То есть не "^", а натурально

К>Тебя, наверное, нагло обманули. Это была книжка по просто Паскалю.

Возжно — я просто не помню

Кстати, при написании сообщения, размышлял, писать "Турбо" или не писать. Решил написать

А что, в Паскале была вот эта самая стрелка вверх?

... << RSDN@Home 1.2.0 alpha rev. 619>>

M>>Согласен, но тем не менее изучение языка это легче не делает. Ведь человек интуитивно воспринимает семантику символа = так, как его учили с детства.

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

Когда нам в школе начали преподавать Паскаль, многие не понимали, что значит := и понятие "присваивать". Так что, можно на то место все, что угодно ставить, сложности с восприятием не будет (или будет — зависит от человека)

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

E>Кстати, Андрей, а со Smalltalk-ом такого не происходит? А то я уже почти выкроил время что бы поизучать, а вдруг там такой же эффект?

Цитирую:

Smalltalk опасен. Smalltalk это как наркотик.
Мой совет Вам — не пробуйте его; он может разрушить Вашу жизнь. Когда вы найдете время изучить его (ДЕЙСТВИТЕЛЬНО изучить) вы увидите, что нет ничего (пока), что может с ним сравниться. Конечно, как и для любого наркотика, его опасность зависит от вашего характера. Возможно, что когда Вы попадете в зависимость, Вам будет тяжело (если вообще возможно) вернутся назад к другим языкам программирования и, если Вас все-таки заставят вернуться, Вы можете стать постоянно ворчащей озлобленной личностью. Кто знает, возможно Вы даже уйдете из софтверной индустрии вообще, так как ничего более не достойно Ваших ожиданий.

Andy Bower.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Не равно, а проверка на равенство, то есть предикат. А исходное значение "=" — это задание отношения равенства. То есть скорее ассерт, если говорить в терминах императивного языка.
GZ>Это лучше всего описывается в логических языках. Это утверждение.

А как по-твоему переводится ассерт?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

VD>>>Не равно, а проверка на равенство, то есть предикат. А исходное значение "=" — это задание отношения равенства. То есть скорее ассерт, если говорить в терминах императивного языка.
GZ>>Это лучше всего описывается в логических языках. Это утверждение.

VD>А как по-твоему переводится ассерт?

Да уж. Не сразу подумал. Велик и могуч английский язык.
Но ты говорил о императиных языках, а там семантика — лови экцепшн. Вот и прогнал. Вобщем виноват.

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

M>Кстати, при написании сообщения, размышлял, писать "Турбо" или не писать. Решил написать

А что, в Паскале была вот эта самая стрелка вверх?

Я думаю, дело в том, что в ASCII (по крайней мере, в древности) не было специфицировано, что именно скрывается за позицией 94 — то ли птичка (циркумфлекс) ^, то ли стрелка ↑. И у каждого компьютерного терминала там было своё.
В языке Васик для микроэвм Ириша

вместо $ использовалась черепашка ¤ — по той же причине.

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

M>Когда нам в школе начали преподавать Паскаль, многие не понимали, что значит := и понятие "присваивать". Так что, можно на то место все, что угодно ставить, сложности с восприятием не будет (или будет — зависит от человека)

Нет, ну все-таки необходимо как-то графическое изображение действия привести в соответствие с интуитивным пониманием этого действия. В данном случае, операция присваивания — это именно действие, причем действие не симметричное, и изображать его графически симметрично нехорошо, это только запутывает изучающего. Ну что говорит символ = об операции присваивания? Да совершенно ничего, и только запутывает, потому что с этим символом в математике связан целый пласт ассоциаций. А если кто-то, как уже пытались здесь выше, скажет мне, что программирование изучается раньше математики и потому символ = для изучающих программирвоание не несет никакой смысловой нагрузки, я только скажу, как ВВП на недавней прессконференции — тьфу на вас! Ну почему не изобразить эту операцию через <-, <=, <== или <-- ? Ведь отсюда сразу видно, что это операция, т.е. действие, состоящее в ассоцировании значения справа со значением слева. Что значит ассоциирование легко уже объяснить. Я понимаю, программисты — это не преподаватели, они трудностей обучения языку си++ не знают ибо такого опыта не имеют, но я уверяю, что это первая проблема, с которой встречается неофит на пути изучения языка.

Отсткпление посвящается опрераторам присваивания.

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

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

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

К>- от начала до конца

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

Модульные системы — не выключаются (ну, если только вместе с самим компьютером).

Про модульные системы надо думать так:
1) Сама модульная система живёт "вечно".
2) Модули: загружаются, исполняются, выгружаются, заменяются, ...
3) В роли "держалки" каждого модуля выступает среда времени исполнения. Чтобы выгрузить модуль, надо попросить об этом среду времени исполнения, а она, в свою очередь, может отказаться сделать это: http://www.rsdn.ru/Forum/Message.aspx?mid=1657391&only=1

Здравствуйте, Сергей Губанов, Вы писали:

СГ>2) Массивы как были ссылочными — так и остались ссылочными. (В Обероне массивы — value типы)

Хочу отметить, что в C# тоже можно создавать массивы как value-типы. См. ключевое слово stackalloc.
Только радости с этого никакой — по любому, передача массива как value-объекта повлечет его копирование (не адрес же с локального стэка отдавать), что для массивов весьма накладно.

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

X>Хочу отметить, что в C# тоже можно создавать массивы как value-типы. См. ключевое слово stackalloc.

1) Так, в unsafe режиме не считается. Там, как говорится, из слона можно муху сделать (или наоборот).
2) А если я не хочу на стеке, а хочу внутри объекта...

Здравствуйте, Сергей Губанов, Вы писали:

X>>Хочу отметить, что в C# тоже можно создавать массивы как value-типы. См. ключевое слово stackalloc.
СГ>1) Так, в unsafe режиме не считается. Там, как говорится, из слона можно муху сделать (или наоборот).

А это еще почему?????

СГ>2) А если я не хочу на стеке, а хочу внутри объекта...

Только внутри структуры.
См. ключевое слово fixed и fixed-size buffers

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

M>Нет, ну все-таки необходимо как-то графическое изображение действия привести в соответствие с интуитивным пониманием этого действия. В данном случае, операция присваивания — это именно действие, причем действие не симметричное, и изображать его графически симметрично нехорошо, это только запутывает изучающего. Ну что говорит символ = об операции присваивания? Да совершенно ничего, и только запутывает, потому что с этим символом в математике связан целый пласт ассоциаций. А если кто-то, как уже пытались здесь выше, скажет мне, что программирование изучается раньше математики и потому символ = для изучающих программирвоание не несет никакой смысловой нагрузки, я только скажу, как ВВП на недавней прессконференции — тьфу на вас! Ну почему не изобразить эту операцию через <-, <=, <== или <-- ? Ведь отсюда сразу видно, что это операция, т.е. действие, состоящее в ассоцировании значения справа со значением слева. Что значит ассоциирование легко уже объяснить. Я понимаю, программисты — это не преподаватели, они трудностей обучения языку си++ не знают ибо такого опыта не имеют, но я уверяю, что это первая проблема, с которой встречается неофит на пути изучения языка.

В моем потоке небыло ниодно человека, который не понял операции присваивания в си. Может матиматиков это и сбивает, но обычный человек когда смотрит на = не задумывается о "симметричности"!
В той же матиматике есть вещи которые очень смущают, например квадрат — это четырехугольник, но читырехугольник не есть квадрат... Вот я над чем парился в детстве! Хотя любому из Вас это ясно, от того что вы это знаете!!! Я это понял и осознал, как понял и осознал знак = в си и := в паскале.
Подобные знаки (=, -->, # и т.п.) используются в разных науках и там не вызывают затруднений, хотя и обозначают отличные от матиматических действия...
Если вы спрашиваете о затруднениях, то это от того что язык начинают изучать с матиматических операций, по этому он с самого начала вызывает такие ассоциации...
Например я не понимал как заставить бейсик вывести ответ и считал что если написать

6 + 7 =

то он мне его посчитает... Когда начинаешь понимать программирование, такие проблемы просто отваливаются... Понял как все происходит и стало все равно, что там стоит за присваеванием = или :=
А Вирт давит на то, что ребенок не пинимает, что (уж простите формула не матиматики, но жизни

)

Маша + Петя = Любовь

Любовь =  Маша + Петя

не одно и тоже, ну так это по моему очевидно...
Короче суть в следующем: почитайте, в топике никто не жаловался на то что он не понял знак присваевания в си, т.е. проблем на этом этапе НЕТ! Проблема в том, что программирование != (или <>) матиматика и обучать ему как матиматике не стоит!
И еще, ничего не мешает Вам начать обучение с (интуитивно понятного и легкого в изучении, по мнению Вирта) Паскаля, а потом перейти на си, на начальном этапе прокатит — я сам так перескочил (ну это конечно скорее всего от того, что о си я узнал познее). Главное то, суть познать! Как хотите здесь плюйтесь, но чтобы получить 6 + 7 = 13, нужно

write(6+7);

ну а это НИКАК с матиматикой не согласуется

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Ну почему не изобразить эту операцию через <-, <=, <== или <-- ? Ведь отсюда сразу видно, что это операция, т.е. действие, состоящее в ассоцировании значения справа со значением слева. Что значит ассоциирование легко уже объяснить. Я понимаю, программисты — это не преподаватели, они трудностей обучения языку си++ не знают ибо такого опыта не имеют, но я уверяю, что это первая проблема, с которой встречается неофит на пути изучения языка.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>То есть кто-то пытается продать BlackBox?

Я бы сказал "впарить"! И мы все знаем кто!

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?
Ну вот в Comega продемонстрировали новый (для меня) подход к многозадачности.

1.1.4 stable rev. 510

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

Z>В моем потоке небыло ниодно человека, который не понял операции присваивания в си. Может матиматиков это и сбивает, но обычный человек когда смотрит на = не задумывается о "симметричности"!

Не знаю как там было в потоке, в моем, я имею ввиду. Но вот я имею некоторый опвт преподавания языка си++. Причем не только в учебном учереждении, но и в виде частных уроков. Для тех, у кого это был первый язык программирования, знак = для обозначения операции присваивания вызывал затруднения. Затем, конечно, трудно было понять, что у действия может быть значение, т.е. что операция в языке рассматривается также и как выражение. Но первый барьер — это понимания смысла операции присваивания. И в преодолении этого барьера символ = не помогает. Не понимаю, это ведь очевидно, о чем здесь спорить? Если в китайском, напрмиер, стол будет называться стулом, то это точно не поможет в постижении сужности стола.

Z>В той же матиматике есть вещи которые очень смущают, например квадрат — это четырехугольник, но читырехугольник не есть квадрат... Вот я над чем парился в детстве!

Так это все паряться. Дело в том, что принятая в наших учебниках 70-80 годов классификация четырехугольников весьма отличается от евклидовской и ринципиально не верна. Правильное название для прямоугольника — это разносторонник, так в оригинале было у Евклида. Т.е. правильно классификацию следует вести по сторонам, а не по углам — отсюда и вся путаница.

Хотя любому из Вас это ясно, от того что вы это знаете!!! Я это понял и осознал, как понял и осознал знак = в си и := в паскале.

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

Z>Подобные знаки (=, -->, # и т.п.) используются в разных науках и там не вызывают затруднений, хотя и обозначают отличные от матиматических действия...
Z>Если вы спрашиваете о затруднениях, то это от того что язык начинают изучать с матиматических операций, по этому он с самого начала вызывает такие ассоциации...
Z>Например я не понимал как заставить бейсик вывести ответ и считал что если написать
Z>

Z>6 + 7 =
Z>

Z>то он мне его посчитает... Когда начинаешь понимать программирование, такие проблемы просто отваливаются... Понял как все происходит и стало все равно, что там стоит за присваеванием = или :=

Ну вот тпичная иллюстрация проблемы. Знак = интуитивно понимается как равенство двух выражений, а не как операция присваивания. Отсюда и все эти проблемы с "6+7=".

Z>А Вирт давит на то, что ребенок не пинимает, что (уж простите формула не матиматики, но жизни

)
Z>

Z>Маша + Петя = Любовь
Z>

Z>и
Z>

Z>Любовь =  Маша + Петя
Z>

Z>не одно и тоже, ну так это по моему очевидно...

Здесь ничего не могу сказать, статью Вирта не читал. Я вообще про другое — про трудности изучения.

Z>Короче суть в следующем: почитайте, в топике никто не жаловался на то что он не понял знак присваевания в си, т.е. проблем на этом этапе НЕТ! Проблема в том, что программирование != (или <>) матиматика и обучать ему как матиматике не стоит!

Ну да, еще бы в этом топике учавствовали те, кто не понимает смысл операции = ! Тогда какая же это философия программирования?

Z>И еще, ничего не мешает Вам начать обучение с (интуитивно понятного и легкого в изучении, по мнению Вирта) Паскаля, а потом перейти на си, на начальном этапе прокатит — я сам так перескочил (ну это конечно скорее всего от того, что о си я узнал познее).

Вот-вот, и получается, что для изучения Паскаль гораздо понятнее.

Главное то, суть познать! Как хотите здесь плюйтесь, но чтобы получить 6 + 7 = 13, нужно
Z>

Z>write(6+7);
Z>

Z>ну а это НИКАК с матиматикой не согласуется

Почему не согласуется? Вполне себе нормальная композиция двух функций: write и +.

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

VD>Когда я учился программировать, то первым моим языком был С. И я точно помню, что =/== проблемой не были. Проблема была в общем понимании концепции переменных, но тоже не такая уж страшная. А вот над пониманием того что же такое sizeof() и на фиг он упал, я потратил кучу времени.

Я ведь еще преподавал си++ достаточно долго и то, о чем я здесь написал — это плод практического опыта. Ели бы этого непонимания не было в реальности, то я бы не писал, что это есть. При объяснении семантики операции присваивания я специально использовал кнутовскую нотацию и это помогало. Т.е. то о чем я писал — это реальность, факт можно сказать. С другой стороны, я говорю только о трудностях в обучении, а не о трудностях в программировании, когда смысл знака = уже постигнут. Вот где трудност в программировании, так эхто в использовании = и == там, где они могут взаимозаменяться, что ведет к опечаткам, которые компилятор не отлавливает.

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

E>>Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?
S>Ну вот в Comega продемонстрировали новый (для меня) подход к многозадачности.

Кстати, в Нэмерл, вроде бы, вставили аналог прямо на макросах.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>Но первый барьер — это понимания смысла операции присваивания. И в преодолении этого барьера символ = не помогает

Ну конечно, еслибы был символ <= помогло? О чем Вы? Этоже знак меньше-равно!
А как вам такое i<-10+5 (и меньше минус десять + пять), ну конечно все сразу становиться ясно!
Программирование не матиматика!

M>Не понимаю, это ведь очевидно, о чем здесь спорить? Если в китайском, напрмиер, стол будет называться стулом, то это точно не поможет в постижении сужности стола.

Любой китаец поймет в чем суть! Если Пете сказать, что в китайском языке стол называется стулом, он что этого не поймет? Или ему былобы гораздо проще понять еслибы стол назывался "киямамусака"? Я конечно понимаю, что гораздо лучше для Пети былобы чтобы все Китайцы выучили Русский язык и общались по Русски

M>Так это все паряться. Дело в том, что принятая в наших учебниках 70-80 годов классификация четырехугольников весьма отличается от евклидовской и ринципиально не верна. Правильное название для прямоугольника — это разносторонник, так в оригинале было у Евклида. Т.е. правильно классификацию следует вести по сторонам, а не по углам — отсюда и вся путаница.

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

Ну и сразу все стали жить дружно и счастливо! И все проблемы бы отвалились...

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

Интуитивно сообразующется со смыслом операции присваевания — слово MOV в ассемблере, ну так это очень простой язык для обучения

M>Ну вот тпичная иллюстрация проблемы. Знак = интуитивно понимается как равенство двух выражений, а не как операция присваивания. Отсюда и все эти проблемы с "6+7=".

Да причем тут операция присваевания вообще! Что если в Паскале написать "6+7=" он мне посчитает?

M>Вот-вот, и получается, что для изучения Паскаль гораздо понятнее.

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

M>Главное то, суть познать! Как хотите здесь плюйтесь, но чтобы получить 6 + 7 = 13, нужно
Z>>

Z>>write(6+7);
Z>>

Z>>ну а это НИКАК с матиматикой не согласуется

M>Почему не согласуется? Вполне себе нормальная композиция двух функций: write и +.

Я видать супер стар стал, что уже в школе на матиматике проходят write? О чем мы тогда с Вами спорим?
Программирования не матиматика! Чтобы получить ответ нужно все сделать по шагам. Это же из ряда задач:

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

Ответ:

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

Вот Вам следующая задача:

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>Но первый барьер — это понимания смысла операции присваивания.

Золотые слова!

M>И в преодолении этого барьера символ = не помогает.

Но и не мешает, что самое главное!
Математика:

f(x) = 2x + 1
a = f(2)
b = f(4)

a + b = ?

Во второй и третьей строчке — именно присваивание. И никаких проблем оно не вызывает.

M>Не понимаю, это ведь очевидно, о чем здесь спорить? Если в китайском, напрмиер, стол будет называться стулом, то это точно не поможет в постижении сужности стола.

Именно! И если операция присваивания будет обозначаться знаком =, := или <-, легче от этого никак не станет.

M>Хотя любому из Вас это ясно, от того что вы это знаете!!! Я это понял и осознал, как понял и осознал знак = в си и := в паскале.

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

Какое?

[skip]

M>Главное то, суть познать! Как хотите здесь плюйтесь, но чтобы получить 6 + 7 = 13, нужно
Z>>

Z>>write(6+7);
Z>>

Z>>ну а это НИКАК с матиматикой не согласуется

M>Почему не согласуется? Вполне себе нормальная композиция двух функций: write и +.

Композиция, это которая (g o f)(x) = (g(f(x)))? Ну так в Паскале она даже близко на такую не похожа. Должна быть, как минимум, такая:

write(+(6 7))

Тогда — да, композиция

Тем более, что в Паскале это называли, по-моему, всегда опреаторами. Это в С++, да еще и в универе, да еще и не на самом первом курсе, когда изучается что-то типа Introduction to C++ 102, когда изучается перегрузка функций — тогда только приходит понимание — а! оно ж тоже функция!

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

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

MS>Я не знаю, что такое Оберон, но однозначно могу сказать, что на комплексных числах Фортран кроет С++ по скорости. И иначе быть не может, поскольку комплексные числа — это встроенный тип в Фортране и оптимизатор все про них знает. А в C++ это некий класс, просто класс. Класс как класс и всех делов.

"однозначно могу сказать" == моё большое IMHO

In a comparison of FORTRAN-77 and C++, Kent Budge and his associates programmed a complex number test case in both languages. (complex is a built-in type in FORTRAN; in C++, it is a concrete class with two members, one real and one imaginary. Standard C++ has made the complex class part of the standard library.)
...
Time comparisons against the FORTRAN-77 code showed the FORTRAN code to be nearly twice as fast. Their first assumption was to blame the temporaries. To verify that, they hand-eliminated all temporaries in the intermediate cfront output. As expected, the performance increased two-fold and equaled that of FORTRAN-77.

(C) Inside the C++ Object Model, Stanley B. Lippman

Это было в 94м. А вот ещё: http://www.oonumerics.org/blitz/benchmarks/

Удивлюсь, если FORTRAN где либо сможет перерасти по производительности C++.

Конечно, могут быть и клинические случаи (типа "В результате, программа Ткачёва на Component Pascal оказалась в 8 раз быстрее программы на С++", s/Component\sPascal/FORTRAN/), но мы им верить не будем, так как они не заслуживают никакого доверия.

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

Z>Программирования не матиматика! Чтобы получить ответ нужно все сделать по шагам. Это же из ряда задач:
Z>

Z>Какие дествия нужно сделать, чтобы запихать бегемота в холодильник? 
Z>

Z>Ответ:
Z>

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

Z>Вот Вам следующая задача:
Z>

Z>Какие действия нужно сделать, чтобы запихать жирафа в холодильник?
Z>

Простые

1. Открыть холодильник
2. Вытащить бегемота из холодильника
3. Запихать жирафа в холодильник
4. Закрыть холодильник

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

M>Математика:
M>

f(x) = 2x + 1
a = f(2)
b = f(4)
a + b = ?

M>Во второй и третьей строчке — именно присваивание.

Нет, уравнения.

Это система уравнений:
a = f(2),
b = f(4),
a + b = с,
где f(x) = 2x + 1

Решение: a = 5, b = 9, c = 14.

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

СГ>>Система программирования Mathematica отличилась тем, что неравенство обозначается именно так как в математике:

M>Ндяяя... Вводится или дополнительным кликом по тулбару или комбинацией клавиш, я так понимаю.

Все проще :)
Там за основу принята нотация LaTeX, т.е. формулы пишутсяn не особо медленнее, чем в техе.
И ели тебе нужно ввести нечто нетривиальное, нажимаешь Esc (появляется символ типа двоеточия), потом пишешь, что тебе нужно (!= или там HypergeometricP) и повторным Esc закрываешь все, что написал — оно преобразуется в символ (если нигде не ошибся). Соответственно, в процессе написания можно и подредактировать, если где опечатался. Причем таких красот можешь еще и своих нагенерить, если разрабатываешь нечто новое со своей системой обозначений. Очень удобно.

Ну, конечно же, можно и комбинацию клавиш ввести, но это уже для настоящих маньяков :)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mamut, Вы писали:

M>>Математика:
M>>

СГ>f(x) = 2x + 1
СГ>a = f(2)
СГ>b = f(4)
СГ>a + b = ?

M>>Во второй и третьей строчке — именно присваивание.

СГ>Нет, уравнения.

СГ>Это система уравнений:

Никакая эта не система уравнений

int f(x)
{
    return 2*x + 1;
}

void main()
{
    int a, b;
    a = f(2);
    b = f(4);
    cout << (a + b);
}

Ну и где здесь сложность, вызываемая знаком "="?

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

M>Ну, то есть да, но. a = f(2) — это не равенство, f(2) != a.

Т.е. Вы утверждаете, что запись вида:

2x + 1 = f(x)
f(2) = a
f(4) = b
? = a + b

Не верна?

---
С уважением, Сиваков Константин.

M>>Ну, то есть да, но. a = f(2) — это не равенство, f(2) != a.

G>Т.е. Вы утверждаете, что запись вида:
G>

G>2x + 1 = f(x)
G>f(2) = a
G>f(4) = b
G>? = a + b

G>Не верна?

"Во валит, гад" (с) анекдот

Возможно, с точки зрения математика, она и верна. Но "простому рабочему парню" непонятна — a и b еще ж "не инициализированы"

Ну, для меня лично, как минимум, a = f(2) в математике всегда означало присвоение. Даже еще в те времена, когда я и программировать-то не мог. И в обратном вы меня не переубедите

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

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

F>>>>Остроумна критика операторов ++/-- (Вирт считает, что это уродство).
GZ>>>Я тоже.
CC>>Обоснуй почему это уродство... Только тем, что можно писать x+++y ? Тогда русский язык с его "Казнить нельзя помиловать" тоже есть уродство. Запятая надо что понять смысл? Точно так же простой пробел исправит непонятки: x++ +y или x+ ++y
GZ>Когда быстро читаешь текст, подобные операции малозаметны. И всегда приходится дополнительно задумываться, чтобы это значило. Что сначало приплюсовало, или что-то другое. Поэтому я очень редко их вставляю не на новой строке. И пользуюсь только x++; Выражения типа while(*x++==*y++) для меня слишком сложны. Такой я глупый программист.

Хорошо еще, что нельзя писать x+++++y. Хотя, если пробелы поставить, то работает

(x++ + ++y)

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

M>Никакая эта не система уравнений

Ну, то есть да, но. a = f(2) — это не равенство, f(2) != a. Мы присваеваем символу а значение, вычисляемое функцией f с заданными параметрами. Здесь знак = имеет абсолютно такое же значение, как и в:

Ты путаешь присваивание с декларацией, и вообще воспринимаешь математику как императивный ЯП. Это принципиальная разница:

M>a = f(2) — это не равенство

это равенстно, _по определению_

Такова математическая запись равенства (... = ...)

M>f(2) != a

Ошибаешься. Они равны. f(2) = a, это тоже равенстно. По определению, "a = b" и "b = a" всегда одновременно либо выполняются, либо не выполнятся, для любых a и b.

M>Мы присваеваем символу а значение, вычисляемое функцией f с заданными параметрами

Это вообще чудовищно

В математике, запись "a = f(2)" вообще никакого вычисления значения не производит! Ни сразу, ни потом, никогда. В записи "a = f(2)" не кроется понятия "вычисление значения и передача его куда-то". Тут просто написано, что "а" и "f(2)" — одно и то же.

Вот это:
f(x) = 2x + 1
a = f(2)
b = f(4)

Описание некого виртуального мира. Просто описание. В отличие от ЯП, никаких вычислений этим описанием не производится.

Это описание является достаточным, чтобы a + b было определено в этом же мире, и имело одно конкретное значение. Если тебе хочется, ты можешь вычислить "a + b" любым способом. Например, сначала подсчитать f(2), затем f(4), затем сумму. Или, преобразовать "a + b" -> "f(2) + f(4)" -> "2*2 + 1 + 2*4 + 1" -> "4 + 1 + 8 + 1" -> "14". Это разные подходы. Описание не навязывает никакого подхода вообще.

Попробуй покурить вот это:
a = b + 1
b = a + 1

Тебе не удастся думать об этом, как о "присвоении `а` значения, которое вычисляется прибавлением к значению `b` единицы", т.к. b определяется через значение a, которое ещё не вычислено. А вот в математике это просто напросто подразумевает, что a = b = 0, не более того. Если ты подумаешь об этом как о "присвоениях вычисленного значения", ты никогда не получишь значений 0 одновременно в a и b.

M>Но и не мешает, что самое главное!
M>Математика:
M>f(x) = 2x + 1
M>a = f(2)
M>b = f(4)
M>
M>a + b = ?
M>
M>Во второй и третьей строчке — именно присваивание. И никаких проблем оно не вызывает.

Проблем с записями вида "a = b" нет ни в математике, ни в ЯП. Но означают они обычно кардинально разные вещи

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Попробуй покурить вот это:
Кё>a = b + 1
Кё>b = a + 1

Извините, я фигню написал. Хотел что-то вроде этого:

a = 1 — b
b = 1 + a

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

Вот вот! теоретики всегда забывают что ПИСАТЬ И ЧИТАТЬ "}" легче чем "end" и "=" легче чем ":=" , особенно забывая , что это одни из самых используемых операций

Кодёнок,

Кё>>Попробуй покурить вот это:
Кё>>a = b + 1
Кё>>b = a + 1

Кё>Извините, я фигню написал.

Да нет, нормально: если мы будем рассматривать решения в циклической группой порядка 2, то смысл очень даже появляется. Если даже будем рассматривать решения в поле вещественных чисел R, то смысл опять же есть:

Значок = — это отношение. Отношение R(x,y) — это подмножество декартового произведения X x Y.
Значок + — это отображение. Отображение f: X -> Y — это... гхм.. отображение (неопределяемое понятие)

Последовательность символов

a = b + 1

есть отношение R(a, f(b)), где R — отношение равенства, f(b) — отображение прибавляющее единицу
Аналогично, последовательность символов

b = a + 1

есть отношение R(f(a), b).

Наконец,

a = b + 1
b = a + 1

есть пересечение множеств R(a, f(b)) и R(f(a), b).

То есть этими двумя равенствами ты описал подмножество декартового произведения A x B (a \in A, b \in B), а не фигню.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Хотя, если пробелы поставить, то работает

(x++ + ++y)

Так у Вирта в статье как раз такая галиматья и критикуется:

Уродство конструкции обычно проявляется в комбинации с другими средствами языка. На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора. Равняется ли значение этого "выражения" значению ++x+++y+1? Верны ли следующие соотношения?

x+++++y+1==++x+++y
x+++y++==x+++++y+1

Так можно было бы постулировать новую алгебру. Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра. В 1962 г. установившиеся традиции аналогичным образом подорвало постулирование правой ассоциативности операций в языке APL. Тогда x+y+z неожиданно стало обозначать x+(y+z), а x-y-z — x-y+z.

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

К>В языке Васик для микроэвм Ириша

вместо $ использовалась черепашка ¤ — по той же причине.

Я думаю это было из-за того, что СССР не воспринимал буржуазные символы. На Искрах и на УКНЦ-ВМ та же самая черепашка была.
Тырили у загнивающего капитализма и добавляли капельку патриотичности (i8080 -> КР580ВМ80А, PDP-11 -> БК0010(К1801ВМ1), и т.д.)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

J>И ели тебе нужно ввести нечто нетривиальное

Пишешь:

\[Alpha]

\[CapitalGamma]

сразу после написания этот текст автоматически схлопывается в греческий символ. Теперь это просто буква — 1 символ.

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

Кё>>Извините, я фигню написал.

LCR>То есть этими двумя равенствами ты описал подмножество декартового произведения A x B (a \in A, b \in B), а не фигню.

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

Кодёнок,

Кё>Я на самом деле хотел показать простой пример с конкретными вещественными значениями, так чтобы их вычисление не сводилось к выполнению равенств как присваиваний.

Ага, понятно.

WH>Про жабу ничего не знаю но есть слухи что C# делают 4 человека.

Anders Hejlsberg: The original C# design team was Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, and myself. The C# 2.0 design team is Peter Hallam, Shon Katzenberger, Todd Proebsting, and myself. Most of the credit for generics goes to Don Syme and Andrew Kennedy from Microsoft Research.

http://www.artima.com/intv/csdes.html

Но это design team, а код пишут большее число человек скорее всего.

В общем, посыпаю голову пеплом.

Все так, все так.

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

Z>В моем потоке небыло ниодно человека, который не понял операции присваивания в си. Может матиматиков это и сбивает, но обычный человек когда смотрит на = не задумывается о "симметричности"!

Я тоже понимаю, что = в C++ обозначает присваивание. И при чтении исходника это не вызывает проблем. Но я не программирую только на C, есть еще другие языки, SQL и т. д. И когда часто переключаешься между двумя языками, возникают опечатки (руки сами пишут). Так вот, одним из достоинств паскалевского синтаксиса является то обстоятельство, что односимвольная опечатка в большинстве случаем (только если это не имя идентификатора) приводит к ошибке компиляции. Хоть С я изучил раньше паскаля, но все равно мне часто приходилось натыкаться свои же опечатки, которые приводили к синтаксически, но не семантически корректной программе.

Q>Ну-ну. Только лучший язык со встроенным параллелизмом в данное время функциональный Erlang, а объектно-ориентированных языков что-то не видно.

А кто сказал, что он не объектно-ориентирован ?
Просто ООП привычно считается только процедурное ООП как в С++.
А не message-based как в Obj.C

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

MS>

MS>Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.

MS>Я не понял выделенного, что значит вековая традиция в его понимании? Сколько лет coputer science (

а сколько лет математике/физике ?

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

MS>>>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда

VD>>Оно не более логично, и не менее логично. Это просто соглашение языка. С++ != математике! Вот и все!

M>Согласен, но тем не менее изучение языка это легче не делает. Ведь человек интуитивно воспринимает семантику символа = так, как его учили с детства. А учили его математике, а не программирвоания. А там вообще при записи подразумевается именно равенство. Поэтому изучающему трудно перестроится. Тем самым создаются дополнительные барьеры на пути неофита. Что по мне, так мне и := не нравится тоже. Логично было бы использовать кнтовскую нотацию <-. Вот здесь как раз все кажется понятно.

Мне нравится запись <=, но она задействована под .LE.

А принципе, есть свободная комбинация: =>, т.е. вполне можно было бы писать так:

x+y => z; // результат операции (x+y) помещаем в z;

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

Хотя, в случае длинных выражений, не факт что это будет читабельно:

GetValueVeryLongAccessorIdentifier(somelongIdentifier1, somelongIdentifier1) => x;

Потому как в первую очередь желательно акцентировать внимание на x и имени ф-ии, но как раз x — теряется из поля зрения...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так у Вирта в статье как раз такая галиматья и критикуется:

Ну извините, фигню можно на чём угодно написать

Можно подумать, если Вирт встретит вот такой код на Обероне, он запрыгает от восхищения?

if 0+x+1+1+x+1+1+x+x # 1+1+1+1+x+1+x+1+1+1 then
  Die
end;

СГ>На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора. Равняется ли значение этого "выражения" значению ++x+++y+1?

Нет загадки, правила лексического анализа однозначны. x+++++y это x ++ ++ + y, а второе выражение равно ++ x ++ + y + 1

Кё>Нет загадки, правила лексического анализа однозначны. x+++++y это x ++ ++ + y,

Да все проще! Если бы не было ++ — не было бы и C++, и в этом главный недостаток этого оператора! :-D

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так у Вирта в статье как раз такая галиматья и критикуется:
Так мы ее собственно и обсуждаем

СГ>

Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра.

Интересно, а Вирта не смущает то, что в английском языке можно точно такие же невнятные конструкции строить?
А невозмутимость оттого, что нормальный человек на такие мелочи внимания не обращает. Не мешает — и фиг тогда с ней. Все остальное устраивает — ну и отлично. К чему все эти сотрясания воздуха!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так можно было бы постулировать новую алгебру. Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра. В 1962 г. установившиеся традиции аналогичным образом подорвало постулирование правой ассоциативности операций в языке APL. Тогда x+y+z неожиданно стало обозначать x+(y+z), а x-y-z — x-y+z.

Ну и что? Особенности АПЛовской грамматики. Причём вполне объяснимые.
1) В языке большое количество 1- и 2-арных операторов, и расставлять между ними приоритеты — это только забивать голову и программисту, и парсеру. Поэтому волюнтаристски принято, что у всех операторов одинаковый приоритет.
2) Оператор присваивания правоассоциативный, поэтому для унификации принято, что все операторы правоассоциативные. Иначе присваивание пришлось бы переписывать в форме x*y*z -> dst

Да, это непривычно по сравнению с калькулятором, где все операторы также имеют равный приоритет, но левоассоциативны. И там действительно присваивание происходит в конце: x*y*z M+

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

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

К>2) Оператор присваивания правоассоциативный, поэтому для унификации принято, что все операторы правоассоциативные. Иначе присваивание пришлось бы переписывать в форме x*y*z -> dst

...что, кстати, было бы не такой уж и плохой идеей.

Кодт,

СГ>>Так можно было бы постулировать новую алгебру. Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра. В 1962 г. установившиеся традиции аналогичным образом подорвало постулирование правой ассоциативности операций в языке APL. Тогда x+y+z неожиданно стало обозначать x+(y+z), а x-y-z — x-y+z.

К>Ну и что? Особенности АПЛовской грамматики. Причём вполне объяснимые.

Мои 5 копеек вдобавок к твоим.

3. Кроме монад и диад там есть причастия, конъюнкции (можно сказать функции высшего порядка) и цепочки (verb trains). Появление хотя бы одного такого конструкта существенно влияет на порядок разбора выражения. Введение приоритетов обычных глаголов сделало бы этот порядок вообще непостижимым.

4. В математике исторически композиция (f#g#h)(x), (что равносильно f g h x в АПЛ), это как раз f(g(h(x))), то есть ассоциативность правая. Распространение этого правила на остальные функции позволяет достичь единообразия.

К>Да, это непривычно по сравнению с калькулятором, где все операторы также имеют равный приоритет, но левоассоциативны. И там действительно присваивание происходит в конце: x*y*z M+

В обычном калькуляторе (не МК51) "(a+b)/(c+d)" невозможно вычислить без применения дополнительной памяти. Убогость!

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

Согласен. Не нужно недооценивать адаптивные возможности человека!

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

D>Здравствуйте, Кодт, Вы писали:

К>>2) Оператор присваивания правоассоциативный, поэтому для унификации принято, что все операторы правоассоциативные. Иначе присваивание пришлось бы переписывать в форме x*y*z -> dst

D>...что, кстати, было бы не такой уж и плохой идеей.

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

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

V>А принципе, есть свободная комбинация: =>, т.е. вполне можно было бы писать так:

V>x+y => z; // результат операции (x+y) помещаем в z;

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

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

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

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

D>>Здравствуйте, Кодт, Вы писали:

К>>>2) Оператор присваивания правоассоциативный, поэтому для унификации принято, что все операторы правоассоциативные. Иначе присваивание пришлось бы переписывать в форме x*y*z -> dst

D>>...что, кстати, было бы не такой уж и плохой идеей.

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

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

Сергей Губанов wrote:
> x+++++y+1==++x+++y
> x+++y++==x+++++y+1
Реально такое почти нигде не используется, так что проблем не
доставляет. А вот шорткаты в виде a++ и ++a — очень удобны.

Posted via RSDN NNTP Server 2.0

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

LCR>4. В математике исторически композиция (f#g#h)(x), (что равносильно f g h x в АПЛ), это как раз f(g(h(x))), то есть ассоциативность правая. Распространение этого правила на остальные функции позволяет достичь единообразия.

Когда это в математике инфиксные операторы с равным приоритетом (вроде тех же сложения и вычитания) были правоассоциативными?

И какую оценку поставил бы учитель арифметики школьнику, получившему в результате вычисления выражения 2 — 1 — 1 двойку?
А правоассоциативность f#g#h(x) и так соблюдается "автоматически": f(g(h(x))).

AVC,

LCR>>4. В математике исторически композиция (f#g#h)(x), (что равносильно f g h x в АПЛ), это как раз f(g(h(x))), то есть ассоциативность правая. Распространение этого правила на остальные функции позволяет достичь единообразия.

AVC>Когда это в математике инфиксные операторы с равным приоритетом (вроде тех же сложения и вычитания) были правоассоциативными?

Операция возведения в степень, операция извлечения корня. А также специальные операторы, например "плюс с крышечкой", смысл которого может меняться от статьи к статье в широких пределах.

AVC>И какую оценку поставил бы учитель арифметики школьнику, получившему в результате вычисления выражения 2 — 1 — 1 двойку?

Плохую, плохую. Исторически сложилось, что минус левоассоциативен.

AVC>А правоассоциативность f#g#h(x) и так соблюдается "автоматически": f(g(h(x))).

Совершенно верно. Взгляните на этот зоопарк:

Есть бинарные инфиксные левоассоциативные операторы с различными приоритетами.
Есть бинарные инфиксные правоассоциативные операторы с различными приоритетами.
Есть унарные операторы — правоассоциативны.
Есть функции — тоже правоассоциативны.

Но во-первых, операторы — это тоже функции. Во-вторых, добавление сюда функторов со своими приоритетами сделает нотацию неподъёмной — я об этом уже писал.

Зададимся целью упростить вещи. Поскольку все операторы — это функции, то пусть операторы будут так же ассоциативны справа и все будут одинакового приоритета. Это простое правило позволяет избавиться от скобок и единообразно рассматривать выражения смешанные из функций, определённых пользователем и функций из системы:

a =: % *: 10 myop 20

Здесь посчитано выражение 1/(myop(10, 20)^2), где myop определён пользователем. Заметим, что соглашения выше позволяют существенно разгрузить выражение от скобок и препинаний.

Можно ввести левую ассоциативность на функциях (опять же без приоритетов). Получится карринг из языков ML и Haskell:

f g h x y z (* вычисляется как (((((f g) h) x) y) z) *)

Опять же такая унификация позволяет существенно уменьшить потребность в скобках и препинаниях.

Наконец, если вы пользовались калькулятором MK51, то наверное отметите тот простой факт, что тот способ вычисления (+ 3 4) требует привыкания, но оказывается очень мощным. На одном дыхании вычислять очень сложные выражения, в то время как пользователи обычных калькуляторов вынуждены использовать бумагу для записи промежуточных результатов.

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

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

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

Да понятно, сам же и написал об этом.
Кстати — это, похоже, одна из причин, почему математики любят короткие нотации. У них зачастую результат приведения/упрощение/преобазования как раз справа находится.

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

D>Это привычка.

Нет, я говорил не о том.

  a := sin(phi);
  b := 3*a + sin(3*phi) + alpha;
  c := a + b;
  if a > arcsin(pi/4) then ; // Что такое a???

В данном случае я должен:
1. Поднять взгляд на строку выше
2. Прочитать c
3. Поднять взгляд на строку выше
4. Прочитать b
5. Поднять взгляд на строку выше
6. Прочитать a
7. Прочитать sin(phi)

А вот если бы это было так:

  sin(phi) -> a
  3*a + sin(3*phi) + alpha -> b
  a + b -> c
  if a > arcsin(pi/4) then ; // Что такое a???

То найти предыдущее присваивание сложнее:
1. Поднять взгляд на строку выше
2. Перевести взгляд в конец строки
3. Прочитать c
4. Поднять взгляд на строку выше
5. Перевести взгляд в конец строки
6. Прочитать b
7. Поднять взгляд на строку выше
8. Перевести взгляд в конец строки
9. Прочитать a
10. Перевести взгляд в начало строки
11. Прочитать sin(phi)

Итого большая нагрузка на глазные яблоки, больше усталось, больше опечаток, ниже качество, ...

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

AVC>>Когда это в математике инфиксные операторы с равным приоритетом (вроде тех же сложения и вычитания) были правоассоциативными?

LCR>Операция возведения в степень, операция извлечения корня. А также специальные операторы, например "плюс с крышечкой", смысл которого может меняться от статьи к статье в широких пределах.

Честно говоря, о возведении в степень я не подумал. Поэтому Ваш аргумент мне понравился.
Из известных мне (в прежние времена

) ЯП, оператор возведения в степень присутствует в Алголе-60 и Фортране.
Правда, вот незадача — в обоих случаях он левоассоциативен.
Это значит, что, например, в Алголе выражение a^b^c вычисляется как (a^b)^c = a^(b*c), а не как a^(b^c).
Вообще, в Алголе, как и в его потомках — Паскале и Обероне — операции с равным приоритетом всегда выполняются слева направо. Поэтому трудностей в понимании выражений нет.
Насчет же оператора "плюс с крышечкой" аргумент, конечно, неотразимый, учитывая, что его смысл "может меняться от статьи к статье в широких пределах". Тут я бессилен.

AVC>>А правоассоциативность f#g#h(x) и так соблюдается "автоматически": f(g(h(x))).

LCR>Совершенно верно. Взгляните на этот зоопарк:

LCR>Есть бинарные инфиксные левоассоциативные операторы с различными приоритетами.
LCR>Есть бинарные инфиксные правоассоциативные операторы с различными приоритетами.
LCR>Есть унарные операторы — правоассоциативны.
LCR>Есть функции — тоже правоассоциативны.

LCR>Но во-первых, операторы — это тоже функции. Во-вторых, добавление сюда функторов со своими приоритетами сделает нотацию неподъёмной — я об этом уже писал.

LCR>Зададимся целью упростить вещи. Поскольку все операторы — это функции, то пусть операторы будут так же ассоциативны справа и все будут одинакового приоритета. Это простое правило позволяет избавиться от скобок и единообразно рассматривать выражения смешанные из функций, определённых пользователем и функций из системы:
LCR>

LCR>a =: % *: 10 myop 20
LCR>

LCR>Здесь посчитано выражение 1/(myop(10, 20)^2), где myop определён пользователем. Заметим, что соглашения выше позволяют существенно разгрузить выражение от скобок и препинаний.

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

Например, "*" могло бы означать возведение в квадрат, а "%" — получение обратной величины.
Но какой знак используется в таком случае для обычного умножения?

LCR>Наконец, если вы пользовались калькулятором MK51, то наверное отметите тот простой факт, что тот способ вычисления (+ 3 4) требует привыкания, но оказывается очень мощным. На одном дыхании вычислять очень сложные выражения, в то время как пользователи обычных калькуляторов вынуждены использовать бумагу для записи промежуточных результатов.

Насколько я понимаю, Вы предлагаете программисту самолично построить и линеаризовать в префиксном порядке синтаксическое дерево.
По видимому, дальше Вы предложите и код сгенерить вручную?

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

Создается впечатление, что простоту каждый понимает по своему.
Что "функциональщику" просто, то "императивщику" — ночной кошмар.

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

LCR>>>4. В математике исторически композиция (f#g#h)(x), (что равносильно f g h x в АПЛ), это как раз f(g(h(x))), то есть ассоциативность правая. Распространение этого правила на остальные функции позволяет достичь единообразия.

AVC>>Когда это в математике инфиксные операторы с равным приоритетом (вроде тех же сложения и вычитания) были правоассоциативными?

Возведение в степень и извлечения корня — не инфиксные операторы. А всякие "плюсы с крышечками" не бывают правоассоциативными.

Трурль,

Т>Возведение в степень и извлечения корня — не инфиксные операторы. А всякие "плюсы с крышечками" не бывают правоассоциативными.

Смотри:

Степень:

2^2^2 = 2^4

Извлечение корня:

В теховской нотации
$\sqrt[2]{\sqrt[3]{\sqrt[4]{x+y}}}$

В инфиксной нотации
2 sqrt 3 sqrt 4 sqrt (x+y)

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

"Плюс с крышечкой" — оператор определяемый человеком, и смысл (и ассоциативность с приоритетом) целиком определяется им.

Lazy Cjow Rhrr,

LCR>Наконец, если вы пользовались калькулятором MK51, то наверное отметите тот простой факт, что тот способ вычисления (+ 3 4) требует привыкания, но оказывается очень мощным.

Я чуть запамятовал

. Способ вычисления там наоборот (3 4 +)

(a+b)/(c+d) вычисляется так:
a ^ b + c ^ d + /

^ — это кнопочка специальная, "в" со стрелкой, означает конец ввода текущего числа и проталкивание его в стек.

AVC,

AVC>Честно говоря, о возведении в степень я не подумал. Поэтому Ваш аргумент мне понравился.

AVC>Из известных мне (в прежние времена

) ЯП, оператор возведения в степень присутствует в Алголе-60 и Фортране.
AVC>Правда, вот незадача — в обоих случаях он левоассоциативен.

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

LCR>>

LCR>>a =: % *: 10 myop 20
LCR>>

AVC>Скажу прямо — упрощенное Вами выражение я разобрать не смог (что, конечно, еще не аргумент).

Ну разумеется, подготовка нужна

. *: (звёздочка и следом двоеточие) — это возведение в квадрат. А просто звёздочка — это умножение.

AVC> "%" — получение обратной величины.
Ваша догадка абсолютно верна. Бинарный % — это деление, а унарный — взятие обратной величины.

AVC>Насколько я понимаю, Вы предлагаете программисту самолично построить и линеаризовать в префиксном порядке синтаксическое дерево.
AVC>По видимому, дальше Вы предложите и код сгенерить вручную?

Оч. смешно

Я немножко ошибся, там порядок постфиксный. Опять же повторюсь, при соответствующем навыке линеаризация делается автоматически. И вложенность скобок не нужно помнить (вы ведь наверняка видели калькулятор со скобками?).

Потом я всё же предпочитаю двигаться в обратном направлении — к абстракциям более высокого уровня. Но понимаете, к этим абстракциям не подобраться, если нижележащие абстракции будут слишком сложны.

AVC>Создается впечатление, что простоту каждый понимает по своему.
AVC>Что "функциональщику" просто, то "императивщику" — ночной кошмар.

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

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

LCR>Степень:
LCR>

LCR>2^2^2 = 2^4
LCR>

LCR>Извлечение корня:
LCR>

LCR>В теховской нотации
LCR>$\sqrt[2]{\sqrt[3]{\sqrt[4]{x+y}}}$

LCR>В инфиксной нотации
LCR>2 sqrt 3 sqrt 4 sqrt (x+y)
LCR>

Вроде речь шла о математике. А математики не пишут "2^2" и тем более "2 sqrt 3".

LCR>"Плюс с крышечкой" — оператор определяемый человеком, и смысл (и ассоциативность с приоритетом) целиком определяется им.
Опять же, в математике не принято определять право(да и лево)ассоциативные операции.

Трурль,

Т>Вроде речь шла о математике. А математики не пишут "2^2" и тем более "2 sqrt 3".

Да, верно. Степень пишут со сдвигом вверх, а корень обозначают причудливым значком. Тем не менее, это по-прежнему инфиксные операторы. Я написал "^" и "sqrt" просто потому, что изобразительные возможности редактора форума малы, а открывать ТеХ и выдирать картинки мне было лень. Тем более, что в свете оригинального спора про операторы в АПЛ-подобных языках это явное излишество.

Т>Опять же, в математике не принято определять право(да и лево)ассоциативные операции.

Тем не менее это делают

Хотя чаще просто определяют отображение F: XxY->Z, здесь ты скорее прав.

Консенсус?

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

Т>Опять же, в математике не принято определять право(да и лево)ассоциативные операции.

Небольшое уточнение: приоритеты и ассоциативность операций вводят не в формальную систему, а только для удобства нотации. Все со времен школы помнят соглашение о приоритете умножения над сложением; для лямбда-термов lambda x y z . expr = lambda x. lambda y. lambda z . expr = lambda x.( lambda y. ( lambda z . expr ) ), т.е. на бумаге правая ассоциативность есть, в лямбда исчислении — нет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Programmierer AG,

Т>>Опять же, в математике не принято определять право(да и лево)ассоциативные операции.

PA>Небольшое уточнение: приоритеты и ассоциативность операций вводят не в формальную систему, а только для удобства нотации. Все со времен школы помнят соглашение о приоритете умножения над сложением...

Ну здесь чуть-чуть уточню. Приоритеты — да, для удобства, а вот ассоциативность — не только. Просто большинство операций, с которыми мы сталкиваемся в жизни являются ассоциативными, например умножение, сложение, композиция.

Если #: X^2 -> X операция, определённая на множестве X, то ассоциативность операции # это просто свойство:

  (a # b) # c = a # (b # c)

Так вот, если операция # не обладает этим свойством, то мы должны определить, как понимать выражение

  a # b # c # d

То есть нам требуется _явно_ указать, как расставляются неявные скобки — справа или слева. Следовательно, указать, левая или правая ассоциативность нужна.

PA>... для лямбда-термов lambda x y z . expr = lambda x. lambda y. lambda z . expr = lambda x.( lambda y. ( lambda z . expr ) ), т.е. на бумаге правая ассоциативность есть, в лямбда исчислении — нет.

Согласен.

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

LCR>Если #: X^2 -> X операция, определённая на множестве X, то ассоциативность операции # это просто свойство:
LCR>

LCR>  (a # b) # c = a # (b # c)
LCR>

Здесь согласен.

LCR>Так вот, если операция # не обладает этим свойством, то мы должны определить, как понимать выражение
LCR>

LCR>  a # b # c # d
LCR>

LCR>То есть нам требуется _явно_ указать, как расставляются неявные скобки — справа или слева. Следовательно, указать, левая или правая ассоциативность нужна.
А вот здесь нет. Неявные скобки не нужны в формальной системе. Правила расстановки неявных скобок — они только для удобства чтения, это синтаксический сахар. Посмотрите на AST выражения в любом языке программирования — по нему невозможно определить, были скобки или нет.
Это же математика, где всегда стараются свести задачу к известным случаям (чтобы наполнить наполовину пустой стакан, надо вылить из него воду, и задача сводится к известной задаче наполнения пустого стакана

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

PA>>... для лямбда-термов lambda x y z . expr = lambda x. lambda y. lambda z . expr = lambda x.( lambda y. ( lambda z . expr ) ), т.е. на бумаге правая ассоциативность есть, в лямбда исчислении — нет.
LCR>Согласен.

Так в случае с бинарной операцией # то же самое. Математически исследуются свойства выражений, в которых все скобки расставлены и неоднозначностей нет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Глеб,

PA>А вот здесь нет. Неявные скобки не нужны в формальной системе. Правила расстановки неявных скобок — они только для удобства чтения, это синтаксический сахар. Посмотрите на AST выражения в любом языке программирования — по нему невозможно определить, были скобки или нет.
Да, невозможно, однако читай дальше... (можно на ты?)

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

PA>...Так в случае с бинарной операцией # то же самое. Математически исследуются свойства выражений, в которых все скобки расставлены и неоднозначностей нет.

Проблема в том, что если # неассоциативна, то выражение a#b#c неоднозначно. Есть 2 пути:
1. Везде требовать правильной расстановки скобок, а выражение a#b#c объявить инвалидным.
2. Объявить, что # является право- или левоассоциативной, тогда a#b#c будет пониматься однозначно.

Я только написал про второй способ работы с бесскобочным a#b#c. Ты говоришь, что можно выбрать первый способ, и он предпочтительнее (как я понял фразу "...если можно построить теорию, в которой разрешены только однозначные выражения").

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

Здравствуй, Lazy Cjow Rhrr, Ты писал:

LCR>(можно на ты?)
Без проблем

.

LCR>Проблема в том, что если # неассоциативна, то выражение a#b#c неоднозначно. Есть 2 пути:
LCR>1. Везде требовать правильной расстановки скобок, а выражение a#b#c объявить инвалидным.
LCR>2. Объявить, что # является право- или левоассоциативной, тогда a#b#c будет пониматься однозначно.
Так всегда и объявляют, вопрос лишь в том, на каком уровне это делается.

LCR>Я только написал про второй способ работы с бесскобочным a#b#c. Ты говоришь, что можно выбрать первый способ, и он предпочтительнее (как я понял фразу "...если можно построить теорию, в которой разрешены только однозначные выражения").
LCR>Да, можно выбрать первый способ.

ИМХО, первый способ не только предпочтительнее и его можно выбрать, его всегда выбирают на практике. Я не знаю языка программирования, в котором приоритеты и ассоциативность операций была частью, так сказать, ядра языка, а не разрешалась на уровне синтаксического анализа. А если мы говорим о математике и формальных системах (http://en.wikipedia.org/wiki/Formal_system):

Mathematical formal systems consist of the following:
1. A finite set of symbols which can be used for constructing formulae.
2. A grammar, i.e. a way of constructing well-formed formulae out of the symbols, such that it is possible to find a decision procedure for deciding whether a formula is a well-formed formula (wff) or not.
3. A set of axioms or axiom schemata: each axiom has to be a wff.
4. A set of inference rules.
5. A set of theorems. This set includes all the axioms, plus all wffs which can be derived from previously-derived theorems by means of rules of inference. Unlike the grammar for wffs, there is no guarantee that there will be a decision procedure for deciding whether a given wff is a theorem or not.

понятно, что чем сложнее грамматика, тем сложнее становится множество правил вывода и сложнее становится теория, поэтому просто нет смысла позволять выражения вида a#b#c: ф.с. на то и формальная, что правила вывода — механистические, им не нужно удобство чтения.

Начинаю повторяться, посему закругляюсь.

Я думаю, мы в основном пришли к консенсусу, только с разных сторон у него стоим

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

От:	fplab	http://fplab.h10.ru http://fplab.blogspot.com/
Дата:	31.01.06 06:05
Оценка:	84 (8)

От:	_Obelisk_	http://www.ibm.com
Дата:	31.01.06 06:36
Оценка:	1 (1) +8 -1

	От:	Дарней
	Дата:	31.01.06 08:29
	Оценка:	+1 -1

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	31.01.06 08:38
Оценка:

	От:	sch
	Дата:	31.01.06 09:08
	Оценка:	10 (3) +7 -3

От:	eao197	http://eao197.blogspot.com
Дата:	31.01.06 16:54
Оценка:	25 (5) +3

От:	VladD2	www.nemerle.org
Дата:	01.02.06 03:45
Оценка:	-2

	От:	Kh_Oleg
	Дата:	01.02.06 07:57
	Оценка:	10 (2) +3 -2

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	01.02.06 10:23
Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	01.02.06 14:33
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	01.02.06 14:35
Оценка:	1 (1) +2

От:	Mystic	http://mystic2000.newmail.ru
Дата:	01.02.06 16:05
Оценка:	+1

От:	Anton Batenev	https://github.com/abbat
Дата:	01.02.06 19:56
Оценка:	1 (1) -1

От:	Andir	http://twitter.com/AndirNotes
Дата:	01.02.06 23:06
Оценка:	+2

	От:	mefrill
	Дата:	02.02.06 06:31
	Оценка:	1 (1) +2

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	02.02.06 08:43
Оценка:	+2

	От:	WolfHound
	Дата:	02.02.06 13:52
	Оценка:	42 (3) +3

	От:	Programmierer AG
	Дата:	02.02.06 15:15
	Оценка:

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	03.02.06 14:04
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	04.02.06 02:59
Оценка:	24 (1)

	От:	Дьяченко Александр
	Дата:	05.02.06 05:43
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	06.02.06 19:43
Оценка:

От:	Сергей Туленцев	http://software.tulentsev.com
Дата:	07.02.06 09:29
Оценка:

	От:	Кодёнок
	Дата:	07.02.06 09:59
	Оценка:	10 (1)

От:	Oyster	https://github.com/devoyster
Дата:	13.02.06 18:11
Оценка: