и достаточно хорошо представлял о чем пойдет речь, мое присутствие там было предопределенно хотя бы тем, что я не мог пропустить лекцию человека по книжкам поторого я начинал учиться программированию.
Слушателей, как и в предыдущих (имеются ввиду ссылки выше) случаях, было много, многие стояли. Из организации хочу поругать только ребят, которые настраивали микрофоны. Почему-то с самого начала лекции не работал микрофон Вирта, а ближе к ее концу, на несколько минут отключились оба микрофона (Вирта и переводчика). Так же из плюсов отмечу, проводилась интернет трансляция прямого эфира. Из локальных сетей Академгородка можно было смотреть трансляцию бесплатно.
С переводчиком нам, видимо, повезло больше, чем в предыдущие разы. Переводил достаточно грамотно, но довольно тихо. Позволял себе иногда собственные комментарии к словам Вирта, почти всегда уместные. Недочеты, конечно, были.
Я ожидал, что среди слушателей будет больший процент преподавательского состава, однако преподавателей IT-дисциплин было около 10 человек. Хотя тут могу ошибаться, возможно, были преподаватели из других ВУЗов.
Контент лекции уже приводился, расскажу о вопросах.
Сперва спросили, а в каких областях программирования ООП, по мнению Вирта, не подходит. На что он посоветовал не использовать ООП в задачах вычислительного плана и он вообще не понимает людей, которые для вычисления произведения матриц, создают соответствующие классы. А так же не применять в тех задачах, которые и без ООП красиво решаются.
Один из вопросов: "Что Вы думаете о Java и C#?". Вирт сказал, что это уже безусловно лучше чем C++, но столь большую популярность они получили соответствующим платформам и маркетинговым ходам.
Я тут хотул спросить, а почему бы не сделать компилятор Оберона под платформу .NET, но мне слово не дали, а предоставилри его какой-то девушке
Девушка спросила: "Вы тут перечисляли 3 парадигмы: функциональное, логическое и ОО программирования. Перечисляли плюсы и минусы каждой из них. Почему бы не придумать парадигму которая была бы лишина всех минусов и содержала плюсы всех 3-х?". Вирт лишь сказал, что это колосально сложная задача и если девушка планирует ей заниматься, то огромной ей удачи.
Спросили про мысли Вирта по поводу Лиспа. Сперва хочу сказать, что во время рассказа про логическое и функциональное программирование ставил вопрос, а не является ли все это "an academic exercise?". Так вот на вопрос о Лиспе Вирт ответил, что это самое лучшее и известное "an academic exercise". Далее были комментарии про то, что все на свете выражать с помощью списков и деревьев можно, но это не самое удачное решение.
Был вопрос и про ПроЛог. Один парень на хорошем английском спросил, а известны ли Вирту, что в Японии на языке ПроЛог, разработана большая система, которая удачно работает и по сей день. Вирт сказал, что, безусловно, такие системы есть и они имеют право на существование, но это по большей части экспертные системы и сам ПроЛог является очень узконаправленным. В общем забывать про него совсем нельзя.
Один преподаватель задал вопрос на англ., а переводчик переводить вопрос не стал, я вопрос не совсем понял. По ответу на него, я так же не смог понять, а в чем вопрос
Один парень спросил про язык программирования Euphoria. Типа если Вирт за простоту, то почему бы не писать на нем? Вирт сказал что не знает такого языка программирования.
Был вопрос и такой: "А в каких областях нельзя применить Oberon? Для решения каких задач он не подходит?" Вирт ответил: "I need more time to answer this question ".
Были и другие менее интересные вопросы про создание национальных версий синтаксиса Оберона и прочие вещи.
По завершению желающим Вирт поставил автографы в свои книжки, а затем все вышли на крыльцо и вместе сфотографировались.
Здравствуйте, ie, Вы писали:
ie>Я тут хотул спросить, а почему бы не сделать компилятор Оберона под платформу .NET, но мне слово не дали, а предоставилри его какой-то девушке
Т.к. Вам не удалось задать свой вопрос, отвечу "за Вирта".
Компиляторов Оберона (и потомков этого языка) для .NET существует несколько.
Еще в 2000 году из 12 первых демонстрируемых компиляторов 2 были "обероновские": Компонентного Паскаля (Шиперски) и Active Oberon (Гуткнехт). Это неудивительно, т.к. Шиперски — один из архитекторов .NET.
Сейчас Гуткнехт (в прошлом — ассистент Вирта) создал на основе Оберона новый язык для .NET — Zonnon.
В Zonnon еще более изощренная многопоточность, чем в Active Oberon.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
ie>>а почему бы не сделать компилятор Оберона под платформу .NET
AVC>Компиляторов Оберона (и потомков этого языка) для .NET существует несколько.
Здесь на форуме не так давно обсуждалась обратная задача: "А не сделать ли возможным для какой-нибудь оберон-системы исполнять .NET-овские dll-модули? То есть не Oberon поверх .Net, а .Net поверх Oberon."
Здравствуйте, AVC, Вы писали:
AVC>Компиляторов Оберона (и потомков этого языка) для .NET существует несколько. AVC>Еще в 2000 году из 12 первых демонстрируемых компиляторов 2 были "обероновские": Компонентного Паскаля (Шиперски) и Active Oberon (Гуткнехт). Это неудивительно, т.к. Шиперски — один из архитекторов .NET.
AVC>Сейчас Гуткнехт (в прошлом — ассистент Вирта) создал на основе Оберона новый язык для .NET — Zonnon. AVC>В Zonnon еще более изощренная многопоточность, чем в Active Oberon.
Эх все никак не доходили руки познакомиться с Oberon'ом поближе, теперь точно выделю время и посмотрю. Сразу после окончания ремонта, наверное
Здравствуйте, ie, Вы писали:
ie>Спросили про мысли Вирта по поводу Лиспа. Сперва хочу сказать, что во время рассказа про логическое и функциональное программирование ставил вопрос, а не является ли все это "an academic exercise?". Так вот на вопрос о Лиспе Вирт ответил, что это самое лучшее и известное "an academic exercise". Далее были комментарии про то, что все на свете выражать с помощью списков и деревьев можно, но это не самое удачное решение.
Lisp programmers are the smartest people in the world. (C) D.Box.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, ie, Вы писали:
ie>>Спросили про мысли Вирта по поводу Лиспа. Сперва хочу сказать, что во время рассказа про логическое и функциональное программирование ставил вопрос, а не является ли все это "an academic exercise?". Так вот на вопрос о Лиспе Вирт ответил, что это самое лучшее и известное "an academic exercise". Далее были комментарии про то, что все на свете выражать с помощью списков и деревьев можно, но это не самое удачное решение.
AVK>Lisp programmers are the smartest people in the world. (C) D.Box.
Здравствуйте, ie, Вы писали:
ie>Эх все никак не доходили руки познакомиться с Oberon'ом поближе, теперь точно выделю время и посмотрю. Сразу после окончания ремонта, наверное
Я "познакомился" с Обероном года три назад.
Язык восхитил меня компактностью, простотой (я выучил его за день) и гармоничностью (как все части соответствуют друг другу). (Особенно сильные эмоции эти качества вызывают после многих лет программирования на Си++. )
Это восхищение осталось у меня до сих пор.
Конечно, это моя субъективная оценка, которую навязывать не буду.
Буду рад, если Вы познакомитесь с Обероном.
Даже если Ваше впечатление будет обратным моему, и Вы раскритикуете язык, все же это будет критика "со знанием дела", и поэтому — интересная.
Удачи!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Фёдор Васильевич увидев безобразие которое творят переводчики обещал лично взяться за перевод начиная с Екатеринбурга.
Может он еще и за оформление сайта возьмется? А то оно тоже безобразие.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Во всех ваших расскзах я так и не услышал что Вирт думает о функциональном программировании, и что за недочеты он находит в парадигмах.
VD>Может кто-нить из вас перескажет эти моменты по продробнее?
Основная идея его рассуждений такова. Он считает что вводить парадигму ФП смысла небыло совсем. Все выражается в виде функций — пускай, но ведь и в процедурных ЯП понятие функций вводилось достаточно давно. Итак, что же мы имеем. Кто-то взял процедурное программирование, выбросил понятие процедуры, а функцию оставил; провозглашает новую парадигму и все. Лично для себя Вирт считает это некоторым обманом — выбросили такую отличную вещь как процедура и представляют получившееся, как нечто более удачное.
Я, к сожалению, ФП еще полностью не познал, поэтому как-то адекватно прокомментировать сказанное не могу, да и говорил Вирт достаточно убедительно.
Здравствуйте, ie, Вы писали:
ie>Основная идея его рассуждений такова. Он считает что вводить парадигму ФП смысла небыло совсем. Все выражается в виде функций — пускай, но ведь и в процедурных ЯП понятие функций вводилось достаточно давно. Итак, что же мы имеем. Кто-то взял процедурное программирование, выбросил понятие процедуры, а функцию оставил; провозглашает новую парадигму и все. Лично для себя Вирт считает это некоторым обманом — выбросили такую отличную вещь как процедура и представляют получившееся, как нечто более удачное.
ie>Я, к сожалению, ФП еще полностью не познал, поэтому как-то адекватно прокомментировать сказанное не могу, да и говорил Вирт достаточно убедительно.
Ясно, похже "дедушка" говорит о том, что чем нихрина не понимат.
Господа, если кто снова попадет на его лекцию, то задайте ему вопрос знаком ли он с лмбда-исчислением, и что он думет о кобмбинаторике функций... о функциях высшего порядка...
Если этого он не поймет, то просто спросте его что он думет о том чтобы смотреть на код как на данные. Почему бы не ввести в Оберон (гы-гы) возможность передавать куски кода в качестве параметров и т.п.
За одно можно спроисть у него что он думат о таких популярных в ФЯ вещах как линивые вычисления, паттерн матчинг (незнаю как это по-русски... наверно выбор по образу).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ie, Вы писали:
ie>Основная идея его рассуждений такова. Он считает что вводить парадигму ФП смысла небыло совсем. Все выражается в виде функций — пускай, но ведь и в процедурных ЯП понятие функций вводилось достаточно давно. Итак, что же мы имеем. Кто-то взял процедурное программирование, выбросил понятие процедуры, а функцию оставил; провозглашает новую парадигму и все. Лично для себя Вирт считает это некоторым обманом — выбросили такую отличную вещь как процедура и представляют получившееся, как нечто более удачное.
Про то, что функции в ФП не имеют состояния (что дает множество бенефитов в виде ленивых вычислений, легкости распараллеливания и т.п.) он почему-то забыл рассказать. Или не знал?
в общем, no comments
ie>да и говорил Вирт достаточно убедительно.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, ie, Вы писали:
ie>>Основная идея его рассуждений такова. Он считает что вводить парадигму ФП смысла небыло совсем. Все выражается в виде функций — пускай, но ведь и в процедурных ЯП понятие функций вводилось достаточно давно. Итак, что же мы имеем. Кто-то взял процедурное программирование, выбросил понятие процедуры, а функцию оставил; провозглашает новую парадигму и все. Лично для себя Вирт считает это некоторым обманом — выбросили такую отличную вещь как процедура и представляют получившееся, как нечто более удачное.
Д>Про то, что функции в ФП не имеют состояния (что дает множество бенефитов в виде ленивых вычислений, легкости распараллеливания и т.п.) он почему-то забыл рассказать. Или не знал? Д>в общем, no comments
Да нет, ИМХО, он все это знает. Думаю, он просто не считает это столь удобным и привлекательным инструментом, ради которого нужно отказываться от процедурного или ОО подхода .
А распараллеливание, будет активно продвигаться в Zonnon'е, а вот откуда тут корни ростут (не из ФП ли?) нам остается только догадываться.
ie wrote:
> Основная идея его рассуждений такова. Он считает что вводить парадигму > ФП смысла небыло совсем. Все выражается в виде функций — пускай, но > ведь и в процедурных ЯП понятие функций вводилось достаточно давно. > Итак, что же мы имеем. Кто-то взял процедурное программирование, > выбросил понятие процедуры, а функцию оставил; провозглашает новую > парадигму и все.
НЕТ! ФП отличается от обычного императивного программирования тем, что у
функций отсутствуют side-effect'ы, что позволяет строить их композиции
без опасений создать ошибку.
Функции/процедуры в обычном императивном языке не являются
ассоциативными относительно операции функциональной композиции. То есть:
[code]
f()*g()*h() не равно f()*(g()*h()) //Здесь * — это композиция.
[code]
А вот в ФП функции ассоциативны, поэтому можно использовать
лямбда-исчисление для работы с ними.
ie wrote:
> Да нет, ИМХО, он все это знает. Думаю, он просто не считает это столь > удобным и привлекательным инструментом, ради которого нужно > отказываться от процедурного или ОО подхода .
Похоже, что просто не знает. Тем более, что ОО и ФП вполне нормально
сосуществуют.
> А распараллеливание, будет активно продвигаться в Zonnon'е, а вот > откуда тут корни ростут (не из ФП ли?) нам остается только догадываться.
Я тут как-то тут сказал, что "Вирт изобретает Эрланг". Сегодня я
посмотрел спеку Зонона — большая часть идей там сперта из Эрланга
(концепция активных объектов, обменивающихся сообщениями).
Вот только Эрланг создавался практиками и для практиков (поэтому
получился удобным и надежным), а Зонон — очередной мертворожденый
академический эксперимент.
Кстати, с помощью перегрузки операторов (на мотив Boost.Spirit) большую
часть фич с "диалогами" в Зононе можно без проблем повторить в С++.
AVC wrote: > Я "познакомился" с Обероном года три назад. > Язык восхитил меня компактностью, простотой (я выучил его за день) и > гармоничностью (как все части соответствуют друг другу). (Особенно > сильные эмоции эти качества вызывают после многих лет программирования > на Си++. )
Глупый вопрос: лучше Pascal? В том варианте, что сейчас есть в FPC
(объекты есть). Просто интересно, стоит ли оно того. Паскаль популярнее,
вполне читаем, да и case-sensitivity Оберону приписывают (что я не люблю).
Здравствуйте, ie, Вы писали:
ie>Да нет, ИМХО, он все это знает. Думаю, он просто не считает это столь удобным и привлекательным инструментом, ради которого нужно отказываться от процедурного или ОО подхода .
если ты правильно передал его слова, то не знает/не понимает. Потому что ФЯ — это далеко не "просто ИЯ без процедур"
ie>А распараллеливание, будет активно продвигаться в Zonnon'е, а вот откуда тут корни ростут (не из ФП ли?) нам остается только догадываться.
никакое это не распараллеливание, просто интеграция поддержки потоков на уровне языка. Распараллеливать алгоритмы придется все равно самому.
Здравствуйте, 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-х. А вот с "отшлифованым механизмом" пока сложности.
Трурль wrote:
> C>Просто смешно смотреть на такие эксперименты, когда есть уже реально > C>работающие реализации с отшлифованым механизмом. > Реально работающие реализации есть уже с конца 60-х. А вот с > "отшлифованым механизмом" пока сложности.
Ну посмотрите на Эрланг, наконец-то. Этот язык реально используется в
массивно-параллельных системах (коммутаторах с тысячами одновременных
соединений).
Как сделать параллельность лучше, чем в Эрланге, — я не представляю.
на Обероне.
СГ>Тот пример лучше на Mathematica реализовывать.
Гы. На чем его лучше реализовать я и так знаю. Лучше всего он реализуется на языках поддерживающих карринг. Ты его на Обероне реализуй. Или признай, что лмбда в Обероне не поддерживается и вообще писать на Обероне в функциональном стиле очень сложно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Здравствуйте, raskin, Вы писали: > > R>method reference реализован так, что его удобнее использовать как > R>лямбду, чем по назначению (ну да, преувеличиваю). Если очень надо — > R>можно написать прослойку и использовать совсем как лямбду. > > Ты точно понимашь о чем я говорию? Можно пример того о чем ты говоришь? > > Реализуй, плиз, пример функциональной комбинаторики приведенной здесь > http://rsdn.ru/forum/Message.aspx?mid=1419773&only=1
Я Паскалист, более-менее, и про большую убогость как лямбды
предупреждал.. Но по функционалу (да, читаемость =0) часто заменяет.
type Tint2tointM= function (z,w:integer):integer of object;
type Tint4toint= function (x,y,z,w:integer):integer;
type rec2intandf=record
f:tin4toint;
z,w:integer;
end;
prec2intandf=^rec2intandf;
function Main_code(x,y,z,w:integer):integer;
begin
result:=x+y+z+w;
end;
function InnerCode(dummy:pointer; x,y:integer):integer;
begin
result:=prec2intandf(dummy).f(x,y,prec2intandf(dummy).z,
prec2intandf(dummy).w));
end;
function composer(z,w:integer; f:tint4toint):tint2tointM;
var
p:prec2intandf;
begin
new(p);
p.z=z;
p.w:=w;
p.f:=f;
result:=makemethod(p,@innercode);
end;
Здравствуйте, raskin, Вы писали:
R>Я Паскалист, более-менее, и про большую убогость как лямбды R>предупреждал.. Но по функционалу (да, читаемость =0) часто заменяет.
R>
Я не сказал, что заменяет. Я бы назвал эту реализацию "закат солнца вручную". Хотя конечно оригинально . Это код который компилятор Шарпа генерирует в теневом режиме. Кстати, оптимизирующий компилятор мог бы вообще породить отдельную функцию.
Ну, да зчтем это решение как плноценное (хотя это довольно спорно). В данном случае это прекрасный пример демонстрирующий плохую выразительность языка спроектированного в минималистском ключе. Ты описал не весь пример. Чтобы их можно было сравнить я сократил свой до того же объема:
static Func<int, int, int> Compose(Func<int, int, int, int, int> func, int z, int w)
{
return (x, y) => func(x, y, z, w);
}
static int f1(int x, int y, int z, int w) { return x + y + z + w; }
И мой код еще довольно длинный, так как в языках поддерживающих карринг можно вобще порождать составные методы по месту.
В общем, назвать это лямбдой никак нельзя. Лямбда — это анонимный метод. А Обероне есть только лишь аналог делегата.
Кайф же лямбды для простого программиста заключается в том, что она позволяет задавать нужный код по-месту. Например, чтобы удалить некоторые элементы из списка не нужно сложных наворотов. Достаточно воспользоваться методом RemoveAll:
using System;
using System.Collections.Generic;
using System.Query;
class Program
{
static void Main()
{
List<int> list = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
PrintList(list);
list.RemoveAll(x => x % 2 == 0);
PrintList(list);
}
static void PrintList<T>(List<T> seq)
{
Console.WriteLine(
seq.ConvertAll(x => x.ToString()).Fold((x, y) => x + ", " + y));
}
}
Этот код выводит:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
1, 3, 5, 7, 9
Хотя в этом коде лмбд и без RemoveAll выше крыши.
Напиши аналогичный код на Обероне и сравним его читаемость и длинну.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Здравствуйте, raskin, Вы писали: > > R>Я Паскалист, более-менее, и про большую убогость как лямбды > R>предупреждал.. Но по функционалу (да, читаемость =0) часто заменяет.
> <Мой тягостный кошмар вырезан>
> R>За опечатки прошу не бить. > > Я не сказал, что заменяет. Я бы назвал эту реализацию "закат солнца > вручную". Хотя конечно оригинально . Это код который компилятор Шарпа > генерирует в теневом режиме. Кстати, оптимизирующий компилятор мог бы > вообще породить отдельную функцию.
В C# не принимаются изменения, которые ничего не рушат, а в FPC —
которые хоть что-то рушат.. Ну нет этого в языке, иногда это плохо...
Поэтому я решил сделать препроцессор, чтоб не маяться — такие вещи
делаются проще так. > > Ну, да зчтем это решение как плноценное (хотя это довольно спорно). В > данном случае это прекрасный пример демонстрирующий плохую > выразительность языка спроектированного в минималистском ключе. Ты
Да, плохая выразительность использования не по назначению средства, не
спорю. Да, этого нет в языке. Но это лечится препроцессором с меньшим
расширением и усложнением языка. > описал не весь пример. Чтобы их можно было сравнить я сократил свой до > того же объема: > > static Func<int, int, int> Compose(Func<int, int, int, int, int> func, int z, int w) > { > return (x, y) => func(x, y, z, w); > } > > > static int f1(int x, int y, int z, int w) { return x + y + z + w; } > > > И мой код еще довольно длинный, так как в языках поддерживающих карринг > можно вобще порождать составные методы по месту. > > В общем, назвать это лямбдой никак нельзя. Лямбда — это анонимный метод. > А Обероне есть только лишь аналог делегата.
Это был Паскаль, за Оберон не скажу. Но лямбда, как мне кажется, не
обязана быть анонимной. Фиксация части параметров уже очень упрощает жизнь. > > Кайф же лямбды для простого программиста заключается в том, что она > позволяет задавать нужный код по-месту. Например, чтобы удалить > некоторые элементы из списка не нужно сложных наворотов. Достаточно > воспользоваться методом RemoveAll.
Когда я захочу нормальную, удобную лямбду я не буду при переходе с
Паскаль останавливаться в промежуточных позициях с Си-порождённым
синтаксисом и выучу Lisp. Или вместо bash буду использовать Ruby или
Python или ..опять Лисп, не знаю. По крайней мере, в ситуациях, когда я
могу выбрать язык, на котором легче и аккуратнее напишу. > > Хотя в этом коде лмбд и без RemoveAll выше крыши. > Напиши аналогичный код на Обероне и сравним его читаемость и длинну.
На Обероне я ничего не напишу точно. А дело всё идёт к написанию кода на
bash, который будет состоять из сплошных eval.. Или я возьму и напишу
на Паскаль+Паскаль-препроцессор. Пока лень. Я не говорил, что в Паскаль
идёт речь о полноценной, удобной лямбде — но когда без этого нельзя,
помогает.
Здравствуйте, raskin, Вы писали:
R>В C# не принимаются изменения, которые ничего не рушат, а в FPC — R>которые хоть что-то рушат..
Это я не понял. Что кто рушит?
R>Ну нет этого в языке, иногда это плохо... R>Поэтому я решил сделать препроцессор, чтоб не маяться — такие вещи R>делаются проще так.
Гы. Это уже будет не Оберон. Вирт же сражается против вот таких вот полезных возможностей.
R>Да, плохая выразительность использования не по назначению средства, не R>спорю. Да, этого нет в языке. Но это лечится препроцессором с меньшим R>расширением и усложнением языка.
Прероцессор у тебя должен быть синтаксическим. А это не так то просто. К тому же к нему потребуется язык. Далее попрут проблемы с поддержкой в разных IDE. Короче, "снежный ком".
Хотя идея очень верная. В приницпе если бы удалось создать простой язык с мощьным инструментом метапрограммирования позволяющим легко рсширять язык, то на его основе можно было бы построить язык мечты адаптируемый не только под желания программиста, но и под решаемые задачи. На таком средстве можно было бы создавать DSL-и о которых на этом сайте так часто говорят в последнее время.
R>Это был Паскаль, за Оберон не скажу.
Хм. Интересно в Обероне это будет сильно отличаться? И в какую сторону? Ждем Губанова...
R> Но лямбда, как мне кажется, не R>обязана быть анонимной. Фиксация части параметров уже очень упрощает жизнь.
А замем имя функции которая нужна только для передачи в качестве параметра? Это же утяжелит синтаксис и опять таки приведет к плохой читаемости.
R>Когда я захочу нормальную, удобную лямбду я не буду при переходе с R>Паскаль останавливаться в промежуточных позициях с Си-порождённым R>синтаксисом и выучу Lisp.
У Лиспа свои проблемы.
R> Или вместо bash буду использовать Ruby или R>Python или ..опять Лисп, не знаю. По крайней мере, в ситуациях, когда я R>могу выбрать язык, на котором легче и аккуратнее напишу.
А точно получится в итоге легче?
Ну, да мы не о том. Мы все же говорили о Вирте, о его Обероне и о приемуществах которые дает минимализм. Если бы Вирт заговорил о расширяемом языке, то я бы вожможно стал бы ярым поклонником Вирта в целом и Оберона в частности.
>> >> Хотя в этом коде лмбд и без RemoveAll выше крыши. >> Напиши аналогичный код на Обероне и сравним его читаемость и длинну.
R>На Обероне я ничего не напишу точно. А дело всё идёт к написанию кода на R> bash, который будет состоять из сплошных eval..
В смысле? Код на нем генерировать? И это вместо того чтобы добавить в язык удбные возможноти?
R> Или я возьму и напишу R>на Паскаль+Паскаль-препроцессор. Пока лень.
Именно! А потом будет еще и не удобно. Текстовый прероцессоры создаст больше проблем чем решит. А создать синтаксический, да с удобным языком — это задача очень не простая.
R> Я не говорил, что в Паскаль R>идёт речь о полноценной, удобной лямбде — но когда без этого нельзя, R>помогает.
Ну, вообще-то мы говорили об Обероне и стремлении Вирта уменьшить его синтаксис. Вы с Губановым тут урверждали, что это стремление якобы должно привести к более понятному коду. Вроде как мы выснили, что все как раз наоборот. И что ошибки в логике Оберонщиков (или Виртуозов?) связаны с тем, что для сравнения они используют С++ где сложная семантика и много неоднозначностей, а выводы делают о простоте синтаксиса.
Вот только почти уверен, что в следующем же сообщении где-нибудь рядом очередной Оберонщик (скорее всего Губанов) продолжит делать подобные утверждения как будто всего этого разговора небыло. В общем, фанатизм. И начинается он с Вирта. Вирт первый кто не хочет признавать очевидные вещи.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Здравствуйте, raskin, Вы писали: > > R>В C# не принимаются изменения, которые ничего не рушат, а в FPC — > R>которые хоть что-то рушат.. > > Это я не понял. Что кто рушит?
А что? Счастье наконец наступило? Любая корректная программа на C#
корректна и работает точно так же на всех старших (минус мелкие баги
компилятора плюс другой оптимизатор, но нет изменений из-за стандарта
языка)? Ура, наконец-то... Просто мне казалось, что C# слишком динамично
вбирает всё полезное и не только, чтобы быть устоявшимся. > > R>Ну нет этого в языке, иногда это плохо... > R>Поэтому я решил сделать препроцессор, чтоб не маяться — такие вещи > R>делаются проще так. > > Гы. Это уже будет не Оберон. Вирт же сражается против вот таких вот > полезных возможностей.
В этом он не прав, наверное. Главное — чтобы они были синтаксически
чётко отделены от того, что уже есть. > > R>Да, плохая выразительность использования не по назначению средства, не > R>спорю. Да, этого нет в языке. Но это лечится препроцессором с меньшим > R>расширением и усложнением языка. > > Прероцессор у тебя должен быть синтаксическим. А это не так то просто. К
Да ну? Многого можно добиться и так. > тому же к нему потребуется язык. Далее попрут проблемы с поддержкой в > разных IDE. Короче, "снежный ком".
ViM... А отладка в gdb разросшегося после обработки Паскаль-кода меня
давно не напрягает. > > Хотя идея очень верная. В приницпе если бы удалось создать простой язык > с мощьным инструментом метапрограммирования позволяющим легко рсширять > язык, то на его основе можно было бы построить язык мечты адаптируемый > не только под желания программиста, но и под решаемые задачи. На таком > средстве можно было бы создавать DSL-и о которых на этом сайте так часто > говорят в последнее время.
Желательно ещё одно условие добавить — этот язык не должен появиться как
расширение Perl. > > R>Это был Паскаль, за Оберон не скажу. > > Хм. Интересно в Обероне это будет сильно отличаться? И в какую сторону? > Ждем Губанова... > > R> Но лямбда, как мне кажется, не > R>обязана быть анонимной. Фиксация части параметров уже очень упрощает > жизнь. > > А замем имя функции которая нужна только для передачи в качестве > параметра? Это же утяжелит синтаксис и опять таки приведет к плохой > читаемости.
Я не говорил, что это можно использовать, как хорошую лямбду. Это
плохонькая лямбда, но иногда лямбда-исчисление нужно семантически, а не
как синтаксический сахар. Да, я согласен, что блок lambda(..)
<expression>; или lambda(..) begin end; считающиеся переменной типа
function был бы очень полезен. И повышал бы читаемость.
> R> Или вместо bash буду использовать Ruby или > R>Python или ..опять Лисп, не знаю. По крайней мере, в ситуациях, когда я > R>могу выбрать язык, на котором легче и аккуратнее напишу. > > А точно получится в итоге легче?
Попробую. Но Паскаль+текстовый препроцессор я уже использую и
получаю код, который мне удобно читать и изменять.
> Ну, да мы не о том. Мы все же говорили о Вирте, о его Обероне и о > приемуществах которые дает минимализм. Если бы Вирт заговорил о > расширяемом языке, то я бы вожможно стал бы ярым поклонником Вирта в > целом и Оберона в частности.
Минимализм? Ну его.. Синтаксис, не дающий скомпилировать программу с
незаметной опечаткой, и локально читаемый почти всегда — причина, по
которой я предпочитаю Паскаль. Или shell.
> R>На Обероне я ничего не напишу точно. А дело всё идёт к написанию кода на > R> bash, который будет состоять из сплошных eval.. > > В смысле? Код на нем генерировать? И это вместо того чтобы добавить в > язык удбные возможноти?
Добавление удачного генератора кода как легко вызываемой процедуры
отличить от добавления новой возможности не так просто. Вы не забудьте,
что у lambda echo #1 adbmal; формально параметрами будут echo, #1, adbmal. > R> Или я возьму и напишу > R>на Паскаль+Паскаль-препроцессор. Пока лень. > > Именно! А потом будет еще и не удобно. Текстовый прероцессоры создаст
Я один раз помучаюсь с реализацией lambda. Препроцессор использую уже.
Он уже решил мне больше неудобств, чем создал. Мне хватит лени не сунуть
его туда, где будет наоборот. > больше проблем чем решит. А создать синтаксический, да с удобным языком > — это задача очень не простая. > > R> Я не говорил, что в Паскаль > R>идёт речь о полноценной, удобной лямбде — но когда без этого нельзя, > R>помогает. > > Ну, вообще-то мы говорили об Обероне и стремлении Вирта уменьшить его > синтаксис. Вы с Губановым тут урверждали, что это стремление якобы > должно привести к более понятному коду. Вроде как мы выснили, что все
Пожалуйста, хоть одну цитату, где я говорил, что принципиальный
минимализм — это наше всё. Я извинюсь за этот бред. Просто читаемый
синтаксис (даже при условии чтения в хорошем редакторе — если отступы со
скобками не увязаны, то Лисп читать могут единицы) сейчас редкость.
Локально читаемый. Я как раз думаю о написании нормального
препроцессора, чтобы от Паскаль оставить идеи синтаксиса + синтаксис
имеющейся семантики — потому то, что есть, сделано хорошо. > как раз наоборот. И что ошибки в логике Оберонщиков (или Виртуозов?) > связаны с тем, что для сравнения они используют С++ где сложная > семантика и много неоднозначностей, а выводы делают о простоте синтаксиса.
Я как раз делаю сравнение хотя бы с Си по направленности синтаксиса на
локальную (не)читаемость. И все последователи Си с этим не борются.
Программист на любом языке программу на Паскаль читать сможет с большей
вероятностью, чем на C/C++/C# (если он пишет не на C/C++/C#). Причём
зачастую даже разобраться в одной функции уже сложнее.
Здравствуйте, VladD2, Вы писали:
VD>Гы. На чем его лучше реализовать я и так знаю. Лучше всего он реализуется на языках поддерживающих карринг. Ты его на Обероне реализуй. Или признай, что лмбда в Обероне не поддерживается и вообще писать на Обероне в функциональном стиле очень сложно.
Признаюсь в страшной вещи. Оберон — обычный, можно даже сказать канонический императивный язык. Генерировать новую функцию по старой функции он не умеет. Ее надо ручками писать.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Буквы x и y — это что? Они же ни где не описаны.
Описаны. Непосредственно слева от => они и описаны. Т.е. здесь 3 декларации:
СГ>С потолка упали? Как их понимать?
Ну вот так и понимать. СГ>Можно ли было вместо букв x,y написать, например, буквы u,v?
Можно. Например, вот так:
seq.ConvertAll(a => a.ToString()).Fold((b, c) => b + ", " + c));
СГ>А если бы было так: СГ>
СГ>System.Threading.Thread x = SomeActivity;
СГ>list.RemoveAll(x => x % 2 == 0);
СГ>
СГ>тогда x в первой строке и x во второй строке между собой связаны бы были?
Нет.
Весь смысл этих падающих с потолка буковок именно в том, чтобы можно было не писать вот так:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Признаюсь в страшной вещи. Оберон — обычный, можно даже сказать канонический императивный язык. Генерировать новую функцию по старой функции он не умеет. Ее надо ручками писать.
Дык, в том то и дело. Это это именно что обычный императивный язык. А кроме тупых циклов в программировании за десятилетия выработалось множество подходов позволяющих резко упростить решение многих задач. Оберон же впитал только КОП.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
СГ>Буквы x и y — это что? Они же ни где не описаны. С потолка упали? Как их понимать? Можно ли было вместо букв x,y написать, например, буквы u,v?
Знакомься — это новая для Оберона концепция. Называется — выведение типов.
Обясняю на пальцах. Предположим у нас есть переменная:
string str = "Мама";
Компилятор и так знает, что тип выражения "Мама" является строка. Так что если компилятор умный и поддерживает выведение типов, то можно тоже самое записать как^
var str = "Мама";
Какзалось бы бенефит не велик, но... Но когда задачи усложняются, то все становится куда интереснее:
IDictionary<List<string>> dic = new IDictionary<List<string>>();
Так вот это део (выведение типов) действиует и на параметры методов. Методы RemoveAll, ConvertAll и Fold испльзованные мной в примере являются так называемыми функцями высшего порядка, так как принимают ссылки на друние методы в качестве параметров. Например, Fold выглядит так:
public static T Fold<T>(this IEnumerable<T> source, Func<T, T, T> func)
{
using (IEnumerator<T> e = source.GetEnumerator())
{
if (!e.MoveNext()) throw new EmptySequenceException();
T result = e.Current;
while (e.MoveNext()) result = func(result, e.Current);
return result;
}
}
this — означает, что метод расширяет типы производные от IEnumerable<T> (в данном случае), т.е. этот метод можно вызвать через точку (как показано в прмере). Жирным же выделено описание ссылки на метод (т.е. делегат). куда и поставляется то непонятное со странными x и y.
Так вот я мог бы написать не
...Fold((x, y) => x + ", " + y))...
а
...Fold((string x, string y) => x + ", " + y))...
но зачем это делать, если компилятор и без меня выведет тип параметров?
Вот я и указал толко имена безымянного методы (лмбды) которые использую внутри него.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
): проще и намного мощнее одновременно.
1.1.4 stable rev. 510
