Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Курилка, Вы писали:
K>>>По моему, классифицировать гибрид Smalltalk-72 и Prolog вообще проблема нетривиальная. К>>Можно комментарий по поводу выделенного? Желательно с фактами?
K>Насколько я знаю, actor model выросла из идей, реализованных в Smalltalk-72.
Шарп (и Немерле заодно) мы гибридом Симулы считать будем?
Ну и фактами чтот не пахнет, хотя неважно, нравится видеть там смолтолк — ради бога
Здравствуйте, eao197, Вы писали:
E>Т.е., все возражения против C#, Eiffel, SmallTalk и Ruby свелись к тому, что там делегаты/агенты/блоки кода не называются "функциями"?
Ты как всегда ошибся. Вроде как твоей аппонент говорил о том, что в C# 1.0 и Eiffel функции не были первокласными объектами, хотя бы потому, что их нельзя было создать по месту и в рантайме. А Смолток и Руби вроде как оперирует понятиями объектов и посылки сообщений. В прочем, на мой взгляд, Руби все же неплохо эмулирует функции как первокласные объекты.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Т.е., все возражения против C#, Eiffel, SmallTalk и Ruby свелись к тому, что там делегаты/агенты/блоки кода не называются "функциями"?
VD>Ты как всегда ошибся. Вроде как твоей аппонент говорил о том, что в C# 1.0 и Eiffel функции не были первокласными объектами, хотя бы потому, что их нельзя было создать по месту и в рантайме.
В Eiffel нет такого ограничения, и ты, и мой оппонент мог бы это увидеть:
Существует так же возможность создавать т.н. inline agents, т.е. агентов тело которых определяется непосредственно в конструкции agent:
Здравствуйте, eao197, Вы писали:
VD>>Ты как всегда ошибся. Вроде как твоей аппонент говорил о том, что в C# 1.0 и Eiffel функции не были первокласными объектами, хотя бы потому, что их нельзя было создать по месту и в рантайме. E>В Eiffel нет такого ограничения, и ты, и мой оппонент мог бы это увидеть: E>
E>Существует так же возможность создавать т.н. inline agents, т.е. агентов тело которых определяется непосредственно в конструкции agent:
E>
По-существу, это литерал не для функции, а для агента. Вы могли бы и увидеть, что такой довод в числе прочих я выдвигал, аргументируя отсутствие первоклассных функций в C# 1.0. К Eiffel у меня другие претензии. Почему передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью ключевого слова agent? Это явное, задаваемое программистом оборачивание функции в объект — точно как и в C# 1.0. Если уж на то пошло, в первом шарпе и то ситуация в этом плане была лучше. Вызов функции через делегат от просто вызова функции никак синтаксически не отличался, а в Eiffel вызов функции через агент отличается от просто вызова. И то и другое хорошо видно в ваших собстенных примерах на Eiffel.
Это, собственно, и означает непервоклассность функций, надеюсь, теперь понятно?
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Курилка, Вы писали:
K>>Насколько я знаю, actor model выросла из идей, реализованных в Smalltalk-72.
К>Шарп (и Немерле заодно) мы гибридом Симулы считать будем?
Я бы считал, если бы на временной оси между Simula и C# небыло бы ни одного известного мне языка с ООП. А между Smalltalk и Erlang я ни одного языка с actor model не знаю. Поэтому так и говорю.
К>Ну и фактами чтот не пахнет, хотя неважно, нравится видеть там смолтолк — ради бога
Какого рода факты интересуют? Я думаю, в статье Википедии про Actor model можно найти ссылки на заслуживающие доверия источники и изучить их — самому мне такую работу проделывать лень. Никакой заинтереснованности в том, чтобы этот мой взгляд на Erlang и смолток 72 разделял еще кто-то у меня нет.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>По-существу, это литерал не для функции, а для агента. Вы могли бы и увидеть, что такой довод в числе прочих я выдвигал, аргументируя отсутствие первоклассных функций в C# 1.0. К Eiffel у меня другие претензии. Почему передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью ключевого слова agent?
Почему передавая в качестве аргумента в Nice не функцию я должен писать:
void f( A b ) { ... }
а передавая в качестве аргумента функцию я должен писать '->'
void f( ()->A b ) { ... }
?
Иными словами, почему "передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью " специальной синтаксической конструкции `->`?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Почему передавая в качестве аргумента в Nice не функцию я должен писать: E>
E>void f( A b ) { ... }
E>
И где здесь передача? Это декларация типа.
E>а передавая в качестве аргумента функцию я должен писать '->' E>
E>void f( ()->A b ) { ... }
E>
E>?
И тут ничего не передается — только тип декларируется.
E>Иными словами, почему "передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью " специальной синтаксической конструкции `->`?
Вы шутите чтоли? Или не отличаете использования функции от ее декларации?
В Nice я вызываю curry так:
curry(foo);
А не
curry(agent foo);
Почему я не могу написать на Eiffel так:
consumer.call_agent (producer.demo)
А вынужден писать так:
consumer.call_agent (agent producer.demo)
При этом так
io.put_string (s) -- s - переменная, содержащая строку.
Я написать могу.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Почему передавая в качестве аргумента в Nice не функцию я должен писать: E>>
E>>void f( A b ) { ... }
E>>
K>И где здесь передача? Это декларация типа.
E>>а передавая в качестве аргумента функцию я должен писать '->' E>>
E>>void f( ()->A b ) { ... }
E>>
E>>?
K>И тут ничего не передается — только тип декларируется.
Извините, я подумал, что есть претензии к способу декларации функций, получающие агенты в качестве параметров.
E>>Иными словами, почему "передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью " специальной синтаксической конструкции `->`?
K>Вы шутите чтоли? Или не отличаете использования функции от ее декларации?
K>В Nice я вызываю curry так: K>
K>curry(foo);
K>
K>А не K>
K>curry(agent foo);
K>
K>Почему я не могу написать на Eiffel так: K>
K>consumer.call_agent (producer.demo)
K>
K>А вынужден писать так: K>
K>consumer.call_agent (agent producer.demo)
K>
По той причине, что и необходимость взятия адреса у функции в D.
Дело в том, что в Eiffel выражение producer.demo означает вызов метода demo или получение значения атрибута demo (методы без аргументов в Eiffel вызываются без скобочек). Поэтому когда компилятор видит producer.demo, но оказывается, что метод demo требует, скажет, два аргумента, то это считается ошибкой -- разработчик не передал аргументы при вызове. А выражение agent producer.demo явно указывает компилятору, что это не вызов, а "взятие адреса" функции.
K>При этом так K>
K>io.put_string (s) -- s - переменная, содержащая строку.
K>
K>Я написать могу.
Если у вас написано так:
local
a: <тип агента>
do
a = agent producer.demo
-- то вы можете написать так же, как и с переменной s.
consumer.call_agent (a)
end
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
K>По-существу, это литерал не для функции, а для агента. Вы могли бы и увидеть, что такой довод в числе прочих я выдвигал, аргументируя отсутствие первоклассных функций в C# 1.0. К Eiffel у меня другие претензии. Почему передавая в качестве аргумента не функцию, я не должен это явно указывать, а передавая функцию — должен, с помощью ключевого слова agent? Это явное, задаваемое программистом оборачивание функции в объект — точно как и в C# 1.0. Если уж на то пошло, в первом шарпе и то ситуация в этом плане была лучше. Вызов функции через делегат от просто вызова функции никак синтаксически не отличался, а в Eiffel вызов функции через агент отличается от просто вызова. И то и другое хорошо видно в ваших собстенных примерах на Eiffel. K>Это, собственно, и означает непервоклассность функций, надеюсь, теперь понятно?
Кстати, Эрланг тоже не функциональный, т.к. он гибрид смолтолка и для создания функциональных значений там надо использовать слово fun?
Здравствуйте, eao197, Вы писали:
E>Извините, я подумал, что есть претензии к способу декларации функций, получающие агенты в качестве параметров.
Рад, что недоразумение улажено, а понимание в этом вопросе наконец достигнуто.
K>>Почему я не могу написать на Eiffel так: K>>
K>>consumer.call_agent (producer.demo)
K>>
K>>А вынужден писать так: K>>
K>>consumer.call_agent (agent producer.demo)
K>>
E>По той причине, что и необходимость взятия адреса у функции в D. E>Дело в том, что в Eiffel выражение producer.demo означает вызов метода demo или получение значения атрибута demo (методы без аргументов в Eiffel вызываются без скобочек). Поэтому когда компилятор видит producer.demo, но оказывается, что метод demo требует, скажет, два аргумента, то это считается ошибкой -- разработчик не передал аргументы при вызове. А выражение agent producer.demo явно указывает компилятору, что это не вызов, а "взятие адреса" функции.
Не совсем понимаю проблему. Язык статически типизированный, у компилятора есть информация о типе параметра call_agent и типе функции producer.demo. Если тип параметра — это функциональный тип, соответствующий типу функции producer.demo — выполняется передача функционального значения, если тип, соответствующий возвращаемому типу producer.demo — выполняется вызов.
Разве только автор считал удобным синтаксически подчеркнуть разницу — а это прямое указание на то, что первоклассность функций считается в этом языке нежелательной возможностью.
E>Если у вас написано так: E>
E>local
E> a: <тип агента>
E>do
E> a = agent producer.demo
E> -- то вы можете написать так же, как и с переменной s.
E> consumer.call_agent (a)
E>end
E>
Ну это-то понятно. a — переменная, содержащая агент. А присвоить ей функцию непосредственно также нельзя — нужно явно оборачивать ее в агент. Это, с моей точки зрения, также говорит о непервоклассности функции в Eiffel. Просто те задачи, которые в ФЯ решались бы с помощью первоклассных функций, решаются в ООП Eiffel с помощью конвергентной ООП-фичи. Точно также как и в SmallTalk/Ruby. С практической точки зрения это большого значения не имеет, но с терминологической — разница есть.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Не совсем понимаю проблему. Язык статически типизированный, у компилятора есть информация о типе параметра call_agent и типе функции producer.demo. Если тип параметра — это функциональный тип, соответствующий типу функции producer.demo — выполняется передача функционального значения, если тип, соответствующий возвращаемому типу producer.demo — выполняется вызов. K>Разве только автор считал удобным синтаксически подчеркнуть разницу — а это прямое указание на то, что первоклассность функций считается в этом языке нежелательной возможностью.
А как быть, если producer.demo -- это метод без параметров, возвращающий агента?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>А как быть, если producer.demo -- это метод без параметров, возвращающий агента?
K>Т.е. () -> (U -> V) , например?
K>Если у параметра тип () -> (U -> V) -передается функциональное значение, а если тип U -> V — выполняется вызов. K>В общем случае () -> X и X.
Насколько я понимаю у тебя тип агента U -> V, тогда вызов должен выполняться при сигнатуре параметра () -> (U -> V), а при U -> V просто передаваться функция. И если даже ты запутался (хотя может и я вру), то тебе не кажется, что это несколько не совсем простые правила? Хотя людям знакомым с Хиндли-Милнером это всё семечки имхо.
P.S. Или имелся в виду тип параметра в сигнатуре функции (consumer.call_agent), которой нужен агент? Тогда какая-то совсем непонятная нотация выходит.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>А как быть, если producer.demo -- это метод без параметров, возвращающий агента?
K>Т.е. () -> (U -> V) , например?
K>Если у параметра тип () -> (U -> V) -передается функциональное значение, а если тип U -> V — выполняется вызов. K>В общем случае () -> X и X.
Говоря об Eiffel не нужно забывать о том, что одной из целей языка является максимальная читабельность программ, которая является одним из основных факторов, облегчающих сопровождение кода. Следствием чего должно быть легкое понимание кода без каких-либо дополнительных инструментов, даже напечатанного в книге или в какой-либо другой документации кода.
Если применить ваш подход, когда встретив выражение:
something( producer.demo )
только компилятор на основании типа producer.demo сможет сделать вывод о том, что же будет выполнено -- вызов demo или взятие адреса demo, то это нарушит одну из целей языка. Человек сможет разобраться в этом только с помощью IDE и только если заострит внимание именно на этом выражении. В то время как выражение:
something( agent producer.demo )
дает однозначное толкование как для читающего код человека (не важно, с экрана ли код читается или из книги) так и для компилятора.
Я, помнится, столкнулся в Nemerle с тем, что написав вызов чего-то без скобочек получил не вызов, а возврат лямбды. Но здесь Nemerl-исты мне ответили, что мол нефиг без нормальной IDE код писать и читать. В отличии от Nemerle в Eiffel такой ошибки нельзя совершить в принципе.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
[cut] E>Я, помнится, столкнулся в Nemerle с тем, что написав вызов чего-то без скобочек получил не вызов, а возврат лямбды. Но здесь Nemerl-исты мне ответили, что мол нефиг без нормальной IDE код писать и читать. В отличии от Nemerle в Eiffel такой ошибки нельзя совершить в принципе.
Только это делает язык многословней и в итоге менее читабельным, если надо "навернуть" что-нибудь посложней. С другой стороны есть всякие Хаскели и Джей, где записывается оно кратко, только для понимания нужны умственные усилия (хотя может быть и там можно IDE заставить помогать, только как-то люди без неё справляются в основном).
Т.е. получается с одной стороы краткость/многословность, а с другой стороны сложность концепций/высота абстракции. Где найти точку оптимума имхо вопрос сильно субъективный. Плюс надо не забывать другие факторы, чтоб посчитать корректно TCO.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
К>[cut] E>>Я, помнится, столкнулся в Nemerle с тем, что написав вызов чего-то без скобочек получил не вызов, а возврат лямбды. Но здесь Nemerl-исты мне ответили, что мол нефиг без нормальной IDE код писать и читать. В отличии от Nemerle в Eiffel такой ошибки нельзя совершить в принципе.
К>Только это делает язык многословней и в итоге менее читабельным, если надо "навернуть" что-нибудь посложней. С другой стороны есть всякие Хаскели и Джей, где записывается оно кратко, только для понимания нужны умственные усилия (хотя может быть и там можно IDE заставить помогать, только как-то люди без неё справляются в основном).
Ну особенность Eiffel-я как раз в том и состоит, что в нем невозможно построить короткое, но сложное выражение, для понимания которого нужно прилагать серьезные умственные усилия. Сами принципы Eiffel-я этому противоречат (в частности Command/Query Separation Principle). Кому-то это может нравится, кому-то нет. Мне кажется, что в большие компании, где над проектами работают команды в сотни программистов, Eiffel удалось протолкнуть именно благодоря этому.
К>Т.е. получается с одной стороы краткость/многословность, а с другой стороны сложность концепций/высота абстракции. Где найти точку оптимума имхо вопрос сильно субъективный. Плюс надо не забывать другие факторы, чтоб посчитать корректно TCO.
Собственно, дело не в определении TCO, а в том, делает ли использование ключевого слова 'agent' в Eiffel невозможным признание самого факта существования функций высшего порядка в Eiffel.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну особенность Eiffel-я как раз в том и состоит, что в нем невозможно построить короткое, но сложное выражение, для понимания которого нужно прилагать серьезные умственные усилия. Сами принципы Eiffel-я этому противоречат (в частности Command/Query Separation Principle). Кому-то это может нравится, кому-то нет. Мне кажется, что в большие компании, где над проектами работают команды в сотни программистов, Eiffel удалось протолкнуть именно благодоря этому.
Вопрос — а так ли нужны эти сотни? Формализм (в данном случае языка) это палка о двух концах. Думаю ты не будешь спорить, что создать формально правильный, но монструозный проект можно вполне запросто
Хотя это уже совсем оффтопик.
E>Собственно, дело не в определении TCO, а в том, делает ли использование ключевого слова 'agent' в Eiffel невозможным признание самого факта существования функций высшего порядка в Eiffel.
Ну сорри, я просто чуть крупнее вопрос затронул
Всё, закругляемся с оффтопиком
Здравствуйте, Курилка, Вы писали:
E>>Ну особенность Eiffel-я как раз в том и состоит, что в нем невозможно построить короткое, но сложное выражение, для понимания которого нужно прилагать серьезные умственные усилия. Сами принципы Eiffel-я этому противоречат (в частности Command/Query Separation Principle). Кому-то это может нравится, кому-то нет. Мне кажется, что в большие компании, где над проектами работают команды в сотни программистов, Eiffel удалось протолкнуть именно благодоря этому. К>Вопрос — а так ли нужны эти сотни?
Думаю, что есть области, где наверняка нужны. Вот ты как-то говорил, что сейчас в области телекома работаешь. Я к этой области так же более-менее причастен. Так здесь куда не плюнь таких задачек нарыть можно. Тот же проект AXD301 взять -- там на Erlang-е, если не ошибаюсь, человек 50 писало. Или вот задастся кто-нибудь целью в сжатые сроки создать свою реализацию софта для средней руки SMS-центра для GSM-оператора -- сотню толковых программистов здесь озадачить можно запросто. А уж бестолковых...
Просто со временем ловишь себя на мысли, что чем больше кода приходится поддерживать, тем больше уважения получают языки вроде Eiffel. И если бы мне сейчас пришлось делать что-нибудь критически важное (ну не ядерные ректоры, но что-нибудь из этой же оперы), то я бы, наверное, Eiffel бы рассматривал среди наиболее вероятных вариантов.
К>Формализм (в данном случае языка) это палка о двух концах. Думаю ты не будешь спорить, что создать формально правильный, но монструозный проект можно вполне запросто
Дык до маразма довести можно что угодно. Или если деньги на проект нужно быстро и "грамотно" оприходывать
К>Хотя это уже совсем оффтопик.
Зато философский
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Говоря об Eiffel не нужно забывать о том, что одной из целей языка является максимальная читабельность программ, которая является одним из основных факторов, облегчающих сопровождение кода. Следствием чего должно быть легкое понимание кода без каких-либо дополнительных инструментов, даже напечатанного в книге или в какой-либо другой документации кода.
E>Если применить ваш подход, когда встретив выражение: E>
E>something( producer.demo )
E>
E>только компилятор на основании типа producer.demo сможет сделать вывод о том, что же будет выполнено -- вызов demo или взятие адреса demo, то это нарушит одну из целей языка. Человек сможет разобраться в этом только с помощью IDE и только если заострит внимание именно на этом выражении. В то время как выражение: E>
E>something( agent producer.demo )
E>
E>дает однозначное толкование как для читающего код человека (не важно, с экрана ли код читается или из книги) так и для компилятора.
Собственно, именно это я и имел в виду, когда написал:
Разве только автор считал удобным синтаксически подчеркнуть разницу — а это прямое указание на то, что первоклассность функций считается в этом языке нежелательной возможностью.
E>Я, помнится, столкнулся в Nemerle с тем, что написав вызов чего-то без скобочек получил не вызов, а возврат лямбды. Но здесь Nemerl-исты мне ответили, что мол нефиг без нормальной IDE код писать и читать. В отличии от Nemerle в Eiffel такой ошибки нельзя совершить в принципе.
Думаю, что гибкость часто может быть противоположна безопасности. Вопрос о том, где должна находится точка компромисса между ними — это вопрос личных предпочтений.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Курилка, Вы писали:
K>>Если у параметра тип () -> (U -> V) -передается функциональное значение, а если тип U -> V — выполняется вызов. K>>В общем случае () -> X и X.
К>Насколько я понимаю у тебя тип агента U -> V, тогда вызов должен выполняться при сигнатуре параметра () -> (U -> V), а при U -> V просто передаваться функция. И если даже ты запутался (хотя может и я вру), то тебе не кажется, что это несколько не совсем простые правила? Хотя людям знакомым с Хиндли-Милнером это всё семечки имхо. К>P.S. Или имелся в виду тип параметра в сигнатуре функции (consumer.call_agent), которой нужен агент? Тогда какая-то совсем непонятная нотация выходит.
псевдокод:
//Есть HOF без параметров, возвращающая функцию a -> b.
//Т.е. тип функционального значения для нее () -> (a -> b)
foo : a -> b
{
//...
}
//Имеем функцию высшего порядка
bar1(a : () -> (a -> b))
{
//...
}
bar1(foo) // передаем в bar1 функциональное значение.
//Имеем функцию высшего порядка
bar2(a : a -> b)
{
//...
}
bar2(foo) // вызываем foo и передаем в bar2 результат.
Я имел в виду именно это.
Правила может и не простые (хотя мне они кажутся простыми, ну да это не важно), но я то и говорю о том, что дело не в компиляторе, а в программисте. Явное конструирование agent сделано для программиста, далекого от ФП, для компилятора я проблемы пока не вижу.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
