Oberon family
От: Кодт Россия  
Дата: 12.11.04 14:15
Оценка: 79 (12) +4 -1
В предыдущих дискуссиях постоянно идёт передёргивание — обсуждаем фичи то одного Оберона, то другого, то третьего (BlackBox, BlueBottle, конь в вакууме). Причём переходы с одного на другой рассогласовываются.
Только что обсуждали, скажем, что закрывать монопольно открытые файлы нужно — и опаньки, оказывается, это ВЫ про BlackBox говорите, а МЫ-то — про Оберон вообще (в котором нет такого понятия, как монопольно открытый файл).
Таких штучек можно насчитать достаточное количество.

О чём это говорит? О низкой культуре дискуссии? — И об этом тоже, конечно.
Но главное — о том, что нет Стандарта на язык.
Понимаете, это всё равно, что выдавать глюки BCB за дефекты С++ вообще. И потом до хрипоты спорить, есть ли вообще этот глюк (потому что комплект багофич дебилдера отличается от комплекта багофич иваси).

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

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



Вот такое у меня сложилось ИМХО.
Специалисты по Оберону (Оберонам?), поправьте если это не так.
Перекуём баги на фичи!
Re: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 15:21
Оценка: :)
Здравствуйте, Кодт, Вы писали:

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


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

Про то как были созданы самая первая ОС Оберон и самый первый язык Оберон:
Никлаус Вирт "Проектирование системы с нуля"
http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm
Re[2]: Oberon family
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 15:27
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


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


Имхо, Кодт хотел сказать, что нет реального стандарта, а есть просто число реализаций по сути схожих, а абсолюта аля ANSI/ISO C++ нету — это и есть причина хаоса

СГ>Про то как были созданы самая первая ОС Оберон и самый первый язык Оберон:

СГ>Никлаус Вирт "Проектирование системы с нуля"
СГ>http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm

Ну а вот это совсем тут не в тему (хоть и Вологда )
Re[3]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 15:51
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Имхо, Кодт хотел сказать, что нет реального стандарта, а есть просто число реализаций по сути схожих, а абсолюта аля ANSI/ISO C++ нету — это и есть причина хаоса



Разных оберонов много, на какой именно из них нужен стандарт? Oberon, Oberon-2, Active Oberon, Component Pascal, и т.д. и т.п. — совершенно разные языки. На каждый из них в отдельности можно завести стандарт, но на них все один стандарт — невозможно, они же разные.
Re[4]: Oberon family
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 15:55
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Имхо, Кодт хотел сказать, что нет реального стандарта, а есть просто число реализаций по сути схожих, а абсолюта аля ANSI/ISO C++ нету — это и есть причина хаоса



СГ>Разных оберонов много, на какой именно из них нужен стандарт? Oberon, Oberon-2, Active Oberon, Component Pascal, и т.д. и т.п. — совершенно разные языки. На каждый из них в отдельности можно завести стандарт, но на них все один стандарт — невозможно, они же разные.


Сергей, блин, ты читай, что тебе пишут — проблема в том, что нет стандарта, а есть просто сборище похожих языков, соответственно есть только чихарда и нет печки, от которой плясать можно.
Re: Oberon family
От: LaptevVV Россия  
Дата: 12.11.04 15:56
Оценка: 9 (2)
Здравствуйте, Кодт, Вы писали:

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


Я тут уже в одной из дискуссий OBERON??????????????????????? тоже так же отвечал, но уважаемые оппоненты совершенно не принимают этот довод.

К>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.
Да, конечно! Абсолютно так и есть! В книге Кенига и Му описание языка С на 15 страницах уместилось. Можно еще значительно короче написать. Но это ж только описание основной семантики языка.
А в стандарте ж прописаны масса технических деталей, которые не позволяют разночтений! И это ИМХО абсолютно правильно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Oberon family
От: AndreyFedotov Россия  
Дата: 12.11.04 16:00
Оценка: 6 (1) +2
Здравствуйте, Сергей Губанов, Вы писали:

Вы это многообразие назвали хаосом?

Во-первых: Такое же точно многообразие в других языках ты сам называешь хаосом
Во-вторых: Для того, что бы изучить Оберон для трёх систем потребуется прочесть книгу по бащовым возможностям оберон (80 страниц), книгу по объектным возможностям оберон (ещё 80 страниц), книгу по базовым библиотекам для данной системы (а это для хоть сколько-нибудь сложной системы — ещё минимум страниц 300), итого: примерно 400-500 страниц. И всё это ДЛЯ КАЖДОЙ системы — так как стандарта нет — то и изучать это придётся заного — в противном случае элементарно наделать ошибок в программе из-за отличия в клонах технологии. Итого для того что бы только-только разобраться с ЯЗЫКОМ — даже на с API Оберона для трёх платформ — потребуется прочесть 1200-1500 страниц. В то время, как для C++ для этого достаточно прочесть только 750 страниц — практически при любом количестве платформ. А если речь идёт о базовых возможностях, без деталей и тонкостей — то и того меньше — страниц 300. Примерно та же динамика для C# — правда он пока только на одной платформе. И как после этого можно говорить о преимуществах оберона или о его краткости?
Re[2]: Oberon family
От: Кодт Россия  
Дата: 12.11.04 16:20
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


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

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

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

Вот, например, язык Форт и Форт-системы. У них настолько простая идеология и настолько компактное ядро, что можно делать уникальные системы, как блины печь. По большому счёту, у Форта даже синтаксиса нет. Но зачем-то ещё в 1979 году рабочая группа FIG (forth interest group) родила стандарт Форт-системы.

Или ответвления UNIX, несовместимые между собой — в итоге привели к соглашению о кроссплатформенном API — POSIX.
Перекуём баги на фичи!
Re[2]: Oberon family
От: buriy Россия http://www.buriy.com/
Дата: 12.11.04 16:26
Оценка: +1 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Да, конечно! Абсолютно так и есть! В книге Кенига и Му описание языка С на 15 страницах уместилось. Можно еще значительно короче написать. Но это ж только описание основной семантики языка.


А вот эту книгу надо бы Вирту показать, чтобы он всякие свои супер-языки не придумывал
/bur
Re[3]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 16:37
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Во-вторых: Для того, что бы изучить Оберон для трёх систем


А зачем Вам 3 РАЗНЫХ системы? Программы между ними НЕПЕРЕНОСИМЫ, они на РАЗНЫХ языках. Это все равно что в качестве трех систем взять Windows, UNIX, Mac и пытаться их учить все сразу. Берите только какую-нибудь одну систему и изучайте.
Re[2]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 16:45
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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


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

LVV>
LVV>Я тут уже в одной из дискуссий OBERON??????????????????????? тоже так же отвечал, но уважаемые оппоненты совершенно не принимают этот довод.

Каждый конкретный оберон описывается своим Language Report. "Оберон" в этом смысле есть собирательное обозначение для всех этих РАЗНЫХ языков, для КАЖДОГО из них можно создать свой персональный СТАНДАРТ. А ОДНОГО стандарта НЕЛЬЗЯ — это все равно что на Си/Си++/C#/Java потребовать ОДИН стандарт.

Си/Си++/C#/Java — все разные. На каждый из них можно написать свой стандарт. Но на все эти 4 языка одного стандарта быть не может — разные они.

Абсолютно точно также: Oberon/Active Oberon/Component Pascal — это тоже РАЗНЫЕ абсолютно непереносимые друг в друга языки. Ну неужели не понятно? Какой еще единый стандарт???
Re[4]: Oberon family
От: Mamut Швеция http://dmitriid.com
Дата: 12.11.04 16:52
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


AF>>Во-вторых: Для того, что бы изучить Оберон для трёх систем


СГ>А зачем Вам 3 РАЗНЫХ системы? Программы между ними НЕПЕРЕНОСИМЫ, они на РАЗНЫХ языках. Это все равно что в качестве трех систем взять Windows, UNIX, Mac и пытаться их учить все сразу. Берите только какую-нибудь одну систему и изучайте.


Берете QT или wxWidgets в руки, изучаете С++ и получаете переносимую систему.
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is playing "Silence">>


dmitriid.comGitHubLinkedIn
Re[3]: Oberon family
От: LaptevVV Россия  
Дата: 12.11.04 16:55
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Си/Си++/C#/Java — все разные. На каждый из них можно написать свой стандарт. Но на все эти 4 языка одного стандарта быть не может — разные они.

Ну так на них и стандартвы разные
СГ>Абсолютно точно также: Oberon/Active Oberon/Component Pascal — это тоже РАЗНЫЕ абсолютно непереносимые друг в друга языки. Ну неужели не понятно? Какой еще единый стандарт???
Ну так хоть на один сделайте стандарт, а потом уж спорьте. Получится, уверяю вас, не менее 500 страниц — я это уже говорил.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Oberon family
От: Mamut Швеция http://dmitriid.com
Дата: 12.11.04 16:55
Оценка: 19 (2) +7
Тогда сорри, я не понял смысла всех предыдущих веток об Оберонах. Там, почти в каждом ответвлении было примерно такое:

Оппонент Оберона: "Покажите мне преимущества в том-то и том-то"
Защитник Оберона: "Ну вот, в Обероне-2 это можно, вот вам, например, код на Компонент Паскале"
ОО: "Это не решение, можно ли вот так..?"
ЗО: "Без проблем, вот еще Оберон делает так..."
ОО: "А как же вот это...?"
ЗО: "Вы мне тут не путайте Компонент Паскаль с Обероном. Я вам даже не Про Оберон-2 говорю, а про Актив Оберон"

Так о каком Обероне были все предыдущие ветки?
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is playing "Silence">>


dmitriid.comGitHubLinkedIn
Re[4]: Oberon family
От: Кодт Россия  
Дата: 12.11.04 17:05
Оценка: 8 (4) +7 :)
Здравствуйте, Сергей Губанов, Вы писали:

AF>>Во-вторых: Для того, что бы изучить Оберон для трёх систем


СГ>А зачем Вам 3 РАЗНЫХ системы? Программы между ними НЕПЕРЕНОСИМЫ, они на РАЗНЫХ языках. Это все равно что в качестве трех систем взять Windows, UNIX, Mac и пытаться их учить все сразу. Берите только какую-нибудь одну систему и изучайте.


Беру язык С++, какой-нибудь кроссплатформенный компилятор (например, GCC), документацию по POSIX и какому-нибудь кроссплатформенному оконному фреймворку (например, Zinc, мать его за ногу, повбывав бы!).
Всё! Я готов программировать хоть под Мак, хоть под Коноплю.

Или беру язык Fortran-77, и пишу математическую библиотеку. Которой смогут пользоваться по всему миру на любой платформе — от IBM 360 до IBM PC.
Это — потому что стандарт.
Перекуём баги на фичи!
Re[4]: Oberon family
От: Кодт Россия  
Дата: 12.11.04 17:14
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Оппонент Оберона: "Покажите мне преимущества в том-то и том-то"

M>Защитник Оберона: "Ну вот, в Обероне-2 это можно, вот вам, например, код на Компонент Паскале"
M>ОО: "Это не решение, можно ли вот так..?"
M>ЗО: "Без проблем, вот еще Оберон делает так..."
M>ОО: "А как же вот это...?"
M>ЗО: "Вы мне тут не путайте Компонент Паскаль с Обероном. Я вам даже не Про Оберон-2 говорю, а про Актив Оберон"

Во-во. Это я про качество дискуссии. И самая засада, что невозможно сконцентрироваться. Это всё равно, что о языках семейства Си говорить.
А их, блин, не меньше чем Оберонов!

C K&R
C для разных микроконтроллеров (как правило, на основе K&R)
C90
C99
Objective C (жутковатая помесь Си со Смолтоком)
C++ (первая редакция языка, где не было всяких разных фич)
C++ (вторая редакция — современная)
Java
JavaScript
Tcl
Csh
D
C#
Кого ещё забыл?
Перекуём баги на фичи!
Re[3]: Oberon family
От: GlebZ Россия  
Дата: 12.11.04 17:16
Оценка:
Здравствуйте, Кодт, Вы писали:

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


К>От платформы к платформе язык меняться не должен! И базовые библиотеки — тоже не должны. Всё, что специфично для данной платформы, идёт как добавка.

К>Иначе не решить вопросы повторного использования кода — и даже повторного использования опыта!
+1

К>Вот, например, язык Форт и Форт-системы. У них настолько простая идеология и настолько компактное ядро, что можно делать уникальные системы, как блины печь. По большому счёту, у Форта даже синтаксиса нет. Но зачем-то ещё в 1979 году рабочая группа FIG (forth interest group) родила стандарт Форт-системы.

Опаньки, что то я не поял. А собственно не синтаксис форта и является его идеологией и позволяет построить компактное и эффективное ядро? А спецификация была на мотив Oberon, короткая. Только его идеология, к сожалению, сильно устарела. Ее в основном можно сравнивать только с языками существующими в 79 году.

Если глупость срубил, извини. Фанател от форта давным-давно.

С уважением, Gleb.
Re[5]: Oberon family
От: Mamut Швеция http://dmitriid.com
Дата: 12.11.04 17:23
Оценка:
Хороший списочек

К>Кого ещё забыл?


PHP Хотя они от Явы отталкиваются, но все туда же

Ну и если вспомнили JavaScript, то все скриптовые языки, основанные на ECMAScript (какой-нибудь ActionScript от Macromedia). Да, еще Lua есть.
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is playing "Silence">>


dmitriid.comGitHubLinkedIn
Re: Мой молоток самый красный - мой ответ на эту демагогию
От: peterbes Россия  
Дата: 12.11.04 17:39
Оценка: 62 (4) +2
Здравствуйте, Кодт, Вы писали:

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

зы вменяемые люди голосуют ногами а не глоткой
Re[4]: Oberon family
От: Кодт Россия  
Дата: 12.11.04 17:45
Оценка:
Здравствуйте, GlebZ, Вы писали:

К>>Вот, например, язык Форт и Форт-системы. У них настолько простая идеология и настолько компактное ядро, что можно делать уникальные системы, как блины печь. По большому счёту, у Форта даже синтаксиса нет. Но зачем-то ещё в 1979 году рабочая группа FIG (forth interest group) родила стандарт Форт-системы.

GZ>Опаньки, что то я не поял. А собственно не синтаксис форта и является его идеологией и позволяет построить компактное и эффективное ядро? А спецификация была на мотив Oberon, короткая. Только его идеология, к сожалению, сильно устарела. Ее в основном можно сравнивать только с языками существующими в 79 году.

GZ>Если глупость срубил, извини. Фанател от форта давным-давно.


Ха! Весь синтаксис форта сводится к тому, что пробел, как правило, является разделителем. Весь лексический анализ сводится к тому, чтобы прочитать входной поток до разделителя. Например,
." hello world!..." 123
  |               ||
  |               |+-- третий разделитель дефолтный
  |               +-- второй разделитель - заявлен командой ." (печать текста)
  +-- первый разделитель дефолтный

Ну в общем, да, синтаксис входит в идеологию.
Перекуём баги на фичи!
Re[2]: Мой молоток самый красный - мой ответ на эту демагоги
От: GlebZ Россия  
Дата: 12.11.04 18:48
Оценка:
Здравствуйте, peterbes, Вы писали:

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


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

P>Оставте вы в покое, оберон и васик вкупе с асмом и машинными кодами, люди будут выбирать тот язык который им в настоящий момент удобен.
P>Хотите с Виртами на равных общаться — гоните свою философию. Эпигоны под ваши гениальные теории язык сбацают, десяток энтузиастов язык соорудят, а потом полмиллиона программеров будут головой об стенку колотиться и кричать — "Аццтой", но все же надеюсь что не все.
Если бы не было этих десятков энтузиастов, то мы бы так и делали каменные топоры и ходили бы в шкурах.
А если бы небыло полмиллиона программеров, которые колотятся о стенку рабочим инструментом и кричат "Аццтой" или наоборот, я бы со скуки сдох. Или спился бы. Скушно среди кодировщиков которые строем ходят.

P>зы вменяемые люди голосуют ногами а не глоткой

Безусловное право каждого человека. Точно так же как и безусловное право каждого человека читать данные флеймы.

С уважением, Gleb.
Re[5]: Oberon family
От: Зверёк Харьковский  
Дата: 12.11.04 20:06
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Кого ещё забыл?

Перлушку! Родимого!
сам слушаю и вам рекомендую: 06 — We Use The Pain
FAQ — це мiй ай-кью!
Re: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 21:26
Оценка: 4 (2) +1
Здравствуйте, Кодт, Вы писали:

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


Ага. Особенно об этом говорит постоянное упоменание в нем неопределенного поведения.

С++ занимает так много места так как язык перепичкан фичами друг с другом плохо согласованных. Виной тому наследие С и нежелание Страуструпа менять язык.

Стандат Шарпа проработан куда лучше, но размер он имеет даже меньший.

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

К>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.


Это всего лишь инсинуация Оберонщиков. Описание языка занимает десятки и сотни страниц. Пару страниц занимает формальная граматика. Вот только она вряд ли может быть описанием языка.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Oberon family
От: Трурль  
Дата: 15.11.04 07:24
Оценка: +1
Здравствуйте, Кодт, Вы писали:

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


К>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.

В приличном обществе подобные утверждения, как правило, аргументируются. Вот, мол, так и так в этом места описание Оберона допускает разночтения, а в C++ смотрите как все четко прописано. (Это о культуре дискуссии, а не по существу, даже в стандарте Ады имеются неоднозначности.)
Re[3]: Oberon family
От: Трурль  
Дата: 15.11.04 07:55
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Для того, что бы изучить Оберон для трёх систем потребуется прочесть книгу по бащовым возможностям оберон (80 страниц), книгу по объектным возможностям оберон (ещё 80 страниц), книгу по базовым библиотекам для данной системы (а это для хоть сколько-нибудь сложной системы — ещё минимум страниц 300), итого: примерно 400-500 страниц. И всё это ДЛЯ КАЖДОЙ системы — так как стандарта нет — то и изучать это придётся заного — в противном случае элементарно наделать ошибок в программе из-за отличия в клонах технологии. Итого для того что бы только-только разобраться с ЯЗЫКОМ — даже на с API Оберона для трёх платформ — потребуется прочесть 1200-1500 страниц. В то время, как для C++ для этого достаточно прочесть только 750 страниц — практически при любом количестве платформ. А если речь идёт о базовых возможностях, без деталей и тонкостей — то и того меньше — страниц 300.


Для того, что бы разобраться с языком достаточно прочитать "сообщение о языке". Это 18 страниц для Оберона, 25 для Оберона-2, 35 для Component Pascal.
Re[4]: Oberon family
От: Privalov  
Дата: 15.11.04 09:12
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Для того, что бы разобраться с языком достаточно прочитать "сообщение о языке". Это 18 страниц для Оберона, 25 для Оберона-2, 35 для Component Pascal.



А я почему-то думал, что нужно пару-тройку стандартных алгоритмов попробовать сделать, основываясь, разумеется, на "сообщении".
Re[2]: Oberon family
От: AndreyFedotov Россия  
Дата: 15.11.04 11:33
Оценка:
Здравствуйте, Трурль, Вы писали:

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


К>>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.

Т>В приличном обществе подобные утверждения, как правило, аргументируются. Вот, мол, так и так в этом места описание Оберона допускает разночтения, а в C++ смотрите как все четко прописано. (Это о культуре дискуссии, а не по существу, даже в стандарте Ады имеются неоднозначности.)

Хорошо. Составь описание языка уровня Оберона или Паскаля, на пару страниц — так, что бы оно было полным и не допкскало разночтений. Сумеешь — мы не только примем твои аргументы, но и будем поклоняться как СГ — Оберону и пророку его — Вирту...
Re[2]: Oberon family
От: bkat  
Дата: 15.11.04 12:39
Оценка: +1
Здравствуйте, Трурль, Вы писали:

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


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


К>>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.

Т>В приличном обществе подобные утверждения, как правило, аргументируются. Вот, мол, так и так в этом места описание Оберона допускает разночтения, а в C++ смотрите как все четко прописано. (Это о культуре дискуссии, а не по существу, даже в стандарте Ады имеются неоднозначности.)

Ты слишком много хочешь от форума
Подобные дискуссии могут сподвигнуть кого-то на написание такого труда,
но тут на форуме этого ожидать не стоит.
Re[3]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 15.11.04 15:32
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Трурль, Вы писали:


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


К>>>А описание Оберона, уместившееся на пару страниц, как раз и обеспечивает такой хаос в реализациях.

Т>>В приличном обществе подобные утверждения, как правило, аргументируются. Вот, мол, так и так в этом места описание Оберона допускает разночтения, а в C++ смотрите как все четко прописано. (Это о культуре дискуссии, а не по существу, даже в стандарте Ады имеются неоднозначности.)

AF> Хорошо. Составь описание языка уровня Оберона или Паскаля, на пару страниц — так, что бы оно было полным и не допкскало разночтений. Сумеешь — мы не только примем твои аргументы, но и будем поклоняться как СГ — Оберону и пророку его — Вирту...


Еще раз: Одну-две страницы занимает не описание языка, а описание синтаксиса. Описание языка занимает 20-40 страниц. Ссылки на эти описания многократно приводились:

Component Pascal (перевод на русский язык) http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm

Oberon-2 (перевод на русский язык) http://www.uni-vologda.ac.ru/oberon/o2rus.htm

Language Report's нескольких других оберонов (на английском языке): http://www.oberon.ethz.ch/compiler/index.html#report
Re[4]: Oberon family
От: Кодт Россия  
Дата: 15.11.04 16:28
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Еще раз: Одну-две страницы занимает не описание языка, а описание синтаксиса. Описание языка занимает 20-40 страниц. Ссылки на эти описания многократно приводились:


СГ>Component Pascal (перевод на русский язык) http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm


СГ>Oberon-2 (перевод на русский язык) http://www.uni-vologda.ac.ru/oberon/o2rus.htm


СГ>Language Report's нескольких других оберонов (на английском языке): http://www.oberon.ethz.ch/compiler/index.html#report


Спасибо.

Сергей, а ты можешь взять на себя труд — составить (или дать ссылки на) перечень расхождений между Oberon, Oberon-2, Component Pascal, а также воплощениями — BlackBox, BlueBottle и т.д.?
Чтобы, во-первых, народ был в курсе, а во-вторых, можно было говорить в едином смысловом пространстве — а не в множестве языков, породнённых близким синтаксисом.
Перекуём баги на фичи!
Re[2]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.11.04 20:29
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>В приличном обществе подобные утверждения, как правило, аргументируются. Вот, мол, так и так в этом места описание Оберона допускает разночтения, а в C++ смотрите как все четко прописано. (Это о культуре дискуссии, а не по существу, даже в стандарте Ады имеются неоднозначности.)


Да все очено просто. Спецификация Оберона стройна и проста. Одна тлолько проблема есть. Она не совместима с жизнью. По этому все реализации Оберона тут же начинают дорабатывать эту спецификацию вводя те или иные фичи. Так же в ней просто не описано много разных нюансов реализации на конкретных платформах. В итоге получается куча похожих языков с общим предком, но разными реализациями.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Oberon family
От: Dervish Россия http://www.dervish.ru
Дата: 16.11.04 00:27
Оценка: 1 (1) :)))
Здравствуйте, Кодт, Вы писали:

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


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


Сорри за офтопик, но мне хотелось бы привести пример ещё одного стандарта. Он существенно отличается и от стандарта С++ и от стандарта Оберона, возможно, кому-то он покажется интересным.

Дома в архивах у меня где-то валяется книжка под названием "Пересмотренное сообщение об Алголе-68". Это полупереводная книга, на каждом развороте одна страница приведена в языке оригинала, по английски, а вторая — по русски, переведена.

Друзья, читать это просто невозможно! Впрочем, вы можете посмотреть сами, я нашёл эту книгу в интернете. Начинать лучше с оглавления.

Могу сразу сказать, что нулевую главу можно не смотреть. Там всё относительно просто. Самое интересное начинается в последующих главах. Например:

3. Clauses
5. Units
7. Modes and nests

Самое интересное, каждое слово в отдельности понимаю. А когда начинаю объединять в предложения, смысл теряется.

Водка "Табуретовка". Почувствуйте себя Буратиной!

В общем, приятного просмотра.
... << RSDN@Home 1.1.4 beta 3 rev. 219>>
Re[5]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 16.11.04 08:38
Оценка: 21 (2)
Здравствуйте, Кодт, Вы писали:

К>Сергей, а ты можешь взять на себя труд — составить (или дать ссылки на) перечень расхождений между Oberon, Oberon-2, Component Pascal, а также воплощениями — BlackBox, BlueBottle и т.д.?

К>Чтобы, во-первых, народ был в курсе, а во-вторых, можно было говорить в едином смысловом пространстве — а не в множестве языков, породнённых близким синтаксисом.

Несколько ссылок могу дать, а сам написать — тоже могу, но только когда это произойдет, я пока сам не знаю.

"Различия между языками Oberon и Oberon-2" Ханспетер Мессенбок, Никлаус Вирт (1995)
http://www.uni-vologda.ac.ru/oberon/infoart/differ.htm


"От Модулы к Оберону" Никлаус Вирт
http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

"Отличия Компонентного Паскаля от Паскаля" Из документации к системе BlackBox, приложение В;
http://www.inr.ac.ru/~info21/cpascal/otliqija_cp_ot_pascal.htm
Re[2]: Oberon family
От: Трурль  
Дата: 16.11.04 10:28
Оценка: :)
Здравствуйте, Dervish, Вы писали:

D>Дома в архивах у меня где-то валяется книжка под названием "Пересмотренное сообщение об Алголе-68". Это полупереводная книга, на каждом развороте одна страница приведена в языке оригинала, по английски, а вторая — по русски, переведена.


D>Друзья, читать это просто невозможно!


Насколько я помню, вполне ничего себе книжечка. Читается посложнее чем "Основы математического анализа", но полегче чем "Введение в теорию категорий и функторов"
Re[6]: Oberon family
От: Кодт Россия  
Дата: 16.11.04 16:05
Оценка: 9 (2) +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>"Различия между языками Oberon и Oberon-2" Ханспетер Мессенбок, Никлаус Вирт (1995)

СГ>http://www.uni-vologda.ac.ru/oberon/infoart/differ.htm

Подход к реализации методов:
1) они вынесены за пределы объявления типа — избавляемся от концепции класса — спорно, но интересно
2) выглядят как инфиксная нотация — симпатичный синтаксический ход
3) обязательный полиморфизм — ну есть и есть, бог с ним.
Однако...

Цитата:

К тому же такой подход четко следует духу Oberon’а — избегать любых скрытых механизмов.

(касается того, что левый операнд явно именуется, а доступ к его членам квалифицируется).

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

Допустим, у нас есть тип Base и наследник Derived, и ассоциированный с ними перекрытый метод Method.

1) проблема с загрузкой.
2) сложности в реализации и стоимость виртуального вызова



1)
Раскидаем работу с ними по разным модулям
MODULE TestBaseType;

TYPE Base = POINTER TO BaseBody;
     BaseBody = RECORD ... END;

(**************************************)

MODULE TestDerivedType;

IMPORT TestBaseType;

TYPE Derived = POINTER TO DerivedBody;
     DerivedBody = RECORD(TestBaseType.BaseBody) ... END;

(**************************************)

MODULE TestBaseMethod;

IMPORT TestBaseType;

PROCEDURE (obj: Base) Method* () BEGIN ... END;

(**************************************)

MODULE TestDerivedMethod;

IMPORT TestDerivedType;

PROCEDURE (obj: Derived) Method* () BEGIN ... END;

(**************************************)

MODULE TestCreateObject;

IMPORT TestBaseType, TestDerivedType;

PROCEDURE Create(): Base BEGIN Create := NEW Derived; END;

(**************************************)

MODULE TestPlayObject;

IMPORT TestBaseType, TestCreateObject;
(* какие из модулей Test???Method нужно импортировать? *)
(* вероятно, TestBaseMethod, ведь мы не знаем здесь о существовании Derived *)
IMPORT TestBaseMethod;

PROCEDURE Play*
VAR obj: TestBaseType.Base;
BEGIN
  obj = TestCreateObject.Create();
  obj.Method();
END;

Поскольку модуль TestDerivedMethod в явном виде нам нигде не потребовался, то рантайм может просто не догадаться его подцепить, и мы вызовем TestBaseMethod.Method.



2)
Вызывая object.Method(...), мы так или иначе должны выполнить поиск наиболее подходящего, на основе динамического типа object.

Можно сказать так, что в программе есть функция
Invoke: (dynamic_type,method_id) -> implementation

В большинстве ООП-языков эту функцию декомпозируют, вводя таблицы виртуальных функций как принадлежности динамического типа (класса или даже отдельных объектов).
Vmt: {static_type,} dynamic_type -> (method_id->implementation)
Invoke(t,m) = Vmt(t)(m)

Хотя можно и по-другому:
Slot: {static_type,} method_id -> (dynamic_type->implementation)
Invoke(t,m) = Slot(m)(t)

По всей видимости, это больше подходит для Оберона, т.к. в точке определения (Object)Method известно всё необходимое, чтобы создать такой слот.
И всё упирается лишь в то, чтобы этот метод попал ещё и в слоты (Parent)Method, (GrandParent)Method и т.д. — то есть то, о чём я написал под номером (1).

Теперь посмотрим на накладные расходы.

С помощью Vmt — мы получаем таблицу за O(1), поскольку это принадлежность динамического типа данного объекта.
Далее получаем конкретный метод за O(1) | O(log N_methods) | O(N_methods) — выполняя поиск в таблице (по индексу либо по имени — например, в скриптовых языках или дисп-интерфейсе).

С помощью Slot — за O(1) мы получаем эту таблицу. А дальше — самое интересное...
Пронумеровать типы мы не можем (хотя бы потому, что верхняя граница неизвестна), так что поиск по индексу отпадает.
Двоичный поиск тоже, похоже, не пройдёт (тут надо подумать, но скорее всего, никак: в дереве наследования проблематично вводить порядок).
Остаётся линейный поиск, причём не сравнения, а проверки dynamic_cast: можно ли привести тип объекта к типу, заявленному в очередной записи таблицы.
Перекуём баги на фичи!
Re[7]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 16.11.04 16:25
Оценка:
Здравствуйте, Кодт, Вы писали:

К>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?


Ответ простой — нет нельзя. Определение типа и связанных с этим типом процедур задается внутри одного и того же модуля.
Re[8]: Oberon family
От: Кодт Россия  
Дата: 16.11.04 17:11
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?


СГ>Ответ простой — нет нельзя. Определение типа и связанных с этим типом процедур задается внутри одного и того же модуля.


То есть, фактически, тип = это определение его структуры + определение ассоциированных процедур. И всё определение целиком должно умещаться в один модуль.

Процедуры, привязанные к типу, могут быть объявлены в произвольном порядке. Их можно даже перемежать процедурами, привязанными к другому типу. В языке Object Oberon, где все методы должны быть объявлены внутри соответствующего объявления класса, обнаружилось, что косвенная рекурсия между методами различных классов может поставить в затруднительное положение предварительные описания целых классов.

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

По большому счёту, новых проблем это создавать не должно: ведь компилятор должен разруливать перекрёстные связи между несколькими определениями функций, идущих подряд. Здесь задача примерно того же рода. И, например, компиляторы C++, Java, C# с ней справляются.
Например, выполняют два прохода — сперва собирают объявления типов и сигнатуры процедур, а затем обслуживают определения процедур.

Или же имеется в виду нечто иное?
Перекуём баги на фичи!
Re[9]: Oberon family
От: Трурль  
Дата: 17.11.04 06:27
Оценка:
Здравствуйте, Кодт, Вы писали:

К>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?


У меня тоже возникал такой вопрос. Интересный язык получился бы.


К>

К>Процедуры, привязанные к типу, могут быть объявлены в произвольном порядке. Их можно даже перемежать процедурами, привязанными к другому типу. В языке Object Oberon, где все методы должны быть объявлены внутри соответствующего объявления класса, обнаружилось, что косвенная рекурсия между методами различных классов может поставить в затруднительное положение предварительные описания целых классов.

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

К>По большому счёту, новых проблем это создавать не должно: ведь компилятор должен разруливать перекрёстные связи между несколькими определениями функций, идущих подряд. Здесь задача примерно того же рода. И, например, компиляторы C++, Java, C# с ней справляются.

К>Например, выполняют два прохода — сперва собирают объявления типов и сигнатуры процедур, а затем обслуживают определения процедур.

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

К>Или же имеется в виду нечто иное?

Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.
Re[10]: Oberon family
От: Кодт Россия  
Дата: 17.11.04 11:29
Оценка:
Здравствуйте, Трурль, Вы писали:

К>>

К>>Процедуры, привязанные к типу, могут быть объявлены в произвольном порядке. Их можно даже перемежать процедурами, привязанными к другому типу. В языке Object Oberon, где все методы должны быть объявлены внутри соответствующего объявления класса, обнаружилось, что косвенная рекурсия между методами различных классов может поставить в затруднительное положение предварительные описания целых классов.

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

К>>По большому счёту, новых проблем это создавать не должно: ведь компилятор должен разруливать перекрёстные связи между несколькими определениями функций, идущих подряд. Здесь задача примерно того же рода. И, например, компиляторы C++, Java, C# с ней справляются.

К>>Например, выполняют два прохода — сперва собирают объявления типов и сигнатуры процедур, а затем обслуживают определения процедур.

Т>В Обероне, как и в его предшественниках, все имена должны объявляться до использования. Это сделано для того, чтобы можно было написать однопроходный (и быстрый) компилятор. Современные компиляторы в большинстве своем многопроходные, но ограничение осталось.


К>>Или же имеется в виду нечто иное?

Т>Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.

Решения:
— многопроходный компилятор
— разнести объявление и определение методов.

Обращу внимание на цитату из "Различия между языками Oberon и Oberon-2"

Мы также отказались от дублирования в самой записи заголовков типизированных процедур, как это сделано в других языках типа C++ и Object Pascal. Это позволяет сохранить записи короткими и избежать избыточности описаний. Ведь изменение в заголовке тогда повлекло бы за собой корректировку в двух разных местах программы, к тому же компилятору пришлось бы еще и проверять идентичность обоих заголовков. Если программист захочет увидеть конкретную запись со всеми связанными с ней процедурами, то он может для получения информации на экране или на листе бумаги воспользоваться специальным инструментом, который называется навигатор модулей (browser).

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

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

Впрочем, какой-нибудь инструмент проектирования, например, Rational Rose или Telelogic UML Suite, всё равно родит болванку кода, выглядящую примерно так:
MODULE SomeMyModule;

(* forward declarations of classes *)
TYPE
  Foo = POINTER TO FooDesc;
  Bar = POINTER TO BarDesc;

(* declaration of class Foo and its methods *)
TYPE
  FooDesc = RECORD ... END;
PROCEDURE^ (this: Foo) foo* ();
PROCEDURE^ (this: Foo) bar* ();

(* declaration of class Bar and its methods *)
TYPE
  BarDesc = RECORD ... END;
PROCEDURE^ (this: Bar) xyz* ();
PROCEDURE^ (this: Bar) tuv* ();

(* declaration of global procedures *)
PROCEDURE^ test* (a: Foo, b: Bar);

(* implementation of procedures *)

(* methods of Foo *)
PROCEDURE (this: Foo) foo* () BEGIN (* TODO: code goes here *) END foo;
PROCEDURE (this: Foo) bar* () BEGIN (* TODO: code goes here *) END bar;

(* methods of Bar *)
PROCEDURE^ (this: Bar) xyz* () BEGIN (* TODO: code goes here *) END xyz;
PROCEDURE^ (this: Bar) tuv* () BEGIN (* TODO: code goes here *) END tuv;

(* global procedures *)
PROCEDURE^ test* (a: Foo, b: Bar) BEGIN (* TODO: code goes here *) END test;

BEGIN
 (* TODO: module startup code goes here *)
END SomeMyModule;
Перекуём баги на фичи!
Re[11]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 17.11.04 13:40
Оценка: :)
Здравствуйте, Кодт, Вы писали:

К>Здесь есть неувязка. Если две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении.


Перекрестные ссылки встречаются редко.
Re[10]: Oberon family
От: Кодт Россия  
Дата: 17.11.04 14:53
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.


Достаточно делать пред-объявление класса как, например, в С++.
Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.
Таким пред-объявлением является объявление типа указателя.
Так что можно было и объявления методов запихать в объявление класса.

Впрочем, дело вкуса.
Мне, понятное дело, больше нравится С++, в котором определение метода можно как внутрь запихать, так и наружу вынести (в отличие от Java|C# — где только внутрь, или от Oberon, где только наружу).
Но такие вещи решаются с помощью интеллектуального редактора или препроцессора. Например (благо, синтаксис лёгкий), за один проход перловый скрипт вытаскивает все указательные типы и прототипы процедур и пишет их объявления в начале файла, сразу после импорта. Тогда программист вообще может расслабиться
Перекуём баги на фичи!
Re[5]: Oberon family
От: _wqwa США  
Дата: 17.11.04 16:51
Оценка:
Здравствуйте, Кодт, Вы писали:

К>C K&R

К>C для разных микроконтроллеров (как правило, на основе K&R)
К>C90
К>C99
К>Objective C (жутковатая помесь Си со Смолтоком)
К>C++ (первая редакция языка, где не было всяких разных фич)
К>C++ (вторая редакция — современная)
К>Java
К>JavaScript
К>Tcl
К>Csh
К>D
К>C#
Ну, тикль с шелл-скриптом по моему, ты зря упомянул. Далековато они находятся от остальных перечисленных...
К>Кого ещё забыл?

Sphinx C-- ?
... << RSDN@Home 1.1.3 stable >>
Кто здесь?!
Re[10]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.04 21:53
Оценка:
Здравствуйте, Трурль, Вы писали:

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


К>>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?


Т>У меня тоже возникал такой вопрос. Интересный язык получился бы.


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

К>>Например, выполняют два прохода — сперва собирают объявления типов и сигнатуры процедур, а затем обслуживают определения процедур.


Т>В Обероне, как и в его предшественниках, все имена должны объявляться до использования. Это сделано для того, чтобы можно было написать однопроходный (и быстрый) компилятор. Современные компиляторы в большинстве своем многопроходные, но ограничение осталось.



Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла. Это проблемы давно ушедших времен когда все данные проекта нельзя было разместить в оперативке. На сегодня 99% компиляторов строит AST или триадный код и уже на базе него отрабатывает нужные сематические правила.

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

У того же Шарпа данное ограничение (предекларация) отсуствует, а компилятор получается очень быстрый. С++ тоже был бы быстрый если бы был модульным и не имел столь сложного препроцессора.

К>>Или же имеется в виду нечто иное?

Т>Здесь, действительно, нечто иное. Пусть метод класса A вызывает метод класса B, а тот в свою очередь вызывает метод класса A. Тогда класс A должен быть описан до B, а B до A.

Примитивиская логика. Вот рпимер на Шарпе:
class A
{
    void f1(B b)
    {
        b.f2(this);
    }
    
    void f3() {}
}

class B
{
    void f2(A a)
    {
        a.f3();
    }
}


Все компилируется без каких либо предеклараций и со скоростью звука. Так что примитивизм не необходим.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.04 21:53
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здесь есть неувязка. Если две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении.


Почему должен? И почему в Яве, Шарпе и ВБ все работает без предеклараций?

К>Почему для обычных процедур мы считаем это нормальным, а для методов — нет?


Я не считаю. По мне так любое дублирование вредно и излишне.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.04 21:53
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.


Почему?
class A
{
    B _b;
}

class B
{
    A _a;
}


Подсунь этот код Шарпу или Яве и убедись, что пролем не возникнет.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Oberon family
От: Трурль  
Дата: 18.11.04 06:05
Оценка:
Здравствуйте, VladD2, Вы писали:


Т>>В Обероне, как и в его предшественниках, все имена должны объявляться до использования. Это сделано для того, чтобы можно было написать однопроходный (и быстрый) компилятор. Современные компиляторы в большинстве своем многопроходные, но ограничение осталось.



VD>Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла.

Вообще-то обход синтаксического дерева тоже называют проходом.
Re[11]: Oberon family
От: Трурль  
Дата: 18.11.04 06:12
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Решения:

К>- многопроходный компилятор
Это по-моему оптимально, но авторам, видимо, хотелось оставить возможность делать однопроходные компиляторы.
К>- разнести объявление и определение методов.
Тогда бы язык получился несовместимым с Обероном.
Re[12]: Oberon family
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 18.11.04 08:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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


К>>Кстати, а что будет, если перекрёстное использование не на уровне методов, а на уровне структур данных? Тут без пред-объявления не обойтись.


VD>Почему?

VD>
VD>class A
VD>{
VD>    B _b;
VD>}

VD>class B
VD>{
VD>    A _a;
VD>}
VD>


VD>Подсунь этот код Шарпу или Яве и убедись, что пролем не возникнет.


Аналогичный код:
TYPE
  A = POINTER TO RECORD 
    b: B;
  END;

  B = POINTER TO RECORD 
    a: A;
  END;

можно подсунуть Блэкбоксу, там тоже никаких проблем не будет.

В данном случае речь идет о процедурах:

MODULE M1;

TYPE
  A = POINTER TO RECORD 
    b: B;
  END;

  B = POINTER TO RECORD 
    a: A;
  END;


(* Предварительное "^" объявление процедуры Bbb() связанной с типом B *)
PROCEDURE^ (t: B) Bbb (), NEW;



(* Объявление и Определение процедуры Aaa() связанной с типом A *)
PROCEDURE(t: A) Aaa (), NEW;
BEGIN
  t.b.Bbb(); (* <--- Вызов объявленной выше, но еще не определенной процедуры Bbb() *)
END Aaa;



(* Определение объявленной ранее процедуры Bbb() связанной с типом B *)
PROCEDURE(t: B) Bbb(), NEW;
BEGIN
  t.a.Aaa();
END Bbb;


END M1.



Да, конечно, предварительное объявление процедуры
PROCEDURE^ (t: B) Bbb (), NEW;

приводит к дублированию кода, которое так напрягает... Но, как я уже писал ранее, перекрестный вызов процедур случается редко. Влом что ли пару раз на всю программу написать предварительное определение? Можете привести реальные примеры когда Вы сами пользовались перекрестными вызовами процедур?
Re[11]: Oberon family
От: Кодт Россия  
Дата: 18.11.04 11:00
Оценка:
Здравствуйте, VladD2, Вы писали:

К>>>У меня сразу же возникает вопрос: а можно ли определять ассоциированную процедуру в другом модуле?


Т>>У меня тоже возникал такой вопрос. Интересный язык получился бы.


VD>Незнаю о том ли ты, но в Руби есть так называемые синглтон-методы. Позволяют переопределять методы у конкретных экземпляров.


Тут речь не о перегрузке у экземпляров, а о том, что полиморфные методы можно определять независимо от классов.
С синтаксической точки зрения, от инфиксной нотации obj.method(args) можно перейти к префиксной method(obj, args).
В принципе, эта задача известна — она возникает, например, при создании мультиметодов без помощи двойной диспетчеризации.
Тут получается вырожденный случай мультиметода — от одного полиморфного аргумента.
Перекуём баги на фичи!
Re[12]: Oberon family
От: Кодт Россия  
Дата: 18.11.04 11:02
Оценка:
Здравствуйте, VladD2, Вы писали:

К>>Здесь есть неувязка. Если две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении.


VD>Почему должен? И почему в Яве, Шарпе и ВБ все работает без предеклараций?


К>>Почему для обычных процедур мы считаем это нормальным, а для методов — нет?


VD>Я не считаю. По мне так любое дублирование вредно и излишне.


Я имею в виду — в Обероне-2.
Перекуём баги на фичи!
Re[12]: Oberon family
От: Кодт Россия  
Дата: 18.11.04 11:05
Оценка:
Здравствуйте, Трурль, Вы писали:

К>>Решения:

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

... утконос и ехидна — отряд однопроходных

К>>- разнести объявление и определение методов.

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

Почему? Если Оберон умеет пред-объявлять обычные процедуры, то чем методы хуже?
Писать постфикс "forward" или компонент-паскалевскую птичку "procedure^" — это, в общем, без разницы.
Перекуём баги на фичи!
Re[13]: Oberon family
От: Кодт Россия  
Дата: 18.11.04 11:12
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, конечно, предварительное объявление процедуры

СГ>
СГ>PROCEDURE^ (t: B) Bbb (), NEW;
СГ>

СГ>приводит к дублированию кода, которое так напрягает... Но, как я уже писал ранее, перекрестный вызов процедур случается редко. Влом что ли пару раз на всю программу написать предварительное определение? Можете привести реальные примеры когда Вы сами пользовались перекрестными вызовами процедур?

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

Кроме того, лично я (никому не навязываю) считаю удобным, когда все описания выглядят компактно. А, как говорил сам Вирт, программа = структуры + алгоритмы. То есть я хочу видеть структуру объекта рядом с перечнем его методов.
Умеет редактор сворачивать текст определения (как, например, VisualStudio.NET) — прекрасно. Не умеет — буду разносить объявление и определение.

Мне кажется, дело в первую очередь в этом, а не в наличии циклов в графе зависимостей.
Перекуём баги на фичи!
Re[12]: Oberon family
От: Павел Кузнецов  
Дата: 18.11.04 13:59
Оценка:
Трурль,

> VD> Проходы в классике — это считывания исходного файла.


> Вообще-то обход синтаксического дерева тоже называют проходом.


Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: Oberon family
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.11.04 14:18
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.


Добавлю что преимущество однопроходных компиляторов имеет место быть для первого варианта.
... << RSDN@Home 1.1.4 beta 3 rev. 232>>
AVK Blog
Re[13]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.04 03:09
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Я имею в виду — в Обероне-2.


То есть ты о непоследовательности? Или Оберону это простительно?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.04 03:09
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Да, конечно, предварительное объявление процедуры

СГ>
СГ>PROCEDURE^ (t: B) Bbb (), NEW;
СГ>

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

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

СГ>Можете привести реальные примеры когда Вы сами пользовались перекрестными вызовами процедур?


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

И вообще, не удобно распологать код в каком-то порядке.

Согласись, что проще не думать о мелочах.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.04 03:09
Оценка: +2
Здравствуйте, Трурль, Вы писали:

VD>>Блин, ну, зачем говорить о том, что слабо знаете? Проходы в классике — это считывания исходного файла.

Т>Вообще-то обход синтаксического дерева тоже называют проходом.

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

Хорошим доказательством того, что количество фаз компиляции мало влияет на скорось компиляции служат компиляторы Явы и Шарпа. Они не уступают по скорости однопроходным компиляторам.

Я могу привести скорость объхода АСТ для R# (на самомо большом проекте). При использовании универсального метода обхода (намного менее эффективного чем обхода на базе визитера) объод занимает ~ 0.05 секунды. При этом парсинг уже закэшированных исходников занимает где-то 0.4 сек. При использовании патерна визитер обход вообще превратится в микросекунды.

Так что на скорость компиляции влияет в основном:
1. Скоростные характеристики семантических правил.
2. Объем обрабатываемого исходного кода.

Например, для С++ оба паказателя крайне велики. И это при том, чтосам язык требует предеклараций.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Oberon family
От: Павел Кузнецов  
Дата: 19.11.04 09:00
Оценка:
VladD2,

> Ущербно само требование предварительной декларации.


Всегда? Требование любых предварительных объявлений?

Даже предварительного объявления переменных?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[14]: Oberon family
От: Трурль  
Дата: 19.11.04 09:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ПК>>Есть, по меньшей мере, две терминологии. Одна называет проходом считывание входного файла, обработку, и запись выходного файла, называя пероход от одного внутреннего представления к другому (в т.ч. и обход синтаксического дерева) фазами. Другая называет проходом и то, и другое.


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

Думаю, лет 20 назад Вы бы не были столь категоричны.
Re[14]: Oberon family
От: Кодт Россия  
Дата: 19.11.04 09:42
Оценка:
Здравствуйте, VladD2, Вы писали:

К>>Я имею в виду — в Обероне-2.


VD>То есть ты о непоследовательности? Или Оберону это простительно?


Я ничего здесь не прощаю
Фразу "Здесь есть неувязка. Если <> две процедуры перекрёстно ссылаются друг на друга, то заголовок одной из них должен быть продублирован — в пред-объявлении и в определении." нужно читать "... Если <в Обероне-2> две процедуры ..."

Про другие языки я не говорил. Поэтому твой ответ пришёлся не к месту.
Перекуём баги на фичи!
Re[15]: Oberon family
От: Кодт Россия  
Дата: 19.11.04 09:48
Оценка: +1 :)
Здравствуйте, Павел Кузнецов, Вы писали:

>> Ущербно само требование предварительной декларации.


ПК>Всегда? Требование любых предварительных объявлений?


ПК>Даже предварительного объявления переменных?


Если объявление и инициализация совмещены — это удобно. C#, PHP... где ещё я это видел...
Особенности компиляции/компоновки С/С++ не позволяют так делать, ну значит, планида у них такая
Перекуём баги на фичи!
Re[15]: Oberon family
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.04 09:49
Оценка:
Здравствуйте, Трурль, Вы писали:

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

Т>Думаю, лет 20 назад Вы бы не были столь категоричны.

Даже 10 лет назад не был бы. А что?
... << RSDN@Home 1.1.4 beta 3 rev. 232>>
AVK Blog
Re[13]: Oberon family
От: Трурль  
Дата: 19.11.04 10:26
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>В "классике", при рассуждениях о скорости компиляции, проходом называют именно считывание/запись файла.

Не знаю, что такое "классика", но вполне себе классический 6-проходный компилятор PL/1 считывал исходный файл только один раз.

Возражение по процедуре ведения.
VD>Блин, ну, зачем говорить о том, что слабо знаете?
Почему Кодту позволительно использовать термин "многопроходный компилятор", а Трурля за то же самое обвиняют в некомпетентности?
Re[16]: Oberon family
От: Трурль  
Дата: 19.11.04 10:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

Т>>Думаю, лет 20 назад Вы бы не были столь категоричны.

AVK>Даже 10 лет назад не был бы. А что?


Разрабатывая Оберон, Вирт учитывал, что ему придется писать компилятор и для какой машины. А вот авторы Component Pascal вполне могли бы снять ограничения, раз уж их язык все равно несовместим с Обероном.
Re[17]: Oberon family
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.04 10:52
Оценка: :)
Здравствуйте, Трурль, Вы писали:

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


Так о том и речь.
... << RSDN@Home 1.1.4 beta 3 rev. 232>>
AVK Blog
Re[15]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.04 01:25
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Всегда? Требование любых предварительных объявлений?


Методов.

ПК>Даже предварительного объявления переменных?


Рад что доставил тебе удоволствие подловить меня еще разок на слове.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Oberon family
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.04 01:25
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Возражение по процедуре ведения.

VD>>Блин, ну, зачем говорить о том, что слабо знаете?
Т>Почему Кодту позволительно использовать термин "многопроходный компилятор", а Трурля за то же самое обвиняют в некомпетентности?

Я не видел где он применял этот термин. Может там разница была не принципиальна. Ты же начал рассуждать о скорости. И тут разница очень велика. Ты ведь заранее оссоциировал многопроходность с тормозами. А в случае "проходов" по AST — это не так. Именно по этому в серьезных книгах для прохода по AST используется отедьный термин.

Иначе моно дорассуждаться до того, что С++-компилятор быстрее C#-пного, так как первый однопроходный, а второй многопроходный, ведь С++ требует предеклараций и пасит код в прямом порядке.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Oberon family
От: Шахтер Интернет  
Дата: 20.11.04 03:31
Оценка: +1
Здравствуйте, Кодт, Вы писали:

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


>>> Ущербно само требование предварительной декларации.


ПК>>Всегда? Требование любых предварительных объявлений?


ПК>>Даже предварительного объявления переменных?


К>Если объявление и инициализация совмещены — это удобно. C#, PHP... где ещё я это видел...

К>Особенности компиляции/компоновки С/С++ не позволяют так делать, ну значит, планида у них такая

В процессе парсинга C++ кода приходится определять классы имён. Имя может быть именем переменной, типа или шаблона. Не определив класс имени нельзя распарсить выражение -- возникают синтаксические неопределённости. Это одна из главных причин необходимости предварительных деклараций. А так же причина появления в языке ключевого слова typename.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[17]: Oberon family
От: Кодт Россия  
Дата: 22.11.04 09:52
Оценка: +1
Здравствуйте, Шахтер, Вы писали:

К>>Если объявление и инициализация совмещены — это удобно. C#, PHP... где ещё я это видел...

К>>Особенности компиляции/компоновки С/С++ не позволяют так делать, ну значит, планида у них такая

Ш>В процессе парсинга C++ кода приходится определять классы имён. Имя может быть именем переменной, типа или шаблона.

... или вообще именем пространства имён.

Ш>Не определив класс имени нельзя распарсить выражение -- возникают синтаксические неопределённости. Это одна из главных причин необходимости предварительных деклараций. А так же причина появления в языке ключевого слова typename.


Можешь привести пример, как класс имени влияет на синтаксический анализ (не на семантику)?
Перекуём баги на фичи!
Re: Oberon family
От: AVC Россия  
Дата: 22.11.04 11:30
Оценка:
Здравствуйте, Кодт, Вы писали:

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


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

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

Хоар
Re[2]: Oberon family
От: Sergey J. A. Беларусь  
Дата: 22.11.04 14:30
Оценка: +1
Здравствуйте, AVC, Вы писали:

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


AVC>В прошлую пятницу я был свидетелем одной милой сцены.

AVC>Один наш сотрудник, почтенный доктор наук, принес результаты тестов, подтверждающие, что для наших задач за глаза хватает 32-битного float. Т.е. встраивать в процессор поддержку double нет никакой нужды.
AVC>На радостях все разговорились, разоткровенничались. В частности, наш доктор наук заявил, что Си++ — "замечательный язык". Правда, быстро выяснилось, что у него перегрузка некоторых операторов приводит не к тем результатам, которые ожидались. (В тестах ему пришлось обойтись без этой перегрузки.) Программисты стали разбираться. Возникло какое-то затруднение. Чтобы помочь ребятам (и вспомнив о тщательной проработке стандарта Си++) я "подкинул" им электронную копию стандарта Си++.
AVC>Через четверть часа они все еще ходили по перекрестным ссылкам, а в конце концов, утомившись, и вовсе оставили это занятие...
AVC>Тут у меня возник "крамольный" вопрос: уж не слишком ли тщательно был составлен стандарт Си++?

А в чём было затруднение то ?
А то у меня кроме вопроса о тщательности составления стандарта возникает и вопрос о квалификации ваших программистов....
Я — свихнувшееся сознание Джо.
Re[3]: Oberon family
От: AVC Россия  
Дата: 22.11.04 17:44
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

SJA>А в чём было затруднение то ?


Не имел времени вникнуть. (Как Вы думаете, если бы у меня было время, ограничился бы я пересылкой стандарта Си++?) Что-то связанное с подбором кандидатов на перегрузку.
Так что я занимался работой и со стороны наблюдал эту сценку. Она меня умилила, вот я и рассказал о ней.

SJA>А то у меня кроме вопроса о тщательности составления стандарта возникает и вопрос о квалификации ваших программистов....


Ну, конечно, куда им до Вас!

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

Хоар
Re[4]: Oberon family
От: Sergey J. A. Беларусь  
Дата: 22.11.04 18:16
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, Sergey J. A., Вы писали:


SJA>>А в чём было затруднение то ?


AVC>Не имел времени вникнуть. (Как Вы думаете, если бы у меня было время, ограничился бы я пересылкой стандарта Си++?) Что-то связанное с подбором кандидатов на перегрузку.

AVC>Так что я занимался работой и со стороны наблюдал эту сценку. Она меня умилила, вот я и рассказал о ней.

Из Вашей истории совершенно ничего не ясно. Была ли непонятность в стандарте или это программеры просто не догнали. Я знал одного "программера" который не смог понять protected mode процессора. Может станем утверждать, что protected mode только запутывает программиста и вообще, стоит вернуться к real mode ?
Вполне возможно, что там был нетривиальный пример. Но мне то откуда знать ?

SJA>>А то у меня кроме вопроса о тщательности составления стандарта возникает и вопрос о квалификации ваших программистов....


AVC>Ну, конечно, куда им до Вас!


Насчёт себя я ничего не утверждал. Однако я хотя бы держу под рукой стандарт и Страуструпа.
Я — свихнувшееся сознание Джо.
Re[18]: Oberon family
От: Павел Кузнецов  
Дата: 22.11.04 18:18
Оценка: 41 (2) +1
Кодт,

> Ш>В процессе парсинга C++ кода приходится определять классы имён. Имя может быть именем переменной, типа или шаблона.


> ... или вообще именем пространства имён.


> Ш>Не определив класс имени нельзя распарсить выражение -- возникают синтаксические неопределённости. Это одна из главных причин необходимости предварительных деклараций. А так же причина появления в языке ключевого слова typename.


> Можешь привести пример, как класс имени влияет на синтаксический анализ (не на семантику)?


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

Тогда:
a * b;

Если a — выражение, обозначающее типа, то результирующая синтаксическая конструкция — объявление, иначе — произведение двух выражений. При этом, в зависимости от того, чем является a, в качестве выражения b разрешены разные виды выражений. Например, если a — тип, то в качестве выражения b конструкция вида c + d не разрешена, и т.п.

Еще:
a(b);

Если a — имя типа, то результирующая синтаксическая конструкция — объявление переменной, если имя объекта — вызов перегруженной функции operator(), если имя функции — вызов функции. При этом, снова-таки, в зависимости от того, чем является a, в качестве b разрешены разные выражения. Например, если a — встроенный тип, то в качестве b выражения вида [i]c, d[i] не разрешены.

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

Конечно, можно
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: Oberon family
От: Павел Кузнецов  
Дата: 22.11.04 18:48
Оценка: +1
AVC,

> В прошлую пятницу я был свидетелем одной милой сцены. <...>

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

А никто не говорил, что будет легко

> Тут у меня возник "крамольный" вопрос: уж не слишком ли тщательно был составлен стандарт Си++?


Если серьезно, то сам язык C++ во многих моментах преизрядно сложен. Сложность стандарта — отражение этого момента. Собственно говоря, сложность данного языка является и его сильной (не сама по себе, а в результате выразительности, которая эту сложность вызывает), и его слабой стороной (очень долгий период обучения).

P.S. Пусть ваши программисты заходят на rsdn.cpp, там им сравнительно быстро и весьма квалифицированно помогут разобраться.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Oberon family
От: Павел Кузнецов  
Дата: 22.11.04 21:13
Оценка:
Sergey J. A.,

> AVC> Через четверть часа они все еще ходили по перекрестным ссылкам, а в конце концов, утомившись, и вовсе оставили это занятие...

> AVC> Тут у меня возник "крамольный" вопрос: уж не слишком ли тщательно был составлен стандарт Си++?

> А в чём было затруднение то ?

> А то у меня кроме вопроса о тщательности составления стандарта возникает и вопрос о квалификации ваших программистов....

Не стоит так категорично... Сложность C++, порожденная стремлением к выразительности языка, зачастую приводит к тому, что полное понимание происходящего даже во внешне простых случаях требует от программиста, действительно, глубокого знания языка, чего часто не нужно (или достигается значительно быстрее) при работе с другими языками.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: Oberon family
От: Sergey J. A. Беларусь  
Дата: 23.11.04 08:27
Оценка: 1 (1)
Здравствуйте, Павел Кузнецов, Вы писали:

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


Посыпаю голову пеплом. Был несколько пьян, и категоричен
Я — свихнувшееся сознание Джо.
Re[5]: Oberon family
От: AVC Россия  
Дата: 23.11.04 14:30
Оценка: 3 (1)
Здравствуйте, Sergey J. A., Вы писали:

SJA>Из Вашей истории совершенно ничего не ясно. Была ли непонятность в стандарте или это программеры просто не догнали. Я знал одного "программера" который не смог понять protected mode процессора. Может станем утверждать, что protected mode только запутывает программиста и вообще, стоит вернуться к real mode ?

SJA>Вполне возможно, что там был нетривиальный пример. Но мне то откуда знать ?

Я вовсе не критикую стандарт Си++. Сложность языка и стандарта, должно быть, вытекает из задач, которые были поставлены разработчиками языка. Критиковать язык можно лишь на такой основе. (Я хотел раньше, чтобы именно так критиковали Оберон.)
"Цель" моей "зарисовки с натуры" другая: применить "остраннение" (термин литературоведа В.Шкловского), посмотреть на ситуацию со стороны. Хотя бы и так, как Холстомер у Л.Н.Толстого наблюдал оперное пение.
А ситуация такая. Действительно компетентный специалист в своей области (для нас особо ценный, как специалист по психоакустике) непременно хочет кодировать именно на Си++, языке действительно трудном и требующем изрядного навыка. Приобретение такого навыка требует значительного времени. (Здесь где-то назывался срок 3 года?)
Оправданно ли употребление Си++ в такой ситуации?
Ведь у нас все программисты (кроме меня, грешного; я, на свою беду, просто прикладной математик) — специалисты в своих областях: физики, аппаратчики и т.д.
Им, кроме стандарта языка, надо держать в голове кучу других стандартов.
А тут еще такой изощренный язык.
Разумно ли это?
В этом и состоит мой вопрос.

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

Хоар
Re[3]: Oberon family
От: AVC Россия  
Дата: 23.11.04 14:56
Оценка: 1 (1) +1
Здравствуйте, Павел Кузнецов, Вы писали:

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

ПК>А никто не говорил, что будет легко

Меня со стороны даже заинтриговал этот процесс "хождения по ссылкам".
Написано что-то вроде см. пункт xxx. Ребята лезут туда. Там пара предложений и сакраментальное "см. пункт yyy". И так далее,
for (;;) ;

Оговорюсь, что это не критика Си++, это, скорее, просто смешная ситуация.
Но некоторые эпизоды собственной жизни, связанные с Си++, не могу забыть.
Вот еще один, "на вскидку".
Прихожу я первый раз на свою предыдущую работу (в начале 1997 года). И что я вижу? Все (человек шесть) программисты сидят в отладчике Watcom C++.
Ну, у меня сразу волосы дыбом...

ПК>Если серьезно, то сам язык C++ во многих моментах преизрядно сложен. Сложность стандарта — отражение этого момента. Собственно говоря, сложность данного языка является и его сильной (не сама по себе, а в результате выразительности, которая эту сложность вызывает), и его слабой стороной (очень долгий период обучения).


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

ПК>P.S. Пусть ваши программисты заходят на rsdn.cpp, там им сравнительно быстро и весьма квалифицированно помогут разобраться.


Спасибо! Это может и правда пригодиться, а то доктора наук что-то совсем "расшалились", им непременно перегрузку операторов подавай!

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

Хоар
Re[18]: Oberon family
От: Шахтер Интернет  
Дата: 24.11.04 02:43
Оценка: 46 (2) +1
Здравствуйте, Кодт, Вы писали:

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


К>>>Если объявление и инициализация совмещены — это удобно. C#, PHP... где ещё я это видел...

К>>>Особенности компиляции/компоновки С/С++ не позволяют так делать, ну значит, планида у них такая

Ш>>В процессе парсинга C++ кода приходится определять классы имён. Имя может быть именем переменной, типа или шаблона.

К>... или вообще именем пространства имён.

Ш>>Не определив класс имени нельзя распарсить выражение -- возникают синтаксические неопределённости. Это одна из главных причин необходимости предварительных деклараций. А так же причина появления в языке ключевого слова typename.


К>Можешь привести пример, как класс имени влияет на синтаксический анализ (не на семантику)?


Вот совсем свежий примерчик из практики
Автор:
Дата: 23.11.04
.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[19]: Oberon family
От: Кодт Россия  
Дата: 24.11.04 09:44
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>Вот совсем свежий примерчик из практики
Автор:
Дата: 23.11.04
.


Это вообще горе C++, что не хватило скобок на шаблоны.
Перекуём баги на фичи!
Re[20]: Oberon family
От: Шахтер Интернет  
Дата: 25.11.04 00:29
Оценка:
Здравствуйте, Кодт, Вы писали:

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


Ш>>Вот совсем свежий примерчик из практики
Автор:
Дата: 23.11.04
.

К>
К>Это вообще горе C++, что не хватило скобок на шаблоны.

Не только С++. Пора уже на клавиатуру вместо всяких виндовых гадостей добавить правильные кнопки.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[21]: Oberon family
От: Кодт Россия  
Дата: 25.11.04 08:38
Оценка:
Здравствуйте, Шахтер, Вы писали:

К>>Это вообще горе C++, что не хватило скобок на шаблоны.

Ш>Не только С++. Пора уже на клавиатуру вместо всяких виндовых гадостей добавить правильные кнопки.

Или в клавиатурный драйвер добавить юникодные композиты. Тогда можно будет на оригинальном APL писать
Перекуём баги на фичи!
Re[6]: Oberon family
От: Павел Кузнецов  
Дата: 29.11.04 23:26
Оценка: 40 (1)
AVC,

> А ситуация такая. Действительно компетентный специалист в своей области (для нас особо ценный, как специалист по психоакустике) непременно хочет кодировать именно на Си++, языке действительно трудном и требующем изрядного навыка. Приобретение такого навыка требует значительного времени. (Здесь где-то назывался срок 3 года?)


Если человек уже знаком с каким-нибудь другим "настоящим" языком программирования (не SQL, не Basic и т.п.), и уверенно управляется с основными понятиями computer science (алгоритмы и структуры данных), при условии наличия кого-нибудь, кто по ходу дела мог бы подсказывать, как "правильно" работать с C++, я бы уменьшил ожидаемый срок обучения в несколько раз по сравнению с названным (несколько месяцев я нахожу более чем реальным). Это до уровня уверенного использования без наступания на грабли.

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

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


Сложный вопрос. С одной стороны, язык, действительно, непростой. С другой — мне почему-то кажется, что основным для успешного использования какого-либо языка является наличие большого количества готовых решений, которые можно использовать в разработке, плюс, очень желательно наличие серьезного сообщества, у которого можно получать информацию о best practices. По моей информации C и C++ достаточно широко используются в научных разработках.

Но, имхо, тут каждый должен решать для себя сам: со стороны многих существенных для правильного выбора моментов не видно...
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.