LINUX.ORG.RU

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

 cobra, ,


0

0

Описание языка:

  • OOP: классы, интерфейсы, структуры, методы, свойства, индексаторы, генерики, аттрибуты
  • Контроль качества: контракты, ассерты, unit-тесты на уровне языка, документирующие строки, слежка за nil во время компиляции
  • Выразительность: статическое и динамическое связывание, списки и словари, оператор in, оператор for, slicing, параметризованные строки, вывод типов
  • Продуктивность: поддержка исключений, стектрейсы, сборка мусора
  • Поддержка скриптования
  • Компилируемый язык

Целевая платформа .NET/Mono. Лицензия - MIT. Вдохновлен python, ruby, eiffel и Objective-С.

>>> Cobra Language

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от AVL2

>компилятор я уже представил. Вместе с декомпилятором...

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

r ★★★★★
() автор топика
Ответ на: комментарий от r

>Во маразм. Комилируемость языка уже зависит от того на каком языке написан его транслятор. Где ты такого бреда набрался?

читать умеем. не зависит.

Более того, тебе в твоей же говнопедии пишут, что деление условно...

Higher-level programming languages are generally divided for convenience into compiled languages and interpreted languages. However, there is rarely anything about a language that requires it to be exclusively compiled, or exclusively interpreted. The categorization usually reflects the most popular or widespread implementations of a language — for instance, BASIC is thought of as an interpreted language, and C a compiled one, despite the existence of BASIC compilers and C interpreters.

Просто ты как, деревенская баба - "що вы пишите здорова! пишите, маленька или как у усих!"

AVL2 ★★★★★
()
Ответ на: комментарий от r

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

согласен. спасибо за поправку.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>Более того, тебе в твоей же говнопедии пишут, что деление условно...

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

r ★★★★★
() автор топика
Ответ на: комментарий от r

>>Хорошо... еще все ньюлайны питона1 заменю пробелами

>Пробел является символом исходного алфавита - он присутствует в исходном коде. Преобразования _нет_. Алфавит питона1 === Алфавиту питон2 как не извращайся.

А в питоне ньюлайн значащий, ты этого даже не сказал :-)

Ладно. Возмьмем паскаль1 на аскии (128 символов) и паскаль2 на аскии, но без символа перевода строки (127) символов и будем транслировать паскаль1 в паскаль2, заменяя ньюлайн пробелом. Алфавит-то уменьшается?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от r

>Деления языков условно. Понятие компиляции - однозначно.

Точно. Но мы говорим именно о языках, является ли _язык_ компилируемым, а не есть ли к нему компилятор, декомпилятор или транслятор...

AVL2 ★★★★★
()
Ответ на: комментарий от r

Вообще, зря от темы отклонились.

Итак, LMD2 утверждает, что .NET-языки некомпилируемые. Или пусть берёт свои слова обратно, или пусть конкретно это и доказывает. Схожу пока за попкорном.

anonymous
()
Ответ на: комментарий от AVL2

Мы говорим о конкретных реализациях языков. А так конечно же можно интерпретировать AST C++, никто не запрещает. Сам по себе язык не есть "компилируемый" или "интерпретируемый".

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>А в питоне ньюлайн значащий, ты этого даже не сказал :-)

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

>Алфавит-то уменьшается?

Алфавит не уменьшается - ты выкидываешь из конкретной программы один из символов. паскаль1 Є Паскаль && паскаль2 Є Паскаль == истина.

Различай алфавит и программу для начала.

r ★★★★★
() автор топика
Ответ на: комментарий от AVL2

>Но мы говорим именно о языках, является ли _язык_ компилируемым

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

r ★★★★★
() автор топика
Ответ на: комментарий от r

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

Даже не код, а алфавит :-)))

anonymous
()
Ответ на: комментарий от r

>>Алфавит-то уменьшается?

>Алфавит не уменьшается - ты выкидываешь из конкретной программы один из символов. паскаль1 Є Паскаль && паскаль2 Є Паскаль == истина.

>Различай алфавит и программу для начала.

Ты не определил что такое Паскаль. А семантика программы при компиляции должна сохранятся.

Взаимно-однозначного отображения исходника и объектного кода при моей компиляции нет. Алфавиты различны. Семантика остается. Что еще надо?

З.Ы. все-таки хочу написать компилятор

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от r

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

а я бы еще спросил, есть ли по-настоящему не виртуальные функции

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

>Мы говорим о конкретных реализациях языков.

Ну так а почему мы вообще обсуждаем - компилируемый он или нет? Потому что и тот и другой варианты имеют свои родимые пятна.

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

> Jit нельзя назвать компиляцией.

Срочно записываемся на получение премии им. Тюринга, вотъ. За дуби^W идейную стойкость.

sv75 ★★★★★
()
Ответ на: комментарий от r

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

принимается.

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

> Итак, LMD2 утверждает, что .NET-языки некомпилируемые. Или пусть берёт свои слова обратно, или пусть конкретно это и доказывает.

Зря надеешься, больной явно безнадежен. Достаточно взгянуть на "Остальное, двойная компиляция - в байткод и далее, в машкод, трансляции, кеширование откомпиленого и т.д. - несущественные опции одного большого процесса - процесса интерпретации." Это же полная, просто полная клиника. У человека компиляция в нативный код - часть интерпретации.

sv75 ★★★★★
()
Ответ на: комментарий от AVL2

О, новая порция определений от воинствующего дилетанта пошла!

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

Чушь. Совершенно не обязательно. Если это инкрементально компилируемый язык (Common Lisp, например) то он потащит за собой и компилятор.

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

Тоже чушь нерелевантная теме. Он не обязан быть платформонезависимым. Кто мешает иметь инструкцию в интерпретируемом бейсике "посмотреть регистр EBX"?

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

Опять что-то "очевидное" твоим гопам на лавочке? Ты не с ними разговариваешь, проснись.

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

anonymous
()
Ответ на: комментарий от AVL2

> зато расходы в рантайме велики.

я тоже так подозреваю, но интересно было бы знать ГДЕ тормозит VM (JIT не в счет, считаем что все скэшировано)

особенно если локальные переменные не в куче, и есть не виртуальные функции, ГДЕ может тормозить?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от AVL2

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

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

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

ДА ВАШУ МАТЬ!!!!! У ДОТНЭТА НЕТ! ПОНИМАЕШЬ? НЕТ И НИКОГДА НЕ БЫЛО ВИРТУАЛЬНОЙ МАШИНЫ!!!!!

Не, я так точно нервный тик заработаю.

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

Нет, дорогой ты мой друг, это все опции одного большого процесса - процесса КОМ-ПИ-ЛЯ-ЦИ-И! Скомпилированная в коды ассемблера прога запускается без малейшего соучастия чего бы там ни было.

Непробиваемый чел, в армии таких ценят!

YogSagot ★★★
()
Ответ на: комментарий от sv75

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

Кстати, C тоже не то чтоб очень ассемблер. И есть на почти всех платформах.

anonymous
()
Ответ на: комментарий от AVL2

> Но логически, он ничем от исходного кода не отличается.

Больной, декомпилируйте ка немножко байткода от компилятора F#. Сравните с исходным кодом. Повторите подвиг Томми. Только порядок не перепутайте, ок?

P.S. Больной, вы в курсе, как работает GCC?

anonymous
()
Ответ на: комментарий от www_linux_org_ru

Опасаюсь, сейчас мы узнаем про то, что все языки с RTTI тоже жуть какие интерпретируемые. :)))

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>А семантика программы при компиляции должна сохранятся.

Это тебе Ахо и Ульман лично сказали?

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

Ее наличие не говорит об отсуствии компиляции. Это тоже до лампочки.

>З.Ы. все-таки хочу написать компилятор

AVL2 тебя опередил.

r ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Опасаюсь, сейчас мы узнаем про то, что все языки с RTTI тоже жуть какие интерпретируемые. :)))

Ага, а С это язык, интерпретируемый gcc =) Пацтава!

YogSagot ★★★
()
Ответ на: комментарий от AVL2

>Интерпретируемый - не требует предварительной трансляции, но зато требует жирный рантайм.

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

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

Неверно. Ты опять пытаешься связать компиляцию с процесами которые тут долампы.

r ★★★★★
() автор топика
Ответ на: комментарий от r

Давайте добьём поц иента:

- Форт в шитом коде - компилируемый или интерпретируемый язык?

- Форт в режиме интерпретации - интерпретируемый? Если да, то где рантайм?

anonymous
()
Ответ на: комментарий от AVL2

>байт-код - нечто среднее.

БАйткод - это другой алфавит. Он от ассемблера по сути не отличается ничем -он ассемблер и есть. Когда ты компиляешь GCC сяшную программу ты обычно генерируешь используя ассемблер твоей архитектуры. Это вовсе не обязательно. У меня вон народ ядрыжки под железки портировал и на x86 архитектуре компилил в MIPS1, MIPS2 - это другие ассемблеры - и исполнгял в самописном тогда эмуляторе на x86 архитектуре linux который был скомпилен в mips. байткод/il - это такой же ассемблер просто для виртуальной архитектуры. _Нет_ никакой разницы с точки зрения компиляции.

r ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

А в Компилируемом языке все связи зашиваются на этапе сборки. Причем нет нужды в универсальной vm. Связал с такой, с какой считаешь нужным. И в прокладках нет нужды (собственно, и возможности). Вот и получается...

AVL2 ★★★★★
()
Ответ на: комментарий от r

>AVL2 тебя опередил.

Вот и хорошо.

______________________________________

что-то смутно припоминаю что основные проблемы в быстродействии прог на питоне, полученных питон ---> C++ ---> elf были из-за того, что все функции приходилось делать виртуальными

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>ГДЕ может тормозить?

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

r ★★★★★
() автор топика
Ответ на: комментарий от AVL2

> VM тормозит, потому что всегда реализует некий усредненый алгоритм использования своих функций

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

> связывание в рантайме

Ничем не лучше и не хуже того, что ld.so делает.

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

Она может вообще отсутствовать, при использовании JIT.

Запомни: в GCC есть виртуальная машина. Знаю, это тебя очень огорчит, но уж прими это как данность.

> А в Компилируемом языке все связи зашиваются на этапе сборки

Ха ха. Позднего связывания не существует. C++ скомпилённый с -fPIC в .so-библиотеку на самом деле интерпретируется. Ты открыл нам глаза, о упорнейший из ламеров!

anonymous
()
Ответ на: комментарий от AVL2

Еще раз повторить, что у дотнэта нет и никогда не было виртуальной машины?

GTK и Qt это прокладка между прогой и API графической системы (иксов, венды и т.п.) GTK и Qt с сегодняшнего дня следует считать виртуальной машиной графического интерфейса?

YogSagot ★★★
()
Ответ на: комментарий от www_linux_org_ru

Виртуальные функции - фигня по сравнению с утиной типизацией (RTTI на всём что движется).

anonymous
()
Ответ на: комментарий от r

>БАйткод - это другой алфавит. байткод/il - это такой же ассемблер просто для виртуальной архитектуры.

>_Нет_ никакой разницы с точки зрения компиляции.

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

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

исходный код: {e,"весь алфавит языка",\n\r}

байт-код: {e,"весь алфавит языка",\n}

e - пустой символ.

компилятор прилагаю

perl -pi -e "/\n\r/\n/" *

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Чувак, а что ты так выборочно отвечаешь? Стыд гложет?

anonymous
()
Ответ на: комментарий от anonymous

>И, да, perl и python компилируемые языки. Интерпретируемые же языки - это их байткоды. Дошло?

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

YogSagot ★★★
()
Ответ на: комментарий от AVL2

>исходный код: {e,"весь алфавит языка",\n\r}

Алфавит формального языка - это то не символы юникода! Сколько можно!

r ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Ха ха. Позднего связывания не существует. C++ скомпилённый с -fPIC в .so-библиотеку на самом деле интерпретируется.

хаха, стартует оно дольше. как при интерпретации.

например на агенде вообще отказались от -fpic и сошки заморозили в памяти.

AVL2 ★★★★★
()
Ответ на: комментарий от r

Кстати да, не надо путать алфавит и грамматику.

anonymous
()
Ответ на: комментарий от AVL2

И что, что стартует дольше? Или у вас, гопников с семками на лавочке, критерий такой, что "тормозит - интерпретатор, летает - компилятор"?

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

anonymous
()

:holy war mode = on

Cobra нинужен. Для мелких проектов есть Пайтон, для больших - D.

:holy war mode = off

---
С Уважением,

BuG2BuG
()
Ответ на: комментарий от BuG2BuG

>:holy war mode = on

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

r ★★★★★
() автор топика
Ответ на: комментарий от r

>Алфавит формального языка - это то не символы юникода! Сколько можно!

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

я поменял один симовл алфавита языка программирования, который кодируется последовательностью \n\r. В новом алфавите этой последовательности нет, но есть символ с последовательностью \n

AVL2 ★★★★★
()
Ответ на: комментарий от YogSagot

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

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

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.