Здравствуйте, FR, Вы писали:

AVC>>Ну вот мне после 20 лет интенсивного кодирования на Си подумалось, что основная.
FR>Не знаю, по моему основное в си максимальная близость к железу, все остальное следствия.

"Близость к железу" — скорее, все-таки, "идея".
Если разбирать конкретные особенности языка, то "близость к железу" превратится в конкретные пункты:

1) наличие битовых операций (хотя нет циклических сдвигов );
2) спецификатор register, помогающий компилятору разобраться, какую переменную лучше поместить в регистр (в основном, это уже в прошлом);
3) и, наконец, адресная арифметика, позволяющая, например, программисту вручную выделять "индуктивные" переменные в цикле.

Пункты 2 и 3 позволяют программисту неплохо оптимизировать циклы вместо оптимизатора.
При наличии оптимизатора надобность в них отпадает, а адресная арифметика начинает скорее мешать оптимизации, чем помогать, т.к. способствует созданию "псевдонимов памяти" — известных блокираторов оптимизации.

FR>>>А какой именно характер у твоего ПО?
AVC>>В основном — системное (компиляторы, отладчики и т.п.).
FR>Такие вещи говорят как раз проще писать ML подобных языках, например на том же Ocaml'е

Спасибо тебе (а также WolfHound-у) за эту мысль.
Интересно будет познакомиться с другим подходом.

AVC>>Отдаленно похоже на обработку оконных сообщений в Windows, но при полном контроле типов.
FR>То есть аналог dispath (если склероз не подвел) методов из Delphi?

Увы, на Delphi я не писал; до Оберона основными языками у меня были Си/Си++ и Турбо Паскаль (в самом начале 90-х).
Единственно, что могу сказать: "программная шина" появилась в Обероне в 1980-х; в сочетании с модульностью это основной инструмент расширения системы.

Здравствуйте, AVC, Вы писали:

AVC>При создании компилятора надо решить много разных задач, больших и маленьких.
AVC>(Слава Богу, что это давно не целина, а хорошо исследованная область!)
AVC>Кроме лексического разбора, синтаксического и семантического анализа есть еще оптимизация и генерация кода, сохранение отладочной информации и т.д.
Это тоже все оченьхорошо делается при помощи pattern-matching'а.
Ведь нам больше не нужно что-то придумывать ибо вместо этого мы можем просто написать паттерны.
AVC>Есть и свои противоречия: например, трудновато совместить оптимизацию кода и отладку (оптимизированный код далек от исходного).
Честно говоря вобще невижу смысла смешивать оптимизацию и отладку.

AVC>Что же касается синтаксического анализа, то частенько "все сделано до нас" (для известных языков).
А для толькочто придуманых?

AVC>Если есть необходимость написать парсер и не хочется писать его методом рекурсивного спуска a-la Wirth (или грамматика не позволяет), то в нашем распоряжении yacc (для LR-грамматик) или CoCo/R(для LL(1)-грамматик; кстати, автор CoCo/R является также автором языков Object Oberon и Оберон-2).
Тут не все так простл. Попробуй ими распарсить тотже C#... Влад пытался использовать CoCo/R но получилось мягко говоря не очень. А что касается всяких yacc'ов то их озвереешь отлаживать и добится от них человекочитаемых сообщений об ошибках.

AVC>А какие есть проблемы с заглядыванием вперед?
LL(1) циифирка 1 о чем говорит?
AVC>Если я пользуюсь генератором парсеров, то я вообще с такой проблемой не сталкиваюсь.
ты только с ней и сталкиваешься... просто ты уже привых укладывать грамматики в прокрустово ложе парсеров.
AVC>Если пишу парсер вручную, то заглядывание происходит всего на один символ вперед.
А я могу заглянуть на сколько нужно.

Здравствуйте, WolfHound, Вы писали:

WH>Я тут пишу парсер простенького языка описаний чтото типа такого:
WH>

WH>channel FileStorageChan[b]n[/n]el
WH>

Может быть так? Или я не понял смысла ключевого слова?

Забыл извинться за оффтопик

Прошу прощения за оффтоп

Здравствуйте, WolfHound, Вы писали:

WH>LL(1) циифирка 1 о чем говорит?
WH>А я могу заглянуть на сколько нужно.
Всё равно это будет LL(N). На Обероне можно сделать практически так же, хотя длиннее и не так красиво.
[code]
IF tokens[pos] IS Identifier & tokens[pos](Identifier).name = "chanel"
& tokens[pos+1] IS Identifier
& tokens[pos+2] IS Brace
THEN
parseChanel(tokens[pos+1](Identifier).name, tokens[pos+1].Brace.decls,0);
parse(tokens, pos+2);
ELSIF ...
[code]

А вот Пролог позволяет не парицца с N.

Здравствуйте, gandalfgrey, Вы писали:

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

Здравствуйте, VladD2, Вы писали:

VD>Своим частным мнением? Создай голосование, увидишь чего оно стоит.
Мы все еще говорим про надобность / необходимость IDE ?
А как создать голосование ?

Здравствуйте, Дарней, Вы писали:

Д>Муниципальный софт, говоришь? Тогда неудивительно, что не жалуются Народ там не избалован удобными программами, мягко говоря.
А как связан тип написуемого софта с использованием / неиспользованием IDE ?
Не жалуются-то разработчики, а не конечные юзвери — которым как-то без разницы, каким образом это писалось. Им ( юзверям ) хочется удобный и красивый гуй, который они и получают.

VladD2 wrote:

> kan>А это точно всё?
> Ага. Для событий все. Причем не нужно даже ядрёной енергии макросов.
> Просто более грамотный дизайн языка.
"640кб оперативной памяти должно быть достаточно для каждого".

> kan> Ты уверен, что банальный массив указателей на методы удовлетворит
> жаждущего паттерн Visitor?
> Уверен, что нет. Но на личном опыте убеждался, что средствами
> метапрограммирования паттерн Посетитель реализуется элементарно. Далее
> он ложится в библиотеку и становится столь элементарным в исползовании,
> что просто поразительно как другие тратят столько времени на его
> реализацию и, самое главное, на его поддержание.
Реализованный паттерн Посетитель это уже не паттерн, а конкретный алгоритм.

> kan> Ведь если взять те же boost::signals и посмотреть что там есть:
> kan>Ordering slot call groups
> kan>Passing values from slots
> kan>Disconnecting Slots
> kan>Blocking Slots
> kan>Scoped connections
> kan>Или это уже не паттерн?
> Весь буст это недоразумение. В нем в основном реализуется то, что должно
> быть реализовано в языке. Это мое, сугубо личное, мнение.
Забудь о том что это буст. Перечисленные возможности по-твоему к чему относятся? Это паттерн Посетитель? Или что?
Посмотри на SObjectizer (110000 строк кода, ну ладно, пусть на Nemerle будет в 100 раз меньше, 1100 строк), это всё ещё
события? Асинхронных событий никому не нужно? Что именно должно быть реализованно в языке?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> Ради этого вводить сущность event? А не проще было сделать интерфейс addEvent, removeEvent. А прямой доступ вообще закрыть. Или сдесь еще есть что-то?
Вы не могли бы излагать свои мысли более внятно?
Ок, попробую угадать, что имелось в виду в качестве альтернативы:

public interface IEvent 
{
  void AddHandler(EventHandler handler);
    void RemoveHandler(EventHandler handler);
}

public class EventPublisher
{
  private class EventImplementation: IEventHandler
    {
      private EventHandler _handler;
    public void AddHandler(EventHandler handler)
        {
            _handler += handler;
        }
        public void RemoveHandler(EventHandler handler)
        {
            _handler -= handler;
        }
        public void Invoke(object source, EventArg args)
        {
          if(_handler != null)
                _handler(source, args);
        }
    }
    
    private EventImplementation _eventHandler = new EventImplementation();
    public IEvent SomethingHappen { get { return _eventHandler; } }
}


public class EventSubscriber
{
    public SubscribeTo(EventPublisher p)
    {
        p.SomethingHappen.AddHandler(HandleEvent);
        p.SomethingHappen.RemoveHandler(HandleEvent);
    }
    private void HandleEvent(object sender, EventArgs a)
    {
    }
}

И вот это называется проще? Разработчикам компилятора естественно проще. К счастью, Хейльсберг больше думал о программистах, чем вы предлагаете. И встроил вот этот громоздкий паттерн в язык.

Здравствуйте, VladD2, Вы писали:
VD>Event можно сделать классом и наружу выставить только операторы + и -.
Влад, это потребует написания класса на каждый чих. Зачем?
В качестве упражнения: попробуй реализовать аналогичную евентам функциональность в библиотеке на C# 2.0.
VD>Ключевое слово event в C# банально вводит свойство доступное только для чтения обеспечивая доступ к нему только по операторам + и -. В общем, бессмысленный хардкодинг.
Влад, в твоем возрасте пора бы уже привыкнуть к тому, что "Влад не видит смысла" != "бессмысленный". Ключевое слово event, кстати, никакого свойства не вводит. Оно вводит два спецметода похожим на свойство образом. Кроме того, оно иногда автоматически вводит поле подходящего типа.

VD>Да и кому такая инкапсуляция нужна. Это что инкапсуляция ради инкапсуляции?
Как бы всем. Влад, евенты встречаются в дотнете сплошь и рядом. Инкапсуляция, очевидно, нужна для устойчивости кода к мелким ошибкам, непроверяемым компилятором.
VD>В Дельфи не было списка.
Я в курсе.
S>> В дотнете все грабли именно с тем, что для свойства есть риск сделать = вместо +=.
VD>Для этого достаточно сделать свойство доступное только для чтения или такое же поле. В общем, это уже притягивание за уши никому не нужной фигни.
А общем, это уже просто нежелание напрячь мозг на 10 секунд чтобы понять очевидные вещи.
VD>Да и в Дельфи никогда проблем не видел.
Ну конечно не видел. Евенты в дельфи были одиночными, поэтому ситуация случайного переписывания обработчика вместо добавления в список не могла возникнуть.
Зато в тех местах, где была нужна множественная подписка, в VCL была написана просто тонна кода. Поверь мне на слово, Влад, Хейльсберг гораздо лучше, чем ты, знает достоинства и недостатки Delphi.
VD>А вот то что в язык вообще не надо встраивать ничего чтобы получить такой же эффект — это показатель. И таких вещей море.
VD>В общем, я согласен с автором статьи приведенной в теме, что наличие паттернов является показателем отсуствия в языке нужных средств.
Совершенно верно.
VD>И согласен с Курилкой, что лучшим решением будет не хардкодинг паттернов в языке, а добавление средств позволяющих оформлять паттерны в виде библиотек и расширять язык шататными средствами.
Совершенно верно. Поддержка event в шарпе — это хорошо. Необходимость переделки компилятора для этого — плохо. Я уверен, что nemerle позволяет реализовывать такие вещи без обращения к разработчикам компилятора. Что позволяет надеяться на его повальное внедрение.

Здравствуйте, gandalfgrey, Вы писали:

G>Не жалуются-то разработчики, а не конечные юзвери — которым как-то без разницы, каким образом это писалось.

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

Здравствуйте, Дарней, Вы писали:

Д>Ну если так — пардон, неправильно понял.
Д>А каков примерно функционал системы и объем кода?
Сервер — на Ерланге. Включает в себя компилятор и среду выполнения своего спец-языка. Есть движок правил — для более жесткого и простого описания логики там, где это возможно. + процессор запросов от клиента. Все это поддерживает некую модель представления данных и связей между ними, как-то Человек-Прописка-Квартира ( в самом простом случае ). По замыслу, должно быть пригодно для обработки любой информации в рамках муниципальных отношений. Просто дописываются скрипты / правила для реализации дополнительной логики.
Клиент — на Тикле + чуть-чуть С. В нем : шина сообщений, процессор интерфейсов — автоматическая обработка форм в смысле сборки / разборки данных ( пока для не шибко сложных форм ), ну и куча формочек...
количество кода — для сервера 7500 строк, из них писано руками 4500, остальное сгенерено для лексера и парсера. Это после рефакторинга так сплющилось — аж самим удивительно, сколько мусора болталос... Для клиента — 6000 строк, из них где-то половина — это описание геометрии и инициализация.
Если бы мы с самого начала знали, какой рынок будет у нас СЕЙЧАС...месяца за 4 написали бы. Текущая реализация написана месяца за 2.5 — но не с нуля.

Здравствуйте, kan, Вы писали:

kan>"640кб оперативной памяти должно быть достаточно для каждого".
Демагогия.

kan>Реализованный паттерн Посетитель это уже не паттерн, а конкретный алгоритм.
Ты этим что хотел сказать?

kan>Забудь о том что это буст. Перечисленные возможности по-твоему к чему относятся?
boost::signals это жуткий мутант и ошибка природы которая должна умереть.
kan>Это паттерн Посетитель? Или что?
Это точно не посетитель. Ты вобще знаешь что такое посетитель и зачем он нужен?

kan>Посмотри на SObjectizer (110000 строк кода, ну ладно, пусть на Nemerle будет в 100 раз меньше, 1100 строк), это всё ещё события? Асинхронных событий никому не нужно? Что именно должно быть реализованно в языке?
Замыкния.

А что касается SObjectizer то мне тоже понадобилось асинхронное общение но идеология SObjectizer'а меня мягко говоря не впечатлила.
Пишу свой велосипед.

Здравствуйте, Курилка, Вы писали:

Паттерны, они разные бывают. Не только примитивные и универсальные, описанные в GoF.

Здравствуйте, AndrewVK, Вы писали:

AVK>Паттерны, они разные бывают. Не только примитивные и универсальные, описанные в GoF.

И что ты этим хотел сказать?

WolfHound wrote:

> kan>Реализованный паттерн Посетитель это уже не паттерн, а конкретный
> алгоритм.
> Ты этим что хотел сказать?
Паттерн != алгоритм. Реализация паттерна есть алгоритм (и то не всегда). Реализация алгоритма есть библиотека или
конструкция языка. Я понимаю, что часто эти понятия путаются, чаще ради упрощения, но в данном контексте, при обсуждении
сабжа — это важно различать.

> kan>Забудь о том что это буст. Перечисленные возможности по-твоему к
> чему относятся?
> boost::signals это жуткий мутант и ошибка природы которая должна умереть.
> kan>Это паттерн Посетитель? Или что?
> Это точно не посетитель.
А что?

> Ты вобще знаешь что такое посетитель и зачем он нужен?

In object-oriented programming and software engineering, the visitor design pattern is a way of separating an
algorithm from an object structure. A practical result of this separation is the ability to add new operations to
existing object structures without modifying those structures.
(с) http://en.wikipedia.org/wiki/Visitor_pattern

В общем почти всё. Это относится к "public MyEvent : Event[int -> void] = Event();" довольно слабо. Что именно должно
поддерживаться языком?

> kan>Посмотри на SObjectizer (110000 строк кода, ну ладно, пусть на
> Nemerle будет в 100 раз меньше, 1100 строк), это всё ещё события?
> Асинхронных событий никому не нужно? Что именно должно быть реализованно
> в языке?
> Замыкния.
Причём тут это? Замыкания требуют gc, а языки без него уже не языки и в них паттерны не реализуются?

> А что касается SObjectizer то мне тоже понадобилось асинхронное общение
> но идеология SObjectizer'а меня мягко говоря не впечатлила.
> Пишу свой велосипед.
Неважно. Вопрос в другом. Ассинхронные сообщения это Event? А если сообщение можно временно блокировать, это всё ещё
Event? Или event это только то, что поддерживается языком "public MyEvent : Event[int -> void] = Event();"?

Здравствуйте, AVC, Вы писали:

AVC>Из всего, что я здесь прочел, напрашивается вывод, что "современными" считаются императивные языки с включением отдельных функциональных конструкций.

Не только. Современным может быть и чистый функциональный язык, например. Но это не важно.
Непонятно, кстати, почему слово "современные" Вы ставите в кавычки. Современные без всяких ковычек. Просто тенденция сейчас такая, веянье времени.
Если мы говорим об императивном ООП, то есть и нововведения которые никак нельзя назвать "отдельными функциональными конструкциями".
В этом смысле Scala — очень показательный пример.

Здравствуйте, Курилка, Вы писали:

AVK>>Паттерны, они разные бывают. Не только примитивные и универсальные, описанные в GoF.

К>И что ты этим хотел сказать?

То, что встраивать в язык паттерны вроде трехзвенного приложения или SCOAB было бы перебором, не находишь?

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

Здравствуйте, AndrewVK, Вы писали:

AVK>По факту есть паттерны, которые можно сделать конструкциями языка. Есть паттерны, для которых можно написать библиотеку, облегчающую их реализацию. Для некоторых паттернов нужна метабиблиотека. А некоторые — просто набор абстрактных идей. Пытаться подравнять все паттерны под одну гребенку, а потом делать на основе этого глубокомысленные выводы я бы не советовал.

По факту получается, что паттерны — это слишком размазанное понятие,