Здравствуйте, cat-man-do, Вы писали:


CMD>В Oberon-е мне нравится _однозначность_ его конструкций. Например, то что в C# можно написать System.Console.WriteLine и Console.WriteLine _я_ уже считаю недостатком языка. Если я в программе на Oberon вижу цепочку identifier1.identifier2.identifier3, то всегда знаю что identifier1 объявлен в текущем модуле и могу быстро посмотреть что он означает.
Не факт, что это достоинство. Фактически, это означает необходимость везде использовать Fully Qualified Names. В среде с развитыми библиотеками это привело бы к идентификаторам кошмарной длины. Как вам имя класса System.Data.SqlClient.SqlConnection?
CMD> Если мне встречается Console.WriteLine в программе на C# я не смогу сразу понять что такое Console и откуда оно взялось, я в курсе, что современные IDE легко позволяют мне это определить, но это решение одного из проявлений проблемы, а не ее самой.
Ну, если так не хочется использовать короткие имена — выкинь все using. Прелесть в том, что всегда есть выбор
CMD>В Delphi похожие недоработки языка приводили к необходимости, в сложных библиотеках, идентификаторов состоящих из 8-10 слов.
Нет. В Delphi недоработка состояла в одноуровневости имен пакетов, что приводило к вынужденным конфликтам имен. И то, на самом деле всегда можно было использовать Qualified Name безо всяких десятисловных идентификаторах.
CMD>В Oberon невозможно обратится к полям/методам результата функции, его можно только присвоить переменной или передать в другую функцию/процедуру, после Delphi это очень раздражало, но то, что вызов метода выглядит как вызов метода (последовательности действий, возможно изменяющих переменные/поля) и отличается от обращения к полям _я_ засчитываю как достоинство языка.
Хм. Это на Delphi вызов метода выглядит как обращение к полю или свойству. На C# вызов метода отличается весьма характерными скобочками.