Выпущена Scala 2.7.2 Final

> тогда С всех уделал ассемблерными вставками.

Если что, в стандарте Си нет ассемблерных вставок :) Ну и если для тебя ассемблерные вставки - это повышение уровня, тогда ой.

> Cи абстрагирует программу от вычислительной модели в виде последовательности инструкций процессора,

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

> и переводит его последовательность аппликации функций к их аргументам и возможности определения этих функций.

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

> Вернемся к питону и жабе: где там различия в уровне? Языки объектные, оперируют пследовательностями аппликаций функций к аргументам, модель вычислений одинаковая.

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

Кстати, в Яве _нет_ функций.

> Но языки эти _одинаковые_.

Вообще все языки - одинаковые, я понял.

>\troll{ А ещё от hjkl меньше запястье устаёт. Можно в IDEA переназначить перемещение курсора со стрелок на hjkl? }

Разумеется, с идеей идут дефолтные кеймапы: Mac OS X, Emacs, Visual Studio, JBuilder, Eclipse, Default for XWin, Default for GNOME, Default for KDE. И любой из них можно взять за основу и модифицировать под себя.

>I came across the idea of using letters as arrows in text editor when I was getting into VIM. Inspired by this idea I used for a while HJKL layout with Alt key to “switch” between letters and arrows (wikipedia says HJKL layout was initially used because Lear-Siegler ADM-3A terminal placed arrow symbols on these letters, not because someone didn't like arrows). After some time I realized that HJKL layout still doesn't feel natural for me, so I came back to using arrows. It was about a year ago that I decided to give this idea another try, but this time I used IJKL layout with some modifications. To my surprise, this time using letters as arrows felt so much better that I still use it.

>These are basic shortcuts I use instead of arrows (it's implied that I'm in editing mode):
>Alt+I – go one line up (originally Up);
>Alt+J – go one word left (Ctrl+Left);
>Alt+K – go one line down (Down);
>Alt+L – go one word right (Ctrl+Right);

>Alt+U – goto to the beginning of line (Home);
>Alt+O – goto to the end of line (End).

>Alt+N – go one character left (Left);
>Alt+M – go one character right (Right).

http://codingmatters.blogspot.com/2008/08/custom-intellij-key-bindings-and.html Custom IntelliJ key-bindings and productivity tips (part 1) http://codingmatters.blogspot.com/2008/09/custom-intellij-key-bindings-and-ti...

>>\troll{ А ещё...

>Разумеется,

Не кормите троллей :P

Переназначение перемещения курсора на другие клавиши не делает редактор более мощным. Vimplugin тут более полезен.

>Использование этих языков в инфраструктуре Java показывает, что Java плохо подходит для бизнес-логики, прототипирования, быстрой разработки и скриптинга. Динамические и рантайм-возможности этих языков куда шире, чем у Java. Это не хороши и не плохо. Это - данность. Джаве - одно, Питону - другое.

Поздравляю, джава и не разрабатывалась для бизнес-логики, прототипирования, быстрой разработки и скриптинга FYI. Джава разрабатывалась как высокопроизводительный кроссплатформенный рантайм с низкоуровневым ОО языком а-ля ассемблер. Те, кому нужны возможности скриптинга, городят JRuby, Groovy, Closure, kawa etc. Но это нужно не всем, это узкая ниша, и если жаба скатится в эту нишу питонов-пэхапэ, то ... дотнету ничего не останется как стать платным и собирать сливки ибо со своей задачей вытеснения жабы из интерпрайза он справится. Питоны и похапы микрософту не конкуренты

>>Какие на хрен абстракции?

>Такие.

Ага, понятно, какие-то абстрации вроде бы есть, но какие -- а "такие".

>>Только в случае, если корректность всего этого выражения проверяется в run-time.

>Что такое "корректность"?

Например, наличие столбца 'a' в 'table' и возможность сравнения его значения с числовым литералом '5'.

>>Если же с помощью метапрограммирования данная конструкция разворачивается, транслируется и проверяется в compile-time, то...

>...то хрен тебе чем это поможет. Разве что у тебя уже компилятор научился распознавать лиалекты SQL и компилить ЯВУ "для постгреса", "для мускуля", "для оракела" и тд.

Ну в LINQ for SQL научились.

>>Тогда Windows -- это прямая реализация актеров.

>А для тебя актер это что-то такое что должно быть непосредственно обявлено и обвешано ярлыками? типа если не стоит extends Actor - то уже и не актер?

Когда человек говорит, что мол в одном языке есть актеры, а в другом нет, значит, актеры в этом языке явно выделены как специальное понятие. И этот человек может это продемонстрировать.

Процессы в Erlang могут использоваться для реализации модели актеров, а могут и не использоваться. Равно как и объекты в Java или Python.

>АКПП не делает из водителя Шумахера. Однако, обезьян с гранатой на дорогах прибавляет.

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

>Ну например, жаба оперирует примитивными типами данных, а tcl -- инструментами, Tool Command Language.

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

>показалось, что язык слишком перегружен (даже больше, чем Си++). Посоветуйте какой-нибудь туториал для тупого анонимуса, лучше на русском

Я боюсь что таким придется скоро конкурировать с индусами за $50/month. Ты готов работать за такую цену? Тем более если понимаешь тех.литературу только по-русски. Не пора ли подумать о более высокооплачиваемом занятии, если программирование непосильный интеллектуальный процесс?

>Ну и если для тебя ассемблерные вставки - это повышение уровня, тогда ой.

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

>От этой вычислительной модели Си ни разу не абстрагирует.

Ну да он конешно думает о том в какие регистры чего загнать и какоую функцию дернуть.

>На ассемблере тоже определяются функции, и тоже можно написать последовательность "аппликаций".

Только _абстракции_ не будет. Точно так же как представленный мной "sql" - это цепочеченый вызов фукнций который словами похож на SQL настоящий.

>На ассемблере тоже определяются функции, и тоже можно написать последовательность "аппликаций".

Не все - посмотри что я перечислил. И некоторые (например скала или хаскель) предоставляют возможности оперировать абстракциями более высокого уровня (благодаря eDSL).

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

так и SQL можно рассматривать как "функции с необчным вызовом". Важно чем ты в этот момент оперируешь как понятиями - если передачей сообщений - значит уровень высокий. Если функциями которые реализуют такую модель - то функциями. Отличие такое же как между SELECT * FROM table WHERE... и Query.select("*").from("table").where("...") что можно написать на любом языке в том или ином виде.

>Кстати, в Яве _нет_ функций.

в яве есть месседжи которые выполняют их роль.

>Вообще все языки - одинаковые, я понял.

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

>Ага, понятно, какие-то абстрации вроде бы есть, но какие -- а "такие".

Какой вопрос такой ответ.

>Например, наличие столбца 'a' в 'table' и возможность сравнения его значения с числовым литералом '5'.

Ты мне покажешь такой компилятор который в состоянии это сделать?

>Ну в LINQ for SQL научились.

ТАм нужна задеплоеная база для того чтобы откомпилировать проект? o_0?!

>И этот человек может это продемонстрировать.

Посмотри на скальный апи и ерланговский. Ты говоришь в скале они есть а в эрланге нет. Для меня загадка как эти близнецы неодинаковы.

>Процессы в Erlang могут использоваться для реализации модели актеров

Так есть же мальчик или о чем же ты споришь?

>> Ну и если для тебя ассемблерные вставки - это повышение уровня, тогда ой.

> Это не повышение

Тогда к чему ты вообще их помянул?

>>От этой вычислительной модели Си ни разу не абстрагирует.

>Ну да он конешно думает о том в какие регистры чего загнать и какоую функцию дернуть.

От распределения регистров - да. А вот от вычислительной модели в виде "последовательности инструкций процессора" Си не изолирует.

Ну а какую функцию дернуть - это основная задача прогера, вообще-то.

>> На ассемблере тоже определяются функции, и тоже можно написать последовательность "аппликаций".

> Только _абстракции_ не будет.

Вообще-то функции (и типы данных) - это именно средства конструирования абстракций. В Питоне, по сравнению с Явой, они прще в использовании.

>>На ассемблере тоже определяются функции, и тоже можно написать последовательность "аппликаций".

>Не все - посмотри что я перечислил

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

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

>так и SQL можно рассматривать как "функции с необчным вызовом"

Ага. Труднее, чем операторы Эрланга, но можно. И кстати, по крайней мере ранний embedded SQL именно так и был реализован - препроцессор PL/I переводил SQL в вызовы runtime DB2.

> Важно чем ты в этот момент оперируешь как понятиями - если передачей сообщений - значит уровень высокий.

Только понятие может быть выражено как синтаксической конструкцией DSL, так и функцией/типом данных.

>>Вообще все языки - одинаковые, я понял.

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

В том неуловимом абстрактном смысле, в котором говоришь ты - наверное, нет (тебе виднее). А я говорю о простых повседневных вещах вроде сокращения объема программы.

>Тогда к чему ты вообще их помянул?

К тому что отличия которые ты перечислил - не есть повышения уровня абстракции. Это просто отличия. Все те же структуры данных, те же объекты, те же функции.

>А вот от вычислительной модели в виде "последовательности инструкций процессора" Си не изолирует.

Серьезно? printf("%s", "aaaa") <- какая последовательность инструкций? А на арме? А не мипсе? llvm? Точно не изолирует? Сяшных программистов беспокоин во что онго скомпилится?

>Ну а какую функцию дернуть - это основная задача прогера, вообще-то.

Имел ввиду методом заганяния адреса вектора в определенный регистр.

>Вообще-то функции (и типы данных) - это именно средства конструирования абстракций.

И языки обладающие схождным набором данных примитивов находятся на одном уровне - верно?

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

Не более чем в С итерирование по списочной структуре "обход списка". Так можно сказать - но по факту мы рулим по указателям. А вот в том же XSLT мы трансформируем дерево. А не такой себе набор определений структур с указателями которым мы представляем деревья. А это уже разница в уровне абстрации - работа с деревом или работа с указателями которые реализуют структуру дерева.

>Труднее, чем операторы Эрланга, но можно

Можно. Но не нужно. Это отдельный язык действующий на большем уровне абстракции чем С. Представь что нет никакого SQL а есть язык типа С - во что превратился бы код? Правильно в структуры данных в которые читаются файлы и наборы функций по их обходу циклами. SQL от этого всего абстрагирует - то есть переводит на более другой уровень абстракциии. Уровень этот можно определить как более высокий именно потому что там в андеграунде именно циклы и структуры с указателями - как технические частности реализации.

>Только понятие может быть выражено как синтаксической конструкцией DSL, так и функцией/типом данных.

Может. Но если ты оперируещшь этими понятиями как first class object - это более высокий уровень абстракции чем как если бы ты их выражал через доступные примитивы - в этом суть. В очередной раз показываю "SELECT * FROM table WHERE" <- реляционная алгебра, а SQL.select("*") - вызов функции.


>А я говорю о простых повседневных вещах вроде сокращения объема программы.

Что никак не отражается на уровне абстракции языка или (тут мы вернемся к теме) - полезности IDE.

>>Например, наличие столбца 'a' в 'table' и возможность сравнения его значения с числовым литералом '5'.

>Ты мне покажешь такой компилятор который в состоянии это сделать?

Что мешает сделать это в Nemerle? Есть еще всякие Template Haskell и camlp4, может с их помощью такие штуки можно делать. Имхо, тут не нужен доступ к БД, достаточно иметь во временя компиляции DDL-файл с описанием схемы данных БД.

>>Ну в LINQ for SQL научились.

>ТАм нужна задеплоеная база для того чтобы откомпилировать проект? o_0?!

Нафига? AFAIK, конструкции LINQ могут отображаться на разные типы РСУБД.

>>И этот человек может это продемонстрировать.

>Посмотри на скальный апи и ерланговский. Ты говоришь в скале они есть а в эрланге нет.

Где я говорил, что в Scala актеры есть, а в Erlang нет?

> Для меня загадка как эти близнецы неодинаковы.

Ну так что получается, в Scala обмен сообщениями реализуется через библиотеку, а в Erlang они "из каропки", но близнецы. Так какая нафиг разница, встроенные это средства или нет, если программисты ими могут пользоваться?

Об этом я тебе и говорю, что в таких языках как Scala, Python, Ruby, C++, C# подобные вещи могут быть добавлены пользователем, но выглядеть не хуже, чем встроенные в Erlang.

>>Процессы в Erlang могут использоваться для реализации модели актеров

>Так есть же мальчик или о чем же ты споришь?

Я хочу, чтобы ты доказал свое утверждение о том, что в Erlang-е есть актеры, а в Python-е нет.

То, что что-то может использоваться для реализации актеров -- не катит. Т.к. для их реализации может использоваться много чего. В том же самом Python-е.

>То, что что-то может использоваться для реализации актеров -- не катит. Т.к. для их реализации может использоваться много чего.

Актёры нахрен никому не нужны сами по себе. Нужна ActorModel. То, что ты считаешь, что для её реализации нужны актёры - это проблемы твоего образования: ты путаешь цель с средством:)

>>То, что что-то может использоваться для реализации актеров -- не катит. Т.к. для их реализации может использоваться много чего.

>Актёры нахрен никому не нужны сами по себе. Нужна ActorModel.

r сказал, что в Erlang есть актеры, а не "модель актеров" и не "средства для реализации модели актеров". Пусть покажет.

>То, что ты считаешь, что для её реализации нужны актёры - это проблемы твоего образования: ты путаешь цель с средством:)

Просвети, как можно реализовать ActorModel без актеров, образованый ты наш.

>Просвети, как можно реализовать ActorModel без актеров, образованый ты наш.

Тебе уже дали ссылку на википедию - начись читать.

>r сказал, что в Erlang есть актеры, а не "модель актеров"

Я думаю, r сам ответит на подобное приписывание ему того, чего он не говорил:)

>>r сказал, что в Erlang есть актеры, а не "модель актеров"

>Я думаю, r сам ответит на подобное приписывание ему того, чего он не говорил:)

"По причине процессов, акторов и распределенности." http://www.linux.org.ru/jump-message.jsp?msgid=3240821&cid=3250028

>>Просвети, как можно реализовать ActorModel без актеров, образованый ты наш.

>Тебе уже дали ссылку на википедию - начись читать.

Кто бы говорил.

>Кто бы говорил.

Так читал или нет? Хотя бы вот отсюда

A number of different programming languages employ the Actor model or some variation of it. These languages include:

и далее?

>>А вот от вычислительной модели в виде "последовательности инструкций процессора" Си не изолирует.

>Серьезно?

Да.

> printf("%s", "aaaa") <- какая последовательность инструкций? А на арме? А не мипсе? llvm?

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

>> Труднее, чем операторы Эрланга, но можно

> Можно. Но не нужно.

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

>> Вообще-то функции (и типы данных) - это именно средства конструирования абстракций.

> И языки обладающие схождным набором данных примитивов находятся на одном уровне - верно?>Труднее, чем операторы Эрланга, но можно

Это как бы намек на то, что в Питоне и Яве сходный набор примитивов, следовательно, они на одном уровне? Тогда мы возвращаемся к вопросу о том, где в Яве функции, нормальные замыкания, comprehensions и прочие приятные и полезные фишки.

> Не более чем в С итерирование по списочной структуре "обход списка".

Кстати, так как в Яве с list comprehensions? :D

>>А я говорю о простых повседневных вещах вроде сокращения объема программы.

>Что никак не отражается на уровне абстракции языка

Ой, правда? Слушай, а какие вообще практические выигрыши дает "высокоуровневость" языка (ну кроме приобщения к высоким абстракциям)? То, что она не сокращает объем программ, я уже понял %)

>(тут мы вернемся к теме) - полезности IDE.

Это другая тема, не имеющая отношения к сравнительному уровню Явы и Питона.

>а какие вообще практические выигрыши дает "высокоуровневость" языка (ну кроме приобщения к высоким абстракциям)? То, что она не сокращает объем программ, я уже понял %)

Значит неправильно "понял":) Посмотри на объём Erlag'овских программ.

> Про LLVM не знаю, правда.

Там есть спец. инструкция переменной длинны - call. Аргументы функции передаются самой инструкции. т.е. в байткоде нет указаний на способ передачи аргументов.

Могу ошибаться, во внутренностях глубоко не копался.

>> printf("%s", "aaaa") <- какая последовательность инструкций? ... llvm?

tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([3 x i8]* @.str, i32 0, i32 0), i8* getelementptr ([5 x i8]* @.str1, i32 0, i32 0)) nounwind

@.str - адрес строки форматирования, @.str1 - строки "aaaa"

> Она на всех традиционных архитектурах примерно одинакова

Можно считать, что LLVM - не традиционная архитектура :)

>>а какие вообще практические выигрыши дает "высокоуровневость" языка (ну кроме приобщения к высоким абстракциям)? То, что она не сокращает объем программ, я уже понял %)

>Значит неправильно "понял":) Посмотри на объём Erlag'овских программ.

Посмотрел. :) Tcl почти всегда меньше. Erlang только за счёт List Comprehension выруливает. Tcl - более высокоуровневый? :D

>Хотя бы вот отсюда

>A number of different programming languages employ the Actor model or some variation of it. These languages include:

>и далее?

Похоже, что это единственное, что вы с r в этой статье прочитали.

>Что мешает сделать это в Nemerle?

Что мешает написать язык более высокого уровня? :)

>AFAIK, конструкции LINQ могут отображаться на разные типы РСУБД.

ТА сказаол про корректность относительно существования у определенных таблиц определенных аттрибутов. Если DDL нет и базы нет - как ты эту "корректность" собрался проверять?

>Где я говорил, что в Scala актеры есть, а в Erlang нет?

А что же ты говорил?

>Ну так что получается, в Scala обмен сообщениями реализуется через библиотеку, а в Erlang они "из каропки", но близнецы

API близнецы. Скала имет относительно высокий уровень DSLности благодаря подобным штукам:

def doit(f: Unit) = f doit { printf("aaaa") }

Однако же и я и ты знаем что это просто функция.

>. Так какая нафиг разница, встроенные это средства или нет, если программисты ими могут пользоваться?

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

>Я хочу, чтобы ты доказал свое утверждение о том, что в Erlang-е есть актеры

Мля ты сам определеись - то ты соглашаешься что они там есть что хочешь чтобы это тебе доказали. Ты наверное актерами что-то другое считаешь, а не actor model.

>Можно считать, что LLVM - не традиционная архитектура :)

А еще можно сказать что человек который написал printf уж точно в этот момент не думает о том в какую последовательность инструкций оно откомпилится :)

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

То есть ты не знаешь что будет но одновременно говоришь что знаешь что это будет - как это понимать?

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

Где?

>Это как бы намек на то, что в Питоне и Яве сходный набор примитивов, следовательно, они на одном уровне?

Именно.

>Тогда мы возвращаемся к вопросу о том, где в Яве функции, нормальные замыкания, comprehensions и прочие приятные и полезные фишки.

Разьясню на кубиках. Есть у тебя два набора детских игрушек. В одном наборе только кубики и пирамидки. Во втором кубики, пирамидки и конусы. По твоему абстракция второго набора выше чем абстракция первого или там всего лишь больше типов объектов?

"Где в питоне статическая типизация, параметрический полиморфизм, синхронизация, и т.д."

Это просто разные наборы примитивов _одного уровня_. Отсутствие в жабе структурного элемента для list comprehesions не делает питон выше - это просто опредленонго виде (ленивый)итератор который оперирует списками. И итераторы и списки в жабе - есть. Сущьности одни и те же - одного уровня. Просто этого конуса в наборе нет. Если в жабе появится синтаксис для list comprehensions - это не сдвинет уровень абстракции никуда - все те же примитивы - просто другая их разхновидность. Вон BGGA компилятор - замыкания, и прочую фигню вроде loop abstractions вроде for times(int i : 20) {println(i)} - что жаба резко выросла по своей абстрактности? Гыде? Тот же базовый набор примитивов - только их стало больше разновидностей.

>Кстати, так как в Яве с list comprehensions?

Ну где-то так:

for (int i : $$({int x => x * 2}, range(10), {int x => x < 5})) out.println(i);

> ./java test.Test
0
1
2
3
4
>

пойдет? :))) Если интересно могу весь код запостить - ~ 40 строк //Edited with ViM :)))

Так что не все так плохо как кажется.

>Слушай, а какие вообще практические выигрыши дает "высокоуровневость" языка (ну кроме приобщения к высоким абстракциям)?

Отсутствие необходимости вникать в подробности реализации, оперирование упомянутыми сущностями к которым приобщаешься на их уровне. Когда я пишу: SELECT * FROM - мне абсолютно все равно как там данные хранятся как их прочитать с диска, обойти, отфильтровать, и прочее. Я сказал откуда и по какому условию и получил табличный результат. Ни про какие списки их представления обходы и фильтрации я и не думал.

>То, что она не сокращает объем программ, я уже понял

Сокращает. Однако не все что сокращает программу - переводит ее на другой уровень абстракции.

>>. Так какая нафиг разница, встроенные это средства или нет, если программисты ими могут пользоваться?

>Я что говорю что ими пользоваться нельзя?

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

> Я говорю об _уровне абстракции_ - какие слова непонятны?

Не понятны две вещи:

1. С какого перепугу ты сопоставляешь предметно-ориентированные языки (XSLT, SQL) языкам общего назначения?

2. Почему ты считаешь, что Erlang является языком более высокого уровня, чем Python? И, в частности, не понятно, каким образом язык Erlang _встроенно_ поддерживает понятие Actor.

>А в XSLT дерево и его трансформация - яв ядре - уровень аьбстракйции там совершенон жругой никаких указателей и функций обхода там нет. Что не ясно?

А нутка, покажи, друг сердешный, перемножение матриц на XSLT. Язык более высокого уровня, чем C, должен позволять сделать это более комактно и выразительно, чем на C.

>>Я хочу, чтобы ты доказал свое утверждение о том, что в Erlang-е есть актеры

>Мля ты сам определеись - то ты соглашаешься что они там есть что хочешь чтобы это тебе доказали.

Ты бы за свои слова отвечал -- сказал, что в Erlang есть актеры -- показывай. Я пока нигде не утверждал, что в Erlang есть актеры. В Erlang есть средства для реализации actor model, но эти средства можно использовать и в других целях.

>Ты наверное актерами что-то другое считаешь, а не actor model.

Актер, да будет тебе извесно, это лишь одна из частей actor model. Если ты говоришь, что язык поддерживает это понятие, то покажи языковые конструкции, которые за это понятие отвечают.

А то ведь в рамках actor model можно строить системы, в которых актерами будут самостоятельные процессы ОС, а средством обмена сообщениями -- протокол SMTP. И получается, что на Python можно строить приложения на основе actor model, но по-твоему мнению, в Python-е актеров нет. А сам Python является языком более низкого уровня, чем Erlang. Как-то твои утверждения противоречат окружающей действительности.

>Ты говоришь о том, что если программист пользуется абстракцией A, встроенной в язык, то это язык более высокого уровня, чем другой, в котором A реализуется библиотекой.

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

>1. С какого перепугу ты сопоставляешь предметно-ориентированные языки (XSLT, SQL) языкам общего назначения?

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

>2. Почему ты считаешь, что Erlang является языком более высокого уровня, чем Python?

Потому что в эрланге есть абстракции более высокого уровня. Или как - эрланг это такой язык никакой ничем не отличающийся от обычного питона?

>А нутка, покажи, друг сердешный, перемножение матриц на XSLT.

С какой радости? Покажи мне как питон ходит за пивом. Что не пожет? Гавно язык?

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

Можегшь показать как тебе за пивом бегает C. А я вспомнил - он для того чтобы проги писать а не бегать за пивом. А - да так и XSLT матрицы перемножать не предназначен - ему деревья трансформировать.

>Ты бы за свои слова отвечал -- сказал, что в Erlang есть актеры -- показывай.

Что ты называешь актером?

>Я пока нигде не утверждал, что в Erlang есть актеры. В Erlang есть средства для реализации actor model, но эти средства можно использовать и в других целях.

Я когда мне шибко надо плоскогубцами гвозди забиваю. Чтобы молоток не доставть. Из этого следует что? Что раз я использхую плоскогубцы в других цельях отличных от плоскогубцевания то.... <тут даже не знаю что описать>. Собственно что?

>Актер, да будет тебе извесно, это лишь одна из частей actor model.

То есть актор модел в ерланге есть а актеров нет? Ты это хочешь сказать? Уже определись.

>И получается, что на Python можно строить приложения на основе actor model, но по-твоему мнению, в Python-е актеров нет.

Ага - надо было эрикам взять питон и не мучацца.

"язык" vs "библиотека". На любом тьюринг-полном языке можно реализовать модель трансформации деревьев. По твоему не будет разницы между XSLT и этой реализацией относительно уровня абстракции?

>Если ты говоришь, что язык поддерживает это понятие, то покажи языковые конструкции, которые за это понятие отвечают.

send receive

>А то ведь в рамках actor model можно строить системы, в которых актерами будут самостоятельные процессы ОС, а средством обмена сообщениями -- протокол SMTP

И писать это все на ассемблере. Какай болван сказал что питон и ассеблер языки оперирующие разным уровнем абстракции....

>>1. С какого перепугу ты сопоставляешь предметно-ориентированные языки (XSLT, SQL) языкам общего назначения?

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

Тогда нужно дать базис для сравнения между собой языков из группы Erlang, Java, Python, XSLT и SQL. Понятие "уровень абстракции" требует определения. Ждем-с.

Кстати, если мы уж смешали в одну кучу эти языки, то было бы интересно узнать, кто из них самый высокоуровневый -- XSLT или SQL. На основании выбранных тобой _одних и тех же_ параметров.

>>Ты бы за свои слова отвечал -- сказал, что в Erlang есть актеры -- показывай.

>Что ты называешь актером?

Я ничего не называю. Ты увидел что-то в Erlang-е, вот и скажи, что именно ты в Erlang-е называешь актером.

>>>Актер, да будет тебе извесно, это лишь одна из частей actor model.

>То есть актор модел в ерланге есть а актеров нет? Ты это хочешь сказать?

Еще раз: по-моему, в Erlang-е есть средства для реализации модели актеров (чтобы быть более точным -- для построения систем на основе модели актеров). А не сама модель.

>Я когда мне шибко надо плоскогубцами гвозди забиваю. Чтобы молоток не доставть. Из этого следует что?

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

>Еще раз: по-моему, в Erlang-е есть средства для реализации модели актеров (чтобы быть более точным -- для построения систем на основе модели актеров). А не сама модель.

Ты ошибаешся. Что, в прочем, и неудивительно, если Erlang ты видел только "на картинках"...

>Понятие "уровень абстракции" требует определения.

Обратитесь к Аристотелю: http://ru.wikipedia.org/wiki/Абстракция
А так же определение по отношению к программированию: http://en.wikipedia.org/wiki/Abstraction_layer

>то было бы интересно узнать, кто из них самый высокоуровневый -- XSLT или SQL.

SQL и XSLT не являются сравнивыми по причине отсутвия общих абстракций которыми они оперируют - то есть они нахдятся в разных иерархиях абстракций.

>Я ничего не называю.

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

Данный прием называется абстрактная аналогия.

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

>>то было бы интересно узнать, кто из них самый высокоуровневый -- XSLT или SQL.

>SQL и XSLT не являются сравнивыми по причине отсутвия общих абстракций которыми они оперируют - то есть они нахдятся в разных иерархиях абстракций.

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

>Процессы выполняют роль акторов в эрланге.

Тогда твое утверждение на счет Erlang-а звучит так: "Потому что в нем есть процессы, процессы и распределенность". Масло масленное. Может ты хоть сейчас это поймешь.

>>Еще раз: по-моему, в Erlang-е есть средства для реализации модели актеров (чтобы быть более точным -- для построения систем на основе модели актеров). А не сама модель.

>Ты ошибаешся. Что, в прочем, и неудивительно, если Erlang ты видел только "на картинках"...

Ну вы с r и такого впечатления не производите.

>>Ты ошибаешся. Что, в прочем, и неудивительно, если Erlang ты видел только "на картинках"...

>Ну вы с r и такого впечатления не производите.

Да я и не собираюсь производить на тебя впечатление. Я просто програмлю не Erlang'е, не первый день, в том числе и с использованием ActorModel без дополнительных телодвижений. И тут появляется пайтонист и пытается доказать мне, что всё это время мне только снилось, что я програмлю на Erlang:)))

Сорри, но ты смешён:)

Я, например, не знаю как программить на пайтоне с ActorModel, и вообще пока-что не знаю воможности Scala, но я и не пытаюсь о них тебе что-то рассказывать:)

> появляется пайтонист и пытается доказать мне, что всё это время мне только снилось, что я програмлю на Erlang:)))

> Сорри, но ты смешён:)

Пайтонист здесь я (и то очень условно). Ты всё перепутал %)

>Тогда ты просто сравниваешь яблоки с помидорами

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

> Тогда твое утверждение на счет Erlang-а звучит так: "Потому что в нем есть процессы, процессы и распределенность"

Двойка тебе по логике. По твоему фирмы продающие "компьютеры и комплектующие" - тоже пишут тавтологию потому что компьютеры состоят из комплектующих?

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

Но сами по себе процессы не обязательно могут быть акторами - легко представить себе модель но shared nothing как в эрланге, а с шареной памятью в которую все пишут и читают. Процессы есть - акторов - нет.

Может ты хоть сейчас это поймешь.

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

> То есть ты не знаешь что будет но одновременно говоришь что знаешь что это будет - как это понимать?

Это понимать так, что я не знаком с системрй команд LLVM даже поверхностно.

>>Кстати, так как в Яве с list comprehensions?

>Ну где-то так:

>for (int i : $$({int x => x * 2}, range(10), {int x => x < 5})) out.println(i);

> пойдет? :)))

Смотря что это. Невыпущенная Ява7? Jexl? Какой-то препроцессор? Или стандартная возможность компилятора Ява6?

> Если интересно могу весь код запостить - ~ 40 строк //Edited with ViM :)))

"Как это понимать?" (C) Причем тут 40 строк? Ты запостил одну и сказал, что она работает.

> не все что сокращает программу - переводит ее на другой уровень абстракции.

> Какай болван сказал что питон и ассеблер языки оперирующие разным уровнем абстракции..

Ты просто сыплешь афоризмами :D Если ассемблер и Питон оперируют одинаковым уровнем абстракций, вопросов больше нет %)

>Это понимать так, что я не знаком с системрй команд LLVM даже поверхностно.

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

>Смотря что это. Невыпущенная Ява7? Jexl? Какой-то препроцессор? Или стандартная возможность компилятора Ява6?

BGGA компилятор. Совместимо с обычной jvm. Будет в ява7.

И вот есть у меня сомнения что уровень абстракции жабы - повысился.... просто добавилась лишняя фигурка в набор кубиков.

>Ты запостил одну и сказал, что она работает.

упомянутый Range и FilteredIterator с лямбдами не есть набором стандартных коллекций jre - так накалякал побыстрому. $$ - собственно статический метод этого итератора. list comprehensions в жабу не добавили - тут все за счет только лямбд. А LC я наваял побыстрому:))

>Ты просто сыплешь афоризмами :D Если ассемблер и Питон оперируют одинаковым уровнем абстракций, вопросов больше нет %)

Там справа горел знак "саркастичная ирония". Конечно они на разном. Но вот коллега заявил что раз на питоне можно заваять реализацию actor model - это поставит на один уровень абстракции _языки_. Руководствуясь этой логикой....

>Пайтонист здесь я (и то очень условно). Ты всё перепутал %)

Не препутал. Про тебя я знал, но думал, что он тоже пайтонист. Прошу прощения, если ошибся.

>> Это понимать так, что я не знаком с системрй команд LLVM даже поверхностно.

> Нет - это понимать так что общие представления о том во что оно компилиться тебя не беспокоят, когда ты оперируешь понятиями функций в Си.

Ну тебе виднее, что меня беспокоит %) Для протокола: бывает, что мне очень интересно, в какие именно инструкции компилирует Си. Редко, но бывает.

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

ооот... _ты_ работаешь. А меня иногда интересует пусть и не вектора и сканкоды, но приоритет keventd. Так что "отучаемся говорить за всех" (c).

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

>>Смотря что это. Невыпущенная Ява7? Jexl? Какой-то препроцессор? Или стандартная возможность компилятора Ява6?

>BGGA компилятор. Совместимо с обычной jvm. Будет в ява7.

Ну то есть в реальности пока не встречается.

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

А всё, с чем мы имеем дело - кубики и клей. SQL - кубик, XSLT - клей.

> Там справа горел знак "саркастичная ирония"

Как-то тускло он горел %)

> Про тебя я знал

ыыыы... я не питонист, я только пишу на Питоне %)

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

Я вон там привел ссылку на Аристотеля. Все перечисленные тобой штуки питона (а яперечислил штуки жабы которых в питоне нет) не повышают уровень абстракции так как примитивы с которыми мы работает - одни и те же. Как еще один контпример смоллтолк- в неи нет управляющей конструкции if - есть только методы Boolean с аргуметами в виде замыканий. Обозначает ли это что смолтолк из-за этого стал билже к ассемблеру по сравнению с С где эта конструкция есть?

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

Уровень абстракции повышается когда примитивами становятся более другие обекты, в частных потрохах которых есть обеъекты над которыми вы повышаемся абстрактно. Гдето-том в потрохах реализации SQL engine - структуры указатели и функции. Однако манипулируем бы более абстрактными обектами - таблицы, строки, столбы, поля, связи. Вот почему SQL - имеет больший уровень абстракции.

>Ну то есть в реальности пока не встречается.

С чего это не встречается? Код работает. Это что - нереально?

>>Тогда ты просто сравниваешь яблоки с помидорами

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

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

Так ты озвучишь общий набор критериев, на основании которых оценивается группа из Java, Python, SQL, XLST и Erlang? Или ты волен каждый язык сравнивать только в какой-то одной очень узкой нише. Прикрываясь при этом умными фразами о Сократе и Аристотеле.

>> Тогда твое утверждение на счет Erlang-а звучит так: "Потому что в нем есть процессы, процессы и распределенность"

>Двойка тебе по логике.

Это всего лишь попытка найти логику в твоих утверждениях.

>По твоему фирмы продающие "компьютеры и комплектующие" - тоже пишут тавтологию потому что компьютеры состоят из комплектующих?

Доказательство по аналогии -- суть демагогия.

>Процесс - не обязательно актор.

Уже прогресс. Но я тебе об этом сказал уже давно: http://www.linux.org.ru/jump-message.jsp?msgid=3240821&cid=3250978

>Но сами по себе процессы не обязательно могут быть акторами - легко представить себе модель но shared nothing как в эрланге, а с шареной памятью в которую все пишут и читают. Процессы есть - акторов - нет.

Если бы вы Led-ом лучше знали actor model, то знали бы, что одним из первых языков, который был создан для ее реализации, была Scheme (http://en.wikipedia.org/wiki/Scheme_programming_language). Так же вы могли бы знать, что actor model базируется на одном простом принципе -- сущности (актеры) взаимодействуют друг с другом только посредством обмена сообщений и принимают решение о своей дальнейшей судьбе только на основании своего текущего состояния и получаемых сообщений. Поэтому сама actor model не налагает никаких требований по поводу sharing nothing или sharing all. Актером может быть кто угодно -- процесс в Erlang-е или объект в Java (SEDA), Scala (ScalaActors), Python (Eventlet, Kamaelia), Ruby (Revactor), C++ (SObjectizer, Act-o). Более того, с использованием архитектуры FIPA актерами могут быть отдельные процессы, использующие различные протоколы для коммуникации.

Так вот в Erlang есть процессы, есть передача сообщений. Понятия актера на уровне языка нет -- ты это не можешь показать. Процессы могут использоваться для реализации actor model, а могут и не использоваться. Аналогично в Python есть объекты, есть вызовы методов. Объекты и вызовы методов могут использоваться для реализации actor model, а могут и не использоваться.

>Да я и не собираюсь производить на тебя впечатление. Я просто програмлю не Erlang'е, не первый день,

Наверное, второй или третий.

> в том числе и с использованием ActorModel без дополнительных телодвижений. И тут появляется пайтонист и пытается доказать мне, что всё это время мне только снилось, что я програмлю на Erlang:)))

Ну если ты знаешь Erlang, то расскажи r, какие языковые конструкции в нем предназначены для поддержки распределенности. А то ведь r утверждает, что в языке (не в среде исполнения) это есть.

>Я, например, не знаю как программить на пайтоне с ActorModel,

Это заметно.

>Я просто програмлю не Erlang'е, не первый день,

>Наверное, второй или третий.

"Железные аргумент":)

>Ну если ты знаешь Erlang, то расскажи r, какие языковые конструкции в нем предназначены для поддержки распределенности.

Зачем мне ему что-то рассказывать? Думаю, он и так знает.

>А то ведь r утверждает, что в языке (не в среде исполнения) это есть.

Да это так.

>>Я, например, не знаю как программить на пайтоне с ActorModel,

>Это заметно.

Чего сказать-то хотел? И просто - чтоб не молчать?:)

>>Ну если ты знаешь Erlang, то расскажи r, какие языковые конструкции в нем предназначены для поддержки распределенности.

>Зачем мне ему что-то рассказывать? Думаю, он и так знает.

>>А то ведь r утверждает, что в языке (не в среде исполнения) это есть.

>Да это так.

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

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

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

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

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

>Прикрываясь при этом умными фразами о Сократе и Аристотеле.

Ты статью то прочитай. Она как раз по теме. Если ты просишь ссылок а по ссылкам не ходишь - тогда разговаривать не очем больще.

>Доказательство по аналогии -- суть демагогия.

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

>Поэтому сама actor model не налагает никаких требований по поводу sharing nothing или sharing all.

Ты сейчас с кем спорил? Где-то кто-то это утверждал?

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

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