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

СГ>Здравствуйте, 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).

Здравствуйте, 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) благодаря компонентному программированию как развитию идеи раздельной компиляции Оберону шаблоны не нужны, т.к. он позволяет делать те же вещи, что делаются шаблонами, другими способами?

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

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

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

ПК>Не очень понял данный фрагмент. Подразумевается, что (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%

Здравствуйте, 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 страниц. И это учитывая, что язык на порядок более серьезный нежели Оберон.

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

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

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

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

Здравствуйте, 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)-языки.

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

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

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

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

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

AF> Да знаю я это прекрасно. Дело не в простоте языка по EBNF — она конечно важна, но больше с сугубо теоретической точки зрения. Ну нет корреляции между сложностью языка и его успешностью. Просто нет. Есть и простые языки и сложные — и те и другие успешны.

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

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

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

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

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

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

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

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

ЗЫ

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

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

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

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

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

+1

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

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

Тогда бы на РСДН в первую очередь восприняли бы в штыки такие технолгии как Ява и дотнет. Но это не так. Ну, а Оберон/КП воспринимается в штыки потому что — это ЛАЖА.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПК>Не очень понял данный фрагмент...

Да, слово "шаблонов" он упомянул зря.

Здравствуйте, 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. Ставлю ящик пива, что кроме меньшего размера грамматики и возможности не использовать классы ты никакого приемущества не обнаружишь.