Здравствуйте, raskin, Вы писали:
>> Я "познакомился" с Обероном года три назад. >> Язык восхитил меня компактностью, простотой (я выучил его за день) и >> гармоничностью (как все части соответствуют друг другу). (Особенно >> сильные эмоции эти качества вызывают после многих лет программирования >> на Си++. )
R>Глупый вопрос: лучше Pascal? В том варианте, что сейчас есть в FPC R>(объекты есть). Просто интересно, стоит ли оно того. Паскаль популярнее, R>вполне читаем, да и case-sensitivity Оберону приписывают (что я не люблю).
Оберон намного лучше Паскаля (честно говоря, я даже сравнивать их не могу ): проще и намного мощнее одновременно.
Это естественно, т.к. Оберон появился из Паскаля и Модулы-2 в результате эволюции.
Case-sensitivity, правда, есть. Я привык к этому и пытаюсь обратить это качество в плюс: т.к. благодаря case-sensitivity нет нужды в синтаксической подсветке, использую цвет для выделения важных фрагментов по своему усмотрению. Весьма удобно, т.к. выделения цветом сразу бросаются в глаза, их трудно не заметить.
Набирать можно и маленькими буквами, редактор их "превратит" в большие. (Наподобие того, как работает abbr в vi.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
C>Я тут как-то тут сказал, что "Вирт изобретает Эрланг". Сегодня я C>посмотрел спеку Зонона — большая часть идей там сперта из Эрланга C>(концепция активных объектов, обменивающихся сообщениями).
Активные объекты взяты, скорее, из Активного Оберона (как дальнейшее развитие идеи).
И тем, и другим проектом "ведает" Гуткнехт.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, VladD2, Вы писали:
VD>Во всех ваших расскзах я так и не услышал что Вирт думает о функциональном программировании, и что за недочеты он находит в парадигмах. VD>Может кто-нить из вас перескажет эти моменты по продробнее?
На магнитофон не записывал поэтому сейчас помню только в общих чертах. О ФЯ он говорил в русле еще одной "хорошей идеи", которая в последствии оказалась не такой уж хорошей как планировалось в начале. Он перечислил заявляемые ФЯ достоинства, потом поговорил о недостатках, а потом задал сам себе вопрос: "А не являются ли ФЯ академическими игрушками?". Отвечать на этот вопрос он не стал. Подробностей я, к сожалению, уже не помню.
AVC wrote:
> C>Я тут как-то тут сказал, что "Вирт изобретает Эрланг". Сегодня я > C>посмотрел спеку Зонона — большая часть идей там сперта из Эрланга > C>(концепция активных объектов, обменивающихся сообщениями). > Активные объекты взяты, скорее, из Активного Оберона (как дальнейшее > развитие идеи). > И тем, и другим проектом "ведает" Гуткнехт.
Просто смешно смотреть на такие эксперименты, когда есть уже реально
работающие реализации с отшлифованым механизмом.
AVC wrote: > R>Глупый вопрос: лучше Pascal? В том варианте, что сейчас есть в FPC > R>(объекты есть). Просто интересно, стоит ли оно того. Паскаль популярнее, > R>вполне читаем, да и case-sensitivity Оберону приписывают (что я не люблю). > > Оберон намного лучше Паскаля (честно говоря, я даже сравнивать их не > могу ): проще и намного мощнее одновременно.
Ну, на почти всю спецификацию языка FPC, как и на спецификацию Scheme,
меня хватило. Так что простоты хватает. А чем мощнее? (на моё мнение
влияет, кстати, то что я написал препроцессор Паскаль, берущий
Паскаль-код отмеченный > в первой колонке, компилирующий, и
подставляющий результат. Техническое метапрограммирование это позволяет
легко, и более-менее всё, что угодно достижимо) > Это естественно, т.к. Оберон появился из Паскаля и Модулы-2 в результате > эволюции.
Ну, Паскаль сегодня — это язык, оддерживающий строки и объекты, так что
он тоже результат эволюции исходного языка, созданного Виртом. > Case-sensitivity, правда, есть. Я привык к этому и пытаюсь обратить это > качество в плюс: т.к. благодаря case-sensitivity нет нужды в > синтаксической подсветке, использую цвет для выделения важных фрагментов
синтаксическая подсветка нужна в момент набора для борьбы с опечатками.
Ну да, и потом чуть-чуть, но большие буквы в приводившихся снимках
экрана раздражают. > по своему усмотрению. Весьма удобно, т.к. выделения цветом сразу > бросаются в глаза, их трудно не заметить.
Хороший комментарий строк на 5 тоже не легко. И это привязано к одной
IDE, то, что Вы говорите. А мне как-то ViM нравится для всего. > Набирать можно и маленькими буквами, редактор их "превратит" в большие. > (Наподобие того, как работает *abbr* в *vi*.)
Вот это плюс редактора. Но лучше не иметь лишних больших букв, на мой
взгляд.
VladD2 wrote: > Господа, если кто снова попадет на его лекцию, то задайте ему вопрос > знаком ли он с лмбда-исчислением, и что он думет о кобмбинаторике > функций... о функциях высшего порядка...
Лямбду добавили за него. Плохонькую, но лямбду. И не рассказывайте, что
это метод объекта... Это надо пользовать и как лямбду, как, например,
делает KOL на Паскаль. Хотя хотелось бы лучшего.
> За одно можно спроисть у него что он думат о таких популярных в ФЯ вещах > как ленивые вычисления, паттерн матчинг (незнаю как это по-русски... > наверно выбор по образу).
Здравствуйте, raskin, Вы писали:
>> Оберон намного лучше Паскаля (честно говоря, я даже сравнивать их не >> могу ): проще и намного мощнее одновременно.
R>Ну, на почти всю спецификацию языка FPC, как и на спецификацию Scheme, R>меня хватило. Так что простоты хватает. А чем мощнее? (на моё мнение R>влияет, кстати, то что я написал препроцессор Паскаль, берущий R>Паскаль-код отмеченный > в первой колонке, компилирующий, и R>подставляющий результат. Техническое метапрограммирование это позволяет R>легко, и более-менее всё, что угодно достижимо)
Метапрограммирование в Обероне не требует ни препроцессора, ни шаблонов.
На эту тему написано много статей.
Вот достаточно любопытный пример: http://www.oberon2005.ru/paper/p_ex.pdf
А позволяет ли FPC сборку мусора?
В давние годы, когда я немного писал на ТурбоПаскале, это было невозможно.
Эта версия Паскаля дрейфовала в направлении Си (т.е. в направлении меньших возможностей и потери безопасности).
Настоящая же поддержка сборки мусора в Си/Си++ пока остается мечтой.
То, что Cyberax говорит об использовании Боэмовского сборщика мусора, очень интересно, но, увы, выглядит как костыли для неспособного ходить на собственных ногах.
>> Это естественно, т.к. Оберон появился из Паскаля и Модулы-2 в результате >> эволюции.
R>Ну, Паскаль сегодня — это язык, оддерживающий строки и объекты, так что R>он тоже результат эволюции исходного языка, созданного Виртом.
Эволюционировать можно в разных направлениях.
А есть ли в FPC многомерные открытые массивы?
Остались ли в языке вариантные записи, нарушающие требование безопасности типов?
Можно ли обеспечить корректный downcasting, используя всего одно сравнение?
И т.д. и т.п.
>> по своему усмотрению. Весьма удобно, т.к. выделения цветом сразу >> бросаются в глаза, их трудно не заметить.
R>Хороший комментарий строк на 5 тоже не легко. И это привязано к одной R>IDE, то, что Вы говорите. А мне как-то ViM нравится для всего.
Маленький оффтоп: мне vim тоже очень нравится.
Собственно, когда я пишу на Си/Си++ — что, увы, в основном — я пользуюсь vim. А т.к. я пишу компиляторы (Си), ассемблеры и проч., то пользую и другие UNIX-программы: yacc/bison, lex и т.д.
Вероятно, мне в vim нравится то же, что и в Обероне — возможности расширения и интеграции.
>> Набирать можно и маленькими буквами, редактор их "превратит" в большие. >> (Наподобие того, как работает *abbr* в *vi*.) R>Вот это плюс редактора. Но лучше не иметь лишних больших букв, на мой R>взгляд.
Сначала я тоже так думал. Сейчас я в этом не уверен. Читабельность обероновских текстов — очень высокая.
Кто знает, м.б. из-за больших букв тоже?
Кстати, изначально редактор не поддерживал возможность, сходную с abbr.
Но любая обероновская среда — исключительно расширяемая. (Для этого Оберон и был создан.)
Кто-то (кажется, Горячев) выложил в Инете подсистему (набор взаимозависимых модулей) Rad.
А я пользуюсь и говорю "спасибо".
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>На магнитофон не записывал поэтому сейчас помню только в общих чертах. О ФЯ он говорил в русле еще одной "хорошей идеи", которая в последствии оказалась не такой уж хорошей как планировалось в начале. Он перечислил заявляемые ФЯ достоинства, потом поговорил о недостатках, а потом задал сам себе вопрос: "А не являются ли ФЯ академическими игрушками?". Отвечать на этот вопрос он не стал. Подробностей я, к сожалению, уже не помню.
Вот и хотелось бы услышать что он занес в список достоинств, а что в список недостатков. А то из ваших рассказов у меня пока что складывается ощущение, что Вирт просто не понимает о чем говрит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ie, Вы писали:
ie>Да нет, ИМХО, он все это знает. Думаю, он просто не считает это столь удобным и привлекательным инструментом, ради которого нужно отказываться от процедурного или ОО подхода .
Больше похоже, на то что мужик влюблем в свое творчество и не воспринимает чужое.
ie>А распараллеливание, будет активно продвигаться в Zonnon'е, а вот откуда тут корни ростут (не из ФП ли?) нам остается только догадываться.
Ну, да. Строим новый мир, а тут под нагами какие-то ламеры мешаются... все орут, что мол "все давно украдено за вас".
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
C>А вот в ФП функции ассоциативны, поэтому можно использовать C>лямбда-исчисление для работы с ними.
Ага. Огромная разница. В ФЯ (точкнее в строких ФЯ) побочные эффекты невозможны, а в любых других языках их попросту можно не делать. Просто так и вижу демонстрации программистов с лозунгами 2оградите нас от побочных эффектов". Чушь какая-то.
ФЯ — это языки проектировашиеся под то чтобы в них в основном использовался функциональный стиль программирования. Не больше и не меньше. Те же ОКамл, Лисп и т.п. ФЯ хотя писать на них можно как угодно, а C# не ФЯ хотя писать на нем в функциональном стиле более чем возможно (и чем дальше, тем удобнее).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>А вот в ФП функции ассоциативны, поэтому можно использовать > C>лямбда-исчисление для работы с ними. > Ага. Огромная разница. В ФЯ (точкнее в строких ФЯ) побочные эффекты > невозможны, а в любых других языках их попросту можно не делать.
Почему же, возможны. Только не в обычных функциях, а в монадах (для
которых определена операция последовательной композиции).
> ФЯ — это языки проектировашиеся под то чтобы в них в основном > использовался функциональный стиль программирования. Не больше и не > меньше. Те же ОКамл, Лисп и т.п. ФЯ хотя писать на них можно как угодно
А есть еще Haskell, Erlang, Clean
> а C# не ФЯ хотя писать на нем в функциональном стиле более чем > возможно (и чем дальше, тем удобнее).
Д>Про то, что функции в ФП не имеют состояния (что дает множество бенефитов в виде ленивых вычислений, легкости распараллеливания и т.п.) он почему-то забыл рассказать. Или не знал?
Функции вообще не имеют состояний. То, что некоторые языки называют функциями нечто, имеющее состояния — проблемы этих языков.
Про легкость распараллеливания Вирт говорил.
Трурль wrote:
> Д>Про то, что функции в ФП не имеют состояния (что дает множество > бенефитов в виде ленивых вычислений, легкости распараллеливания и > т.п.) он почему-то забыл рассказать. Или не знал? > Функции вообще не имеют состояний. То, что некоторые языки называют > функциями нечто, имеющее состояния — проблемы этих языков.
Функции могут модифицировать данные, которые не были им переданы
непосредственно в виде параметров (т.е. глобальные или статические
переменные) — под этим и понимается "состояние".
> Про легкость распараллеливания Вирт говорил.
AVC wrote: > Здравствуйте, raskin, Вы писали: > R> А чем мощнее? (на моё мнение > R>влияет, кстати, то что я написал препроцессор Паскаль, берущий > R>Паскаль-код отмеченный > в первой колонке, компилирующий, и > R>подставляющий результат. Техническое метапрограммирование это позволяет > R>легко, и более-менее всё, что угодно достижимо) > > Метапрограммирование в Обероне не требует ни препроцессора, ни шаблонов.
Ну, меня 150 строк не напрягли. Кстати, в статье описано
метапрограммирование в виде чтения (а не модификации) структуры
программы. Это пока мне не удалось. Мне пока была нужна генерация. В
моём случае код получился эффективнее, когда генерируется, а не сам себя
разбирает. Но, кстати, в Виртовском описании языка про
метапрограммирование нет ни слова.
> На эту тему написано много статей. > Вот достаточно любопытный пример: > http://www.oberon2005.ru/paper/p_ex.pdf
Вместо Raise(eof) напишу exit(EofHandler) . Перекрытие процедур работает
нормально.
> А позволяет ли FPC сборку мусора?
Нет.
> В давние годы, когда я немного писал на ТурбоПаскале, это было невозможно. > Эта версия Паскаля дрейфовала в направлении Си (т.е. в направлении > меньших возможностей и потери безопасности).
Возможности сейчас у FPC достаточные, на мой взгляд.
> Настоящая же поддержка сборки мусора в Си/Си++ пока остается мечтой. > То, что Cyberax говорит об использовании Боэмовского сборщика мусора, > очень интересно, но, увы, выглядит как костыли для неспособного ходить > на собственных ногах.
Почему? "Это можно реализовать на уровне библиотек, а не языка." Всё равно
окончательный код тот же. А отсутствие символа ^ в коде можно и проверить
поиском.
>> > Это естественно, т.к. Оберон появился из Паскаля и Модулы-2 в результате >> > эволюции. > > R>Ну, Паскаль сегодня — это язык, оддерживающий строки и объекты, так что > R>он тоже результат эволюции исходного языка, созданного Виртом. > > Эволюционировать можно в разных направлениях. > А есть ли в FPC *многомерные* открытые массивы?
Есть, но, к сожалению, ведут себя по Си-шному. Т.е. array of array of
byte — это независимые массивы.
> Остались ли в языке вариантные записи, нарушающие требование > безопасности типов?
Остались, иногда это удобно, если нет — "case byte of" ищется поиском в
редакторе. В отличие от Си, Паскаль не позволяет сделать глупость
случайно, всё же Вирт создавал читаемый язык.
> Можно ли обеспечить корректный downcasting, используя всего одно сравнение?
Ой. Они это выкинули. А в TP были проверки на переполнение малых типов.
Попытаться, что ли поправить..
> И т.д. и т.п.
>> > по своему усмотрению. Весьма удобно, т.к. выделения цветом сразу >> > бросаются в глаза, их трудно не заметить. > > R>Хороший комментарий строк на 5 тоже не легко. И это привязано к одной > R>IDE, то, что Вы говорите. А мне как-то ViM нравится для всего. > > Маленький оффтоп: мне vim тоже очень нравится. > Собственно, когда я пишу на Си/Си++ — что, увы, в основном — я пользуюсь > vim. А т.к. я пишу компиляторы (Си), ассемблеры и проч., то пользую и > другие UNIX-программы: yacc/bison, lex и т.д. > Вероятно, мне в vim нравится то же, что и в Обероне — возможности > расширения и интеграции.
Ну так.. Но при этом подсветка фона как свойство редактора пропадает.
> >> > Набирать можно и маленькими буквами, редактор их "превратит" в большие. >> > (Наподобие того, как работает *abbr* в *vi*.) > R>Вот это плюс редактора. Но лучше не иметь лишних больших букв, на мой > R>взгляд. > > Сначала я тоже так думал. Сейчас я в этом не уверен. Читабельность > обероновских текстов — очень высокая.
А Паскалевских низкая?? В каком-то споре поклонник Си++ признался, что
читал алгоритм на Паскаль не зная языка (Паскаль, английский знал) и не
напрягаясь (как псевдокод).
> Кто знает, м.б. из-за больших букв тоже? > Кстати, изначально редактор не поддерживал возможность, сходную с *abbr*. > Но любая обероновская среда — исключительно *расширяемая*. (Для этого > Оберон и был создан.)
А ещё для этого были созданы *.so . И units в Паскаль. Вопрос как
пользоваться.
> Кто-то (кажется, Горячев) выложил в Инете подсистему (набор > взаимозависимых модулей) Rad. > А я пользуюсь и говорю "спасибо".
Rad — это то, что я подумал? Я пользуюсь FPC-библиотекой и KOL для
интерфейса в Windows, в KOL даже bug-fix отослал...
VladD2 wrote: > Здравствуйте, raskin, Вы писали: > > R>Лямбду добавили за него. > > Кто и куда? >
method reference реализован так, что его удобнее использовать как
лямбду, чем по назначению (ну да, преувеличиваю). Если очень надо —
можно написать прослойку и использовать совсем как лямбду. > К тому же не очень интереско то что кто-то куда-то что-то добавил. > Интересно услышать мнение о перечисленных вещах самого мэтра.
Это да.
Здравствуйте, raskin, Вы писали:
R>method reference реализован так, что его удобнее использовать как R>лямбду, чем по назначению (ну да, преувеличиваю). Если очень надо — R>можно написать прослойку и использовать совсем как лямбду.
Ты точно понимашь о чем я говорию? Можно пример того о чем ты говоришь?
Реализуй, плиз, пример функциональной комбинаторики приведенной здесь
Здравствуйте, ie, Вы писали:
ie>Эх все никак не доходили руки познакомиться с Oberon'ом поближе, теперь точно выделю время и посмотрю. Сразу после окончания ремонта, наверное
ремонт нельзя закончить, его можно только прекратить
Здравствуйте, Cyberax, Вы писали:
C>Просто смешно смотреть на такие эксперименты, когда есть уже реально C>работающие реализации с отшлифованым механизмом.
Реально работающие реализации есть уже с конца 60-х. А вот с "отшлифованым механизмом" пока сложности.
): проще и намного мощнее одновременно.
