Ada_Ru форум

Обсуждение языка Ада

[ada_ru] Modula-3 and Ada

Оставить новое сообщение

Сообщения

Alexey Veselovsky
[ada_ru] Modula-3 and Ada
2009-02-17 19:34:36

Наткнулся на любопытный текстик-сравнение Модулы-3 с Адой:

 

http://www.cs.wichita.edu/~rodney/languages/Modula-Ada-comparison.txt

=================

Modula-3 and Ada

 

A summary of the differences between the two languages, (and a touch of C++).

 

I spent a lot of time programming in Ada, mostly on things that also process Ada code, including working on two different compilers and a general front end. At one time I had most of the semantics of the 83 dialect in my head.

 

Ada has a similar list of useful "features" as Modula-3, but is far more complicated. Economy of concept is quite low. There are 511 pages in the Ada-95 definition, counting the same way that Modula-3 counts its 50 pages (no introduction, no syntax summary, no libraries, etc.) I used the annotated version of the Ada manual that includes all the clarifications and interpretations that users and compiler-writers demanded. Similar clarifications and interpretations have been

integrated into the Modula-3 definition.

 

Things Modula-3 has that Ada doesn't:

 

Sets. If you've used them, you will greatly miss them. Pascal and Modula-2 also have them. They are a strongly-typed and high-level replacement for the bitwise oring, anding, etc. of bitmasks, poorly disguised as integers, used in C and C++.

 

Partial revelation. This is far more flexible as an information-hiding mechanism than the private types of Ada. It allows the fields and methods of a type to be partitioned into an unlimited number of subsets and any scope can see any subset of the subsets. The private

types of Ada give all-or-nothing visibility.

 

Garbage collection. On one medium-sized project in Ada that I was involved in, the decision was made to first implement without

bothering to deallocate, get that working, then add deallocation in a later development phase. That second phase took the same amount of time as the first, by the time we got the observable dangling pointer bugs tracked down. It could have been somewhat less trouble if we had designed-in the deallocation from the first, but it still would have been a mess. That experience really converted me to a believer in garbage collection, after years of skepticism.

 

On the other hand, if you really must use explicit deallocation, Modula-3 has an alternate heap that works that way, so you can

choose.

 

Things Ada has that Modula-3 doesn't:

 

Variant records. I recall that at one point, Modula-3's designers found leaving them out was a major savings in complexity. A hierarchy of object types can be used instead for the same purpose. Ada-83 isn't object oriented, so they were needed there. Ada-95 is, but it still has the variant records. Modula-3 has a TYPECASE statement, that is needed to conveniently use an object hierarchy instead of a variant record.

 

Local variables and function results of types whose size is not

static. I have always hated heap-allocating anything that had LIFO lifetime, so I use these in Ada regularly. They introduce some semantic complexity and require some care in use, often extra nested blocks, etc. There is hidden, unexpected (for many programmers) space and time overhead in their implementation. Having a garbage collector in Modula-3 makes them of little use.

 

User-defined overloading. My experience with Ada has made me a

vehement foe of user-defined overloading. It's a semantic train wreck. The great majority of Ada's tenfold extra complexity

disadvantage compared to Modula-3 derives from this one (mis)feature and its myriad interactions with practically everything else in the language.

 

In one way, it's not as bad as in C++, in that there are very few implied conversions that can be used to make a candidate function fit a call, and there's nothing like the relative goodness of fit that C++ uses. But, unlike C++, the candidate functions can come from many different scopes. Also unlike C++, many of the builtin operators can be replaced by programmer-defined functions that are called using the same operator notation. This in turn means that builtin operators are not necessarily visible, unlike every other language I know of.

Worse, the result type of a function/operator participates in the overload resolution, along with the parameter types. This means overload resolution information can flow in all directions in an expression tree (actually, an even bigger region, called a "complete context"), in from the top, out the top, up from and down to any of the descendants, and crosswise, at every call/operator location.

 

As an example, the seemingly innocent notation "A(I)" has 17 possible structurally distinct interpretations. One example interpretation is this: A is a function that is implicitly called, with no parameters, returns a pointer, the pointer is implicitly dereferenced giving an array, the array is subscripted (the parentheses--the only

syntactically explicit operation in the example), the subscript being the result of implicitly calling function I.

 

On the other hand, only a subset of the "builtin" operations can be overloaded. For those that can't, virtually every one has a different rule about the subset of the directions overload resolution

information can flow. The ellipsis "..", has, as I recall, 5

different rules, in 5 different contexts, which, mercifully, are at least syntactically distinguished.

 

Without overloading, procedure/function identity is determined just by whether the names are the same. With overloading, it has to take into account, some portion of the entire signature. In Ada 83, as I recall, there are 5 different rules, used in different situations, as to just what subset this is.

 

All of this mess only buys saving the effort of thinking up different names for your procedures, a few keystrokes typing them, and, in some cases, the readability of operator notation over function call

notation. It is syntactic heroin. The first couple of fixes may feel really good, but you will pay a heavy price indeed, in the end.

Fixed point data types, i.e. non-integer fixed point. If you really want these, Ada is the only game I know of. They are rarely used. I worked peripherally with one embedded systems project that used them. They interact with the overloading and operator visibility rules in an ugly way, creating a glaring inconsistency in the rules.

 

Enclosing scope qualifiers. This is the only thing in Ada that I wish Modula-3 had. The qualified reference A.B works where A is the name of some enclosing scope and B is declared local to it. When using nested procedures, I think this really helps readability when referring to a identifier declared local to a procedure that is not innermost. Also, when B is declared in interface A, it allows moving code in or out of A or a module that exports A, without having to edit the code.

 

Things that are different:

 

Ada requires one-to-one match between specifications (interfaces) and bodies (modules). Most Modula-3 code is written this way, but it doesn't have to be, and there at least one group of library routines that are not, that have a well-reasoned and carefully documented case for their design. In contrast, Ada can make it very difficult to reorganize things. But Ada's rule does make it a lot easier for a compiler to find the source files that are are needed.

 

Private (opaque) types. Ada puts the equivalent of a revelation in the package spec (interface), so the compiler can always know the revealed type. Language rules prevent client source code from utilizing this information. The problem is, in a multi-person project using any kind of source code control, data structure changes that should be only the body (module) writer's business require that the spec (interface) be checked out, changed, etc. Then all client code implementors must at some time, upgrade to the new interface, review what has changed to determine that it requires no source code changes for them, then recompile, possibly massive amounts of code. On the other hand, it does allow you to have an private type that is not heap-allocated.

Generics. Ada's generic facility is extremely complicated, but not as flexible. Generic parameters are restricted to a complex but incomplete subset of the kinds of declarable entities. On the other hand, it does allow most semantic checking on a generic unit to be done independently, without any instantiation. The only semantic checks done at the time of instantiation are actual/formal matchings of the generic parameters, similar to calls on procedures in an interface. There is one exception to this in Ada 83, that was fixed in Ada 95.

 

The simplicity plus flexibility of Modula-3's generic facility has a cost. Very little semantic checking can be done on an uninstantiated generic unit. The checking is all deferred until instantiation time.

Threads. Ada's thread facility has complex semantics and a lot of runtime overhead, even at many block entry and exit points where nothing happens that the programmer might expect to have anything to do with threads. The synchronization method, the "rendezvous", has high overhead and is very confusing in that it attempts to create the illusion that you can "call" another thread like a procedure. I have had so much difficulty trying to get students to understand how threads are different from procedures, that I hate this idea.

 

Many embedded system projects couldn't tolerate the overhead and just resorted to using thread libraries instead. Ada-95 added "protected" types that are implicitly subject to mutual exclusion and can be much faster, but of course, mutual exclusion is not a complete

synchronization system.

 

Parameter modes. Formal parameter modes in Ada are "in", "out", and "in out", denoting the intended use. For some combinations of mode and type, the actual mechanism (reference, copy-in-copy-out) is compiler-writer's option. This choice can alter the semantics of a program, but the language makes no attempt to determine whether this can happen. It's undoubtedly undecidable. If you write code that depends on the mechanism, Ada defines your program as "erroneous", which means the meaning is undefined, but you won't get any error message. Of course, C++ has this kind of undefinedness all over the place, Ada only in a few places.

 

Object orientation. Ada-95 added something like object orientation, in a strange sort of way. If T is the name of a "tagged" type (i.e., one that can "extended" (subtyped)), T contains only those values that are not members of any extension of T. For the latter, there is the type T'class, which includes all possible extended values as well.

All other object-oriented languages put the fields and methods (and nothing else) inside a syntactically delimited construct, the object type, in the case of Modula-3. Ada syntactically packages the fields, but the methods are scattered around anywhere in the same scope as the type. Any time there is a procedure with a formal parameter of a tagged type, it is a method of that type. It need not be the first parameter.

=================

 

Заинтересовало, в частности вот это:

" As an example, the seemingly innocent notation "A(I)" has 17 possible structurally distinct interpretations. One example interpretation is this: A is a function that is implicitly called, with no parameters, returns a pointer, the pointer is implicitly dereferenced giving an array, the array is subscripted (the parentheses--the only

syntactically explicit operation in the example), the subscript being the result of implicitly calling function I.

"

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

Alexey Veselovsky wrote:

Наткнулся на любопытный текстик-сравнение Модулы-3 с Адой:

 

http://www.cs.wichita.edu/~rodney/languages/Modula-Ada-comparison.txt

 

Я б сказал - детский сад, трусы на лямках. Пропущено основное:

 

Things Ada has that Modula-3 doesn't:

 

Ада - индустриальный язык, Модула - язык мертвый.

 

Мелкие передергивания и, мягко говоря, спорные формулировки на

этом фоне разбирать нет смысла.

 

Заинтересовало, в частности вот это:

" As an example, the seemingly innocent notation "A(I)" has 17 possible

structurally distinct interpretations. One example interpretation is

this: A is a function that is implicitly called, with no parameters,

returns a pointer, the pointer is implicitly dereferenced giving an

array, the array is subscripted (the parentheses--the only

syntactically explicit operation in the example), the subscript being

the result of implicitly calling function I.

"

 

Этому приколу - сто лет в обед. Плюха была обнаружена чуть ли не сразу же

после публикации стандарта образца 83-го года

 

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

 

Что именно не сказывается? Конкретная плюха с "A (I)"? Конечно, сказывается -

сам на нее минимум один раз попал (вызов функции перепутал с преобразованием

типа, но тут основная причина была в идиотской организации библиотеки, откуда

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

много.

 

В ЛЮБОМ языке есть неудачные проектные решения и откровенные ляпы. Ада

отличается тем, что в ней этих ляпов МЕНЬШЕ ВСЕГО.

Я б сказал - детский сад, трусы на лямках. Пропущено основное:

 

Things Ada has that Modula-3 doesn't:

 

Ада - индустриальный язык, Модула - язык мертвый.

 

Я таки дико извиняюсь, но с т.з. человека не вовлеченного в проекты всяких боингов и прочей высокой промышленности (куда, думается Ада попала во многом благодаря оборонке США), Модула-3 выглядит сильно pболее живой нежели Ада. Например на ней написана столь популярная утилита как CVSup. На аде же ничего общественно полезного в обозримых просторах не наблюдается.

 

Опять же, с т.з. простого, рядового программиста.

 

А насчет высоких материй и критического софта... ПО наших спутников (и возможно самолётов) до сих пор вроде пишется на Modula-2.

 

Так что язычок таки не мертвый.

Alexey Veselovsky wrote:

 

Ада - индустриальный язык, Модула - язык мертвый.

 

Я таки дико извиняюсь, но с т.з. человека не вовлеченного в проекты

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

попала во многом благодаря оборонке США), Модула-3 выглядит сильно

pболее живой нежели Ада.

Так и я про то же: Ада - язык индустриальный, Модула - нет.

 

Например на ней написана столь популярная

утилита как CVSup. На аде же ничего общественно полезного в обозримых

просторах не наблюдается.

 

А на самолетах летать приходилось? На гражданских Боингах или

Аэробусах? А над Европой летать?

 

А насчет высоких материй и критического софта... ПО наших спутников (и

возможно самолётов) до сих пор вроде пишется на Modula-2.

 

Эххх.... Этим летом встретился и немного поговорил с начальником тех

самых писателей на Модуле для наших спутников (они, кстати, слюной

изошли, глядя на пару простеньких Адских примеров с многозадачностью,

что в моем докладе были. Модулой они пользуются по бедности,

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

по привычке. Если вы это называете индустрией, то я - Памелла Андерсон.

 

Так что язычок таки не мертвый.

 

С точки зрения живой индустрии - мертвый. Наши спутники до сих пор не все

используются для сбивания американских просто по недоразумению и

по ошибке. Увы, но индустрии в нашей некогда великой некогда стране

больше нет. Одна швабода с реформами осталась :(

Sergey I. Rybin wrote:

 

А на самолетах летать приходилось? На гражданских Боингах или

Аэробусах? А над Европой летать?

 

Ну а если кто на черноморские моря отправится на самолёте, то тоже может про Ada вспоминать... Правда это не наше достижение, а приобретённое из-за бугра :-(

Я таки дико извиняюсь, но с т.з. человека не вовлеченного в проекты всяких боингов и прочей высокой промышленности (куда, думается Ада попала во многом благодаря оборонке США), Модула-3 выглядит сильно pболее живой нежели Ада.

 

Так и я про то же: Ада - язык индустриальный, Модула - нет.

 

А С/С++ ещё более индустриальный! А уж Ява... ;-)

 

А на самолетах летать приходилось? На гражданских Боингах или

Аэробусах? А над Европой летать?

Летать приходилось. Но на отечественных самолетах по отечественным просторам.

А насчет высоких материй и критического софта... ПО наших спутников (и возможно самолётов) до сих пор вроде пишется на Modula-2.

 

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

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

Ну, есть же вполне коммерческий компилятор XDS. Правда оно явно не для тех спутников...

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

ограничений железа. Модула-2 это ж таки почти полный аналог С. Оно и рантайма не требует...

 

Так что язычок таки не мертвый.

С точки зрения живой индустрии - мертвый.

А с точки зрения мертвой индустрии -- живой! И эта мертвая индустрия таки пока живет.

 

А Modula-3 развивается вполне себе живой конторой которая на этом деле как-то умудряется таки заработать и выжить. Вполне себе похоже на Ada Core ;-)

 

http://www.elegosoft.com/index.php?id=170&L=1

 

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

 

Наши спутники до сих пор не все используются для сбивания американских просто по недоразумению и

по ошибке. Увы, но индустрии в нашей некогда великой некогда стране больше нет. Одна швабода с реформами осталась :(

 

А как же этот, как его.., гланасс?

Ну и как бы чисто софтверные компании которые занимаются не

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

Alexey Veselovsky wrote:

 

А С/С++ ещё более индустриальный! А уж Ява... ;-)

 

Ну дык... С этим сложно спорить

 

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

ограничений железа. Модула-2 это ж таки почти полный аналог С. Оно и

рантайма не требует...

 

Ада без рантайма - давно уже отъезженная технология.

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

не потянуть?

 

С точки зрения живой индустрии - мертвый.

А с точки зрения мертвой индустрии -- живой! И эта мертвая индустрия

таки пока живет.

 

Это вам только так кажется :(

 

Но мы отвлеклись - а какова, собственно, цель дискуссии?

 

Сейчас есть явно больше одного языка, которые каждый в своей нише

лучше всех. Но вот число индустриальных языков крайне невелико.

Ада в это число входит (возможно, что и на пределе). Модула - нет.

 

На мой взгляд, имеет смысл сравнивать только языки-одноклассники.

 

То есть Аду - с Джавой и клонами С, а Модулу - с Оберонами и проч.

 

Сравнения "крест-накрест" просто бессмысленны, ибо не могут привести

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

 

И причины тому - куда как сложнее, чем чисто технические

Ада без рантайма - давно уже отъезженная технология.

 

Если Аду тянет копеечный ноутбук, который практически каждый

студент-программист с собой в рюкзаке таскает - то чего б спутнику не потянуть?

 

Потому что на спутнике может стоять сильно более дремучий (по

производительности) процессор, зато сильно более живучий в

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

 

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

обработанные данные пересылает в диспетчерскую на центральный сервер, компутер уровня 486 133 МГц, 16 Мб ОЗУ. "Винчестер" -- 32 Мб (на

который лучше не писать).

 

Ноутбук который таскает каждый студент на пару-тройку порядков

производительней будет.

 

С точки зрения живой индустрии - мертвый.

А с точки зрения мертвой индустрии -- живой! И эта мертвая индустрия таки пока живет.

 

Это вам только так кажется :(

 

Ну я как бы работаю в софтверной компании которая занимается именно своими продуктами. Процентов 70 российского рынка держит и имеет более 600 компаний за рубежом в 62 странах. Это таки кажется?

 

Но мы отвлеклись - а какова, собственно, цель дискуссии?

 

Цель простая -- оценить какие проектные решения в этих языках были удачны а какие нет.

 

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

Ада в это число входит (возможно, что и на пределе). Модула - нет.

 

Ну, вот допустим решаю я какой язык выбрать для своего нового проекта. Какие тут отличия Ады от Модулы-3 в плане живости? Что там что там я могу взять свободную некоммерческую реализацию и иметь поддержку

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

 

На мой взгляд, имеет смысл сравнивать только языки-одноклассники.

 

То есть Аду - с Джавой и клонами С, а Модулу - с Оберонами и проч.

Модулу-3 с оберонами не получится. Насколько я знаю, на данных момент нет реализации компилятора (точнее, инструметария разработчика ведь ещё и библиотеки нужны какие-то и проч) Оберона имеющего коммерческую тех. поддержку. И с кроссплатформенностью там тоже сильно не все

ладно. Про стандартную библиотеку промолчу...

 

Да и общественно полезных программ писаных на обероне я не упомню.

On Tue, 17 Feb 2009 22:47:45 +0300, you wrote:

 

Alexey Veselovsky wrote:

 

Заинтересовало, в частности вот это:

" As an example, the seemingly innocent notation "A(I)" has 17 possible structurally distinct interpretations. One example interpretation is this: A is a function that is implicitly called, with no parameters, returns a pointer, the pointer is implicitly dereferenced giving an array, the array is subscripted (the parentheses--the only

syntactically explicit operation in the example), the subscript being the result of implicitly calling function I.

"

Этому приколу - сто лет в обед. Плюха была обнаружена чуть ли не сразу же после публикации стандарта образца 83-го года

 

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

 

Я не знаю, что товарищ имел ввиду под "structurally distinct

interpretations". Что такое "структура интерпретации", которая оказалась разной?

 

В ЛЮБОМ языке есть неудачные проектные решения и откровенные ляпы. Ада отличается тем, что в ней этих ляпов МЕНЬШЕ ВСЕГО.

 

Это сложно померить. Разумеется некоторые вещи следовало бы в Аде изменить (но не пример выше). С моей точки зрения в Ада правилен подход к

программированию, идеология. Конкретные решения - следствие подхода.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

hi,

 

Alexey Veselovsky wrote:

 

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

Какие тут отличия Ады от Модулы-3 в плане живости?

 

о-о-о! Знакомая проблема ;-)

Однако, я бы не так выразился: не проблема "отличия в плане живости", а проблема ВЛАДЕНИЯ инструментальной технологией!

 

Размеры инструментария под Модулу/Паскаль несоизмеримо меньше чем для Ады. Поэтому овладеть "на коленке" Модулой/Паскалем как-то можно, а вот Ада "на коленке" не помещается. Как правило ресурсов на _внешний_ support у коллектива разработчиков нет, а в некоторых случаях внешний support (а тем более зарубежный) может быть просто невозможен по целой куче причин. Поэтому и получается, что у многих команд отечественных разработчиков какой-то умелец "лепит на коленке" под свои задачи малой автоматизации свой собственный runtime или даже недо-OS и сопутствующий программный инструментарий компоновки-прошивки в железо на Модуле/Паскале/.../вообще на ассемблере. Причем подобные поделки нормально воспринимаются только как вспомогательные или инициативные, но не целевые работы(!). Соответственно, подобные поделки, как правило, плохо или вообще никак не документированы, а в случае ухода отца-умельца из коллектива - забрасываются куда подалее.

 

То есть Аду - с Джавой и клонами С, а Модулу - с Оберонами и проч.

Модулу-3 с оберонами не получится. Насколько я знаю, на данных момент

нет реализации компилятора (точнее, инструметария разработчика ведь

ещё и библиотеки нужны какие-то и проч) Оберона имеющего коммерческую

тех. поддержку. И с кроссплатформенностью там тоже сильно не все

ладно. Про стандартную библиотеку промолчу...

 

Да и общественно полезных программ писаных на обероне я не упомню.

 

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

 

Alex

Dmitry A. Kazakov wrote:

 

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

переменной и вызовом функцией нет никакой. Для меня это не плюха, а

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

тогда да, - плюха.

 

Можно и так на это посмотреть :)

 

Проблема точно есть для компиляторщиков, точнее, для инструментов

анализа исходного текста.

 

И потом - есть ситуации, когда этот "нормальный уровень абстрагирования"

оборачивается китайскими боевыми граблями. Я минимум раз такими

граблями по лбу получал

 

Я не знаю, что товарищ имел ввиду под "structurally distinct

interpretations". Что такое "структура интерпретации", которая оказалась

разной?

 

Адский синтаксис - не контекстно-свободный. Есть ситуации, и их достаточно

много, когда для определения, к какой синтаксической категории принадлежит

конструкция, нужен контекстный анализ. Это - одна из таких ситуаций.

 

Это сложно померить. Разумеется некоторые вещи следовало бы в Аде изменить

(но не пример выше). С моей точки зрения в Ада правилен подход к

программированию, идеология.

 

Правильный подход для определенных областей применения. Правильного подхода

на все случаи жизни просто не бывает!

 

Конкретные решения - следствие подхода.

 

Безусловно. Но нельзя утверждать, что в Аде вообще нет неудачных решений.

Ибо при принятии такого количества конкретных решений ни разу не ошибиться -

нельзя.

 

В частности, я абсолютно не уверен, что возможность интерпретировать

F (X) как:

 

- вызов функции

- компонент массива

- преобразование типа

- subtype indication с ограничением индекса

- subtype indication с ограничением дискриминанта

 

есть хорошо.

On Wed, 18 Feb 2009 00:50:33 +0300, you wrote:

 

Alexey Veselovsky wrote:

 

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

ограничений железа. Модула-2 это ж таки почти полный аналог С. Оно и рантайма не требует...

 

Ада без рантайма - давно уже отъезженная технология.

 

Да, но бесполезная там, где RTL нужен. Вообще, дискуссия эта, скорее, академическая. Bare board платформы помрут, раньше или позже.

 

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

Ада в это число входит (возможно, что и на пределе). Модула - нет.

На мой взгляд, имеет смысл сравнивать только языки-одноклассники.

То есть Аду - с Джавой и клонами С, а Модулу - с Оберонами и проч.

Сравнения "крест-накрест" просто бессмысленны, ибо не могут привести к сколь-нибудь интересным и полезным выводам.

 

И причины тому - куда как сложнее, чем чисто технические

 

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

 

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

сертифицированные системы. Наваляли там на UML или Simulink картинок, сгенерировали из них код, и считается, что это уже безопасно. Какой там branch coverage "УМЕЛьских" блоков?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

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

сертифицированные системы. Наваляли там на UML или Simulink картинок, сгенерировали из них код, и считается, что это уже безопасно. Какой там branch coverage "УМЕЛьских" блоков?

 

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

- и, пожалуйста, творит!

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

сертифицированные системы. Наваляли там на UML или Simulink картинок, сгенерировали из них код, и считается, что это уже безопасно. Какой там branch coverage "УМЕЛьских" блоков?

 

Но если они позволяют на этапе компиляции отловить те логические

ошибки которые не возможно отловить в Аде (в том же FSM), то почему бы и нет?

 

Или же всем следует резко перейти на какой-нибудь Nemerle, где

возможно создавать новые синтаксические конструкции с соответствующей новой семантикой под конкретно решаемую задачу?

On Wed, 18 Feb 2009 11:51:56 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

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

 

Можно и так на это посмотреть :)

 

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

 

Но это не проблема программиста.

 

Я не знаю, что товарищ имел ввиду под "structurally distinct

interpretations". Что такое "структура интерпретации", которая оказалась разной?

 

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

 

И пес с ним! Идея определения идентификатора на предмет переменная или функция, на этапе синтаксического анализа - бред (если мы имеем дело с ОО языком высокого уровня).

 

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

 

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

 

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

 

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

Конкретные решения - следствие подхода.

 

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

 

В частности, я абсолютно не уверен, что возможность интерпретировать F (X) как:

 

- вызов функции

- компонент массива

- преобразование типа

- subtype indication с ограничением индекса

- subtype indication с ограничением дискриминанта

 

есть хорошо.

 

Хорошо! Потому, что ни одна из перечисленных альтернатив не имеет ничего специфического в предметной области программы. Одна и та же вещь там, может быть реализована в Аде как вызов функции, индексация и т.п. Нет никаких причин, почему они должны синтаксически отличаться. Это программисту решать, что означает "эф с икс в скобочках". Та же ситуация имеет место с F.X (вызов, член, точка входа, имя и т.п.) Более того, это ровно то же, что и F + X. + здесь это что?

 

Идея разлива семантики в синтаксис принципиально порочна в корне.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

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

 

Ну, это ОЧЕНЬ сильное утверждение :)

 

В частности, я абсолютно не уверен, что возможность интерпретировать

F (X) как:

 

- вызов функции

- компонент массива

- преобразование типа

- subtype indication с ограничением индекса

- subtype indication с ограничением дискриминанта

 

есть хорошо.

 

Хорошо! Потому, что ни одна из перечисленных альтернатив не имеет ничего

специфического в предметной области программы. Одна и та же вещь там, может

быть реализована в Аде как вызов функции, индексация и т.п. Нет никаких

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

решать, что означает "эф с икс в скобочках". Та же ситуация имеет место с

F.X (вызов, член, точка входа, имя и т.п.) Более того, это ровно то же, что

и F + X. + здесь это что?

 

Идея разлива семантики в синтаксис принципиально порочна в корне.

 

Рассказываю про боевые грабли, которые не я один нашел.

 

Есть такая штука - ASIS. Я ее по долгу службы наизусть знаю.

 

Так вот, есть в этом ASIS'е такие объявления в разных пакетах

 

package Asis is

...

type Element is ...

...

subtype Subtype_Mark is Element;

subtype Definition is Element;

subtype Expression is Element;

...

end ASIS;

 

package Asis.Definitions is

...

function Subtype_Mark

(Definition : Asis.Definition)

return Asis.Expression;

...

end Asis.Definitions;

Ж Иво т умен я вкод ебыл:

 

New_Element := Subtype_Mark (Old_Element);

 

о Ябы лувере, нчт о явызыва юФУНКЦИ Subtype_Mark, Ю аво тспецификаци

иконтекст а ииспользовани япакето (use) влегл ита, кчт оэт ооказалос

ьпреобразование мтип. а Ядолг он емо гпонят, ькаког орожн амно йнаписанна

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

оон - авовс ен ефункци, я (атождественно) епреобразовани етип.

 

а Ичт оест ьхорошег о втако "муровн еабстракци"?

 

(ASIS итож енепра, вопределя ядл якрасивост иэт ибестолковы еподтип, ын

оязы-кт овсем уэтом ун евоспрепятствова!)

On Wed, 18 Feb 2009 11:59:14 +0300, you wrote:

 

По моему глубокому убеждению, прикладные языки - рак индустрии разработки

матобеспечения. Что совсем плохо, эта мерзость проникает в

сертифицированные системы. Наваляли там на UML или Simulink картинок, сгенерировали из них код, и считается, что это уже безопасно. Какой там branch coverage "УМЕЛьских" блоков?

 

Но если они позволяют на этапе компиляции отловить те логические ошибки которые не возможно отловить в Аде (в том же FSM), то почему бы и нет?

 

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

 

А вот - конкретика. Как насчет reuse, модульности, капсульности? Возьмем набор блоков UML. Это - модуль? Интерфейс какой? Использовать в другом месте можно? Тестировать как? Реализацию поменять оставив интерфейс?

Ничего нельзя! Добро пожаловать в каменный век!

 

Или же всем следует резко перейти на какой-нибудь Nemerle, где

возможно создавать новые синтаксические конструкции с соответствующей новой семантикой под конкретно решаемую задачу?

 

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

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Wed, 18 Feb 2009 12:34:35 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

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

 

Ну, это ОЧЕНЬ сильное утверждение :)

 

ДА! (:-))

 

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

 

Рассказываю про боевые грабли, которые не я один нашел.

 

Есть такая штука - ASIS. Я ее по долгу службы наизусть знаю.

 

Так вот, есть в этом ASIS'е такие объявления в разных пакетахЖ

 

package Asis is

...

type Element is ...

...

subtype Subtype_Mark is Element;

subtype Definition is Element;

subtype Expression is Element;

...

end ASIS;

 

package Asis.Definitions is

...

function Subtype_Mark

(Definition : Asis.Definition)

return Asis.Expression;

...

end Asis.Definitions;

 

И вот у меня в коде было:

 

New_Element := Subtype_Mark (Old_Element);

 

Я был уверен, что я вызываю ФУНКЦИЮ Subtype_Mark, а вот спецификации контекста и использования пакетов (use) легли так, что это оказалось преобразованием типа. Я долго не мог понять, какого рожна мной написанная функция, которая по определению не может возвращать аргумент в

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

она - вовсе не функция, а (тождественное) преобразование типа.

 

И что есть хорошего в таком "уровне абстракции"?

 

Ничего, проблема не там, а в перегрузке Subtype_Mark, это программист так невольно решил. С правилами видимости в Аде НАСТОЯЩИЕ проблемы. Следующий круг проблем как раз в недостаточном уровне абстракции. Subtype_Mark в обоих случаях должна была бы быть "примитивной" операцией Element. Тогда компилятор бы рявкнул, что function Subtype_Mark переписывает

преобразование подтипа без ключевого слова overriding.

 

(ASIS тоже неправ, определяя для красивости эти бестолковые подтипы, но язык-то всему этому не воспрепятствовал!)

 

Согласен.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

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

Ну, это ОЧЕНЬ сильное утверждение :)

 

ДА! (:-))

 

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

деятельностью, то предмет у нее будет свой.

 

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

 

Ничего, проблема не там, а в перегрузке Subtype_Mark, это программист так

невольно решил. С правилами видимости в Аде НАСТОЯЩИЕ проблемы. Следующий

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

обоих случаях должна была бы быть "примитивной" операцией Element. Тогда

компилятор бы рявкнул, что function Subtype_Mark переписывает

преобразование подтипа без ключевого слова overriding.

 

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

Dmitry A. Kazakov wrote:

On Wed, 18 Feb 2009 11:59:14 +0300, you wrote:

 

По моему глубокому убеждению, прикладные языки - рак индустрии разработки

матобеспечения. Что совсем плохо, эта мерзость проникает в

сертифицированные системы. Наваляли там на UML или Simulink картинок, сгенерировали из них код, и считается, что это уже безопасно. Какой там branch coverage "УМЕЛьских" блоков?

 

Но если они позволяют на этапе компиляции отловить те логические ошибки которые не возможно отловить в Аде (в том же FSM), то почему бы и нет?

 

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

 

А вот - конкретика. Как насчет reuse, модульности, капсульности? Возьмем набор блоков UML. Это - модуль? Интерфейс какой? Использовать в другом месте можно? Тестировать как? Реализацию поменять оставив интерфейс?

Пожалуйста! Всё это возможно!

 

Повторное использование. При наличии готовой UML модели имеется

возможность как расширить уже существующую модель, так и создать

собственную дополняющую модель. Во втором случае случае первая модель остаётся "как есть", вторая определяет необходимые дополнения, а

результат слияния моделей (model merge) порождает полную модель.

 

Модульность. Всё, что есть в UML моделе может размещаться во вложенных пакетах.

 

Капсульность. UML предоставляет возможность определить "потроха"

элементов. Для компонента можно спуститься до сотавляющих его

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

 

Так что каменный век не выходит ;-)

Но если они позволяют на этапе компиляции отловить те логические

ошибки которые не возможно отловить в Аде (в том же FSM), то почему бы

и нет?

А они позволяют? Вот Вы стрелочку не справа налево, а слева на право

поставили. И как это ошибку найти? А в Аде стрелок нет, да и в Ассемблере

тоже. Рассуждения такого рода - на кофейной гуще.

Позволяют. Например если вы на одно событие нарисуете из текущего состояния ДВА (и более) перехода то оно таки матюгнется ещё на этапе компиляции. Как того же добиться средствами Ады?

 

Или же всем следует резко перейти на какой-нибудь Nemerle, где

возможно создавать новые синтаксические конструкции с соответствующей

новой семантикой под конкретно решаемую задачу?

Не надо создавать синтаксические конструкции. Их достаточно уже.

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

 

Между

прочим, в натуральных языках синтаксис самая консервативная вещь. Помните,

"...и хрюкотали зелюки, как мумзики в мове."?

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

Новое сообщение:
Страницы: 1 2 3

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти