Ответ на »сообщение 2648« (Владимир Лось)
___________________________

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

Исходя из опыта общения на форумах RSDN, могу заявить, что идиосинкразия уже начинается просто от слов PROCEDURE, BEGIN, END... - только этого уже вполне достаточно.

Ответ на »сообщение 2648« (Владимир Лось)
___________________________

Насчет Эль-76. Была книга Пентковского. Больше, по-моему, книг по нему ничего не выходило. Насколько помню, в Бауманском использовали эмулятор Эль-76 (под Windows).

Есть еще один проект, неким боком затрагивающий Оберон и Эль-76.

http://www.enlight.ru/frog/index.php?page=c_pindraft

Ещё новости-размышлизмы:
http://www.unixreview.com/documents/s=9846/ur0508l/ur0508l.html

Ответ на »сообщение 2647« (Руслан Богатырев)
___________________________
Практика показывает, что языку программирования в современных условиях пробиться 'в люди' можно лишь одним из двух способов.
Первый ...
Второй ...
Знаете, Руслан, по моему опыту, всё-таки, главное - что бы язык, с точки зрения "обычного" программиста, не имел слишком много "высоконаучной" зауми...
Вот когда, мы, давая язык, начинаем сразу же говорить о какой-то там "дисциплине", "технологии", "теоретической базе" - у "народа" начинается идиосинкразия.
При всей своей нелюбви к Сям, должен признать, что он представляет собой довольно прямолинейно-естественный способ получить непосредственный доступ к выч.модели (воплощённой в железе) современных архитектур...

Сколько бы мы не пытались "привить вкус", пока архитектура останется "калькуляторной", тенденцию переломить не удасться...

Попробуйте поработать на Лисп-процессоре на Си. Или на Катане (Смолток-ориентированный процессор). Может и получиться, но с большими "издержками". Те же издержки (только зеркально отображённые) мы получаем и для тех, кого пытаемся приучить Модуле, Оберону, Смолтоку и Форту с Лиспами...

Это мы "пляшем" от "формулок" и "научных теорий", а я теперь вот (на новой работе) бьюсь, что бы заставить людей воспринять ОО-подход в проектировании ОЧЕНЬ ответственных систем... Одна из "опорных точек" - раскрыть им глаза, ЧЕМ Си, не смотря на свои отдельные приятные качества, всё же, не подходит для проектирования сложных и больших систем. Не получается. Разум людей плотно закрыт наслоениями мифообразного порядка. Вплоть до глубокой и ни чем непоколебимой убеждённости, что Ада - интерпретатор... Представляете, что будет, если я о bluebottle разговор заведу или о новом ядре от esmertec? :о)

Язык Си позволяет в полной мере реализовывать сиюминутный "заплаточный" способ производства систем. Тех, кто его "знает" - плюнь - не промахнёшься. А менеджеры "старшего поколения" до сих пор несут знания о программированиии из своей фортранной молодости. Причём, они строго экстраполируют на проектирование больших систем свои "осчусчения" на счёт, "как писать программы" из своих курсовых студенческо-аспирантской юности и 1000-строчных РАСЧЁТНЫХ программ. И никак не поймут, что, СОБСТВЕННО РАСЧЁТНЫЕ ЧАСТИ, - НЕ ЕСТЬ ГЛАВНОЕ...

С другой стороны, ну кто остался в пресловутых НИИ? "Тётеньки" и люди предпенсионного возраста... Слава Богу, что вещи, делаемые ими до сих пор летают и "пикают" (хоть и "с грехом пополам"). Они только-только Си "освоили", научились (не все, правда!) правильно располагать аргументы gсс... И тут приходит Влад, весь такой "теоретически подкованный" и "с опытом работы" и начинает непонятные вещи говорить... Это ж просто - "культурный шок"...

"Наследование", "выделение интерфейсов", "формирования набора сущностей предметной области", "согласование семантики элементов интерфейса"... Где-то на третьей фразе или начинается зевота, или  (по глазам видно! :о) ) начинается напряженная мыслительная работа по поиску причины "слинять"...

"Написано, оттестировано? - из головы - вон"...

А в исходниках - вещи, совершенно дичайшего порядка!
Вот представьте ситуацию: три компонента (ну, это я их компонентами называю, чисто условно). Один вызывает другой и ждёт результата операции. Второй передаёт это по rs232, тоже ждёт окончания операции и должен оповестить третий компонент (этот, последний является подобием View).

Я, когда код своего предшественника стал разгребать, - волосы дыбом встали! В куче мест - первый компонент оповещался об окончании операции вторым до её окончания. На Viewer отсылались данные ещё до завершения обмена с внешним устройством.
...А потом все хором удивляются "странному поведению" программы и плодят байки о "самостоятельной жизни" программ и "трудноуловимых ошибках"...
Сейчас этот человек в Канаду уехал. У него (по рассказам) более 10 лет работы в Юникс-системах.
Что это? Кто оценивал его знания? Тут бьёшься над каждой строчкой, "вылизываешь" код не только на "локальную" правильность, но и постоянно сверяешь это с архитектурой "взагали", а граждане "левой ногой", "шо слюна на язык принесла", - "льют" в код... Нет, ежели "оно" такое ТАМ всё поехало (сумев "нарисовать" перед тамошними работодателями о себе, как о специалисте, "красивую картинку"), то  - на душе спокойней... :о) Не зря ж, при всех громогласных славословиях, их марсоход каждые два часа ресетится... :о) Но ведь и здесь (в массовом порядке) и такого не остаётся... Или идёт веб-странички рисовать...

При чём тут синтаксические конструкции, если на архитектурном уровне и при проектировании работа делалась, как в бреду или в угаре? Или это элементарное вредительство? Термин затасканный, но другого ничего на ум не приходит!

А отладка и исправления ошибок, временами, меня просто "в умиление приводят": вылетаем за границы массива и начинаем "гадить" в соседнем массиве? - ОК - увеличь свой массив, примерно, на столько элементов, на сколько обычно "вылезаешь"...

А ведь это - не системы не складского учёта, не "бухгалтерия". Тут если чего "не так" "щёлкнет", может быть "фейерверк" на пол-Евразии...

ЗЫ Граждане, меня интересует всё, что есть про Эль-76. Дайте ссылок или вышлите, у кого чего есть, пжлст!

Вчера на глаза мне попался первый номер журнала 'Технология программирования' (1995). Прочитал свою вступительную статью и удивился, насколько она перекликается с днем сегодняшним. Судите сами.

'Первый номер нового журнала посвящен представлению незаслуженно забытого языка Modula-2. Судьбу его и в самом деле счастливой не назовешь. Почему же так произошло, что начав десяток лет назад свое триумфальное восхождение на Олимп, он за несколько лет погрузился в пучину безвестности? Хотя на его основе был разработан М-код, созданы компьютеры Lilith и Kronos, написано множество операционных систем, в частности, для IBM AS/400, созданы компиляторы для различных платформ, начиная от PC, Macintosh и Amiga и кончая такими экзотическими, как 'Эльбрус' и транспьютеры Inmos.

Мнения на сей счет разные, но все же наиболее правдоподобные рассуждения кроются в отсутствии общепринятых библиотек и подобия какого-то стандарта. Первые компиляторы языка следовали каноническому описанию PIM (по первым буквам книги Вирта 'Programming in Modula-2'). Но какой бы хорошей книга ни была, все же она не стандарт. Нет стандарта -- нет и поддержки представителей промышленных кругов. Стандарт утрясали так долго, что даже самые преданные участники этого процесса потеряли веру в то, что увидят его при своей жизни.'

Прошло 10 лет с момента написания тех строк. Теперь можно спокойно слово 'Modula-2' заменить на 'Oberon' -- остальное почти не изменится.

Посмотрите, язык Java до сих пор не имеет международного стандарта (ни ISO, ни ECMA). И ничего. Обходится. Microsoft, пользуясь своим влиянием на комитет по стандартизации в европейской ECMA (European Computer Manufacturer's Association), в мгновение ока протолкнул туда C#, а заодно надолго отбил охоту у Sun заниматься международной стандартизацией Java. ISO/ECMA-стандарт на Delphi -- это что-то из области фантастики. Modula-2 в 1995 г. получила-таки ISO-стандарт, но ее это от забвения не спасло.

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

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

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

Ответ на »сообщение 2645« (Сергей Губанов)
___________________________

Ну тады только через SYSTEM. Хотя можно такую процедуру и в Meta добавить...

Ответ на »сообщение 2644« (Иван Горячев)
___________________________

Чисто абстрактный ответ - а
a # b
не прокатит?

Не прокатит:
1) Для RECORD-ов нет операций сравнения.
2) Для элементарных типов a # b сравнит значения переменных, но не установит того, что ссылки a и b ссылаются на одну и ту же переменную.

Ответ на »сообщение 2643« (Сергей Губанов)
___________________________
Чисто абстрактный ответ - а

a # b

не прокатит?

Чисто абстрактный вопрос. Просто любопытно.

PROCEDURE Do (VAR a, b: SomeType);
BEGIN
  (* ... *)
END Do;

Как узнать, что a и b - ссылки на разные объекты, т.е. как отличить вызов Do(X, X) от вызова Do(X, Y)?

Понятно, что можно как-нибудь так:

IF SYSTEM.ADR(a) # SYSTEM.ADR(b) THEN ... END;

но есть ли другой способ (без SYSTEM)?

Ответ на »сообщение 2640« (Сергей Губанов)
___________________________
Мур, вроде, предсказывал удвоение не по частоте, а по количеству транзисторов в процессоре.
Да, действительно, "с прямым углом перепутал"... :о)
Но, согласитесь, замедление роста частоты - тоже показательно...
Правда сейчас оно начинает удваиваться за счет удвоения количества процессорных ядер.
Ну и что толку?
Во-первых, специализация компонентов необходима, а тут мы вынуждены постоянно "мигрировать" по исполняющим элементам (со всеми "радостями" переключения контекстов и синхронизации).
Во-вторых, возрастает неимоверно сложность "коммутации" между элементами исполнения (минимум квадратичная зависимость)...
Проблемы будут расти до тех пор, пока мы не научимся менять структуру (архитектуру) элементарных исполняющих блоков (и шинные интерфейсы со всеё их "требухой" - протоколами, уровнями, последовательностями сигналов) за один такт... :о)

То есть настраивать исполнительную среду на задачу, а не наоборот...

ЗЫ Ну, или хотя бы, за два... :о)