Вышел язык програмирования Cobra 0.7.4

>Ну так все, нет больше интерпретируемых языков? все довольны?

С какой стати?

> Опоздал. Уже начался. Я когда постил новость все думал по чем же тут флейм начнется. Что вокруг компиляторов - не ожидал:)

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

Блин, ну даже компилятор тебе написал ко всем языкам...

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

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

дотнет родной был, микрософтовский...

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

Памяти. Висящие в памяти JiT и CLR много под себя берут. Да и к тому-же компилиться байткод не самый оптимизированный код ради скорости компиляции. Но все-же исполняется на процессоре непосредственный нативный код, а не интерпретируемый байткод. Ну а то, что много ненужного на мобильных устройствах бекграунда, то это уже другой вопрос. Все таки KDE ты на своем КПК запускать тоже не станешь, не так ли?

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

L={[^n]* | є,R={}}

Ко всем говоришь? если тебе угодно предаваться маразмам.

L={[^\n]* | є,R={}} естественно.

или другой вариант.

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

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

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

А пока это все виртуально компилируемые сферические коныки в вакуумах...

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

16 разрядная архитектура уже виртуальная. Скоро к ней присоединися 32 разраядная.

Ой молодец, исключение написал... Ладно, пойду спать...

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

Я бы предложил словосочетание "компилируемые языка" без указания КУДА компилируемые считать бессмысленным. Целевая архитектура должна указываться.

Т.е. на х86 язык может быть интерпретируемым, где-то компилируемым...

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

"Я устал. Я ухожу."(С)

Как только сделают такую аппаратную С архитектуру, на которой исходные коды на сях запускаются без своего жирного довеска в виде gcc....

Намек понят?

Жирный довесок в виде моно в памяти выполняет СОВЕРШЕННО аналогичную роль, что и твой родной gcc. Просто сам момент компиляции в нативный код различается.

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

во первых, она хотя бы была. и теперь работает быстрее, чем когда то нативная.

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

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

Вот с этой точки зрения и делят на компилируемые и интерпретируемые. Иначе смысл этого деления исчезает и начинается маразм - все интерпретируемое для АЛУ процессора или все компилируемое, только для коня...

Для дураков повторюсь в последний раз. В любом интерпретаторе есть компилятор. Без него никуда. Отличие как раз в том, КОГДА он работает. Заранее и один раз. или при каждом старте программы.

ладно, все.

>Я бы предложил словосочетание "компилируемые языка" без указания КУДА компилируемые считать бессмысленным.

Я ползаю под столом. "Вношу предложение словосочетание признать бессмыссленным". Я ползаю.....

> Отличие как раз в том, КОГДА он работает. Заранее и один раз. или при каждом старте программы.

Я думаю можно это формализовать и еще с кэшированием разобраться.

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

>. Если по аппаратной части, это одно, если по базовой установке ОС, то другое, а если по виртуальной машине, то уже третье.

И самое главное - не первое ни второе ни третье к процессу компиляции отношения никакого не имеют.

>В любом интерпретаторе есть компилятор. Без него никуда.

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

>Отличие как раз в том, КОГДА он работает.

ЗАбавный факт - оба эти языка обрабатывались в рантайме. Для одного из них код вообще на лету генерировался, потом на лету компилировался и исполнялся.

>Я думаю можно это формализовать и еще с кэшированием разобраться.

С википедией разберитесь сначала.

> Я ползаю под столом.

Странно.

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

>И самое главное - не первое ни второе ни третье к процессу компиляции отношения никакого не имеют.

Формально не имеют.

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

- Где мы находимся?!

- Вы на земном шаре!

Правильно, но бесполезно...

> - Вы на земном шаре! Правильно, но бесполезно...

полностью поддерживаю

________________________

а неужели никому не интересно будет ли кобра быстрее питона, скомпиленого через с++?

> С википедией разберитесь сначала.

Modern trends toward just-in-time compilation and bytecode interpretation also blur the traditional categorizations.

Посему считаю что словосочетание "компилируемый язык" без указания целевой архитектуры бессмыслено.

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

Ы? Еще один поц иент?

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

Просто этим редко пользуются.

>Просто этим редко пользуются.

примерно, как py2exe...

всеж хотелось бы критерий какой придумать объективный...

YogSagot, ты бы как определил компилируемость, чтобы с этим все согласились и моно оказалось компилируемым, а не интерпретируемым?

Даже относительно форматной строки printf можно поспорить, что она интерпретируется.

>примерно, как py2exe...

Да иди ты в пень

>YogSagot, ты бы как определил компилируемость, чтобы с этим все согласились и моно оказалось компилируемым, а не интерпретируемым?

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

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

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

Дотнэт/моно работает по принципу, описанному в первом случае.

> интерпретатор разбирает исходный код/байткод и на каждое описанное там логическое действие вызывает определенную подпрограмму в собственном коде

... в результате чего невозможно статически слинковать прогу с какой-то частью интерпретатора, а только с целым.

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

А теперь внимание -- вопрос: если дотнет -- действительно компилятор, как мне *статически* слинковать мою аппликуху для КПК с .net runtime, и тем самым высвободить кучу памяти, которую .net runtime совершенно несправедливо жрет?

(а то что кто-то жутко жрет либо память, либо проц, видно невооруженным глазом, YogSagot утверждал что память)

Это чисто практический вопрос. Если это сделать нельзя, то будь он хоть 10 раз компилятор, мне он будет не лучше интерпретатора.

Интересен этот же вопрос для платформы моно на х86.

Уточнение (я его считал очевидным, но на всякий случай...):

Статически слинковать с .net runtime означает статически слинковать с ИМЕННО ТОЙ ЧАСТЬЮ .net runtime, которая необходима данной конкретной апликушке. Статическая линковка только с полным .net runtime фактически означает что это -- интерпретатор.

Вот мой критерий.

"Несколько" расплывчатая формулировка - а если я не запускаю на выполнение ? 8)) И как быть с самомодифицирующимся кодом ? 8) Я уж не говорю о такой мелочи как невозможность скомпилировать некоторые конструкты языков 8)

> Не поверишь - C, после трансляции Web2C.

Это то понятно. Только я имел ввду паскалевый компилятор

не преумножайте сущности без надобности (кто-то умный)

Здо́рово! Больше языков, хороших и разных.

>В любом интерпретаторе есть компилятор. Без него никуда

Блин, вы реально невменяемы! В любом интерпретаторе есть синтаксический и семантический разбор! Как в компиляторе. Но в интерпретаторе нету кодагенерации! Там есть исполнение!

не нужен

http://ru.wikipedia.org/wiki/Язык_программирования

Компилируемые и интерпретируемые языки

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

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

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

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

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

Для любого интерпретируемого языка можно создать компилятор — например, язык Лисп, изначально интерпретируемый, может компилироваться без каких бы то ни было ограничений. Создаваемый во время исполнения программы код может так же динамически компилироваться во время исполнения.

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

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

Некоторые языки, например, Java и C#, находятся между компилируемыми и интерпретируемыми. А именно, программа компилируется не в машинный язык, а в машинно-независимый код низкого уровня, байт-код. Далее байт-код выполняется виртуальной машиной. Для выполнения байт-кода обычно используется интерпретация, хотя отдельные его части для ускорения работы программы могут быть транслированы в машинный код непосредственно во время выполнения программы по технологии компиляции «на лету» (Just-in-time compilation, JIT). Для Java байт-код исполняется виртуальной машиной Java (Java Virtual Machine, JVM), для C# — Common Language Runtime.

Подобный подход в некотором смысле позволяет использовать плюсы как интерпретаторов, так и компиляторов. Следует упомянуть также оригинальный язык Форт(Forth), который является как бы одновременно интерпретируемым и компилируемым.

> Для выполнения байт-кода обычно используется интерпретация

4.2 ? Это разве не реалии Java 1.0?

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

синтаксический диабет

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

и чем оно лучше того же boo?

спешите видеть, весь вечер на манеже -- GOTO.NET, новый язык под .NET! состоит из одной инструкции GOTO куда,+счётчик[,ещёКуда]: куда -- является ссылкой на внешние по отношению к языку объекты, после перехода счётчик инструкций уменьшается на единицу с каждой инструкцией и когда станет 0, автоматически выполнится переход ещёКуда (на очередную инструкцию GOTO). Таким образом, GOTO.NET описывается самым компактным байткодом: адрес, счётчик[, и возможно следующий адрес]. Так как язык не содержит других инструкций, он является идеально безопасным: выполняются только внешние по отношению к языку доверенные подписанные объекты, при этом в метаданных подписанных объектов хранится допустимое максимальное значение счётчика, таким образом, код на GOTO.NET является верифицируемым. Но и это ещё не всё!! всего за $99.99 вы бесплатно получите continuations framework для GOTO.NET, под названием "No Pasaran!". Закапывайте прямо сейчас!

>Просто делает это не "один раз и забыл" как gcc, а КАЖДЫЙ раз во время исполнения программы.

да и то не всегда -- в вянде, например, в GAC откомпилированные сборки кешируются.

>Ну хорошо, давай я прогу буду из koi-8 переводить utf16. Устроит?

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

>>А компиляция в объектный код идет чиста бес правил как бои?

> Процесс оптимизации идет без правил, ограничения налагаются только на результат оптимизации.

есть там правила, эвристики. Ты когда вручную что-то профилируешь, оптимизируешь -- это что, совсем неформализуемое шаманство? Или есть алгоритм?

>1. Компилятор вполне может заменить это выражение на 0 2. В байткоде ты не имеешь права это делать.

В байткоде JIT может это сделать, сообразуюясь со статистикой, собранной о выполнении методов, каких-то probes из dtrace (это я уже гоню, но суть понятна).

>Пример оптимизации: прога вычисляет a*(a+1) по модулю 2

>1. Компилятор вполне может заменить это выражение на 0 2.

компилятор может заменить (a*a+a)%2, если знает, что a-константа. JIT может заменить, если знает на момент запуска конкретное значение a. Просто замена выйдет отложенной во времени. JIT может хоть lookup таблицу составить для конкретных a и вычислять за O(N), если такая эвристика в нем есть.

>Что толку, что ты собрал С-программу для альфы, если ты запускаешь ее исключительно на x-86 в эмуляторе? Если это конечное состояние, то ты получил обычный байт-код, который играет в виртуальной машине "альфа".

в обратную сторону, кстати, под Альфу был бинарный компилятор FX!32, который бинарный маш. код x86 компилировал в бинарный маш. код 21064.

Бедненький, мозгом повредился. МИНЗДРАВ предупреждает dotNet вреден для неокрепшей психики.

не всякий перевод исходника будет компиляцией. ROT13-компилятор, ЛОЛ :)

да ты чо! это же самый расdontnetный байткод, круче уже некуда! :))) ( для непонятливых -- на том посте должен был стоять смайлик :)