Ответ на »сообщение 905« (AVC)
___________________________


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

Чтобы не быть голословным, сошлюсь хотя бы на один источник:
http://www.rsdn.ru/article/philosophy/SyntacticSugar.xml
Возможно, кому-то это покажется интересным.
Вообще -- противоположную точку зрения тоже надо знать...

Что думает по этому поводу почтеннейшая публика?

Ответ на »сообщение 904« (12)
___________________________

Вероятно на RSDN так не считают. Предложить им взять реализацию фич от Oberon-а и не мучаться?

Ребят с RSDN вообще не так-то легко понять, уж больно они крутые...
Подавай им замыкания, и все тут!
Спрашиваю: ребята, ведь в замыкании главное "прихватить" контекст; а если так, то чем вам объекты-то не подходят? (Сами говорят, что в ряде ФЯ объекты реализуются через замыкания.)
Нет, говорят, замыкания -- круче! Гораздо круче!
Но только вот я так и не понял, зачем нам замыкания в объектно-ориентированном языке... :(

Сейчас на RSDN в большом фаворе Nemerle.
Возможно, потому что позволяет менять язык, с помощью макросов, не переделывая компилятор.
Какая гибкость!
А действительно ли это хорошая идея?
Чем она принципиально отличается от популярной в 1960-е идеи "расширяемых языков"?
Если интересно, мнение Вирта (по поводу старой инкарнации этой идеи) можно найти здесь:
http://www.rsdn.ru/article/philosophy/virt.xml
в разделе "Смешанные методы / синтаксический анализ".

Кстати, в приватной переписке некоторые RSDN-щики (как мне кажется, самые опытные и рассудительные) отмечают, что Вирт "во многом прав". (Это о статье "Хорошие идеи: взгляд из Зазеркалья".)

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

Вероятно на RSDN так не считают. Предложить им взять реализацию фич от Oberon-а и не мучаться?

Ответ на »сообщение 902« (Илья Ермаков)
___________________________

Кто-то выше упоминал об идее Шиперски касательно дженериков (не Вы ли, Сергей?)...
А можно поподробнее, и ссылочку дать? А то меня как раз эта тема интересует...

Это, наверное, был я. :)
Вот ссылки:

http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz
http://sky.fit.qut.edu.au/~roe/papers/JMLC97.ps.gz

Здесь эта статья в постскриптовском формате.

Кто-то выше упоминал об идее Шиперски касательно дженериков (не Вы ли, Сергей?)...
А можно поподробнее, и ссылочку дать? А то меня как раз эта тема интересует...

Ответ на »сообщение 898« (AVC)

Сергей, Вы могли бы назвать навскидку пару пунктов, иллюстрирующих Ваше мнение?

Пару пунктов?

1) Ну, например, с конструкторами объектов там уж больно накуролесили и вообще с инициализацией. Например, в Component Pascal у модуля есть секция, которая выполняется при его загрузке - и всё. В .Net библиотеке может присутствовать несколько статический классов и в каком порядке их члены инициализируются понять не реально. Вот, вопрос на засыпку:

namespace ConsoleApplication1
{
internal static class A
{
public static int a = B.b + 1;
}

internal static class B
{
public static int b = A.a + 1;
}

class Program
{
static void Main (string[] args)
{
System.Console.WriteLine("A.a = " + A.a + ", B.b = " + B.b);
System.Console.ReadLine();
}
}
}

Что будет напечатано?

2) Поскольку разрешено писать идентификаторы без их полной квалификации (используя using), то народ их так и пишет сокращенно (лично я всега полное имя пишу, и даже this пишу везде где это возможно). Взяв чужой текст чрезвычайно легко "залететь" при подключении к проекту очередной библиотеки в которой случайно используются аналогичные имена идентификаторов (скажем Packet, Call, Table - довольно часто используемые названия и писать их без полного квалифицирования нельзя, а пишут засранцы, потому что язык позволяет). Опять же пространство имён зачастую никак не связаны с именами библиотек, так что не понятно в какой из подключенных библиотек определён тот или иной идентификатор.

Ответ на »сообщение 896« (AVC)
___________________________

Сейчас вот только вернулся с очередной сессии обсуждения системы обработки данных со своими экспериментаторами.
Чтоб я сдох: провались пропадом все эти, блин, функции высших порядков...

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

С Трурлем трудно не согласиться насчет параметрического...
Но и тут keep it simple, stupid: редко это встречается, можно скопировать код и поменять там INTEGER на CHAR...

..... все эти замыкания -- говорю как математический физик.

Ответ на »сообщение 882« (AVC)
___________________________
>>>Бог мой, когда же это? :)
В самом начале 60-х. Цепочку CPL->BCPL->B->C можно представить как последовательное искоренение фич.

>>>Главное -- как Вы относитесь к отсутствию таких фич в Обероне?
Со смирением. :-) Иногда кое-что хотелось бы иметь, особенно параметрический полиморфизм. Мне даже кажется что было бы полезнее вместо Object Oberon и затем Oberon -2 сделать какой-нибудь Generic Oberon. Но мода тогда была другая.

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


Сергей, если есть возможность, не могли бы Вы назвать ряд пунктов, где, по Вашей оценке, Обероны до сих пор превосходят C#? Мне это крайне интересно.

Пункт-то всего один: чистота дизайна. Всё остальное - фичи.

Т.е. дизайн дотнета "нечист" (избыточен? "неконсистентен"? противоречив?).
В принципе, это можно предположить, учитывая, насколько дотнет сложнее Оберона.
Сергей, Вы могли бы назвать навскидку пару пунктов, иллюстрирующих Ваше мнение?

А то я как-то немного растерялся: тамошние гуру "впаривают" мне множество фич в "новых" языках, а я в них что-то не чувствую потребности; вместе с тем, аргументировать свою "интуицию" мне непросто, т.к. сам я в последнее время занимаюсь в основном встроенными системами, а не "передовыми технологиями".

Ответ на »сообщение 896« (AVC)
___________________________

Вдогонку. :)
Единственное, об отсутствии чего в Обероне я на самом деле (иногда) жалею -- параметрический полиморфизм (хотя бы в виде дженериков).
Почему-то не прижилась идея Шиперского (возможно, есть технические трудности).
А ответ Гуткнехта я тогда так и не понял... :(