Re[12]: Технология - Философия программирования

Началом послужило сообщение спорим из-за "="

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

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

Почему же не пожелал? В том выступлении Вирта содержится такая мысль: Современные средства разработки ПО слишком сложны, в то время как на самом деле они могли бы быть простыми. Надо обсуждать вопрос — почему современные системы разработки ПО стали такими сложными и как с этим бороться???

Вирт цитирует Дейкстру:

Вспоминается рассказ Э.Дейкстры о его ночном кошмаре после чтения спецификаций нового языка программирования PL/1 в 1965 г. Ему представилось, что в будущем программирование приравняют к выучиванию PL/1, а информатику — к овладению OS/360 JCL <речь идет о языке программирования и языке управления заданиями для компьютеров фирмы IBM, печально известных своим крайне неудачным дизайном; российские программисты старшего поколения помнят, что это такое, по опыту работ на ЕС ЭВМ — прим. перев.>. Достаточно заменить PL/1 на C++ или Java, а JCL — на Windows или Linux, и вы чудесным образом перенесетесь в настоящее.

Вирт цитирует фрагмент доклада своего коллеги из США:

Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

СГ>Вспоминается рассказ Э.Дейкстры о его ночном кошмаре после чтения спецификаций нового языка программирования PL/1 в 1965 г. Ему представилось, что в будущем программирование приравняют к выучиванию PL/1, а информатику — к овладению OS/360 JCL <речь идет о языке программирования и языке управления заданиями для компьютеров фирмы IBM, печально известных своим крайне неудачным дизайном; российские программисты старшего поколения помнят, что это такое, по опыту работ на ЕС ЭВМ — прим. перев.>. Достаточно заменить PL/1 на C++ или Java, а JCL — на Windows или Linux, и вы чудесным образом перенесетесь в настоящее.

а сложность Современные средства разработки ПО .. . разве с ложности языка?

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

СГ>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?
Пардон, а что считается "сложным"? И с чем его сравнивают? Давай сравним C# 2.0 и Active Oberon. И посмотрим, настолько ли он проще, как обещали, и достаточно ли он выразителен. Для определенности поясню, что выразительностью языка я называю компактность записи программ. Я боюсь, что первый же шаблонный контейнер порвет Active Oberon по выразительности в клочки.

А если ты попробуешь родить на Обероне аналог алгоритма БПФ для вектора произвольной длины (а не степени 2), который на плюсах делается на шаблонах и разворачивается в компайл-тайме, то убедишься, что для децких задач упрощенные языки — самое то. А для настоящих задач надо что-то помощнее. Потому как немощные средства проиграют по скорости разработки и производительности результирующего кода.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

СГ>>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

SK>Java, как язык, осваивается быстро. Долго осваиваются окружающие библиотеки и технологии.

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

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

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

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

СГ>>>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

SK>>Java, как язык, осваивается быстро. Долго осваиваются окружающие библиотеки и технологии.
AV>Ну да, я примерно это и хотел сказать. Сложность освоения средств разработки, совсем не в сложности синтаксиса языка.

Я так понял, что ты предлагаешь использовать вместо всех этих средств, то что уместится на 30 страницах? Выглядит загадочно

Или я тебя не правильно понял?

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

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

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

СГ>>>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

SK>>Java, как язык, осваивается быстро. Долго осваиваются окружающие библиотеки и технологии.

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

А, сорри, пропустил. Я думал, что ты — открыватель топика. Мое предыдущее сообщение — забудь

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

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

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

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

СГ>>>>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

SK>>>Java, как язык, осваивается быстро. Долго осваиваются окружающие библиотеки и технологии.
AV>>Ну да, я примерно это и хотел сказать. Сложность освоения средств разработки, совсем не в сложности синтаксиса языка.

SK>Я так понял, что ты предлагаешь использовать вместо всех этих средств, то что уместится на 30 страницах? Выглядит загадочно

Или я тебя не правильно понял?

Конечно не правильно понял.

Описание синатксиса оберона может и уместиться на 30 листах, да, наверное, можно любой язык так описать используя грамматику. Но а толку ни будет никакого, то есть не получится написать даже "Привет, моя маленький крокодильчик", а все потому, что где описания библиотеки ввода/вывода? Не выводить же эту фразу приветствия крокодильчика в консоль. )

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

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

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

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

СГ>>>>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны. Они очень простые — исчерпывающее описание оберонов спокойно убираются примерно на 30 страницах (последняя книга Вирта Programming in Oberon (от 1 октября 2004 года) содержит всего полсотни страниц). Каждый из них можно освоить, как раз, за ту самю неделю. Зачем пользоваться сложным если с тем же успехом можно пользоваться простым?

SK>>>Java, как язык, осваивается быстро. Долго осваиваются окружающие библиотеки и технологии.

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

SK>А, сорри, пропустил. Я думал, что ты — открыватель топика. Мое предыдущее сообщение — забудь

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

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

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

Нет не синтаксиса, а всего языка, описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице. Не любой язык можно так описать. Вот, например, описание синтаксиса С++ в EBNF в третьем издании книги Страуструпа занимает примерно 20 страниц (приведено в конце книги) его конечно можно сделать покомпактнее, чем это сделал Страуструп, но на ОДНОЙ странице синтаксис С++ в EBNF явно не уместиться.

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

S> Пардон, а что считается "сложным"?

Сложность в смысле сколько труда и времени надо затратить на освоение.

Если можно освоить за неделю — простое, если надо упражняться пару лет — это уже сложное.

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

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

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

СГ>Нет не синтаксиса, а всего языка, описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице. Не любой язык можно так описать. Вот, например, описание синтаксиса С++ в EBNF в третьем издании книги Страуструпа занимает примерно 20 страниц (приведено в конце книги) его конечно можно сделать покомпактнее, чем это сделал Страуструп, но на ОДНОЙ странице синтаксис С++ в EBNF явно не уместиться.

Наверное, я не очень понимаю, какую цель вы преследуете, рекламируя Оберон?

И на vb.net, и на c# я стал писать сразу, без предварительно чтения спец. литературы, только время от времени обращался к документации по классам .NET Framework.
Н уда, пусть будет примерно неделя, что мне пришлось потратить на то, что бы, писать на этих языках (особенно на c#) более менее легко и уверенно. Да, к документации по классам .NET Frameworк обращаюсь и сейчас.

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

СГ>Началом послужило сообщение спорим из-за "="

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

СГ>Вирт цитирует фрагмент доклада своего коллеги из США:
СГ>

СГ>Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

Наверное, дело все-таки в учебниках, которыми пользовался Вирт?

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

СГ>Вот, например, описание синтаксиса С++ в EBNF в третьем издании книги Страуструпа занимает примерно 20 страниц (приведено в конце книги) его конечно можно сделать покомпактнее, чем это сделал Страуструп, но на ОДНОЙ странице синтаксис С++ в EBNF явно не уместиться.
Нет, если набрать мелким шрифтом, то одной страницы должно хватить

... << RSDN@Home 1.1.4 beta 3 rev. 0>>

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Если можно освоить за неделю — простое, если надо упражняться пару лет — это уже сложное.
Конкретнее, конкретнее! С кем воюем-то? Что, кто-то настаивает на том, что без пары лет упражнений программировать грех?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

СГ>Нет не синтаксиса, а всего языка, описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице. Не любой язык можно так описать. Вот, например, описание синтаксиса С++ в EBNF в третьем издании книги Страуструпа занимает примерно 20 страниц (приведено в конце книги) его конечно можно сделать покомпактнее, чем это сделал Страуструп, но на ОДНОЙ странице синтаксис С++ в EBNF явно не уместиться.

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

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

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

СГ>>Вирт цитирует фрагмент доклада своего коллеги из США:
СГ>>

СГ>>Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

AV>Наверное, дело все-таки в учебниках, которыми пользовался Вирт?

Тогда уж не Вирт, а его коллега из США.

СГ>>Вирт цитирует фрагмент доклада своего коллеги из США:

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

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

СГ>>>Вирт цитирует фрагмент доклада своего коллеги из США:
СГ>>>

СГ>>>Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

AV>>Наверное, дело все-таки в учебниках, которыми пользовался Вирт?

СГ>Тогда уж не Вирт, а его коллега из США.
СГ>

СГ>>>Вирт цитирует фрагмент доклада своего коллеги из США:

Точно, извините, не Вирт, а его коллега, а Вирт, не проверив эти данные, и поверив своему коллеги, решил написать короткую книгу (из 30 листов) и под этот ограниченный объем создал язык??

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

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

СГ>>Вот, например, описание синтаксиса С++ в EBNF в третьем издании книги Страуструпа занимает примерно 20 страниц (приведено в конце книги) его конечно можно сделать покомпактнее, чем это сделал Страуструп, но на ОДНОЙ странице синтаксис С++ в EBNF явно не уместиться.
AK>Нет, если набрать мелким шрифтом, то одной страницы должно хватить

Ага и лист ещё А0 взять

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

СГ>Сложность в смысле сколько труда и времени надо затратить на освоение.

СГ>Если можно освоить за неделю — простое, если надо упражняться пару лет — это уже сложное.

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

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

Что толку в простоте среды, если, выучив инструкции языка Паскаль (к примеру), я обнаруживаю, что у него нет ни раздельной компиляции, ни средств работы с внешними библиотеками. (Я не о Borland Pascal, а о том, описание которого занимает десяток страниц. Кстати, а сколько занимает описание среды разработки Borland Pascal?). Увидев, что я не могу использовать написанное мною ранее на (к примеру) Фортране, я, разумеется, возвращаюсь к старому доброму Фортрану. Он не отвечает, может быть, каким-то новым веяниям, зато разработка в этой среде займет меньше времени и сил, с учетом использования возможностей его среды (раздельная компиляция, подключение библиотек).

Так что в данном случае простота эта — та самая, которая хуже воровства...

А проект может продолжаться и больше, чем два года...

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

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

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

СГ>>>>Вирт цитирует фрагмент доклада своего коллеги из США:
СГ>>>>

СГ>>>>Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

AV>>>Наверное, дело все-таки в учебниках, которыми пользовался Вирт?

СГ>>Тогда уж не Вирт, а его коллега из США.
СГ>>

СГ>>>>Вирт цитирует фрагмент доклада своего коллеги из США:

AV>Точно, извините, не Вирт, а его коллега, а Вирт, не проверив эти данные, и поверив своему коллеги, решил написать короткую книгу (из 30 листов) и под этот ограниченный объем создал язык??

Канэшна, ведь этож коллека из США! Из самой правильной страны, им можно на слово верить, самим-то нахрен читать учебники по каким-то мегасложным C++?

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

СГ>Почему же не пожелал? В том выступлении Вирта содержится такая мысль: Современные средства разработки ПО слишком сложны, в то время как на самом деле они могли бы быть простыми. Надо обсуждать вопрос — почему современные системы разработки ПО стали такими сложными и как с этим бороться???

С мыслью, высказанной Виртом, я совершенно согласен.
Но (как мне кажется) слишком много внимания уделяется синтаксической "компактности" Оберона и слишком мало его действительному содержанию: Оберон — это скорее не язык, а именно технология, в некоторых случаях способная полностью заменить все альтернативные средства вместе взятые.
Как мне кажется, нет большого смысла рассматривать язык Оберон в отрыве от Оберон-систем.
Оберон является прежде всего промышленным языком, а то, что он пригоден и для целей обучения студентов, является дополнительным "бонусом", следствием качественной разработки языка.

СГ>Вирт цитирует фрагмент доклада своего коллеги из США:
СГ>

СГ>Мне еще ни разу не попадался учебник по UNIX/C++/Java, который я мог бы освоить за неделю. Их учебники невозможно читать, они предполагают, что читатель принадлежит какой-то секте, чьи заклинания должны оставаться тайной для публики, и читателю не следует ожидать многого в плане надежности, связности или общей элегантности

В отношении UNIX я не согласен.
Например, книжка Кернигана и Пайка "UNIX programming enviroment" достаточно проста и вполне доступна начинающему.

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

S>Пардон, а что считается "сложным"? И с чем его сравнивают? Давай сравним C# 2.0 и Active Oberon. И посмотрим, настолько ли он проще, как обещали, и достаточно ли он выразителен. Для определенности поясню, что выразительностью языка я называю компактность записи программ. Я боюсь, что первый же шаблонный контейнер порвет Active Oberon по выразительности в клочки.
Злой ты какой то. Вся идеология Вирта прежде всего направлена и обучение с меньшими затратами и максимумом понимания. Еще раз в который раз повторюсь когда после фортрана и Васика для ДВК был выбор между С и Паскаль я выбрал второе о чем ни капли не жалею. Прекрасный трамплин.
Честно говоря не видел Oberon но дисскусия продвигается в сравнении несравнимого.
Или ты считаешь, что обучение должно идти с фреймворк 2.0 на любом из нетовских языков (уточню непонимаю почему обязательно C# их (языков) там и без него как грибов)

... << RSDN@Home 1.1.3 stable >>

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

AVC>Но (как мне кажется) слишком много внимания уделяется синтаксической "компактности" Оберона и слишком мало его действительному содержанию: Оберон — это скорее не язык, а именно технология, в некоторых случаях способная полностью заменить все альтернативные средства вместе взятые.

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

Опять "серебряная пуля"?

Вы сами-то, надеюсь, видите ограничения этой технологии?

Сергей Губанов wrote:

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

Posted via RSDN NNTP Server 1.9 gamma

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

Я — за плюрализм!

Да и кроме того, положа руку на сердце, не дотягивает Оберон до такого mind-crashing уровня.

... << RSDN@Home 1.1.3 stable >>

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

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

AVC>>Но (как мне кажется) слишком много внимания уделяется синтаксической "компактности" Оберона и слишком мало его действительному содержанию: Оберон — это скорее не язык, а именно технология, в некоторых случаях способная полностью заменить все альтернативные средства вместе взятые.

СГ>А ведь, действительно, термин "технология" к оберонам очень подходит. Может быть, именно из-за того что оберон системы — это технология, способная заменить все остальные технологии, их во всем мире вообще, и на форуме RSDN в частности, воспринимают в штыки?

Т.е. в том виде, каком Оберон сейчас есть, он позволяет обращаться к БД, делать WEB приложения, поддерживает распределенные транзакции и делает еще кучу подобной лабуды?

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

К>Да, остаётся пожалеть 99% человечества, которое всё ещё использует эти "безумно сложные" C++/Java/C# и пр.
К>Ну тупые видимо, не иначе...

Эти тупые они! Однозначно! Меня надо президентом сделать! Я пока все будут сапоги мыть в индейском океане — из страны конфетку сделаю. Однозначно!

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

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

СГ>А ведь, действительно, термин "технология" к оберонам очень подходит. Может быть, именно из-за того что оберон системы — это технология, способная заменить все остальные технологии, их во всем мире вообще, и на форуме RSDN в частности, воспринимают в штыки?

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

А то, что Оберон критикуют, дак это только во благо ему пойдет,
если у него вообще есть потенциал для развития.

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

AF> Ну фанатам оберона обяснить то, что крупный проект на нём сделать не возможно никак не получается.

Несколько операционных систем написанных на оберонах — это, по Вашему, не несколько крупных проектов? То есть ОСь — это мелкий проект, а вот что-то работающее, например, с СУБД — это уже крупный проект.

Может хватит попусту трепаться?

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

SK> ... делать WEB приложения ...?

http://bluebottle.ethz.ch/

... Of course this page is hosted on server running Bluebottle.

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

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

AF>> Ну фанатам оберона обяснить то, что крупный проект на нём сделать не возможно никак не получается.

СГ>Несколько операционных систем написанных на оберонах — это, по Вашему, не несколько крупных проектов? То есть ОСь — это мелкий проект, а вот что-то работающее, например, с СУБД — это уже крупный проект.

СГ>Может хватит попусту трепаться?

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

Но, мне кажется, что пройдет совсем немного времени, и blackbox (с обероном) станут примерно такими же монстрами, как и те средства разработки, которые вы называете сложными.

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

СГ>Нет не синтаксиса, а всего языка, описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице.

Я хочу на это посмотреть! Итак, одна страница — это примерно 60 строк текста. Если полное описание синтаксиса уместится в этот размер — я, пожалуй познакомлюсь с Обероном поближе.

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

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

СГ>>Нет не синтаксиса, а всего языка, описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице.

W>Я хочу на это посмотреть! Итак, одна страница — это примерно 60 строк текста. Если полное описание синтаксиса уместится в этот размер — я, пожалуй познакомлюсь с Обероном поближе.

Ну, Вас никто за язык не тянул.

34 правила
54 строчки

Приложение B: Синтаксис Компонентного Паскаля

Module = MODULE ident ";" [ImportList] DeclSeq [BEGIN StatementSeq] [CLOSE StatementSeq] END ident ".".
ImportList = IMPORT [ident ":="] ident {"," [ident ":="] ident} ";".
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}} {ProcDecl ";" | ForwardDecl ";"}.
ConstDecl = IdentDef "=" ConstExpr.
TypeDecl = IdentDef "=" Type.
VarDecl = IdentList ":" Type.
ProcDecl = PROCEDURE [Receiver] IdentDef [FormalPars] MethAttributes
[";" DeclSeq [BEGIN StatementSeq] END ident].
MethAttributes = ["," NEW] ["," (ABSTRACT | EMPTY | EXTENSIBLE)].
ForwardDecl = PROCEDURE "^" [Receiver] IdentDef [FormalPars] MethAttributes.
FormalPars = "(" [FPSection {";" FPSection}] ")" [":" Type].
FPSection = [VAR | IN | OUT] ident {"," ident} ":" Type.
Receiver = "(" [VAR | IN] ident ":" ident ")".
Type = Qualident | ARRAY [ConstExpr {"," ConstExpr}] OF Type
| [ABSTRACT | EXTENSIBLE | LIMITED]
RECORD ["("Qualident")"] FieldList {";" FieldList} END
| POINTER TO Type
| PROCEDURE [FormalPars].
FieldList = [IdentList ":" Type].
StatementSeq = Statement {";" Statement}.
Statement = [ Designator ":=" Expr | Designator ["(" [ExprList] ")"]
| IF Expr THEN StatementSeq
{ELSIF Expr THEN StatementSeq}
[ELSE StatementSeq] END
| CASE Expr OF Case {"|" Case}
[ELSE StatementSeq] END
| WHILE Expr DO StatementSeq END
| REPEAT StatementSeq UNTIL Expr
| FOR ident ":=" Expr TO Expr [BY ConstExpr] DO StatementSeq END
| LOOP StatementSeq END
| WITH [ Guard DO StatementSeq ]
{"|" [ Guard DO StatementSeq ] }
[ELSE StatementSeq] END
| EXIT
| RETURN [Expr]
].
Case = [CaseLabels {"," CaseLabels} ":" StatementSeq].
CaseLabels = ConstExpr [".." ConstExpr].
Guard = Qualident ":" Qualident.
ConstExpr = Expr.
Expr = SimpleExpr [Relation SimpleExpr].
SimpleExpr = ["+" | "-"] Term {AddOp Term}.
Term = Factor {MulOp Factor}.
Factor = Designator | number | character | string | NIL | Set | "(" Expr ")" | " ~ " Factor.
Set = "{" [Element {"," Element}] "}".
Element = Expr [".." Expr].
Relation = "=" | "#" | "<" | "<=" | ">" | ">=" | IN | IS.
AddOp = "+" | "-" | OR.
MulOp = " * " | "/" | DIV | MOD | "&".
Designator = Qualident {"." ident | "[" ExprList "]" | " ^ " | "(" Qualident ")" | "(" [ExprList] ")"} [ "$" ].
ExprList = Expr {"," Expr}.
IdentList = IdentDef {"," IdentDef}.
Qualident = [ident "."] ident.
IdentDef = ident [" * " | "-"].

Обещали — исполняйте, вот ссылочка: http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm

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

СГ>Современные средства разработки ПО слишком сложны, в то время как на самом деле они могли бы быть простыми.

Современные средства разработки ПО сложны, потому что с их помощью решают сложные проблемы.
И так будет до тех пор, пока не изобретут компонент TProgrammer

P.S. Лом — тоже вот очень простой инструмент, проще практически некуда. А бульдозер — очень даже сложный, чтобы научиться им пользоваться тоже немало времени надо.
Но значит ли это, что выкопать фундамент под дом будет проще с помощью лома, чем с помощью бульдозера?

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

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

СГ>>Современные средства разработки ПО слишком сложны, в то время как на самом деле они могли бы быть простыми.

Д>Современные средства разработки ПО сложны, потому что с их помощью решают сложные проблемы.
Д>И так будет до тех пор, пока не изобретут компонент TProgrammer

Д>P.S. Лом — тоже вот очень простой инструмент, проще практически некуда. А бульдозер — очень даже сложный, чтобы научиться им пользоваться тоже немало времени надо.
Д>Но значит ли это, что выкопать фундамент под дом будет проще с помощью лома, чем с помощью бульдозера?

Почти то же самое хотел сказать

А еще лом надежен, универсален и никогда не подведет

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

СГ>Ну, Вас никто за язык не тянул.

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

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

Д>P.S. Лом — тоже вот очень простой инструмент, проще практически некуда. А бульдозер — очень даже сложный, чтобы научиться им пользоваться тоже немало времени надо.
Д>Но значит ли это, что выкопать фундамент под дом будет проще с помощью лома, чем с помощью бульдозера?

Проще, но значительно тяжелее.

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

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

СГ>>Ну, Вас никто за язык не тянул.

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

Вопрос был задан именно о размере описания синтаксиса:

>>описание синтаксиса (в EBNF) оберонов умещается на ОДНОЙ странице.

>>Я хочу на это посмотреть!

Кстати, описания синтаксиса C# в EBNF, насколько я понимаю, просто не существует

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

M>Кстати, описания синтаксиса C# в EBNF, насколько я понимаю, просто не существует

очень сильно ошибаешься

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

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

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

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

СГ>Ну, Вас никто за язык не тянул.

СГ>Приложение B: Синтаксис Компонентного Паскаля

Хм... А компонентный паскаль и оберон — суть одно и то же разве?

СГ>Обещали — исполняйте, вот ссылочка: http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm

Легла в букмарки. Как с делами развяжусь — утащу домой, гляну

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

W>Хм... А компонентный паскаль и оберон — суть одно и то же разве?

Всяких оберонов полно. Компонентный Паскаль — усовершенствованная версия языка Оберон-2, разработанная компанией Oberon microsystems.

Про оригинальный 1-вый Оберон там:
http://www.oberon.ethz.ch/compiler/index.html#report

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

M>Кстати, описания синтаксиса C# в EBNF, насколько я понимаю, просто не существует

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

Есть такая 32 битная, многопточная ОС ADRT. Она гораздо удобнее, проще и легче в освоении чем Windows или Linux. Программы, написанные под неё работают с проиводительностью несколько миллиардов операций в секунду. В своей области у неё нет конкурентов. Более того — если считать число копий, то она возможно уже догнала Windows. Так где же она?

Это ОС для DSP Analog Devices — и используется она для упрощения их программирования. И она действительно гораздо проще и Windows и Linux. И DSP на которых она используется при той же тактовой частоте гораздо производительнее Penium IV/Athlon/Duron...

Ну написали на обероне ОС. Да хоть 10. Ну и что. В интституте еждегодно народ по нескольку операционок для проверки полученных знаний и демонтсрации крутизны пишет. И попадаются даже весьма удачные экземпляры.

То же самое и с БД.

Но всё это ничего не значит, пока ОС или БД не стала использоваться так широко как Windows или хотя бы Linux. Потому, как многие проблемы всплывут и будут очевидны именно тогда, а не пока этой ОС или БД восхищённо любуются и ничего особенного — крупного и коммерчески выгодного не делают.

Ах да! 2-3 коммерчески успешных проекта под каждую такую ОС?

Ну так и под DOS можно при желании написать проект гораздо сложнее, чем среднестатистический проект под Windows. Более того их и писали.

Оберон проще и легче изучать? Прекрасно. Но программа то это не только язык. Об этом тут сказали уже кучу раз. Это ещё и библиотеки, средства разработки, инструменты, которые прозволяют её отлаживать.

Вы уверены, что кривой WinAPI станет на обероне вдруг прямым?

Или как обычно — до основанья, а затем?

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

Posted via RSDN NNTP Server 1.9 gamma

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

Да, кстати говоря... кажется, тобой упоминалось о том, что Оберон задумывался как нечто вроде ОО ассемблера.
Есть и другой такой язык — это MSIL

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

Да и просто писать на нем желающих довольно мало.

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

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

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

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

Правильно. Так я ведь и говорил: не упрощения, а облегчения. Процесс разработки ПО вряд ли вообще можно упростить, а вот облегчить — задача каждого разработчка, в первую очередь разработчика систем программирования

Д>Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась.
Д>Чем проще будет язык программирования, тем больше программисту придется эмулировать своими силами

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

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

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

Д>>Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась.
Д>>Чем проще будет язык программирования, тем больше программисту придется эмулировать своими силами

P>Естественно, кто же спорит. Где-то раньше и я говорил о том, что это та самая простота, которая хуже воровства...
P>

Ага, только вот такое ощущение, что до Сергея это как-то ну совсем не доходит

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

Ещё одно доказательство того, что кое-кто выдаёт желаемое за действительное. Такое описание не один нормальный человек не воспримет. А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль. Но это не означает ещё — что тот или иной язык проще освоить или им легко пользоваться.

Лучше сравнить два адекватных по качеству описания обоих языков на естественном языке.

А по той нотации, что здесь дана можно оберон до второго пришествия изучать...

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

СГ>А ведь, действительно, термин "технология" к оберонам очень подходит. Может быть, именно из-за того что оберон системы — это технология, способная заменить все остальные технологии, их во всем мире вообще, и на форуме RSDN в частности, воспринимают в штыки?

Такое предположение можно сделать в отношении крупных компаний, стремящихся устранить конкурентов своим ОС и языкам программирования. Яркий пример — Microsoft. Но они борются отнюдь не только с Обероном, а со всеми: с UNIX, с Linux и т.д.
Что же касается "критики" в адрес Оберона на RSDN, то здесь верно скорее обратное: многие участники форума не представляют, в чем именно заключается альтернативность Оберона. Я делаю такой вывод на основании здешних "постов".
Это говорит о том, что мы "не с той стороны подошли к кобыле".

Наверное, надо начать с того, что такое сложность ПО, и каким образом Оберон пытается решить эту проблему. Показать, что продуманная ОС — не сложнее компилятора, а обратное — предрассудок. Что компонентное программирование есть просто естественное развитие идеи раздельной компиляции. Что именно поэтому в Обероне нет шаблонов. И т.д., и т.п.
Т.е. надо менять собственный подход к обсуждению вопроса.
Конечно, это только моя точка зрения, и ее можно и нужно критиковать.

Вы уж извините, Андрей, но такое письмо онозначно характеризует автора
как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur
Form) — это де-факто стандартный способ описания синтаксиса языка
программирования уже в течение лет 20. Подобные описания используются
для синтаксического анализа в компиляторах (вы с YACC когда-нибудь
работали?). И речь в этом топике именно о формальном описании грамматики
языка и шла.

Вы, видимо, имели в виду описание _семантики_ языка, но это совсем
другая история. Замечу, что и в этом отношении С++ много сложнее Оберона.

AndreyFedotov wrote:

> Здравствуйте, Сергей Губанов, Вы писали:
>
> Ещё одно доказательство того, что кое-кто выдаёт желаемое за
> действительное. Такое описание не один нормальный человек не
> воспримет. А в заковырестой нотации можно умудриться сделать C++
> компактнее чем Паскаль. Но это не означает ещё — что тот или иной
> язык проще освоить или им легко пользоваться.

Лучше сравнить два
> адекватных по качеству описания обоих языков на естественном языке.
>

А по той нотации, что здесь дана можно оберон до второго
> пришествия изучать...

Posted via RSDN NNTP Server 1.9 gamma

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

TB>Вы уж извините, Андрей, но такое письмо онозначно характеризует автора
TB>как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur
TB>Form) — это де-факто стандартный способ описания синтаксиса языка
TB>программирования уже в течение лет 20. Подобные описания используются
TB>для синтаксического анализа в компиляторах (вы с YACC когда-нибудь
TB>работали?). И речь в этом топике именно о формальном описании грамматики
TB>языка и шла.

Если я ничего не путаю, то YACC работает не с EBNF, а с BNF, т.е. с (лево)рекурсивным представлением грамматики без циклов.
Например:
список: элемСписка
| ',' элемСписка
;
А Вирт пользуется именно EBNF, например:
список = элемСписка { ',' ЭлемСписка }

Опечатка, sorry!

AVC>Например:
AVC>список: элемСписка
AVC> | ',' элемСписка
AVC> ;

Конечно, так "правильнее":
список: элемСписка
| список ',' элемСписка
;

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

О том, что такое EBNF я прекрасно знаю. И прекрасно знаю, что не только оберон, но и многие другие языки обладают синтаксисом на страницу или меньше.

Посмотри на исходную посылку. Она была (поправь, если я ошибаюсь), что простота языка означает и большую простоту написания программ. Она сама по себе спорна. Потом была сделано второе предположение. Критерий простоты языка его представление в форме EBNF. Что опять таки крайне спорно. Простой синтаксис и простой язык не одно и то же. Думаю синтаксис ассеблера вообще займёт две-три строчки. Это не означает, что ассемблер проще чем С++ или Оберон и что программировать на нём проще.

И опять таки, несмотря на то, что EBNF очень старая, полезная и признаная форма, вопрос о том, является ли компактность описания языка в этой форме критерием его простоты (не теоретической, а практической) — очень спорен (см. ассеблер).
И вполне допускаю, что возможно придумать такое представление языка, в котором более сложные языки (такие как C++ или Java или C#) будут выглядет проще, чем более простые. Допустим для простоты опысывать каждый язык аналогичным кодом на C++. Естественно в таком представлении C++ окажется самым простым языком.

Но будет ли это правильно? Будет ли такое представление отражать реали программирования?

Совершенно верно. EBNF легко переводится в BNF, AFAIK она (EBNF) была
введена для более компактного описания грамматики в печатных изданиях.

AVC wrote:

>
> Если я ничего не путаю, то YACC работает не с EBNF, а с BNF, т.е. с (лево)рекурсивным представлением грамматики без циклов.

Posted via RSDN NNTP Server 1.9 gamma

Я, пожалуй, поясню подробнее, что именно мне не понравилось:

> Такое описание не один нормальный человек не воспримет.

Как раз EBNF и является наиболее естественным описанием грамматики.
Правда, не для человека, а для программиста

> А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль

Сильно сомневаюсь, интуиция протестует. Поскольку соответствующим мат.
аппаратом не владею, вот ссылка на исследование в этой области:
http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/paper.html
. Вот здесь
(http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/node8.html)
есть некоторые численные результаты.

Posted via RSDN NNTP Server 1.9 gamma

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

TB> есть некоторые численные результаты.

В добавок:
http://www.uni-vologda.ac.ru/cs/syntax/ariphm.htm

Элементы         Мodula2 Оberon Оberon2  Си   Си++  Java  Ада  
Лексемы          887     765    726      917  1662  1771  2206  
Нетерминалы      70      62     43       917  126   174   226  
Терминалы        88      90     91       123  131   121   102  
Служебные слова  39      32     34       27   47    48    63

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

TB>Я, пожалуй, поясню подробнее, что именно мне не понравилось:

>> Такое описание не один нормальный человек не воспримет.

TB>Как раз EBNF и является наиболее естественным описанием грамматики.
TB>Правда, не для человека, а для программиста

Тогда посмотрим на это с другой стороны. Если мы опросим нормальных людей — хотя бы здесь на RSDN — считают ли они нормальным человеком того, кто учит язык по его EBNF нотации вместо обычных книг и документации — интересно — а какой ответ мы получим?

И не в этом ли проблема Вирта с его коллегой?

>> А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль

TB>Сильно сомневаюсь, интуиция протестует. Поскольку соответствующим мат.
TB>аппаратом не владею, вот ссылка на исследование в этой области:
TB>http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/paper.html
TB>. Вот здесь
TB>(http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/node8.html)
TB>есть некоторые численные результаты.
С числами согласен. Они относятся к EBNF и думаю совершенно справделивы

Как сделать нотацию в которой самый компактный C++ (С#, Java или даже Oberon) — я показал.

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

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

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

TB>> есть некоторые численные результаты.

СГ>В добавок:
СГ>http://www.uni-vologda.ac.ru/cs/syntax/ariphm.htm
СГ>

СГ>

СГ>Элементы         Мodula2 Оberon Оberon2  Си   Си++  Java  Ада  
СГ>Лексемы          887     765    726      917  1662  1771  2206  
СГ>Нетерминалы      70      62     43       917  126   174   226  
СГ>Терминалы        88      90     91       123  131   121   102  
СГ>Служебные слова  39      32     34       27   47    48    63  
СГ>

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

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

AndreyFedotov wrote:

> Тогда посмотрим на это с другой стороны. Если мы опросим нормальных
> людей — хотя бы здесь на RSDN — считают ли они нормальным человеком
> того, кто учит язык по его EBNF нотации вместо обычных книг и
> документации — интересно — а какой ответ мы получим?

Откуда, кстати, взялся тезис "учить язык по его EBNF нотации"? К этому
тут никто не призывал. Если говорить об объёме описания языка — сравните
ANSI стандарт C++ (300 стр, если исключить описание библиотеки) и
описание Оберона.

> Как сделать нотацию в которой самый компактный C++ (С#, Java или даже
> Oberon) — я показал.

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

Вы, кстати, не задумывались, почему все пользются именно [E]BNF?
Почитайте про теорию дедуктивных систем (Theory of Deductive Systems).
Это связано с весьма фундаментальными математическими положенями.

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

Почему нельзя сравнивать C++ и ассемблер — и так очевидно, думаю.

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

Posted via RSDN NNTP Server 1.9 gamma

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

TB>Откуда, кстати, взялся тезис "учить язык по его EBNF нотации"? К этому
TB>тут никто не призывал. Если говорить об объёме описания языка — сравните
TB>ANSI стандарт C++ (300 стр, если исключить описание библиотеки) и
TB>описание Оберона.

Утверждалось, что Оберон гораздо проще и учить его легче (с чем я совершенно согласен), но затем в качестве демонстрации сего постулата Остапа понесло и он заявил, что Оберон настолько простой что его описание вообще страницу занимает (в EBNF нотации).

Вот ответ на подобные заявления (в качестве набивания цены оберону).

>> Как сделать нотацию в которой самый компактный C++ (С#, Java или даже
>> Oberon) — я показал.

TB>Я не очень понял, как "опысывать каждый язык аналогичным кодом на C++".
TB>Изложите предлагаемую нотацию в строгом и замкнутом виде

Ну чтож — это просто. Описываешь конструкцию любого другого языка на C++ наиболее простым образом — вот тебе и нотация.

TB>Вы, кстати, не задумывались, почему все пользются именно [E]BNF?
TB>Почитайте про теорию дедуктивных систем (Theory of Deductive Systems).
TB>Это связано с весьма фундаментальными математическими положенями.

Да знаю я это прекрасно.

Дело не в простоте языка по EBNF — она конечно важна, но больше с сугубо теоретической точки зрения.

Ну нет корреляции между сложностью языка и его успешностью. Просто нет. Есть и простые языки и сложные — и те и другие успешны.

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

TB>Почему нельзя сравнивать C++ и ассемблер — и так очевидно, думаю.

Да очевидно. Но вот только не надо от темы в кусты.

Сначала наезжаем по поводу EBNF нотации, а как по делу так ничего сказать не можем?

TB>"Простота" языка не определяет его распространённость, но может быть
TB>полезна в разных случаях (тут много про это писали, не буду
TB>повторяться). В частности, недостатки и достоинства Оберона лежат совсем
TB>в иной плоскости (см. посты AVC).
Именно. Но так зачем ей тогда уделять столько внимания — если она в действительности она не важна?

AVC:

> компонентное программирование есть просто естественное развитие идеи раздельной компиляции. Что именно поэтому в Обероне нет шаблонов.

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

Если второе или что-то иное, то можно здесь чуть подробнее?

Posted via RSDN NNTP Server 1.9 gamma

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

>> компонентное программирование есть просто естественное развитие идеи раздельной компиляции. Что именно поэтому в Обероне нет шаблонов.

ПК>Не очень понял данный фрагмент. Подразумевается, что (1) шаблоны не вписываются в компонентное программирование (aka раздельная компиляция), и поэтому их нет в Обероне, или же подразумевается, что (2) благодаря компонентному программированию как развитию идеи раздельной компиляции Оберону шаблоны не нужны, т.к. он позволяет делать те же вещи, что делаются шаблонами, другими способами?

ПК>Если второе или что-то иное, то можно здесь чуть подробнее?

Я имел в виду, что шаблоны компилируются как часть исходного кода импортирующего их модуля. Здесь нет раздельной компиляции, это соответствует варианту (1) в Вашем вопросе. Т.е. шаблоны (на мой взгляд) не вписываются в компонентное программирование.
Как мне кажется, в других языках дело обстоит также.

Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны? Автоматизировать операцию "copy-and-paste"?
Я сам одно время достаточно активно пользовался STL с целью сэкономить время разработки. Экономия времени — минимальная, код почти нечитаем, его эффективность — гораздо ниже кода, написанного самим. В итоге — скорее минус, чем плюс. То, что внедрение STL было поспешным, подтверждает и факт отсутствия в ней хэш-таблиц. (Конечно, я знаю о "самопальных" вариантах: boost и т.п., но факт показательный.)
А сколько раз ко мне обращались за помощью молодые ребята, недавно начавшие пользоваться STL: помоги найти ошибку. И правда, вместо внятного сообщения об ошибке — какая-то "простыня" на весь экран, приводящая "новичков" (и не только!) просто в отчаяние.
Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.

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

AVC:

> Я имел в виду, что шаблоны компилируются как часть исходного кода импортирующего их модуля. Здесь нет раздельной компиляции, это соответствует варианту (1) в Вашем вопросе. Т.е. шаблоны (на мой взгляд) не вписываются в компонентное программирование. Как мне кажется, в других языках дело обстоит также.

В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования). Уж .Net или Java, как ни крути, от компонентного подхода просто не отделимы.

> Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны? Автоматизировать операцию "copy-and-paste"?

Имхо, кардинальная разница с copy-and-paste в том, что в случае шаблонов мы по-прежнему способны вносить изменения в одном месте, в то время как в случае copy-and-paste изменения локализации если и поддаются, то очень слабо.

> Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.

Благо, мне везет работать с оставшимися 5%

Posted via RSDN NNTP Server 1.9 gamma

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

AVC>Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны? Автоматизировать операцию "copy-and-paste"?

Допустим шкут 60 различных списков — и в исходном врианте (с которого делали CopyPaste) обнаружена ошибка. Разница по времени в часы, если не дни. И без шаблонов — нет гарантий — что ошибка будет подправлена везде.

Добавление новой функциональности — то же самое.

AVC>Я сам одно время достаточно активно пользовался STL с целью сэкономить время разработки. Экономия времени — минимальная, код почти нечитаем, его эффективность — гораздо ниже кода, написанного самим. В итоге — скорее минус, чем плюс. То, что внедрение STL было поспешным, подтверждает и факт отсутствия в ней хэш-таблиц. (Конечно, я знаю о "самопальных" вариантах: boost и т.п., но факт показательный.)
AVC>А сколько раз ко мне обращались за помощью молодые ребята, недавно начавшие пользоваться STL: помоги найти ошибку. И правда, вместо внятного сообщения об ошибке — какая-то "простыня" на весь экран, приводящая "новичков" (и не только!) просто в отчаяние.
AVC>Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.

Думаете это доказывает не эффективность C++ и превосходство оберона?

Это доказывает только то, что оберон никому не нужен.

Как только оказалось, что Java и C# — нужены, в них сразу стали добавлять шаблоны. Это знают здесь почти все. Но помнят ли при этом — что в C++ шаблоны в своё время были добавлены точно так же?

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

Догадайтесь, что случилось бы если бы (чур-чур-чур!

) Оберон стал бы столь же распространён? Через 2-3 года его напичкали бы шаблонами. И опять выстраивались бы очереди из ленивцев, которые не могли бы потратить пару часов своего времени, что бы разобраться как же работает список из OberSTL

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

M>Вопрос был задан именно о размере описания синтаксиса:

EBNF — это такое же описание синтаксиса как карта без обозначения названий населенных пунктов.

M>Кстати, описания синтаксиса C# в EBNF, насколько я понимаю, просто не существует

Полное описание синтаксиса, т.е. BNF + описание на ангийском + список библиотек можно взять здесь:
http://msdn.microsoft.com/vcsharp/team/language/default.aspx

Спецификация второй версии занимает ~500 страниц. Из которых на описание именно языка затрачено где-то 300 страниц. И это учитывая, что язык на порядок более серьезный нежели Оберон.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

TB>Вы уж извините, Андрей, но такое письмо онозначно характеризует автора
TB>как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur
TB>Form) — это де-факто стандартный способ описания синтаксиса языка
TB>программирования уже в течение лет 20. Подобные описания используются
TB>для синтаксического анализа в компиляторах (вы с YACC когда-нибудь
TB>работали?). И речь в этом топике именно о формальном описании грамматики
TB>языка и шла.

Я наверно тоже дилетант, так как тоже считаю описание в BNF/EBNF непригодным для изучения языка. Это формальная граматика которую можно исользовать только для посторения парсеров или для разрешения тонких моментов плохо описанных в человеческом описании.

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

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

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

TB>>Вы уж извините, Андрей, но такое письмо онозначно характеризует автора
TB>>как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur
TB>>Form) — это де-факто стандартный способ описания синтаксиса языка
TB>>программирования уже в течение лет 20. Подобные описания используются
TB>>для синтаксического анализа в компиляторах (вы с YACC когда-нибудь
TB>>работали?). И речь в этом топике именно о формальном описании грамматики
TB>>языка и шла.

AVC>Если я ничего не путаю, то YACC работает не с EBNF, а с BNF, т.е. с (лево)рекурсивным представлением грамматики без циклов.

Правильно понимашь, только с циклами. Вот тольк причем тут это?

AVC>Например:
AVC>список: элемСписка
AVC> | ',' элемСписка
AVC> ;
AVC>А Вирт пользуется именно EBNF, например:
AVC>список = элемСписка { ',' ЭлемСписка }

Правильно он пишит примитивные языки которые намного проще выразить в EBNF. EBNF вообще компактнее. И EBNF хорошо преспособленна для построения LL(1)-пасреров. А все языки Вирта LL(1)-языки.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

AF> Но суть не в конкретной нотации и её обоснованности, а в том, можно ли вообще считать простоту языка в некоторой нотации критерием его большей полезности или эффективности. И привел пример — ассемблер. Вот уж чья нотация проще некуда. Но попробуйте на неё что-нибудь написать!

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

как раз очень хорошо демонстриует, что сегодняшние фовариты угадали с данной характиристикой. Ява, С++ и дельфи по удивительному стечению обстоятельств практически угадили в одну точку. А неудачники оказались выше или ниже этой точки. Ада оказалась слишком сложной, да и появилась тогда когда ее сложность еще не была востребована (а может сложность не компенсировалась выразительносью). Обероны ушли в даун и на них вообще никто не обращает внимание как на языки прикладного программирования.

Очень интересно было бы посмотреть на те же цифры для Питона, Руби и Шарпа.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

AF> Да знаю я это прекрасно.

Дело не в простоте языка по EBNF — она конечно важна, но больше с сугубо теоретической точки зрения.

Ну нет корреляции между сложностью языка и его успешностью. Просто нет. Есть и простые языки и сложные — и те и другие успешны.

Кстати, похоже есть. Языки с примитивным EBNF-описанием ни разу не становились популярными.

Да и кореляция между сложностью и простотой обучения тоже есть. Но синтаксическая сложность и сложность языка это совсем разные вещи. C# значительно сложнее С++ с точки зрения EBNF-представления. Но сам язык значительно преще. От части из-за более простой граматики, а отчасти зи-за большей логичности и удобства.

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

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

СГ>Если можно освоить за неделю — простое, если надо упражняться пару лет — это уже сложное.

Тебе тут уже минимум четверо сказали, что влились в Шарп за неделю. А ты все тоже самое поешь.

Освоить Шарп не сложнее чем Оберон. Хотя синтаксис у него и сложнее.

Освоение языка — это не зазубривание EBNF.

ЗЫ

Значит выразительность сравнивать не хочешь?

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

СГ>Несколько операционных систем написанных на оберонах — это, по Вашему, не несколько крупных проектов? То есть ОСь — это мелкий проект, а вот что-то работающее, например, с СУБД — это уже крупный проект.

В общем, проспали MS с IBM свое счастье. Надо было им Оберон брать и было бы им полнейше и неотвратимое счастье.

СГ>Может хватит попусту трепаться?

+1

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

TB>Вы сами-то, надеюсь, видите ограничения этой технологии?

Смешся что ли?

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

СГ>http://bluebottle.ethz.ch/
СГ>

СГ>... Of course this page is hosted on server running Bluebottle.

Вау! Надо еще на досе срвер сделать и там таким приятным для глаза цветом... ну, таким ярко малиновым по ярко салатовому написать: "Эта стрница хостится на устаревшей, покрытой плесенью ОС MS DOS 3.31. Не верьте оберонщикам!".

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

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

За одно сравнить с тем что есть на рынке и завоевало популярность (C#, Ява) и понять, что у Оберона нет шансов против них.

AVC>Показать, что продуманная ОС — не сложнее компилятора, а обратное — предрассудок.

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

AVC> Что компонентное программирование есть просто естественное развитие идеи раздельной компиляции.

И что упомянутые C#, Ява справляются с ней значительно лучше.

AVC> Что именно поэтому в Обероне нет шаблонов. И т.д., и т.п.

Не. Именно по этому у Оберона нет будущего. А вот его конкуренты C# 2.0, Ява 1.5 как раз таки обзавелись средствами на подобии шаблонов (обощенного программирования) и это при том, что их компонентные возможности на голову выше чем у Оберона.

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

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

AVC>Конечно, это только моя точка зрения, и ее можно и нужно критиковать.

Собственно если окончатся фанатствующие выпады, можно сесть и серьзно сравнить возможности Оберона и тех же C# с Явой. Это будет хотя бы интересно. А вот заявления в стиле Новых Васюков кроме смеха уже ничего не вызвают (даже раздражения).

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

AVC>Как мне кажется, в других языках дело обстоит также.

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

AVC>Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны?

Создавать обобщенный код. Другими словами поднимать уровень абстракции, уменьшать объем кода, создавать безопасный (проверяемый во времы компиляции) полиморфный код.

AVC>Автоматизировать операцию "copy-and-paste"?

А что копи-пэст уже стало очередным достоинством Оберона?

AVC>Я сам одно время достаточно активно пользовался STL с целью сэкономить время разработки.

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

AVC> Экономия времени — минимальная,

Может быть это проблема не в СТЛ?

AVC> код почти нечитаем,

Сам СТЛ почти во всех реализациях не читаем. Но код на нем вроде как довольно понятный. Может дело в руках?

AVC>его эффективность — гораздо ниже кода, написанного самим.

Гы. Щаз тебя порвут.

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

AVC> В итоге — скорее минус, чем плюс.

Так зачем используешь? Столько недостатков, а ты все используешь и испльзуешь?

AVC> То, что внедрение STL было поспешным, подтверждает и факт отсутствия в ней хэш-таблиц.

Это большая недоработка. Но назвать процесс в 10 лет поспешным...

AVC> (Конечно, я знаю о "самопальных" вариантах: boost и т.п., но факт показательный.)

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

AVC>А сколько раз ко мне обращались за помощью молодые ребята, недавно начавшие пользоваться STL: помоги найти ошибку. И правда, вместо внятного сообщения об ошибке — какая-то "простыня" на весь экран, приводящая "новичков" (и не только!) просто в отчаяние.

Вэлкам ту # 2.0! Вилеколпная диагностика ошибок, полная интеграция дженериков (аналогов шаблонов С++) с компонентым подходом, модульность, компактность... далее куча эпититов на две страницы...

AVC>Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.

Видимо я из тех 5%. И все кого я видел тоже.

Хотя СТЛ я тоже недолюбливою, но не за то. А за своеобразный дизайн и странные названия методов.

AVC>Еще раз оговорюсь: все это — мое личное мнение, я просто пытаюсь создать целостную картину, взвесить "за" и "против" Оберона; при этом меня может немного "заносить", так что не стесняйтесь — критикуйте.

Ну, давай сравним Оберн с C# 2.0. Ставлю ящик пива, что кроме меньшего размера грамматики и возможности не использовать классы ты никакого приемущества не обнаружишь.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

ПК>В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования).

Во втором случае (Явы) уже вышел релиз. Вэлкам: http://java.sun.com/j2se/1.5.0/download.jsp.

Вот только там обработка дженериков ведется компилятором, хотя и лучше интегрирована в язык чем в случае С++ (сказывется меньшее количество неоднозначностей при парсинге), в следствии чего с диагностикой ошибок проблем нет. Но вот к сожалению в Яве жденерики не могут быть использованы для управления вэлью-типами и производительность сильно страдает (боксинг/анбоксинг).

ПК> Уж .Net или Java, как ни крути, от компонентного подхода просто не отделимы.

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

ПК>Имхо, кардинальная разница с copy-and-paste в том, что в случае шаблонов мы по-прежнему способны вносить изменения в одном месте, в то время как в случае copy-and-paste изменения локализации если и поддаются, то очень слабо.

Да это как минимум намного больший объем кода. А это и лишняя работа, и лишний объем изучаемого кода.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

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

Ксткти, один в один с ФЯ. Там вместо циклов используется рекурсия.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

Так я об этом и пишу.

Убрать из C++ ключевые слова:

 - template,
 - struct, (достаточно class),
 - for/do, (вполне хватит while)
 - switch/case/default, (достаточно if)
 - break/continue, (по тем же причинам, это же замаскированные goto)
 - static_cast/dynamic_cast/reinterprete_cast, (хаватит обычного приведения типов),
 - RTTI вместе с typeid/typename
 и конечно (под бурные овации) goto

Ну и то, что — язык станет проще — но станет ли проще на нём программировать?

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

ПК>В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования). Уж .Net или Java, как ни крути, от компонентного подхода просто не отделимы.

Это очень интересная информация (о C# 2.0), спасибо!
Надо будет посмотреть, как это там реализовано. (Ведь я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем.)
Но, даже если Вы и правы в отношении C# 2.0, обращаю Ваше внимание, как долго шаблоны и компонентное программирование "шли друг другу навстречу". В лучшем случае они изначально были друг другу "ортогональны".

>> Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны? Автоматизировать операцию "copy-and-paste"?

ПК>Имхо, кардинальная разница с copy-and-paste в том, что в случае шаблонов мы по-прежнему способны вносить изменения в одном месте, в то время как в случае copy-and-paste изменения локализации если и поддаются, то очень слабо.

Здесь я, конечно, согласен.

(Именно такую "инкапсуляцию" я и имел в виду, когда написал, что меня может "заносить". К сожалению, переформулировать "пост" поточнее вчера уже не было времени.)

>> Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.

ПК>Благо, мне везет работать с оставшимися 5%

Я охотно верю, что все участники форумов RSDN входят в число этих 5%.
Но по моим наблюдениям (видно я работаю среди сплошных неумех, которые при этом каким-то образом умудряются делать весьма сложные программные комплексы, не прибегая к C#) 90% программистов, пишущих на Си++, пользуются шаблонами лишь эпизодически или не пользуются вовсе. А про тех, кто пользуется, я уже писал.

Отдельная благодарность за информативность и корректность Вашего поста.

AVC:

> я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем

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

При этом еще интересно, что в C# (а точнее, в .Net), собственно, и не совсем шаблоны. Даже совсем не шаблоны

И имя у них другое — generics.

В этом отношении согласен: если говорить буквально о шаблонах, в том виде, как они приняты в C++, то можно вполне уверенно утверждать, что практическая вероятность пересечения ими границы модуля во время исполнения, фактически, равна нулю. Если, конечно, не добавлять к программе полный компилятор C++, что вряд ли кому-нибудь реально нужно. Особенно учитывая, что область применения компонентного подхода вполне покрывается платформой .Net, которая уже обеспечивает "докомпиляцию" во время исполнения. На эту "докомпиляцию", собственно, и полагаются generics.

В общем, поэтому в C++/CLI (*) шаблоны и generics существуют параллельно — или, в зависимости от взгляда на вещи, ортогонально

(*) C++/CLI — модификация C++ для более тесной интеграции с .Net. CLI — название .Net в терминологии организации ECMA, занимающейся стандартизацией этой платформы.

Posted via RSDN NNTP Server 1.9 gamma

VladD2:

> ПК> В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования).

> Во втором случае (Явы) уже вышел релиз. Вэлкам: http://java.sun.com/j2se/1.5.0/download.jsp.

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

Posted via RSDN NNTP Server 1.9 gamma

P.S. Оставил цитату, и не заметил, что ответ не дописал.

> AVC:

>> я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем

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

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

Posted via RSDN NNTP Server 1.9 gamma

VladD2,

> дженериков (аналогов шаблонов С++)

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

Posted via RSDN NNTP Server 1.9 gamma

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны.
Ну и что. Оберон — реинкарнация Паскаля. Сделав то же предложение, Вирт получит тот же результат.
И действительно, язык не есть средство разработки (http://www.rsdn.ru/Forum/Message.aspx?mid=883537&only=1). Если вы согласны, следует сдвинуть фокус внимания именно в сторону системы разработки. Она как, встроена в ОС? Можно там набрать выражение языка и в соседнем окошке получить результат? Компиляция там явно вызывается или этот процесс, как и промежуточные файлы, спрятан?
Я думаю, по сравнению с богатством ЯП, в области IDE есть застой. Для программиста была бы удобной её более тесная интеграция с ОС, так, чтобы функции были first-class citizens в файловой системе, чтобы написанными функциями можно было бы сразу начинать полноценно пользоваться, а не заворачивая их перед этим в графический интерфейс. Средств разработки много, и они для самых разных задач: от конкатенации файлов с помощью copy (это тоже программирование) через БД и SQL к численным методам и графическим интерфейсам. Они как-то поразительно разобщены. Например, как в MS SQL Server загрузить файл в ячейку таблицы стандартными средствами SQL? Или выполнить на записи некоторые вычисления, которые можно задать только в другом ЯП, не проходя через геморрой с компиляцией DLL и под постоянным страхом, что она порушит работающий сервер? Я не знаю. (Я привожу просто пример, ибо у Microsoft больше всех шансов сделать среду более удобной, раз он владеет и ОС, и ЯП.) А например, найти в таблице функцию, применить её к файлу, и результат скормить другой программе, так, чтобы, когда исходный файл меняется, программа получала уведомление? Думаю, на интеграцию всех этих компонентов будет затрачено больше времени, чем собственно на программирование. А ведь это рядовая автоматизация повседневной работы, каких много. Может быть, ОС должна создавать для пользователя более декларативное (в смысле парадигмы программирования) окружение.
Это IMHO более существенный вопрос, чем пережевывание резины с хорошими и плохими ЯП. Тема поднята верная, только ставить на первый план ЯП не совсем верно.

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

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

AVC>>Как мне кажется, в других языках дело обстоит также.

VD>Кристись. К примеру, C# 2.0 поддерживает дженерики которые полностью комилируются в промежуточный код (в точности как в Обероне) и могут размещаться в отдельных бинарных модулях. При этом его можно использовать из других модулей. Т.е. на лицо полное непротиворечие идеи модульного и обобщенного программирования.

Кажется, Павел Кузнецов писал, что дженерики и шаблоны все-таки не совсем одно и то же?
Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.

AVC>>Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны?

VD>Создавать обобщенный код. Другими словами поднимать уровень абстракции, уменьшать объем кода, создавать безопасный (проверяемый во времы компиляции) полиморфный код.

В целом согласен, но почему-то сомневаюсь насчет "уменьшать объем кода".

AVC>>его эффективность — гораздо ниже кода, написанного самим.

VD>Гы. Щаз тебя порвут.

VD>По своему опыту скажу, что скорость шаблонного кода не отличается от рукопашного.

Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана вместе с Пайком. Эти злобные критики Си++ пишут в третьей главе своей книги "Практика программирования":

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

Хочу также обратить Ваше драгоценное внимание на время исполнения на 400 MHz Pentium II(c) программ с одинаковым алгоритмом:

на Си — 0.3 сек
на AWK — 2.1 сек
на Java — 9.2 сек
на Си++/STL/deque — 11.2 сек

Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL?
Ведь нарочно не напишешь!

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

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

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

Несомненное приемущество у денириков только одно. Они намного проще в использовании.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

ПК>В этом отношении согласен: если говорить буквально о шаблонах, в том виде, как они приняты в C++, то можно вполне уверенно утверждать, что практическая вероятность пересечения ими границы модуля во время исполнения, фактически, равна нулю. Если, конечно, не добавлять к программе полный компилятор C++, что вряд ли кому-нибудь реально нужно. Особенно учитывая, что область применения компонентного подхода вполне покрывается платформой .Net, которая уже обеспечивает "докомпиляцию" во время исполнения. На эту "докомпиляцию", собственно, и полагаются generics.

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

Причем те системы программирования, которые для них приходится делать, они же и выполняют функции операционной системы. Отчасти поэтому меня и интересует Оберон, ведь он для таких случаев и создавался.
Но пока что пишу Си-компиляторы, ассемблеры и отладчики, и страдаю угрызениями совести, глядя как ребята мучаются с отладкой "прикладного" кода на "железе" и FPGA.
Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?
Это очень интересная идея (кажется тема диссертации одного виртовского аспиранта?), но, увы, неприменимая для автономных систем, которыми я занимаюсь, обязанных работать в real-time. (Правда, может быть, я опять тороплюсь с выводами?)
В целом же мне кажется, что большого противоречия между нашими высказываниями нет, если опустить некоторые мои неосторожные формулировки.

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

ПК>Тот же C++, при всех объективных недостатках, обусловленных совместимостью с C, является столь популярным не потому, что его начали преподавать в вузах, а благодаря все той же совместимости с C. А сейчас ситуация такова, что если за новым языком не будет стоять гигант индустрии типа Microsoft или Sun, и, тем более, если язык не будет давать принципиально новых возможностей (к каковым его простоту и даже большую безопасность я относить не склонен), то вряд ли он станет, действительно, популярным.

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

)
Но простоту и безопасность он, похоже, готов защищать до конца (в чем с ним всегда были согласны все "отцы" структурного программирования: Дейкстра, Хоар и т.д., просто Вирт остался "последним из могикан"), что не так уж удивительно, если вспомнить, что Оберон используется в ряде систем, критических с точки зрения безопасности.

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

AVC>Кажется, Павел Кузнецов писал, что дженерики и шаблоны все-таки не совсем одно и то же?

Аналогичность не означает эквивалентность. См. Re[8]: Технология

AVC>Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.

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

Компонентность обязательно подразумевает использование независимых физических едениц.

AVC>В целом согласен, но почему-то сомневаюсь насчет "уменьшать объем кода".

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

С точки зрения объема исполняемого (машинного) кода, то он тоже уменьшается, так как для ссылочных типов код дженерик-типов испльзуется повторно.

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

AVC>Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана...

Им давно пора не пенсию. Меня вообще сегда удручало защита устаревших технологий.

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

AVC>Хочу также обратить Ваше драгоценное внимание на время исполнения на 400 MHz Pentium II(c) программ с одинаковым алгоритмом:

AVC>

AVC>

AVC>на Си — 0.3 сек
AVC>на AWK — 2.1 сек
AVC>на Java — 9.2 сек
AVC>на Си++/STL/deque — 11.2 сек

AVC>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL?
AVC>Ведь нарочно не напишешь!

Мне кажется, что это намеренное введение в заблуждение. Я просто уверен, что алгоритмы не идентичны. В качестве опровержения этогой инсинуации могу привести результаты собственных эксперементов:
http://gzip.rsdn.ru/article/devtools/perftest.xml
http://gzip.rsdn.ru/article/devtools/perftest2.xml
http://gzip.rsdn.ru/article/devtools/perftest3.xml

В частности, советую обратить внимание на результаты теста "Quick Sort (быстрая сортировка)". Там как раз в С++ применялась шаблонная функция.

Что же касается конкретно СТЛ. СТЛ — это всего лишь интерфейс. Он не может быт ни медленным, ни быстрым. Скорость работы СТЛ-кода зависит исключительно от двух факторов:
1. Качество реализации библиотеки.
2. Качество оптимизации компилятора.

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

AVC>Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?

"Де" — означает обратный. Докомпиляция — означает востановление исходников по бинарным форматам вроде модулей оберона, сборок дотнета или исполняемым файлам Виндовс.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

VladD2,

> AVC> Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?

> "Де" — означает обратный.

+1

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

"Докомпиляция" начинается с "до", а не с "де"

В данном случае AVC совершенно прав: я имел в виду именно JIT и аналогичные решения.

Posted via RSDN NNTP Server 1.9 gamma

AVC:

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

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

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

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

> Но пока что пишу Си-компиляторы, ассемблеры и отладчики, и страдаю угрызениями совести, глядя как ребята мучаются с отладкой "прикладного" кода на "железе" и FPGA.

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

Фактически, это означает, что указатель будет состоять из трех частей: 1) собственно, адрес; 2) адрес/смещение начала блока; 3) размер блока или адрес/смещение его конца. В "настольных" системах это используется редко (фактически, почти не используется) из-за проблем бинарной совместимости с существующим кодом.

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

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

> Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?

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

> Это очень интересная идея (кажется тема диссертации одного виртовского аспиранта?), но, увы, неприменимая для автономных систем, которыми я занимаюсь, обязанных работать в real-time. (Правда, может быть, я опять тороплюсь с выводами?)

Я тоже склонен полагать, что встроенным системам JIT и аналоги вряд ли нужны. Более того, у меня есть стойкое ощущение, что и компонентность в трактовке Java/.Net им тоже не слишком нужна. Впрочем, здесь у меня практического опыта нет, только академический интерес.

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

И вновь мне ничего не остается, кроме как согласиться

Да, собственно, вроде, мы и не спорим

Posted via RSDN NNTP Server 1.9 gamma

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

AVC>Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана вместе с Пайком. Эти злобные критики Си++ пишут в третьей главе своей книги "Практика программирования":
Канэчно порвем. Код в студию!

... << RSDN@Home 1.1.4 rev. 185 >>

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

AVC>на Си — 0.3 сек
AVC>на AWK — 2.1 сек
AVC>на Java — 9.2 сек
AVC>на Си++/STL/deque — 11.2 сек

AVC>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL?
AVC>Ведь нарочно не напишешь!

Если не ошибаюсь, то там речь шла о построении словаря или о чём-то подобном. Здесь прикол в том, что они использовали довольно медлительную версию STL и, кстати, сами чуть ниже об этом упомянули.

... << RSDN@Home 1.1.3 stable >>

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

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

AVC>>на Си — 0.3 сек
AVC>>на AWK — 2.1 сек
AVC>>на Java — 9.2 сек
AVC>>на Си++/STL/deque — 11.2 сек

AVC>>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL?
AVC>>Ведь нарочно не напишешь!

ГВ>Если не ошибаюсь, то там речь шла о построении словаря или о чём-то подобном. Здесь прикол в том, что они использовали довольно медлительную версию STL и, кстати, сами чуть ниже об этом упомянули.

я помню этот тест, там была еще куча приколов.
они юзали std::string, хотя он и нафиг не сдался, если не предполагается активно изменять содержимое строк,
там было много new и delete и в тесте не использовались никакие аллокаторы, понятно, что даже Java будет быстрее.

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

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

Кстати, у тебя там в первой ссылке какие-то нереальные результаты получились для VB6.
По моему опыту он отставал от С++ в обычных вычислениях примерно в 1.2-2 раза, но не в 10

за исключением ситуаций:
— запуск из среды (это выполнение P-кода вместо компиляции в двоичный код)
— использование нетипизированных значений (VARIANT)
— забыли поставить ByVal для числового параметра
— стоит ByVal для строкового параметра или объектного параметра

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

V>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.

Опять вернулись на круги своя

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>

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

V>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.

О, да! Я даже сам когда-то принимал участие в разработке таких чудес. Прикол в том, что код на C++, может не только не уступать по производительности коду на C, но и существено его превосходить. За счёт статического полиморфизма и строгой типизации, разумеется. Естественно, если это не случай передачи std::stdring по значению.

... << RSDN@Home 1.1.3 stable >>

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

V>>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.

M>Опять вернулись на круги своя

Только ситуация ещё хуже! Чем больше возможностей языка — тем более возможностей написать дикий код.

Видел как пара физиков в МФТИ написала следующий код для расчётов:
Класс формулы с двумя методами — конструктором (в который загонялось более 40 параметров, причём с преобразованием типа от int к float, а потом к double), методом Compute (с двумя параметрами x и y); всё остальное делалось в коде main исключительно в стиле C.
Поскольку конструктор со всеми параметрами вызывался в цикле (и это при том, что из всей кучи менялись только три параметра), для каждой пары x,y, да и сама формула вычислялась далеко не оптимальным образом. Так как у них уже была программа на C, которая всё это вычисляла (как потом выяснилось, что и с исходниками) — оказалось, что она считала всё это примерно раз в 15 быстрее (около 4-х секунд, против минуты). Что они только не говорили про язык C++. После того, как я им её переписал, тоже самое стало считаться за 0,5 секунды, правда при этом исходный файл с данными я перевёл с помощью простенького конвертора из текстовой формы в двоичную. Но и до этого всё считалось быстрее (где то около 1,5 — 2 секунд). Они очень удивились.

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

B>Я думаю, по сравнению с богатством ЯП, в области IDE есть застой. Для программиста была бы удобной её более тесная интеграция с ОС, так, чтобы функции были first-class citizens в файловой системе, чтобы написанными функциями можно было бы сразу начинать полноценно пользоваться, а не заворачивая их перед этим в графический интерфейс. Средств разработки много, и они для самых разных задач: от конкатенации файлов с помощью copy (это тоже программирование) через БД и SQL к численным методам и графическим интерфейсам. Они как-то поразительно разобщены. Например, как в MS SQL Server загрузить файл в ячейку таблицы стандартными средствами SQL? Или выполнить на записи некоторые вычисления, которые можно задать только в другом ЯП, не проходя через геморрой с компиляцией DLL и под постоянным страхом, что она порушит работающий сервер? Я не знаю. (Я привожу просто пример, ибо у Microsoft больше всех шансов сделать среду более удобной, раз он владеет и ОС, и ЯП.) А например, найти в таблице функцию, применить её к файлу, и результат скормить другой программе, так, чтобы, когда исходный файл меняется, программа получала уведомление? Думаю, на интеграцию всех этих компонентов будет затрачено больше времени, чем собственно на программирование. А ведь это рядовая автоматизация повседневной работы, каких много. Может быть, ОС должна создавать для пользователя более декларативное (в смысле парадигмы программирования) окружение.

На самом деле, к IDE это имеет очень отдаленное отношение. Так же, как и к языкам. Основная проблема здесь — это проблема интеграции между языками, и как следствие — проблемы при интеграции программ. Я искренне надеюсь, что .NET/CLI постепенно решит большинство из этих проблем. Собственно, для этого он и создавался

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

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

AVC>

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

непредсказуема — это не значит, что она обязательно будет хуже. Хрестоматийный пример — это std::sort, который рвет сишный qsort на немецкий крест

Собственно, "ослабление контроля" — это как раз то, для чего STL создавался. Я не понимаю, зачем его нужно за это ругать

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

AF> Как сделать нотацию в которой самый компактный C++ (С#, Java или даже Oberon) — я показал.

А Вы так уверены в мощности С++? Думаете на нем все можно выразить? А можно попросить Вас задуматься как на С++ объявить тип функции, возвращаемым значением которой является переменная ее собственного типа?

TYPE 
  SelfReplicatindMachine = PROCEDURE (): SelfReplicatindMachine;

Вот так это записывается на Component Pascal.

VAR m: SelfReplicatindMachine;
BEGIN
  m := m0;
  WHILE m # NIL DO m := m() END

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

СГ>А Вы так уверены в мощности С++? Думаете на нем все можно выразить? А можно попросить Вас задуматься как на С++ объявить тип функции, возвращаемым значением которой является переменная ее собственного типа?

В C++ для таких вещей обычно используют функторы, и никаких проблем здесь не будет.
А если использовать указатель на функцию, то это, уважаемый, будет уже plain C

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

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

ПК>Однако в плане программирования встроенных систем на Обероне мне интересен другой вопрос: насколько я понимаю, такие системы должны тесно взаимодействовать с "железом". А насколько это просто организовать, учитывая, что адресной арифметики и многих других "низкоуровневых" возможностей в Обероне и аналогах нет?

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

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

AF> Догадайтесь, что случилось бы если бы (чур-чур-чур!

Вы правы. Таких ленивцев пруд пруди. Я в интернете однаждый видел реализацию оберона с генериками. Ссылка, правда, сейчас стала битой, поэтому дать не могу. Мерещится, что это был какой-то из вариантов OOC, O2C.

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

AVC>>Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.

VD>Промежуточный код — это то что находится в нутри модулей оберона (и дотнета).

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

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

Д>непредсказуема — это не значит, что она обязательно будет хуже. Хрестоматийный пример — это std::sort, который рвет сишный qsort на немецкий крест

А рукопашная реализация sort, точно так же рвет std::sort потому что std::sort использует O(N*Log(N)) алгоритмы, в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.

10'000'000 целых 4-байтовых чисел (Celeron 1000, 512 Мб ОЗУ, шина 133 МГц)

C++     std::sort    3.835 сек
Delphi  поразрядная  2.354 сек

Скорость поразрядной сортировки прямо пропорциональна скорости памяти. То есть если в два раза увеличить скорость памяти (с 133 до 266 МГц), то и скорость увеличится примерно в 2 раза: На P4 1800Mh 512Kb, 256Mb DDR266 10'000'000 4-байтовых чисел сортируются за 1.312 сек. При переходе с 266 на 400 Мгц память скорость опять увеличивается пропорционально увеличению скорости памяти +40%.

http://www.progz.ru/forum/viewtopic.php?t=850

СГ>

СГ>Элементы         Мodula2 Оberon Оberon2  Си   Си++  Java  Ада  
СГ>Лексемы          887     765    726      917  1662  1771  2206  
СГ>Нетерминалы      70      62     43       917  126   174   226  
СГ>Терминалы        88      90     91       123  131   121   102  
СГ>Служебные слова  39      32     34       27   47    48    63  
СГ>

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

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

Д>PS Вот хоть убейте меня — не вижу ни одной реальной задачи, в которой такая конструкция действительно необходима.

Что значит необходима? Вопрос не в необходимости, а в максимальной простоте. Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.

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

СГ>в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.

Как раз для такого случая существует частичная специализация шаблонов

А вообще — говорили мы совсем не об этом.

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

СГ>Что значит необходима? Вопрос не в необходимости, а в максимальной простоте. Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.

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

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

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

Аналогия не верна. Пиджинг-инглиш — это что-то типа VB script, а не полноценный язык.

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

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

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

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

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

СГ>Что значит необходима? Вопрос не в необходимости, а в максимальной простоте.

Какой смысл искать простые решения несуществующих проблем?

СГ>...Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.

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

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

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

СГ>>в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.

Д>Как раз для такого случая существует частичная специализация шаблонов

Вот именно. На каждое средство в С++ есть противосредство. Даже на шаблоны придумали противошаблоны — частичную специализацию.

Д>А вообще — говорили мы совсем не об этом.

Как же не об этом если именно об этом!!! Смысл шаблона состоит в том что он одинаков для всех случаев. А если писать специализацию, то спасибо, я и без шаблона ее могу написать. Мне такие шаблоны не нужны.

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

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

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

СГ>>>в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.

Д>>Как раз для такого случая существует частичная специализация шаблонов

СГ>Вот именно. На каждое средство в С++ есть противосредство. Даже на шаблоны придумали противошаблоны — частичную специализацию.

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

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

Q>Сомнительная аналогия. Для естественных языков характерна тенденция к упрощению.

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

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

Q>Аналогия не верна. Пиджинг-инглиш — это что-то типа VB script, а не полноценный язык.

А что, с каких пор скриптовые языки стали неполноценными?
На том же самом VB script пишут даже системные службы, например. А ты говоришь — неполноценный

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

AVC>>Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана вместе с Пайком. Эти злобные критики Си++ пишут в третьей главе своей книги "Практика программирования":
WH>Канэчно порвем. Код в студию!

Код содержится в третьей главе упомянутой книги Кернигана и Пайка.
На всякий случай привожу его здесь.

/* Copyright (C) 1999 Lucent Technologies */
/* Excerpted from 'The Practice of Programming' */
/* by Brian W. Kernighan and Rob Pike */

#include <time.h>
#include <iostream>
#include <string>
#include <deque>
#include <map>
#include <vector>

using namespace std;

const int  NPREF = 2;
const char NONWORD[] = "\n";    // cannot appear as real line: we remove newlines
const int  MAXGEN = 10000; // maximum words generated

typedef deque<string> Prefix;

map<Prefix, vector<string> > statetab; // prefix -> suffixes

void        build(Prefix&, istream&);
void        generate(int nwords);
void        add(Prefix&, const string&);

// markov main: markov-chain random text generation
int main(void)
{
    int    nwords = MAXGEN;
    Prefix prefix;    // current input prefix

    srand(time(NULL));
    for (int i = 0; i < NPREF; i++)
        add(prefix, NONWORD);
    build(prefix, cin);
    add(prefix, NONWORD);
    generate(nwords);
    return 0;
}

// build: read input words, build state table
void build(Prefix& prefix, istream& in)
{
    string buf;

    while (in >> buf)
        add(prefix, buf);
}

// add: add word to suffix deque, update prefix
void add(Prefix& prefix, const string& s)
{
    if (prefix.size() == NPREF) {
        statetab[prefix].push_back(s);
        prefix.pop_front();
    }
    prefix.push_back(s);
}

// generate: produce output, one word per line
void generate(int nwords)
{
    Prefix prefix;
    int i;

    for (i = 0; i < NPREF; i++)
        add(prefix, NONWORD);
    for (i = 0; i < nwords; i++) {
        vector<string>& suf = statetab[prefix];
        const string& w = suf[rand() % suf.size()];
        if (w == NONWORD)
            break;
        cout << w << "\n";
        prefix.pop_front();    // advance
        prefix.push_back(w);
    }
}

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

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

Q>>Сомнительная аналогия. Для естественных языков характерна тенденция к упрощению.

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

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

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

СГ>Именно такая конструкция является самым простым способом для программирования конечного автомата.
Те программирование сферического коня в вакууме? Не смешите мои тапочки. Конечные автоматы ручками не пишут. А если и пишут то на языке специально для этого заточеном.
Например лексер эффективнее всего реализовать именно конечным автоматом но блин вдолбить ручками конечный автомат в котором может быть несколько сотен состояний и при этом ни разу не ошибиться это не реально. По этому все пользуются генераторами лексеров, задают лексемы регулярными выражениями и не парятся. А построением по регулярному выражению НДКА, объеденением всех НДКА в один с несколькими конечными состояниями, преобразованием НДКА в ДКА, оптимизацией ДКА и генерацией кода занимается программа.
Короче Дон-Кихот (в смысле Вирт) нашол очередную мельницу и успешно ее победил.

Ура товаррищи!

Урррра!!!

ЗЫ Даже если не брать готовый генератор то ИМХО его проще написать чем ручками долбить конечный автомат.
ЗЗЫ Готов спорить что генереный КА будет работать быстрее чем рукописный построеный на указателях на функции.

... << RSDN@Home 1.1.4 rev. 185 >>

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

WH> Конечные автоматы ручками не пишут.

А разве я предлагал ручками писать? Нет, действительно, я предлагал руками писать или не предлагал??? В моем сообщении написано, что указанный способ — самый простой. Могу добавить что еще и самый эффективный, так как нет затрат на switch. Там где-нибудь написано, что данный способ надо кодировать РУКАМИ, а не КОДОГЕНЕРАТОРОМ??? Что Вы себе позволяете, в конце-то концов...

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

Q>Ну тогда обоснуй свое мнение. Я уже привел пример русского. Точно также проще стали французский, испанский и немецкий. А англиский — это вообще потомок немецкого и то, что там практически полностью исчезли рода говорит само за себя. И почему тебя удивляет, что древние языки очень сложные? Какая-нибудь деревянная хата, построенная без единого гвоздя, может быть тоже в определенном смысле сложнее простого как палка небоскреба. Однако, последний явно превосходит ее технологически. Языки избавляются от лишней грамматической мути, которая только мешает излагать свои мысли.

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

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

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

WH>>Канэчно порвем. Код в студию!

AVC>Код содержится в третьей главе упомянутой книги Кернигана и Пайка.
AVC>На всякий случай привожу его здесь.
А это... ну его уже порвали... Там использованы разные алгоритмы...
Отсюда и дальше
http://gzip.rsdn.ru/Forum/?mid=559116
рвут на следующей странице.

После того, как я посмотрел на код свежим взглядом, выяснилось, что все, что я говорил про данный (С++) код ранее, мягко говря, бред Т.е. время уходит именно на заполнение map'а. Попробовал поиграть с типом ключа — без толку... А вот замена на hash_map (пришлось, правда, свою функцию написать) действительно, ускорила время в два раза. Итого на MSVC 6.0 SP5 + STLPort 0.23 sec, (ANCI C вариант — 0.22).

Те в приделах погрешности измерения... А если сравнить объем кода

... << RSDN@Home 1.1.4 rev. 185 >>

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

СГ>Вот именно. На каждое средство в С++ есть противосредство.

СГ>Даже на шаблоны придумали противошаблоны — частичную специализацию.
угу, спасибо авторам, здоровья им!

СГ>Смысл шаблона состоит в том что он одинаков для всех случаев. А если писать специализацию, то спасибо, я и без шаблона ее могу написать. Мне такие шаблоны не нужны.

Полная и частичная специализация — разные вещи.

Полная:
Представь, что у тебя есть правило, которое верно для 100 случаев, но имеет исключения для 101-го. Если бы не возможность полной специализации, ты бы должен был написать 101-у реализацию, а так ты пишешь всего 2.

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

Мне такие шаблоны нужны.

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

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

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

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

имхо

... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>

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

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

А откуда перед этим взялась усложенная грамматика и орфография? Зеленые человечки научили?

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

А как насчёт сравнения обычных конструкций языка?

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

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

WH>> Конечные автоматы ручками не пишут.

СГ>А разве я предлагал ручками писать? Нет, действительно, я предлагал руками писать или не предлагал??? В моем сообщении написано, что указанный способ — самый простой. Могу добавить что еще и самый эффективный, так как нет затрат на switch. Там где-нибудь написано, что данный способ надо кодировать РУКАМИ, а не КОДОГЕНЕРАТОРОМ??? Что Вы себе позволяете, в конце-то концов...

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

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

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

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

СГ>Вы правы. Таких ленивцев пруд пруди. Я в интернете однаждый видел реализацию оберона с генериками. Ссылка, правда, сейчас стала битой, поэтому дать не могу. Мерещится, что это был какой-то из вариантов OOC, O2C.

Вот это другое дело. Мне кажется — что в Обероне есть интересные идеи и возможно, что он со временем разовётся в нечто более инетерсное, чем сейчас комплект C++/C#/Jaba. И чем больше мы будем непредвзято обмениваться фактами — как позитивными, так и негативными для той или иной технологии — тем лучше будут они развиваться. В том числе и оберон.

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

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

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

Д>А откуда перед этим взялась усложенная грамматика и орфография? Зеленые человечки научили?

И это вариант скидывать со счетов не надо

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

Так, русский сохранил в себе всего 5 времен для глаголов (будущее и прошедшее могут быть совершенного или несовершенного вида), но в нем все еще есть неправильные глаголы и причастия с деепричастиями.

В английском есть только герундий, но орфография — бррр. Причем в американском английском идет ее частичное упрощение (neighbour -> neighbor, colour -> color, programme -> program, dialogue -> dialog, plough -> plow), а некоторые из 16 возможных времен почти не используются (Future Perfect Continuous/Progressive in the Past — would have been doing

).

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

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

Сейчас в большинстве современных языков достаточно развитых наций, как мне кажется, идет тенденция к упрощению грамматики языка (в том же румынском плюсквамперфект/Past Perfect, еще относительно недавно бывший не таким уж и редким, сейчас — удел поэтов; когда вы в последний раз видели букву ё в русском?; невозможно встретить какой-нибудь Future Perfect Continuous in the Past Passive Voice в английском, а в турецком заимствованые слова screen, kral(король) постепенно становятся sikrin, kiral, чтобы соответствовать правилам языка).

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>

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

V>Представь, что у тебя есть правило, которое верно для 100 случаев, но имеет исключения для 101-го...

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

Теперь по существу вопроса. Эффективные алгоритмы сортировки для разных типов чисел разные.
1) Однобайтовые числа — сортировка за один проход.
2) Двух байтовые числа — в зависимости от экономии/неэкономии памяти либо за один либо за два прохода, либо еще как...
3) Четырех байтовые числа — в зависимости от скорости памяти и размера кэша процессора и стратегии экономии или не экономии памяти есть несколько реализаций O(N) алгоритмов.
4) 64-битные — тоже что и для предыдущих пунктов с учетом большей нагрузки на пропускную способность памяти....
5) Тоже что и для предыдущих пунктов, но еще и для чисел со знаком — там нужен дополнительный "подкрут" в конце работы...
6) Числа из заданного диапазона.
....

То есть, например, говорить о шаблонах и приводить в качестве примера шаблонную сортировку — это НЕХОРОШО. Так как в этом случае все наоборот: есть 1 общий случай и 100 частных конкретизаций, а раз так, то в случае сортировок шаблоны просто не нужны.

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

Q>>>Сомнительная аналогия. Для естественных языков характерна тенденция к упрощению.

Q>Ну тогда обоснуй свое мнение. Я уже привел пример русского. Точно также проще стали французский, испанский и немецкий. А англиский — это вообще потомок немецкого и то, что там практически полностью исчезли рода говорит само за себя. И почему тебя удивляет, что древние языки очень сложные? Какая-нибудь деревянная хата, построенная без единого гвоздя, может быть тоже в определенном смысле сложнее простого как палка небоскреба. Однако, последний явно превосходит ее технологически. Языки избавляются от лишней грамматической мути, которая только мешает излагать свои мысли.

Ага. Тогда, следуя этой логике, идеальный язык — это язык без слов.
Я, вообщем-то, склонен с этим согласиться, ибо еще Лао-Цзы сказал:
"Слово которое можно сказать — не есть истинное Слово"

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

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

СГ>А разве я предлагал ручками писать? Нет, действительно, я предлагал руками писать или не предлагал??? В моем сообщении написано, что указанный способ — самый простой.
А к чему тогда все эти

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

Ведь если КА генерируется то это не имеет ни какого значения. Простота может иметь значение только при ручной работе. Когда работают машины там уже несколько иные критерии.
СГ>Могу добавить что еще и самый эффективный, так как нет затрат на switch.
Без комментариев. Иди учить матчасть

... << RSDN@Home 1.1.4 rev. 185 >>

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

AF> практическую бессмысленность этой задачи

1) Задача о конечных автоматах имеет практический смысл.
2) Наиболее эффективное решение этой задачи, без всяких сомнений, тоже имеет практический смысл.
3) Я показал способ решения более эффективный чем способ большого switch-я по состояниям.

Так в чем же бессмысленность?

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

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

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

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

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

СГ>1) Задача о конечных автоматах имеет практический смысл.
Несомненно.
СГ>2) Наиболее эффективное решение этой задачи, без всяких сомнений, тоже имеет практический смысл.
Несомненно.
СГ>3) Я показал способ решения более эффективный чем способ большого switch-я по состояниям.
Иди учить матчасть.

... << RSDN@Home 1.1.4 rev. 185 >>

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

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 229>>

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

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

AF>> практическую бессмысленность этой задачи

СГ>1) Задача о конечных автоматах имеет практический смысл.
Безусловно.

СГ>2) Наиболее эффективное решение этой задачи, без всяких сомнений, тоже имеет практический смысл.
Безусловно. Но краткость записи — ещё не гарантия большей эффективности решения. D mathcad или mathlab формулы записываются не в пример короче C++/Java или Оберона — а вот считаются отнюдь не быстрее.

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

СГ>3) Я показал способ решения более эффективный чем способ большого switch-я по состояниям.
Возможно, хотя это ещё надо проверять.

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

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

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

Д>А откуда перед этим взялась усложенная грамматика и орфография? Зеленые человечки научили?

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

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

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

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

V>>Представь, что у тебя есть правило, которое верно для 100 случаев, но имеет исключения для 101-го...

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

А что делать, если по твоим постам всё выглядит именно так?

СГ>Теперь по существу вопроса. Эффективные алгоритмы сортировки для разных типов чисел разные.
СГ>1) Однобайтовые числа — сортировка за один проход.
СГ>2) Двух байтовые числа — в зависимости от экономии/неэкономии памяти либо за один либо за два прохода, либо еще как...
СГ>3) Четырех байтовые числа — в зависимости от скорости памяти и размера кэша процессора и стратегии экономии или не экономии памяти есть несколько реализаций O(N) алгоритмов.
СГ>4) 64-битные — тоже что и для предыдущих пунктов с учетом большей нагрузки на пропускную способность памяти....
СГ>5) Тоже что и для предыдущих пунктов, но еще и для чисел со знаком — там нужен дополнительный "подкрут" в конце работы...
СГ>6) Числа из заданного диапазона.
СГ>....

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

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

Кроме того, очевидно, что сам пример с сортировкой не совсем корректен. Так как обычно нужен алгоритм достаточно быстрой NxLn(N), а не сверх быстрой сортировки. Если задача настолько критична по быстродействию, что потребовались такие методы — то это признак того, что код вообще должен не только писаться, но и проектироваться иначе, чем в обычных слуаях. Скорее всего тут может вообще потребоваться оптимизировать некоторые куски на ассемблере.

СГ>То есть, например, говорить о шаблонах и приводить в качестве примера шаблонную сортировку — это НЕХОРОШО. Так как в этом случае все наоборот: есть 1 общий случай и 100 частных конкретизаций, а раз так, то в случае сортировок шаблоны просто не нужны.
Как раз в большинстве случаев — нужны.

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

AVC>>Код содержится в третьей главе упомянутой книги Кернигана и Пайка.
AVC>>На всякий случай привожу его здесь.
WH>А это... ну его уже порвали... Там использованы разные алгоритмы...
WH>Отсюда и дальше
WH>http://gzip.rsdn.ru/Forum/?mid=559116
WH>рвут на следующей странице.
WH>

После того, как я посмотрел на код свежим взглядом, выяснилось, что все, что я говорил про данный (С++) код ранее, мягко говря, бред Т.е. время уходит именно на заполнение map'а. Попробовал поиграть с типом ключа — без толку... А вот замена на hash_map (пришлось, правда, свою функцию написать) действительно, ускорила время в два раза. Итого на MSVC 6.0 SP5 + STLPort 0.23 sec, (ANCI C вариант — 0.22).

WH>Те в приделах погрешности измерения... А если сравнить объем кода

Спасибо, за ссылку на интересное обсуждение.
Вот такая конкретная аргументация мне нравится!
Однако, насколько я понял, Вы цитируете "сговорчивого" Андрея Ушакова, а не Кернигана (как я сначала подумал).
Но, похоже, я читал "первоисточник" внимательнее, чем Андрей.
И здесь есть маленькая такая тонкость.
Продолжу цитирование Кернигана и Пайка.

"Переход с дека на список (в STL это двухсвязанный список) кардинальным временем улучшает время. Переход же с отображения (map) на (нестандартный) контейнер hash под Irix не приносит никаких изменений (на машине с Windows у нас не было реализации hash)."

Ни я, ни тем более Керниган с Пайком (они, в принципе, STL там хвалят) не утверждали, что код STL не может быть эффективным в принципе.
Утверждалось следующее: реализации STL пока страдают недоделками, их производительность непредсказуема, стандартного контейнера hash нет.
И что же из сказанного неверно?
Если при переходе с deque на list производительность поменялась в 7 с лишним раз, а переход на (нестандартный) hash не привел к выигрышу, разве честно утверждать, что причина была в разнице между hash_map и map?
На Windows Керниган и Пайк в 1999г. не нашли hash_map (возможно, они не слишком и утруждали себя). Наверное, нашли бы, если бы этот шаблон входил в стандарт Си++.
Однако почему-то такие большие дяди, заседавшие в комитете по стандартизации Си++, не смогли прийти за 10(!) лет к единому мнению, каким он должен быть. Разве это не говорит о том, что не все ладно в "королевстве Си++"?
Но в целом за пост спасибо. Он информативен и конкретен. Так и надо!

Аналогия между языками программирования и естественными языками — весьма отдалённая.

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

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

Но всё это никоим образом к языкам программирования отнести не возможно.

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

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

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

Я прочитал, программировать на Обероне не научился

, наверно невнимательно читал.

А вобще компактность языка не так критична, главное стройность и логичность, возможности.
Меня не очень напрягает что в C# 2.0 появятся новые фичи и он станет немного сложнее, даже наоборот жду с нетерпением

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

СГ>

СГ>VAR m: SelfReplicatindMachine;
СГ>BEGIN
СГ>  m := m0;
СГ>  WHILE m # NIL DO m := m() END
СГ>

А состояние тогда где лежит? В глобальных переменных?

Очень мило!

... << RSDN@Home 1.1.3 stable >>

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

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

СГ>Теперь по существу вопроса. Эффективные алгоритмы сортировки для разных типов чисел разные.
согласен, для чисел малой разрядности можно использовать адресную сортировку, но уже для 32 бит это, ИМХО, излишество. Затраты на выделение временной памяти могут сожрать весь выигрыш от алгоритма. К тому же эти алгоритмы ведут себя одинаково на разных последовательностях (даже практически отсортированных), что, зачастую, тоже не есть гут.

[кусь]

СГ>То есть, например, говорить о шаблонах и приводить в качестве примера шаблонную сортировку — это НЕХОРОШО. Так как в этом случае все наоборот: есть 1 общий случай и 100 частных конкретизаций, а раз так, то в случае сортировок шаблоны просто не нужны.

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

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

Что ты получишь, определив данную стратегию?
— Полезную, повторно используемую наработку, применимую даже вне стен целевого алгоритма.
— К тому же, открытую к расширению, ибо для каждого нового типа тебе будет достаточно лишь определить новую специализацию (если вдруг стандартная не устраивает).
— Скорость разработки и отладки. В первом варианте ты можешь использовать самый общий оригинальный шаблон без специализаций (quick sort — неплохое "начало"). После, в процессе оптимизации, ты можешь "вылизать" свою стратегию, но смежники пока могут спокойно работать с твоим первоначальным кодом.
И т.д. и т.п.

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

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

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

)

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

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

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

СГ>>

СГ>>VAR m: SelfReplicatindMachine;
СГ>>BEGIN
СГ>>  m := m0;
СГ>>  WHILE m # NIL DO m := m() END
СГ>>

ГВ>А состояние тогда где лежит? В глобальных переменных?

Очень мило!

можно таблицу как параметр передавать

целесообразность подобного решения становится еще более спорной.

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

ГВ>>А состояние тогда где лежит? В глобальных переменных?

Очень мило!
V>можно таблицу как параметр передавать

V>целесообразность подобного решения становится еще более спорной.

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

... << RSDN@Home 1.1.3 stable >>

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

Я вообще не понимаю, чего на мужика накинулись.
Ну улучшили Паскаль. Ну на здоровье!
Через 10 лет еще улучшат. Мне вообще кажется, что языки, нацеленные на одни задачи, и нацеленные на выполнение их одинаковыми методами (здесь ООП + GC), где-то в будущем должны сходиться, с точностью до деталей синтаксиса и имен операторов. Просто Оберон отстает на старте, но еще неизвестно, каким он будет на середине дистанции.

Пути нашей братии неисповедимы...

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

V>Я вообще не понимаю, чего на мужика накинулись.
Так на Вирта никто по большому счёту и не набрасывается. Кхм... почти никто. Губанов уж больно провокационно выступает. Вот и расшумелись.

V>Ну улучшили Паскаль. Ну на здоровье!
V>Через 10 лет еще улучшат. Мне вообще кажется, что языки, нацеленные на одни задачи, и нацеленные на выполнение их одинаковыми методами (здесь ООП + GC), где-то в будущем должны сходиться, с точностью до деталей синтаксиса и имен операторов. Просто Оберон отстает на старте, но еще неизвестно, каким он будет на середине дистанции.
Это верно.

Aos, кстати, любопытная система.

... << RSDN@Home 1.1.3 stable >>

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

M>И это вариант скидывать со счетов не надо

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

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

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

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

Q>Поэтому сложная грамматика — это как раз признак древнего языка. Можешь спросить об этом лингвистов, если мне не веришь.

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

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

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

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

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

Д>Но если рассмотреть процесс в целом, то языки все-таки развиваются от простого к сложному. К примеру, в первых языках вообще не было такого понятия как время (и у некоторых современных неразвитых племен — то же самое). Но затем появилась потребность выражать в языке отношения во времени — и появились конструкции, которые позволяют это сделать.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>

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

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

СГ>>

СГ>>VAR m: SelfReplicatindMachine;
СГ>>BEGIN
СГ>>  m := m0;
СГ>>  WHILE m # NIL DO m := m() END
СГ>>

ГВ>А состояние тогда где лежит? В глобальных переменных?

Очень мило!

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

Кстати, я тут недавно выписывал роли модулей, перечислил 6-7 пунктов, вот к ним надо добавить еще пункт:

7) Модуль — это объект существующий в единственном экземпляре (синглетон).

Во-вторых, можно, например, так:

TYPE
  State   = RECORD (* ... *) END;
  Machine = PROCEDURE (VAR s: State): Machine;


VAR m: Machine; s: State;
BEGIN
  m := m0; s := s0;
  WHILE m # NIL DO m := m(s) END

Это очень близко к ООП, но все же это не ООП, а нечто более тривиальное. (А раз так, то зачем "платить" больше?)

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

A> Где, например, определение IS в книге?

Та книга, как Вы могли заметить, вообще не описывает ООП (а инструкция IS — это из ООП). ООП будет описано в четвертой дополнительной главе, которую Вирт пока еще не написал, но собирается написать в скором времени.

A> ...Вирт тут хитрит...

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

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

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

A>> ...Вирт тут хитрит...

СГ>Ага, вот делать семидесятилетнему мужику больше нечего, кроме как хитрить, он вообще в таких категориях может не думает... Совсем что ли тут на RSDN Вирта за дурачка держут или как?

Думаю, что за дурачка его особо не держат, но вот его защитники имхо часто выставляют его таковым

(без его желания)

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

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

A>> Где, например, определение IS в книге?

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

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

A>> ...Вирт тут хитрит...

СГ>Ага, вот делать семидесятилетнему мужику больше нечего, кроме как хитрить, он вообще в таких категориях может не думает... Совсем что ли тут на RSDN Вирта за дурачка держут или как? Просто, по его мнению книга самодостаточна и без главы про ООП, а Вы с этим не согласны?

Нет. Либо ты описываешь весь язык, либо подмножество, не превосходящее по возможностям Паскаль, грубо говоря. Так можно описать подмножество C++, что оно тоже в 50 страниц влезет.

Кстати IS — это не из OOP. Накатай-ка сортировку общего назначения без IS и какого-нибудь способа приведения типов, который кстати тоже в книге не описан.

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

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

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

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

Женской логикой здесь пользуешься только ты. Я тебе привел примеры нескольких языков, грамматика которых упростилась за последние 1000 лет. На них разговаривает около 2 миллиардов жителей планеты. Добавь сюда еще китайский, где грамматика проще английской, а письменность постоянно упрощалась, и получишь, что большая (и лучшая в плане образованности) часть населения земли разговаривает на простых языках. От тебя я не дождался ни единого примера самого занюханного языка, который бы усложнялся.

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

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

Д>Но если рассмотреть процесс в целом, то языки все-таки развиваются от простого к сложному. К примеру, в первых языках вообще не было такого понятия как время (и у некоторых современных неразвитых племен — то же самое). Но затем появилась потребность выражать в языке отношения во времени — и появились конструкции, которые позволяют это сделать.

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

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

A>Извини меня, но к чему ты тогда привел эту книгу как пример компактности языка? Твой пример некоректен. Как же ты на некоректном примере строишь свою аргументацию?

Прости, я действительно не имел права приводить ту книгу в качестве примера в контексте того сообщения. Но даже если бы там и была четвертая глава про ООП, то это добавило бы максимум 20-30 страниц. Итого получилось бы что-то около 80. Супротив тысячи страниц про С++ все равно не хило.

A>Кстати IS — это не из OOP. Накатай-ка сортировку общего назначения без IS и какого-нибудь способа приведения типов, который кстати тоже в книге не описан.

IS — это инструкция вызова механизма RTTI для определения динамического типа переменной во время исполнения программы. Сами понятия статический тип и динамический тип переменной уже еть ООП.

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

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

A>>Извини меня, но к чему ты тогда привел эту книгу как пример компактности языка? Твой пример некоректен. Как же ты на некоректном примере строишь свою аргументацию?

СГ>Прости, я действительно не имел права приводить ту книгу в качестве примера в контексте того сообщения. Но даже если бы там и была четвертая глава про ООП, то это добавило бы максимум 20-30 страниц. Итого получилось бы что-то около 80. Супротив тысячи страниц про С++ все равно не хило.

Тысяча страниц про C++ — это его стандарт. Супротив него ты только стандарт Оберона можешь поставить. Он будет совсем не 80 страниц.

A>>Кстати IS — это не из OOP. Накатай-ка сортировку общего назначения без IS и какого-нибудь способа приведения типов, который кстати тоже в книге не описан.

СГ>IS — это инструкция вызова механизма RTTI для определения динамического типа переменной во время исполнения программы. Сами понятия статический тип и динамический тип переменной уже еть ООП.

Меня все таки интересует обобщенная сортировка написанная с применением только тех возможностей Оберона, которые описаны в книге. В C, который OOP никакой особой поддержки не оказывает, это возможно.

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

СГ>Во-вторых, можно, например, так:
СГ>

СГ>TYPE
СГ>  State   = RECORD (* ... *) END;
СГ>  Machine = PROCEDURE (VAR s: State): Machine;


СГ>VAR m: Machine; s: State;
СГ>BEGIN
СГ>  m := m0; s := s0;
СГ>  WHILE m # NIL DO m := m(s) END
СГ>

Мне что-то не совсем понятно, как в таком случае создать 2 конечных автомата с разными состояниями ?

Я — свихнувшееся сознание Джо.

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

A>Меня все таки интересует обобщенная сортировка написанная с применением только тех возможностей Оберона, которые описаны в книге. В C, который OOP никакой особой поддержки не оказывает, это возможно.

Ну, хорошо, уговорили. Приводите пример исходного кода на Си, а я его постараюсь переписать на обероне.

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

СГ>7) Модуль — это объект существующий в единственном экземпляре (синглетон).

А если мне эта сущность (инкапсулированная в модуле) понадобится два раза? Т.е два независимых экземпляра?

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

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

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

Д>>Но если рассмотреть процесс в целом, то языки все-таки развиваются от простого к сложному. К примеру, в первых языках вообще не было такого понятия как время (и у некоторых современных неразвитых племен — то же самое). Но затем появилась потребность выражать в языке отношения во времени — и появились конструкции, которые позволяют это сделать.

Q>Это бред. Или ты открыл предполагаемый праязык? Тогда тебе положена Нобелевская премия, поскольку в индоевропейских языках с самого начала было понятие времени. И то, что его нет в неких индейских наречиях не значит, что это понятие возникает в результате развития. А из чего возникли первые индоевропейские языки никому неизвестно, кроме тебя, видимо.

Индейские наречия — единственные, которые можно считать древними в современном мире. Что-то я сильно сомневаюсь, чтобы в каком-нибудь финикийском существовали прошедшие-в-прошедшем и будущие-в-прошедшем времена.

На самом деле идет так:

1. Древние языки. Минимум грамматических и словарных конструкций
2. Развивающиеся языки. Усложнение грамматики и расширение словаря.
3. Современные языки. Перекресток. Продолжение расширения словаря, но развитие грамматики приостановилось
4. Гипотетические языки будущего. Упрощенная грамматика, но очень развитый словарь.

ИМХО.

... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>

Здравствуйте, Sergey J. A., Вы писали:

SJA>Мне что-то не совсем понятно, как в таком случае создать 2 конечных автомата с разными состояниями?

А что два? Два это мало, давай сразу N

VAR m: ARRAY N OF Machine; 
    s: ARRAY N OF State;

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

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

СГ>>7) Модуль — это объект существующий в единственном экземпляре (синглетон).

WF>А если мне эта сущность (инкапсулированная в модуле) понадобится два раза? Т.е два независимых экземпляра?

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

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

Q>Женской логикой здесь пользуешься только ты. Я тебе привел примеры нескольких языков, грамматика которых упростилась за последние 1000 лет. На них разговаривает около 2 миллиардов жителей планеты. Добавь сюда еще китайский, где грамматика проще английской, а письменность постоянно упрощалась, и получишь, что большая (и лучшая в плане образованности) часть населения земли разговаривает на простых языках. От тебя я не дождался ни единого примера самого занюханного языка, который бы усложнялся.

1. Еще раз. Частный пример не доказывает общего утверждения
Здесь будут какие-то возражения?

2. Чтобы язык упрощался, он должен сначала откуда-то возникнуть. Ты хочешь сказать, что языки появились каким-то образом сразу в очень сложном виде?
Отвечай просто — да или нет.

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

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

Я понял! Этот самый пра-язык открыл ты. Иначе откуда ты это знаешь? Ну что же, тогда я спорить не могу

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

M>1. Древние языки. Минимум грамматических и словарных конструкций
M>2. Развивающиеся языки. Усложнение грамматики и расширение словаря.
M>3. Современные языки. Перекресток. Продолжение расширения словаря, но развитие грамматики приостановилось
M>4. Гипотетические языки будущего. Упрощенная грамматика, но очень развитый словарь.

Я все-таки сомневаюсь, что на этом всё остановится. Скорее, развитие будет идти по спирали. Хотя точно все равно никто не может знать

Mamut -> "Re[23]: А вот за язык-то Вас никто не тянул..."

M> 4. Гипотетические языки будущего. Упрощенная грамматика, но очень
M> развитый словарь.

Т.е. китайцы с японцами не так уж и не правы, рисуя иероглифы

.

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Posted via RSDN NNTP Server 1.9 gamma

Сергей Губанов -> "Re[17]: А вот за язык-то Вас никто не тянул..."

СГ>>>7) Модуль — это объект существующий в единственном экземпляре
СГ>>>(синглетон).

WF>>А если мне эта сущность (инкапсулированная в модуле) понадобится два
WF>>раза? Т.е два независимых экземпляра?

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

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

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Posted via RSDN NNTP Server 1.9 gamma

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

Д>1. Еще раз. Частный пример не доказывает общего утверждения
Д>Здесь будут какие-то возражения?

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

Д>2. Чтобы язык упрощался, он должен сначала откуда-то возникнуть. Ты хочешь сказать, что языки появились каким-то образом сразу в очень сложном виде?
Д>Отвечай просто — да или нет.

Да, он должен возникнуть. В каком виде и как они появились никому не известно. Если у тебя есть на этот счет какие-то данные — пиши диссертацию

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

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

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

Д>Я понял! Этот самый пра-язык открыл ты. Иначе откуда ты это знаешь? Ну что же, тогда я спорить не могу

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

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

M>Индейские наречия — единственные, которые можно считать древними в современном мире. Что-то я сильно сомневаюсь, чтобы в каком-нибудь финикийском существовали прошедшие-в-прошедшем и будущие-в-прошедшем времена.

Может и не существовали и что? В русском существовало прошедшее в прошедшем и исчезло.

M>На самом деле идет так:
M>1. Древние языки. Минимум грамматических и словарных конструкций
M>2. Развивающиеся языки. Усложнение грамматики и расширение словаря.
M>3. Современные языки. Перекресток. Продолжение расширения словаря, но развитие грамматики приостановилось
M>4. Гипотетические языки будущего. Упрощенная грамматика, но очень развитый словарь.
M>ИМХО.

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

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

Q>Не надо демагогии, это не математика. Эти "частные" примеры охватывают половину земного шара, при этом если покопать другие языки, то уверен на 90%, что там будет та же картина. Ты же не привел вообще ни единого примера, только нес какую-то чушь, основанную на чисто умозрительных рассуждениях.

Это не математика, это просто логика. Пока что твои аргументы с ней мало дружат.

Q>Да, он должен возникнуть. В каком виде и как они появились никому не известно. Если у тебя есть на этот счет какие-то данные — пиши диссертацию

Ответь на вопрос, это очень просто сделать. Там всего два очень простых ответа

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

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

Q>У науки нет данных о действительно древних языках. Не известно достоверно как возникли предки современных языков и был ли один первоначальный язык или они возникли независимо. Поэтому пункты 1 и 2 просто недоказуемы, более того, пункт 2 очень сомнителен ибо мне пока что не привели примера усложняющегося языка.

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

я такого просто не выдержу

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

при существующем объеме знаний, твое "знаю" выглядит ничуть не более обоснованным, чем мое "предполагаю"

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

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

Q>>Не надо демагогии, это не математика. Эти "частные" примеры охватывают половину земного шара, при этом если покопать другие языки, то уверен на 90%, что там будет та же картина. Ты же не привел вообще ни единого примера, только нес какую-то чушь, основанную на чисто умозрительных рассуждениях.

Д>Это не математика, это просто логика. Пока что твои аргументы с ней мало дружат.

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

Q>>Да, он должен возникнуть. В каком виде и как они появились никому не известно. Если у тебя есть на этот счет какие-то данные — пиши диссертацию

Д>Ответь на вопрос, это очень просто сделать. Там всего два очень простых ответа

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

Ты читай повнимательнее. Я уже ответил — ДА. Был переход от примитивного бормотания к более развитому языку, но это произошло так давно, что даже нет никаких данных о том как это происходило. Это мягко говоря противоречит, твоему бредовому утверждению, что языки постоянно усложняются. Или уже 4000 лет идет деградация, если следовать твоей "теории"?

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

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

я такого просто не выдержу

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

Д>при существующем объеме знаний, твое "знаю" выглядит ничуть не более обоснованным, чем мое "предполагаю"

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

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

Q>Ты меня утомил. Ни привел никакого обоснования своей лажовой теории, а от меня требуешь каких-то непонятных доказательств. Заинтересованные люди, желающие сами разобраться в вопросе, могут взять учебник по санскриту — одному из самых древних языков И-Е семьи, могу дать даже ссылку — и убедиться, что в этом языке было практически все, что есть в современных европейских языках включая славянские и более того есть то, чего в современных языках нет. С тобой же я закончил.

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

Q>Ты читай повнимательнее. Я уже ответил — ДА. Был переход от примитивного бормотания к более развитому языку, но это произошло так давно, что даже нет никаких данных о том как это происходило. Это мягко говоря противоречит, твоему бредовому утверждению, что языки постоянно усложняются. Или уже 4000 лет идет деградация, если следовать твоей "теории"?

Насколько мне известно, первые люди современного типа появились 40-50 тысяч лет назад. До этого существовали более примитивные формы, не знаю точно в течение какого периода. Можно предположить, что это срок был больше как минимум на порядок.
По сравнению с этим периодом, 4 тысячи лет — это очень маленький срок. И на его основании ты делаешь свои далеко идущие выводы, что языки все время упрощаются?

Скорее — не деградация, а упрощение тех форм, которые оказались не нужны. Хотя деградация тоже имела место, например — после падения Римской империи. НО — это всего лишь временное явление.

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

Q>Да куда уж нам до истинных знатоков типа тебя. В этом случае я просто заявляю — первый язык создал Бог, поэтому он был самый сложный. Это предположение ничем не хуже твоих предположений, в него верят миллионы людей.

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

На этом спор действительно можно считать законченным. Спорить с религиозным фанатиком все равно нет никакого смысла.

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

Д>Насколько мне известно, первые люди современного типа появились 40-50 тысяч лет назад. До этого существовали более примитивные формы, не знаю точно в течение какого периода. Можно предположить, что это срок был больше как минимум на порядок.
Д>По сравнению с этим периодом, 4 тысячи лет — это очень маленький срок. И на его основании ты делаешь свои далеко идущие выводы, что языки все время упрощаются?

Д>Скорее — не деградация, а упрощение тех форм, которые оказались не нужны. Хотя деградация тоже имела место, например — после падения Римской империи. НО — это всего лишь временное явление.

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

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

Д>Я так и ожидал, что этим закончится. С помощью бога можно доказать все что угодно, вплоть до того, что Луна сделана из лимбургского сыра

Д>На этом спор действительно можно считать законченным. Спорить с религиозным фанатиком все равно нет никакого смысла.

Ловко ты навешиваешь ярлыки. Я в Бога не верю.

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

Q>...могут взять учебник по санскриту — могу дать даже ссылку...
Можно мне?

сам слушаю и вам рекомендую: в тишине сижу

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

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

Q>>...могут взять учебник по санскриту — могу дать даже ссылку...
ЗХ>Можно мне?

http://www.franklang.ru/sanskrit.html

В разделе Грамматика и лексика первая книга. Там достаточно просмотреть уроки начиная где-то с 6. Там будет информация о склонениях, лицах, временах. Очень много сходства со славянскими языками, кроме обилия времен. А обилие времен указывает на романские языки.

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

Д>>Насколько мне известно, первые люди современного типа появились 40-50 тысяч лет назад. До этого существовали более примитивные формы, не знаю точно в течение какого периода. Можно предположить, что это срок был больше как минимум на порядок.
Д>>По сравнению с этим периодом, 4 тысячи лет — это очень маленький срок. И на его основании ты делаешь свои далеко идущие выводы, что языки все время упрощаются?

Очень радует, что ты хотя бы перестал распространять данные о текущем положении дел на всю историю человечества

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

Примеров нет просто потому, что у нас слишком мало данных. Лингвистам с этим намного сложнее, чем археологам

Q>Неизменность языка — признак застоя, а упрощение — прогресса.

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

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

Q>Ловко ты навешиваешь ярлыки. Я в Бога не верю.

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

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

Д>В таком случае, самым прогрессивным языком можно считать пиджин-инглиш? Странно, что на нем еще не говорит половина мира.

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

AF>> Догадайтесь, что случилось бы если бы (чур-чур-чур!

СГ>Вы правы. Таких ленивцев пруд пруди. Я в интернете однаждый видел реализацию оберона с генериками. Ссылка, правда, сейчас стала битой, поэтому дать не могу. Мерещится, что это был какой-то из вариантов OOC, O2C.

Правильно мерещится:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2

Насчет OberSTL:
http://cvs.sourceforge.net/viewcvs.py/ooc/ooc2/lib/src/ADT/

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

V>Правильно мерещится:
V>http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2

V>Насчет OberSTL:
V>http://cvs.sourceforge.net/viewcvs.py/ooc/ooc2/lib/src/ADT/

Ну да, это самое я и имел в виду. Это ведь Вы ту ссылку тогда давали в королевском форуме "Мысли об Обероне"?

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

СГ>Ну да, это самое я и имел в виду. Это ведь Вы ту ссылку тогда давали в королевском форуме "Мысли об Обероне"?

Ссылка была другая, но на тот же документ.

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

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

Д>>Я понял! Этот самый пра-язык открыл ты. Иначе откуда ты это знаешь? Ну что же, тогда я спорить не могу

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

Я не специалист в истории языков но как-то давно смотрел передачу Гордна посвященную этому вопросу. Так его гость (кто именно не помню) вполне убедительно (для меня) показывал методику по которой можно сравнить родство языков. АФАИР там учитывалось количество общих слов в языках (исключая заимствованные). И на этой основе делался вывод о близости (родственности) языков.

Сергей Губанов,

> ПК> Однако в плане программирования встроенных систем на Обероне мне интересен другой вопрос: насколько я понимаю, такие системы должны тесно взаимодействовать с "железом". А насколько это просто организовать, учитывая, что адресной арифметики и многих других "низкоуровневых" возможностей в Обероне и аналогах нет?

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

Напиши, пожалуйста.

Posted via RSDN NNTP Server 1.9 gamma

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

ПК>"Докомпиляция" начинается с "до", а не с "де"

В данном случае AVC совершенно прав: я имел в виду именно JIT и аналогичные решения.

Да со слипу под вечер не рассмотрел.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

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

V>Кстати, у тебя там в первой ссылке какие-то нереальные результаты получились для VB6.
V>По моему опыту он отставал от С++ в обычных вычислениях примерно в 1.2-2 раза, но не в 10

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

В общем, исходники доступны. Скачай — погляди. Где-то там есть даже в 2 раза (вроде) хотя любому видившему порождаемый ВБ код в общем-то явсно почему он так отстает. Там на каждом шагу КОМ с тучей проверок и хэлпер-функций.

V>за исключением ситуаций:
V>- запуск из среды (это выполнение P-кода вместо компиляции в двоичный код)
V>- использование нетипизированных значений (VARIANT)
V>- забыли поставить ByVal для числового параметра
V>- стоит ByVal для строкового параметра или объектного параметра

Исходники доступны...

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

Я как бы не идиот и все это и сам понимаю. В режиме интерпретации там не 10 раз, а все 100. А оптимизация их мало что дает. Все что можно было включено.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

СГ>В модулях оберона находится, к Вашему сведению, не промежуточный код, а уже готовый к употреблению объектный код — машинные команды целевого процессора, быть может слегка разбавленные командами обращающимися к run-time системе (если таковая предусмотрена на данном конкретном оборудовании).

И зачем тогда оберону этот самый джит нужен?

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

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

AVC>Но в целом за пост спасибо. Он информативен и конкретен. Так и надо!

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

А ято до ткчтоы, то сравни как-нить на досуге qcort из CRT и sort из StlPort. Увидишь насколько С может отставать от С++.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

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

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

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

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

ПК>Напиши, пожалуйста.

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

Например, в BlackBox заходим в раздел хелпа под названием Platform-Specific Issues (Windows). Что мы там видим:

Module SYSTEM

Module SYSTEM contains certain procedures that are necessary to implement low-level operations. It is strongly recommended to restrict the use of these features to specific low-level modules, as such modules are inherently non-portable and usually unsafe. SYSTEM is not considered as part of the language Component Pascal proper.

The procedures contained in module SYSTEM are listed in the following table. v stands for a variable. x, y, and n stands for expressions. T stands for a type. P stands for a procedure. M[a] stands for memory value at address a.

Function procedures
    Name    Argument types    Result type    Description
    ADR(v)    any    INTEGER    address of variable v
    ADR(P)    P: PROCEDURE    INTEGER    address of Procedure P
    ADR(T)    T: a record type    INTEGER    address of Descriptor of T
    LSH(x, n)    x, n: integer type*    type of x    logical shift (n > 0: left, n < 0: right)
    ROT(x, n)    x, n: integer type*    type of x    rotation (n > 0: left, n < 0: right)
    TYP(v)    record type    INTEGER    type tag of record variable v
    VAL(T, x)    T, x: any type    T    x interpreted as of type T
    * integer types without LONGINT
Proper procedures
    Name    Argument types    Description
    GET(a, v)    a: INTEGER; v: any basic type,    v := M[a]
        pointer type, procedure type
    PUT(a, x)    a: INTEGER; x: any basic type,    M[a] := x
        pointer type, procedure type
    GETREG(n, v)    n: integer constant, v: any basic type,    v := Register n
        pointer type, procedure type
    PUTREG(n, x)    n: integer constant, x: any basic type,    Register n := x
        pointer type, procedure type
    MOVE(a0, a1, n)    a0, a1: INTEGER; n: integer type    M[a1..a1+n-1] := M[a0..a0+n-1]
The register numbers for PUTREG and GETREG are:
0: EAX, 1: ECX, 2: EDX, 3: EBX, 4: ESP, 5: EBP, 6: ESI, 7: EDI.

Warning
VAL, PUT, PUTREG, and MOVE may crash BlackBox and/or Windows when not used properly.
Never use VAL (or PUT or MOVE) to assign a value to a BlackBox pointer. Doing this would corrupt the garbage collector, with fatal consequences.

System Flags

The import of module SYSTEM allows to override some default behavior of the compiler by the usage of system flags. System flags are used to configure type- and procedure declarations. The extended syntax is given below.
Type     =    Qualident
        | ARRAY ["[" SysFlag "]"] [ConstExpr {"," ConstExpr}]
            OF Type 
        | RECORD ["[" SysFlag "]"] ["("Qualident")"] FieldList
            {";" FieldList} END
        | POINTER ["[" SysFlag "]"] TO Type
        | PROCEDURE [FormalPars].
ProcDecl    =    PROCEDURE ["[" SysFlag "]"] [Receiver] IdentDef
            [FormalPars] ";"
        DeclSeq [BEGIN StatementSeq] END ident.
FPSection    =    [VAR ["[" SysFlag "]"]] ident {"," ident} ":" Type.
SysFlag    =    ConstExpr | ident.
For SysFlags either the name of the flag or the corresponding numeric value can be used.

System flags for record types
Name    Value    Description
untagged    1    No type tag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        No type-bound procedures are allowed for the record.
        Pointers to untagged record type or extensions of this
        record type inherit the attribute of being untagged.
        The offsets of the fields are aligned to
        MIN(4-byte, size), where size is the size of the field.
        The size of the record and the offsets of the fields are
        aligned to 32-bit boundaries.
noalign    3    Same as untagged but without alignment.
align2    4    Same as untagged but with
        MIN(2-byte, size) alignment. 
align8    6    Same as untagged but with
        MIN(8-byte, size) alignment. 
union    7    Untagged record with all fields allocated at offset 0.
        The size of the record is equal to the size of the
        largest field.
        Used to emulate C union types.

System flags for array types
Name    Value    Description
untagged    1    No typetag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        Pointers to this array type inherit the attribute of
        being untagged.
        Only one-dimensional untagged open arrays
        are allowed.
        For open untagged arrays, index bounds are
        not checked.

System flags for pointer types
Name    Value    Description
untagged    1    Not traced by the garbage collector.
        No type-bound procedures are allowed for the pointer.
        Must point to an untagged record.

System flags for VAR parameters
Name    Value    Description
nil    1    NIL is accepted as formal parameter.
        Used in interfaces to C
        functions with pointer type parameters.

System flags for procedures
Name    Value    Description
code    1    Definition of a Code procedure (see below).
ccall    -10    Procedure uses CCall calling convention.
Code procedures

Code procedures make it possible to use special code sequences not generated by the compiler. They are declared using the following special syntax:
ProcDecl    =    PROCEDURE "[" SysFlag "]" IdentDef [FormalPars]
            [ConstExpr {"," ConstExpr}] ";".
The list of constants declared with the procedure is interpreted as a byte string and directly inserted in the code ("in-line") whenever the procedure is called. If a parameter list is supplied, the actual parameters are pushed on the stack from right to left. The first parameter however is kept in a register. If the type of the first parameter is REAL or SHORTREAL, it is stored in the top floating-point register. Otherwise the parameter (or in the case of a VAR/IN/OUT parameter its address) is loaded into EAX. For function procedures the result is also expected to be either in the top floating-point register or in EAX, depending on its type. Be careful when using registers in code procedures. In general, the registers ECX, EDX, ESI, and EDI may be used. Parameters on the stack must be removed by the procedure.

Examples
    PROCEDURE [code] Sqrt (x: REAL): REAL        (* Math.Sqrt *)
        0D9H, 0FAH;            (* FSQRT *)

    PROCEDURE [code] Erase (adr, words: INTEGER)    (* erase memory area *)
        089H, 0C7H,            (* MOV EDI, EAX *)
        031H, 0C0H,            (* XOR EAX, EAX *)
        059H,            (* POP ECX *)
        0F2H, 0ABH;            (* REP STOS *)

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

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

СГ>>В модулях оберона находится, к Вашему сведению, не промежуточный код, а уже готовый к употреблению объектный код — машинные команды целевого процессора, быть может слегка разбавленные командами обращающимися к run-time системе (если таковая предусмотрена на данном конкретном оборудовании).

VD>И зачем тогда оберону этот самый джит нужен?

Какой еще джит в Обероне????????????

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

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

A>>Меня все таки интересует обобщенная сортировка написанная с применением только тех возможностей Оберона, которые описаны в книге. В C, который OOP никакой особой поддержки не оказывает, это возможно.

СГ>Ну, хорошо, уговорили. Приводите пример исходного кода на Си, а я его постараюсь переписать на обероне.

Условие: применять только те возможности Оберона, что описаны в книге Вирта.

#include <stdio.h>

void swap( char * p, char * q, size_t size ) {
    char t;
    while ( size-- ) {
        t = *p;
        *p++ = *q;
        *q++ = t;
    }
}

void sort( void const * start,
           size_t num,
           size_t width,
           int ( *comp )( void const *, void const * ) ) {
    char * p, * max, * begin = ( char * ) start, * end = begin + num;

    while ( end != begin ) {
        max = ( char * ) start;
        for ( p = begin + width; p < end; p += width ) {
            if ( comp( p, max ) > 0 )
                max = p;
        }

        swap( p, end, width );
        end -= width;
    }
}

int int_comp( void const * a, void const * b ) {
    int const * ia = ( int const * ) a;
    int const * ib = ( int const * ) b;

    return *ia > *ib ? -1 : ( *ia < *ib ? 1 : 0 );
}

int main() {
    int arr[] = { 5, 7, 2, 1 };
    int size = sizeof( arr ) / sizeof( int );
    int i;

    sort( arr, size, sizeof( int ), int_comp );

    for ( i = 0; i < size; ++i )
        printf( "%d ", arr[ i ] );
}

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

A>Условие: применять только те возможности Оберона, что описаны в книге Вирта.

В Обероне нет адресной арифметики, поэтому написать предложенную Вами функцию нельзя.

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

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

A>>Условие: применять только те возможности Оберона, что описаны в книге Вирта.

СГ>В Обероне нет адресной арифметики, поэтому написать предложенную Вами функцию нельзя.

Какая жалость

Здравствуйте, alexeiz, Вы писали:
A>Какая жалость

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

GIV>Я не специалист в истории языков но как-то давно смотрел передачу Гордна посвященную этому вопросу. Так его гость (кто именно не помню) вполне убедительно (для меня) показывал методику по которой можно сравнить родство языков. АФАИР там учитывалось количество общих слов в языках (исключая заимствованные). И на этой основе делался вывод о близости (родственности) языков.

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

    *  be - быть,
    * nose - нос,
    * goose - гусь,
    * eat - есть,
    * brow - бровь,
    * crook - крюк,
    * beat - бить,
    * cheek - щека,
    * widow - вдова,
    * talk - толковать,
    * beard - борода,
    * stream - стремнина,
    * grab - грабить,
    * deal - дело,
    * pastor - пастух, пастор,
    * three - три,
    * dale - дол, долина,
    * stall - стойло.

Одни из самых древних — это, конечно, числительные. Из первых десяти явно совпадают 0, 1, 3, 5, 6, 7.

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

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

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

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

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

Язык неизменяющийся == язык умирающий

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

S>Не плачь — ты не первый, кто просил Сергея написать сортировку на Обероне. Вариант из С++ он тоже переписать не сумел.

Сортировку я написать на обероне могу. Но я не могу написать функцию оперирующую с адресами и размерами объектов. Адресов и размеров объектов в обероне нет, равно как нет адресного пространства как такового. Аналогично я не могу написать шаблонную сортировку, так как нету шаблонов.

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Сортировку я написать на обероне могу. Но я не могу написать функцию оперирующую с адресами и размерами объектов. Адресов и размеров объектов в обероне нет, равно как нет адресного пространства как такового. Аналогично я не могу написать шаблонную сортировку, так как нету шаблонов.
Ну то есть нет никакой возможности написать полиморфсную сортировку, так? Для каждого конкретного типа надо писать отдельную сортирующую функцию. Я правильно понял?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

S>Ну то есть нет никакой возможности написать полиморфсную сортировку, так? Для каждого конкретного типа надо писать отдельную сортирующую функцию. Я правильно понял?

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

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

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

S>>Ну то есть нет никакой возможности написать полиморфсную сортировку, так? Для каждого конкретного типа надо писать отдельную сортирующую функцию. Я правильно понял?

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

В Component Pascal есть ANYREC и соответсвующий ему ANYPTR — для них можно. В Active Oberon есть OBJECT — для него можно.

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

СГ>Какой еще джит в Обероне????????????

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

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

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

СГ>В Component Pascal есть ANYREC и соответсвующий ему ANYPTR — для них можно. В Active Oberon есть OBJECT — для него можно.

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

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

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

СГ>>В Component Pascal есть ANYREC и соответсвующий ему ANYPTR — для них можно. В Active Oberon есть OBJECT — для него можно.

Д>все равно, здесь будут обычные неприятные последствия такого метода — падение скорости на порядки, и плюс к этому вероятность поймать runtime-exception
Д>

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

Сергей Губанов,

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

Это сразу выводит нас за рамки моноязычной системы, что и было написано в давешнем сообщении:

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

на которое в качестве ответа я получил краткий эксурс в металловедение.

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

Posted via RSDN NNTP Server 1.9 gamma

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	04.11.04 08:33
Оценка:

	От:	AlexandrV
	Дата:	04.11.04 08:37
	Оценка:	+1

	От:	StanislavK
	Дата:	04.11.04 08:56
	Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	04.11.04 08:57
Оценка:	31 (3) +5

	От:	AlexandrV
	Дата:	04.11.04 08:58
	Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	04.11.04 09:09
Оценка:	1 (1)

	От:	Privalov
	Дата:	04.11.04 10:20
	Оценка:	20 (3) +2

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	04.11.04 11:17
Оценка:

	От:	Дарней
	Дата:	04.11.04 12:56
	Оценка:	20 (3) +3

	От:	AndreyFedotov
	Дата:	04.11.04 15:04
	Оценка:	9 (3) +5

	От:	AVC
	Дата:	05.11.04 11:06
	Оценка:	22 (4) +2 -2

	От:	TheBeard
	Дата:	05.11.04 11:23
	Оценка:	12 (1) +1 -1

	От:	Павел Кузнецов
	Дата:	05.11.04 19:49
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	06.11.04 10:18
Оценка:	+1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	08.11.04 17:26
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	09.11.04 00:16
Оценка:

	От:	Quintanar
	Дата:	09.11.04 10:06
	Оценка:	20 (2)

	От:	WolfHound
	Дата:	09.11.04 11:18
	Оценка:	7 (2) -1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.11.04 13:13
Оценка:	20 (2)

	От:	vdimas
	Дата:	10.11.04 00:21
	Оценка:	50 (4) +1

	От:	Зверёк Харьковский
	Дата:	10.11.04 13:24
	Оценка: