Выпущена Scala 2.7.2 Final

>>Так это как? Какие языковые конструкции в Erlang отвечают за распределенность?

>Можно вопрос - ты сейчас чтобы прооппонировать какому моему утверждению задавал вопорс?

Конечно. Ты утверждал, что Erlang более высокоуровневый, чем Java и Python, поскольку в нем есть "процессы, акторы и распределенность". Со временем выяснилось, что эта фраза должна звучать как "процессы, процессы и распределенность". Теперь можно показать, что из нее следует выбросить еще и "распределенность".

>>Ну так умножь матрицы на SQL или хотя бы сделай обработку деревьев на SQL.

>Я вот думаю ты серьезно не понимаешь или одно из двух?

Я всего лишь показываю, что ты проводишь сравнение нескольких языков, не декларируя набора критериев, по которым это сравнение проводится. При этом ты явно сравниваешь разные языки по разным критериям.

А для того, чтобы убедить себя в собственной правоте, пытаешься казаться умнее самого себя. Кстати, я не просил ссылок на Сократа с Аристотелем. Я прошу от тебя озвучить критерий "уровень абстракции" на вообще, а в применении к твоему конкретному сравнению языков.

>>Понятия актера на уровне языка нет -- ты это не можешь показать

>Задаю вопрос в третий раз - что такое по твоему актор? Объект? Интерфейс? Ключевое слово? Что ты ждешь чтобы там было?

Понятие актера определяется конкретной реализацией модели актеров. Это может быть объект, если модель строится на объектах; процесс, если модель строится на основе SMTP протокола. Но в любом случае актеры явно выделяются среди других объектов программы (если речь идет о модели на объекта) -- либо наследованием от специального базового класса, либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

Так вот, если ты заявляешь, что язык Erlang _непосредственно_ поддерживает понятие актера, то покажи, как в языке Erlang процессы-актеры _явно_ выделяются по сравнению с процессами не-актерами.

>Со временем выяснилось, что эта фраза должна звучать как "процессы, процессы и распределенность". Теперь можно показать, что из нее следует выбросить еще и "распределенность".

Забавный ты человек. В XSLT остутствует какое-либо упоминание "дерева" в языке - обозначает ли это что там нет деревьев?

>Я всего лишь показываю, что ты проводишь сравнение нескольких языков, не декларируя набора критериев, по которым это сравнение проводится.

Я думал что достаточно разумный человек в состоянии сделать пересечение множеств функций этих языков и сделать вывод что говорю именно о них - извини ошибся.

>При этом ты явно сравниваешь разные языки по разным критериям.

Пожалуста больше не делай никаких выводов - у тебя это плохо получается.

>Кстати, я не просил ссылок на Сократа с Аристотелем.

Ты просил обяснить что такое уровни абстракции. Аристотель тот самый человек который ввел это понятие. Я тебе дал ссылки на философское определение и на применение в области IT.

>Я прошу от тебя озвучить критерий "уровень абстракции" на вообще, а в применении к твоему конкретному сравнению языков.

Вот там именно это и озвучено.

> Но в любом случае актеры явно выделяются среди других объектов программы (если речь идет о модели на объекта) -- либо наследованием от специального базового класса, либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

Серьезно? Можно узнать это ты сам придумал или ты в состоянии привести ссылку на авторитетный источник по этому поводу?

>либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

Ага. То что процессы эрланга понимают месседж пассинг семантикс тебе о чем нить говорит?

И еще такой комемнтарий - ты не заметил как ты туже все свел к обектным языкам? ДАю справку - языки могут быть совсем не объектными. Особенно когда мы углубляеся в специализированные языки.

>Так вот, если ты заявляешь, что язык Erlang _непосредственно_ поддерживает понятие актера, то покажи, как в языке Erlang процессы-актеры _явно_ выделяются по сравнению с процессами не-актерами.

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

Я так понял люди с кровью на основе железа не существуют по причине того что невозможно во всем человечестве найти люедей с отличной кровью.

>>Я всего лишь показываю, что ты проводишь сравнение нескольких языков, не декларируя набора критериев, по которым это сравнение проводится.

>Я думал что достаточно разумный человек в состоянии сделать пересечение множеств функций этих языков и сделать вывод что говорю именно о них - извини ошибся.

Сделай, пожалуйста, пересечение множеств функций языков SQL, Python и XSLT (именно этих трех сразу), что бы я понял, на основании чего можно говорить об уровнях абстракции. А то у меня не получается.

>>Со временем выяснилось, что эта фраза должна звучать как "процессы, процессы и распределенность". Теперь можно показать, что из нее следует выбросить еще и "распределенность".

>Забавный ты человек. В XSLT остутствует какое-либо упоминание "дерева" в языке - обозначает ли это что там нет деревьев?

Когда в языке что-то есть, то для этого чего-то существуют специальные языковые конструкции. Вот, список примеров:

В Eiffel и D есть DesignByContract и соответствующий синтаксис для работы с ним.

В Java есть понятие пакета и соответствующий синтаксис для работы с ним.

В функциональных языках есть паттерн-матчинг и синтаксис для работы с ним.

В Java есть понятие интерфейса и специальный синтаксис для его описания. А вот в C++ нет понятия "интерфейса" -- есть только классы. Программист на C++ может пользоваться интерфейсами, применяя для этого абстрактные классы, но встроенной поддержки "интерфейса" в C++ нет. В отличии от Java.

Когда ты говоришь о том, что в языке есть какие-то понятия (актер, распределенность), то хотелось бы видеть, какими синтаксическими конструкциями эти понятия поддерживаются _напрямую_.

>Сделай, пожалуйста, пересечение множеств функций языков SQL, Python и XSLT

Я понимаю что википедию ты читать не хочешь и потому понятие иерархия абстракции для тебя ничего не значит - но я напомню то о чем упоминал - SQL и XSLT не находятся в одной иерархии, и не существует в данном треде не одного моего утверждения из которого можно допустить что XSLT сравним с SQL. Из чего я делаю вид что ты вместо того чтобы читать мнение оппоненто его придумываешь. А спорить с твоими фантазиями бесполезно - ты все равно не читаешь.

>> Но в любом случае актеры явно выделяются среди других объектов программы (если речь идет о модели на объекта) -- либо наследованием от специального базового класса, либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

>Серьезно? Можно узнать это ты сам придумал или ты в состоянии привести ссылку на авторитетный источник по этому поводу?

Серьезно. А ты можешь это мнение опровергнуть?

>>либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

>Ага. То что процессы эрланга понимают месседж пассинг семантикс тебе о чем нить говорит?

Мне это о многом говорит. В частности о том, что передача сообщений и разделение работы в Erlang на процессы, в первую очередь направлено на обеспечение sharing nothing и, как следствие, на повышение отказоустойчивости. А все остальное, в том числе и дешовая реализация модели актеров является следствием из этого. И именно поэтому в Erlang есть такое понятие как процесс, но нет такого понятия как актер.

>И еще такой комемнтарий - ты не заметил как ты туже все свел к обектным языкам?

Если ты не заметил, то специально для тебя повторю еще раз: объекты в объектных языках могут использоваться для реализации модели актеров не менее успешно, чем процессы в Erlang. Это доказано практикой. Хотя ты можешь этого не знать и не хотеть увидеть.

Поэтому это еще одна некорректность утверждения о том, что Erlang более высокоуровневый язык, чем Python на основании отсутствия в Python объектов.

>ДАю справку - языки могут быть совсем не объектными. Особенно когда мы углубляеся в специализированные языки.

Справок дальше Wikipedia от тебя ждать не приходится.

>В Eiffel и D есть DesignByContract и соответствующий синтаксис для работы с ним.

*капризно* Хочу видеть концепцию контракта в языке. Хочу видеть интерфейс Contract или реализацию с помощью утиного тайпинга. покажи мне контракты в D.

>В функциональных языках есть паттерн-матчинг и синтаксис для работы с ним.

Хачу интерфейс или дактайпинг к паттерн матчингу! Пакажите мне паттерн матчинг!

>Когда ты говоришь о том, что в языке есть какие-то понятия (актер, распределенность), то хотелось бы видеть, какими синтаксическими конструкциями эти понятия поддерживаются _напрямую_

Вот и найди мне какими синтаксическими конструкциями поддерживается вывод типов. Я так понимаю что на основании отсутствия оных можно удверждать что такого понятия как вывод типо вообще не существует.

>Серьезно. А ты можешь это мнение опровергнуть?

Легко - это не верно. А ты можешь это мнение опровергнуть?

>Это доказано практикой.

Та хоть религиозной доктриной - кто-то утверждал что модель акторов нельяз реализовать отдельно? Короче иди читай аристотеля - ты вообще не понимаешь слова абстракция и о чем тут был разговор.

>Справок дальше Wikipedia от тебя ждать не приходится.

Ты и википедии осилить не в состоянии. Обратить в среднюю школу.

> Хочу видеть концепцию контракта в языке. Хочу видеть интерфейс Contract или реализацию с помощью утиного тайпинга.

IMHO эти два требования противоречат друг другу.

>>В Eiffel и D есть DesignByContract и соответствующий синтаксис для работы с ним.

>*капризно* Хочу видеть концепцию контракта в языке.

http://eao197.narod.ru/better_language/languages/eiffel/0_overview.html#desig...

http://docs.eiffel.com/eiffelstudio/general/guided_tour/language/tutorial-09....

>покажи мне контракты в D.

http://www.digitalmars.com/d/1.0/dbc.html

>>>Когда ты говоришь о том, что в языке есть какие-то понятия (актер, распределенность), то хотелось бы видеть, какими синтаксическими конструкциями эти понятия поддерживаются _напрямую_

>Вот и найди мне какими синтаксическими конструкциями поддерживается вывод типов.

Легко -- синтаксис, допускающий декларации сущностей (переменных, констант) без указания их типов.

PS. Мне казалось, что я разговаривал с хоть что-то знающим человеком.

>>Серьезно. А ты можешь это мнение опровергнуть?

>Легко - это не верно. А ты можешь это мнение опровергнуть?

Легко -- оно не подтверждено авторитетными источниками.

>ты вообще не понимаешь слова абстракция и о чем тут был разговор.

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

>IMHO эти два требования противоречат друг другу.

Это к господину который требует чтобы все сущьности выражались синтаксическим конструктом интерфейсом или дактайпингом.

>http://eao197.narod.ru/better_language/languages/eiffel/0_overview.html#desig...
>http://docs.eiffel.com/eiffelstudio/general/guided_tour/language/tutorial-09....
>http://www.digitalmars.com/d/1.0/dbc.html

В какой строке там интерфейс или дактайпинг?

>Легко -- синтаксис, допускающий декларации сущностей (переменных, констант) без указания их типов.

JavaScript, Python, Ruby, ......

Я так понимаю все эти языки имебт вывод типов - в них синтаксис это допускает.

>PS. Мне казалось, что я разговаривал с хоть что-то знающим человеком.

Он как раз что-то знает и в состоянии отличить type inference и отсутствие манифестационной типизации.

Так что жду в чем жэе конкретно выражается синтаксис вывода типов, при чем желательно с применением интерфейсов и дактайпингов.

>>IMHO эти два требования противоречат друг другу.

>Это к господину который требует чтобы все сущьности выражались синтаксическим конструктом интерфейсом или дактайпингом.

"Из чего я делаю вид что ты вместо того чтобы читать мнение оппоненто его придумываешь. А спорить с твоими фантазиями бесполезно - ты все равно не читаешь." (c) r

>в любом случае актеры явно выделяются среди других объектов программы (если речь идет о модели на объекта) -- либо наследованием от специального базового класса, либо реализацией какого-то интерфеса (пусть даже на основе duck typing-а).

Сиди читай.

>Сиди читай.

Вот здесь речь шла об актерах: http://www.linux.org.ru/jump-message.jsp?msgid=3240821&cid=3258926

А здесь о прямой поддержке каких-либо понятий синтаксисом языка: http://www.linux.org.ru/jump-message.jsp?msgid=3240821&cid=3260449

Это разные сообщения и нигде не было утверждений о возможности реализации контрактов или паттерн-матчинга через duck-typing не было.

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

>Он как раз что-то знает и в состоянии отличить type inference и отсутствие манифестационной типизации.

Попытка в разговоре о выводе типов приводить примеры динамически-типизированных языков служит доказательством обратного.

>Это разные сообщения и нигде не было утверждений о возможности реализации контрактов или паттерн-матчинга через duck-typing не было.

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

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

Я признаться подумал что ты хочешь поговорить о языках, а не о том как ты видишь мир. Последнее мне не интересно. Извини что подумал что ты хочешь обсудить языки программирования.

>Попытка в разговоре о выводе типов приводить примеры динамически-типизированных языков служит доказательством обратного.

Динамические языки подходят пот твое определения синтаксиса вывода типов - они неотличимы.

Хватит валять дурака - нет никакого синтаксиса для вывода типов - вывод типов - это возможность компилятора языка.

Из чего проистекает очевидная истина - не все ствойства языка выражаются синтаксическими конструктами - их может быть ровно ноль. Модель вычислений пролога никак не выражается в языке. Деревья XSLT никак не выражаются в языке. Вывод типов никак не выражается в языке.

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

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

В эрлагне есть актеры роль коих выполняют процессы и специальные синтаксические конструкты ! и receive которые являются частью реализации актор модел. Поскольку они являются именно языковыми конструкциями, а не библиотечными функциями можно сказать что actor model поддерживается на уровне языка.

Это все господа пресяжные заседатели.

>Модель вычислений пролога никак не выражается в языке.

Крутая у тебя трава!

>Крутая у тебя трава!

Не подскажешь синтаксические конструкции? (токо шоб с дактайпингом и интерфесами). Оценю твою траву.

>>Крутая у тебя трава!

>Не подскажешь синтаксические конструкции? (токо шоб с дактайпингом и интерфесами). Оценю твою траву.

У меня не трава, у меня грибы. Но ты смешал их со своей травой и теперь тебе мерещится, что контракты Eiffel-я, паттерн-матчинг OCaml-а и правила вывода в Прологе я реализую исключительно через duck type interface.

>У меня не трава, у меня грибы

Жаль что не синтаксические конструкции.