Здравствуйте, Privalov, Вы писали:
P>"Простой" и "тяжелый" — понятия разные. Скажем так, усложнение системы, как правило, делается с целью облегчения ее использования.
Просто аналогия не совсем точная. В случае программирования, упрощение инструментов не упростит сам процесс разработки программ; результат будет прямо противоположным.
Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась.
Чем проще будет язык программирования, тем больше программисту придется эмулировать своими силами
Здравствуйте, mihoshi, Вы писали:
M>Кстати, описания синтаксиса C# в EBNF, насколько я понимаю, просто не существует
Ну в каком-то виде обязательно существует.
Раз есть компилятор, то обязана быть и спецификация языка,
включая синтаксис (простая часть) и семантику (менее тривиальная часть).
Re[4]: Сложность современных средств разработки ПО
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Ну фанатам оберона обяснить то, что крупный проект на нём сделать не возможно никак не получается.
СГ>Несколько операционных систем написанных на оберонах — это, по Вашему, не несколько крупных проектов? То есть ОСь — это мелкий проект, а вот что-то работающее, например, с СУБД — это уже крупный проект.
СГ>Может хватит попусту трепаться?
Вы кое что забыли. Кое что очевидное. Есть такая 32 битная, многопточная ОС ADRT. Она гораздо удобнее, проще и легче в освоении чем Windows или Linux. Программы, написанные под неё работают с проиводительностью несколько миллиардов операций в секунду. В своей области у неё нет конкурентов. Более того — если считать число копий, то она возможно уже догнала Windows. Так где же она?
Это ОС для DSP Analog Devices — и используется она для упрощения их программирования. И она действительно гораздо проще и Windows и Linux. И DSP на которых она используется при той же тактовой частоте гораздо производительнее Penium IV/Athlon/Duron...
Ну написали на обероне ОС. Да хоть 10. Ну и что. В интституте еждегодно народ по нескольку операционок для проверки полученных знаний и демонтсрации крутизны пишет. И попадаются даже весьма удачные экземпляры. То же самое и с БД.
Но всё это ничего не значит, пока ОС или БД не стала использоваться так широко как Windows или хотя бы Linux. Потому, как многие проблемы всплывут и будут очевидны именно тогда, а не пока этой ОС или БД восхищённо любуются и ничего особенного — крупного и коммерчески выгодного не делают. Ах да! 2-3 коммерчески успешных проекта под каждую такую ОС? Ну так и под DOS можно при желании написать проект гораздо сложнее, чем среднестатистический проект под Windows. Более того их и писали.
Оберон проще и легче изучать? Прекрасно. Но программа то это не только язык. Об этом тут сказали уже кучу раз. Это ещё и библиотеки, средства разработки, инструменты, которые прозволяют её отлаживать. Вы уверены, что кривой WinAPI станет на обероне вдруг прямым? Или как обычно — до основанья, а затем?
Имхо, если программа не системная, т.е. ее цель не устранить недостатки системы, а быть чем-то самостоятельно полезным, то с некоторого объема уже без разницы на чем писать. И объем этот очень не велик, скажем 10000 строк. Программист делает интерфейс между системой исполнения и представлениями предметной области, затем основную часть пишут уже в понятиях предметной области. И тут уже любой язык начинает мешать, если это не тот язык на котором оформлена постановка задачи. Там уже совершенно безразлично скобочки там или begin-end, убирается мусор или нет.
Да, кстати говоря... кажется, тобой упоминалось о том, что Оберон задумывался как нечто вроде ОО ассемблера.
Есть и другой такой язык — это MSIL Только я ни разу не слышал, чтобы кто-нибудь предлагал начинать обучение программированию именно с него Да и просто писать на нем желающих довольно мало.
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: Сложность современных средств разработки ПО
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Privalov, Вы писали:
P>>"Простой" и "тяжелый" — понятия разные. Скажем так, усложнение системы, как правило, делается с целью облегчения ее использования.
Д>Просто аналогия не совсем точная. В случае программирования, упрощение инструментов не упростит сам процесс разработки программ; результат будет прямо противоположным.
Правильно. Так я ведь и говорил: не упрощения, а облегчения. Процесс разработки ПО вряд ли вообще можно упростить, а вот облегчить — задача каждого разработчка, в первую очередь разработчика систем программирования
Д>Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась. Д>Чем проще будет язык программирования, тем больше программисту придется эмулировать своими силами
Естественно, кто же спорит. Где-то раньше и я говорил о том, что это та самая простота, которая хуже воровства...
Re[5]: Сложность современных средств разработки ПО
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Дарней, Вы писали:
Д>>Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась. Д>>Чем проще будет язык программирования, тем больше программисту придется эмулировать своими силами
P>Естественно, кто же спорит. Где-то раньше и я говорил о том, что это та самая простота, которая хуже воровства... P>
Ага, только вот такое ощущение, что до Сергея это как-то ну совсем не доходит
Ещё одно доказательство того, что кое-кто выдаёт желаемое за действительное. Такое описание не один нормальный человек не воспримет. А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль. Но это не означает ещё — что тот или иной язык проще освоить или им легко пользоваться.
Лучше сравнить два адекватных по качеству описания обоих языков на естественном языке. А по той нотации, что здесь дана можно оберон до второго пришествия изучать...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А ведь, действительно, термин "технология" к оберонам очень подходит. Может быть, именно из-за того что оберон системы — это технология, способная заменить все остальные технологии, их во всем мире вообще, и на форуме RSDN в частности, воспринимают в штыки?
Такое предположение можно сделать в отношении крупных компаний, стремящихся устранить конкурентов своим ОС и языкам программирования. Яркий пример — Microsoft. Но они борются отнюдь не только с Обероном, а со всеми: с UNIX, с Linux и т.д.
Что же касается "критики" в адрес Оберона на RSDN, то здесь верно скорее обратное: многие участники форума не представляют, в чем именно заключается альтернативность Оберона. Я делаю такой вывод на основании здешних "постов".
Это говорит о том, что мы "не с той стороны подошли к кобыле".
Наверное, надо начать с того, что такое сложность ПО, и каким образом Оберон пытается решить эту проблему. Показать, что продуманная ОС — не сложнее компилятора, а обратное — предрассудок. Что компонентное программирование есть просто естественное развитие идеи раздельной компиляции. Что именно поэтому в Обероне нет шаблонов. И т.д., и т.п.
Т.е. надо менять собственный подход к обсуждению вопроса.
Конечно, это только моя точка зрения, и ее можно и нужно критиковать.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Вы уж извините, Андрей, но такое письмо онозначно характеризует автора
как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur
Form) — это де-факто стандартный способ описания синтаксиса языка
программирования уже в течение лет 20. Подобные описания используются
для синтаксического анализа в компиляторах (вы с YACC когда-нибудь
работали?). И речь в этом топике именно о формальном описании грамматики
языка и шла.
Вы, видимо, имели в виду описание _семантики_ языка, но это совсем
другая история. Замечу, что и в этом отношении С++ много сложнее Оберона.
AndreyFedotov wrote:
> Здравствуйте, Сергей Губанов, Вы писали: > > Ещё одно доказательство того, что кое-кто выдаёт желаемое за > действительное. Такое описание не один нормальный человек не > воспримет. А в заковырестой нотации можно умудриться сделать C++ > компактнее чем Паскаль. Но это не означает ещё — что тот или иной > язык проще освоить или им легко пользоваться. Лучше сравнить два > адекватных по качеству описания обоих языков на естественном языке. > А по той нотации, что здесь дана можно оберон до второго > пришествия изучать...
Здравствуйте, TheBeard, Вы писали:
TB>Вы уж извините, Андрей, но такое письмо онозначно характеризует автора TB>как полнейшего дилетанта в программировании. EBNF (Extended Backus-Naur TB>Form) — это де-факто стандартный способ описания синтаксиса языка TB>программирования уже в течение лет 20. Подобные описания используются TB>для синтаксического анализа в компиляторах (вы с YACC когда-нибудь TB>работали?). И речь в этом топике именно о формальном описании грамматики TB>языка и шла.
Если я ничего не путаю, то YACC работает не с EBNF, а с BNF, т.е. с (лево)рекурсивным представлением грамматики без циклов.
Например: список: элемСписка
| ',' элемСписка
;
А Вирт пользуется именно EBNF, например: список = элемСписка { ',' ЭлемСписка }
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Конечно, так "правильнее": список: элемСписка
| список ',' элемСписка
;
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
О том, что такое EBNF я прекрасно знаю. И прекрасно знаю, что не только оберон, но и многие другие языки обладают синтаксисом на страницу или меньше.
Посмотри на исходную посылку. Она была (поправь, если я ошибаюсь), что простота языка означает и большую простоту написания программ. Она сама по себе спорна. Потом была сделано второе предположение. Критерий простоты языка его представление в форме EBNF. Что опять таки крайне спорно. Простой синтаксис и простой язык не одно и то же. Думаю синтаксис ассеблера вообще займёт две-три строчки. Это не означает, что ассемблер проще чем С++ или Оберон и что программировать на нём проще.
И опять таки, несмотря на то, что EBNF очень старая, полезная и признаная форма, вопрос о том, является ли компактность описания языка в этой форме критерием его простоты (не теоретической, а практической) — очень спорен (см. ассеблер).
И вполне допускаю, что возможно придумать такое представление языка, в котором более сложные языки (такие как C++ или Java или C#) будут выглядет проще, чем более простые. Допустим для простоты опысывать каждый язык аналогичным кодом на C++. Естественно в таком представлении C++ окажется самым простым языком. Но будет ли это правильно? Будет ли такое представление отражать реали программирования?
Я, пожалуй, поясню подробнее, что именно мне не понравилось:
> Такое описание не один нормальный человек не воспримет.
Как раз EBNF и является наиболее естественным описанием грамматики.
Правда, не для человека, а для программиста
> А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль
Здравствуйте, TheBeard, Вы писали:
TB>Я, пожалуй, поясню подробнее, что именно мне не понравилось:
>> Такое описание не один нормальный человек не воспримет.
TB>Как раз EBNF и является наиболее естественным описанием грамматики. TB>Правда, не для человека, а для программиста
Тогда посмотрим на это с другой стороны. Если мы опросим нормальных людей — хотя бы здесь на RSDN — считают ли они нормальным человеком того, кто учит язык по его EBNF нотации вместо обычных книг и документации — интересно — а какой ответ мы получим?
И не в этом ли проблема Вирта с его коллегой?
>> А в заковырестой нотации можно умудриться сделать C++ компактнее чем Паскаль
TB>Сильно сомневаюсь, интуиция протестует. Поскольку соответствующим мат. TB>аппаратом не владею, вот ссылка на исследование в этой области: TB>http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/paper.html TB>. Вот здесь TB>(http://www.cs.clemson.edu/~malloy/research/iwpc2000/paper/paper/node8.html) TB>есть некоторые численные результаты.
С числами согласен. Они относятся к EBNF и думаю совершенно справделивы Как сделать нотацию в которой самый компактный C++ (С#, Java или даже Oberon) — я показал.
Но суть не в конкретной нотации и её обоснованности, а в том, можно ли вообще считать простоту языка в некоторой нотации критерием его большей полезности или эффективности. И привел пример — ассемблер. Вот уж чья нотация проще некуда. Но попробуйте на неё что-нибудь написать!
