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

> Она формально компилятор... ну а практически?

А что тебе практически от компилятора надо? Компилятор преобразует один язык в другой. ТОЧКА. Все другие мнения идут лесом, как ламерские.

> Я стою здесь на практической точке зрения.

Да какой из тебя практик? Ты же даже не сформулировал никаких практических критериев.

> http://www.linux.org.ru/jump-message.jsp?msgid=2560187&cid=2564107 Исходное сообщение, исходная проблема. Перечитайте весь тред.

Я-то, грешным делом, вёл дискуссию вот с этого места, где впервые всплыло слово "интерфейс": http://www.linux.org.ru/jump-message.jsp?msgid=2560187&cid=2564174

>> А как быть с расширенным функционалом (пусть окромя функции pook() добавлена функция defecate())?

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

> Я стою здесь на практической точке зрения.

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

> Так, наш ламер и про Лисп ни хрена не знает. Apply не делает его интерпретатором, более того, аналог apply есть и в любом компилируемом языке. Вот eval - можно с натяжкой счесть за встроенный интерпретатор. Хотя, в том же SBCL даже eval сначала в нейтив компилирует.

1) Я сказал apply и подобные -- туда входит конечно же eval, defun, и еще что на вскидку не вспомню.

2) Я _не_ сказал что чтобы лисп стал полностью компилируемым, обязательно надо исключить apply. Я сказал что если исключить apply и подобные, лисп станет полностью компилируемым языком.

Анонимус, ты даже не можешь понять такие высказывания, которые тупой третьекурсник понимает.

Зарегистрируешься -- буду общаться. А так - нафиг.

>Почитай дискуссию сначала, какой был флейм что есть компилятор, и как наконец АВЛ2 придумал достаточно тупую прогу которую р вынужден был принять как компилятор.

Да читал я.

>Она формально компилятор... ну а практически?

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

> 1) Я сказал apply и подобные -- туда входит конечно же eval, defun, и еще что на вскидку не вспомню.

И чем же, по-твоему, defun мешает компилировать? В лиспе есть только одна функция: eval, которую можно считать интерпретатором, хотя это не совсем так, ну да ладно.

> Зарегистрируешься -- буду общаться. А так - нафиг.

Хотя зарегистрироваться и неплохо, но вообще-то аргументы не зависят от того, кто их высказывает.

>> C + dlopen уже (почти) болеет всеми болезнями интерпретатора

> Си + dlopen ничем не болеет

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

>> поэтому я считаю что его можно считать интерпретатором.

> Ты опубликуешь используемое тобой определение интерпретатора или нет?

1) Я не уверен что смогу его формализовать достаточно для публикации.

2) Может кто здесь не тупой (я без иронии -- например ты) укажет почему такой подход ведет в тупик.

3) Что касается классического определения -- оно вообще мало пригодно для практики, и позволяет МС дурачить нас с .нет

Но в принципе я был бы за какие-то численные критерии к/и, хотя бы по форме "доказуемая верхняя граница -- доказуемая нижняя граница".

>Мое предложение насколько я могу судить такие отмазки прекращало.

Ваше предложение лишь вызывает волну истерики.

>и позволяет МС дурачить нас с .нет

Да кто тебя дурачит-то? :) Исходники дотнета открыты "на посмотреть" :)

> Кроме того, у .NET тормозов нет.

Да простит меня, гик, но я сплагиатничаю: Бугага!

А я грешным делом все время говорю об ООП интрефейсах. Хотя, если оперировать библиотеками на C, то проблемы не будет вообще при добавлении новой функции?

> 1) Я сказал apply и подобные -- туда входит конечно же eval, defun, и еще что на вскидку не вспомню.

apply просто применяет функцию к аргументам. Всё. Это то же самое, что

(*fptr)(блаблабла) в Си.

defun это форма, а не функция, это то же самое, что определение функции в Си. Компилируется.

eval - может быть и интерпретатором. Но не обязательно.

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

А из Си тогда надо исключить dlopen, popen, system (а то мало ли, дёрнет кто из рантайма компилятор Си и подгрузит новый код).

> Анонимус, ты даже не можешь понять такие высказывания, которые тупой третьекурсник понимает.

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

> Это твои личные половые трудности и проблемы реализации .NET на этом самом КПК.

Я подозреваю, что там был винмобайл с родной микрософтской реализацией :)

> У меня вот mono на ARM не тормозит, скорость сопоставимая с нативными бинарниками.

Самовнушение ведёт к аутизму, не забывайте :)

> Хотя зарегистрироваться и неплохо, но вообще-то аргументы не зависят от того, кто их высказывает.

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

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

> Бугага!

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

> Но толку слушать человека который меня даже понять не смог?

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

> Самовнушение ведёт к аутизму, не забывайте :)

Это бенчмарк. С конкретными числами.

Кажущиеся тормоза .NET - это тормоза библиотек и кривой код (ну, всем ясно, что за люди обычно на c# пишут).

> Иначе лишишься шанса чему либо умному научиться.

У понтового анонимуса мне нечему учиться.

Разумный человек себя ведет примерно как tailgunner (эт... я не всех тут разумных выяснил, так что не обижайтесь, постепенно найду у кого учиться надо)

>Но толку слушать человека который меня даже понять не смог?

Может дело не в нем?

>С анонимусами флеймить толку нет.

Флеймить вообще толку нет. Нужен конструктивный спор компетентных лиц.

>я могу хотя бы выяснить, надо мне его в будущем слушать и пытаться до него достучаться

Анонимусов тоже игнорить можно ;)

> А я грешным делом все время говорю об ООП интрефейсах.

Да там всё те же вопросы останутся. Функции pook и defecate могу добавляться в класс.

> Хотя, если оперировать библиотеками на C, то проблемы не будет вообще при добавлении новой функции?

Разве что та "проблема", что её, следуя Вашей логике надо занумеровать.

> 3) Что касается классического определения -- оно вообще мало пригодно для практики, и позволяет МС дурачить нас с .нет

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

Ясно, студентик-ламер, ты слил. Презираю.

> eval - может быть и интерпретатором. Но не обязательно.

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

> А из Си тогда надо исключить dlopen, popen, system (а то мало ли, дёрнет кто из рантайма компилятор Си и подгрузит новый код).

Уже скомпилированный код при этом не поменяется.

>> Кроме того, у .NET тормозов нет.

>Да простит меня, гик, но я сплагиатничаю: Бугага!

Тормоза понятие относительное, они зависят от реакции человека. Ну и конечно же смотря с чем dotNet сравнивать, с php или c C.

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csha...

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

Что, компиляцию в рантайме с последующим выполнением тоже интерпретацией теперь звать будем? Приплыли.

>> Самовнушение ведёт к аутизму, не забывайте :)

> Это бенчмарк. С конкретными числами.

Проведённый фирмой м-софт? ;)

> Кажущиеся тормоза .NET - это тормоза библиотек и кривой код (ну, всем ясно, что за люди обычно на c# пишут).

Да-да, задержка на jit-компиляцию тоже из-за индусов появилась :)

>Разве что та "проблема", что её, следуя Вашей логике надо занумеровать.

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

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

> Что, компиляцию в рантайме с последующим выполнением тоже интерпретацией теперь звать будем? Приплыли.

Не надо передёргивать. Я отвечал на узкий вопрос "как обкарнать лисп, чтобы его можно было скомпилировать".

> Проведённый фирмой м-софт? ;)

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

> Да-да, задержка на jit-компиляцию тоже из-за индусов появилась :)

Тормоз? Болеешь и не лечишься? Нет в .NET "полноценного" JIT, это не JVM с его HotSpot. В .NET (и конкретно в Mono) все классы пре-компилируются до использования, при загрузке assembly.

> Чувачок, ты бы базар пофильтровал, а? Ты - наглый ламер. Я - специалист. Будь вежливым и почтительным, когда с тобой разговаривают мудрые старшие товарищи. Иначе лишишься шанса чему либо умному научиться.

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

____________________________________________

Дополнение: полезные для прочтения ссылки могут давать не только разумные люди.

Что, студентик, обидно осознавать себя ламером и беситься от бесслия доказать свою нелепую позицию, встретившись с настоящими специалистами? Ну бесись, студентик, это полезно. Все равно программистом ты не станешь.

LMD. Типа при наличии eval скомпилировать уже нельзя? Приплыли.

LOR населен студентиками-недоучками. :(

>> Разве что та "проблема", что её, следуя Вашей логике надо занумеровать.

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

Да. Попробую разжевать, что же я имел в виду:

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

Потом добавляем ещё одну функцию, и нумерацию приходится повторить.

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

Забей, их тут полно. Они все повально архитекторы да манагеры. Причём настолько заняты, что им не хватает времени залогиниться :)

> Флеймить вообще толку нет. Нужен конструктивный спор компетентных лиц.

Мне кажется лоровский формат подходит в основном для флейма. Для конструктивного спора нужна типа блог+вики с обсуждением строго по теме + не то чтобы модератор, но типа того. Смотри, тема-то называется "Вышел язык програмирования Cobra 0.7.4"

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

>Потом добавляем ещё одну функцию, и нумерацию приходится повторить.

А если мы этого не сделаем, тогда пресловутому менеджеру пакетов (который обсуждался в глубине сего топика) как узнать, что для такой-то программы A, использующей эту библиотеку libjopa.2 (если кто помнит) нужна версия именно с новой функцией?

Но сменив нумерацию программа B (которая использовала libjopa.1) будет требовать старую библиотеку, ЕМНИП что мы и наблюдаем на прмиере мохнатых программ и libc.5 libc.6

>>> C + dlopen уже (почти) болеет всеми болезнями интерпретатора

>> Си + dlopen ничем не болеет

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

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

>> Ты опубликуешь используемое тобой определение интерпретатора или нет?

> 1) Я не уверен что смогу его формализовать достаточно для публикации.

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

> Но сменив нумерацию программа B (которая использовала libjopa.1) будет требовать старую библиотеку, ЕМНИП что мы и наблюдаем на прмиере мохнатых программ и libc.5 libc.6

Да, так и есть в данный момент. А вместо этого Вы предлагаете напложить ещё большее количество библиотек.

Так чем Ваш способ лучше?

а не знает ли уважаемый сэр хороших книг про лисп?

OnLisp, Practical Common Lisp. Не совсем про Лисп, но полезно - SICP.

>>> Ты опубликуешь используемое тобой определение интерпретатора или нет?

>> 1) Я не уверен что смогу его формализовать достаточно для публикации.

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

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

Меня вот что интересует:

1. Считаешь ли ты что классическое понимание к/и достаточно для практических приложений?

2. Считаешь ли ты что классическое понимание к/и может / не может быть улучшено примерно так как я обрисовал?

А вообще вне флейма меня это мало интересует... наверно мало толку от этой метрики.

Меня практические вещи интересуют. Вот например создатель скалы ввел тип nothing -- да это ценно, еще ко-контравариантность в зависимости от того, константна ли коллекция -- тоже ценно... но ему как слишком академичному не хватило ума ввести named parameters :-)

> пусть разбирается, мое мнение тут достаточно консистенто

Твое мнение - "что мне нравится - то компилятор, что не нравится - то интерпретатор". Уровень примерно детского сада.

> 1. Считаешь ли ты что классическое понимание к/и достаточно для практических приложений?

Зачем для практических приложений "понимание" терминологии? Для практики важно понимать, что нужно от языка и от приложений на нем написанных. И важно уметь реализовывать все формы компиляции и интерпретации для достижения сбалансированного, полезного на практике решения.

> 2. Считаешь ли ты что классическое понимание к/и может / не может быть улучшено примерно так как я обрисовал?

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

> Считаешь ли ты что классическое понимание к/и достаточно для практических приложений?

Да.

> Считаешь ли ты что классическое понимание к/и может / не может быть улучшено примерно так как я обрисовал?

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

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

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

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

Некоторые думают что математика -- наука строгая. Но я советую принять во внимание, что:

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

* существует конструктивизм, и в нем тоже все не совсем так как вы привыкли

* континуум-гипотеза независима от общепринятой системы аксиом

... короче все это сделано в основном под "нравится - не нравится", нравится так доказывать или не нравится так доказывать.

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

Здравствуй честное ЛОРовское программистское честное сообщество! Мне интестно, здесь остался хотя-бы один человек с нормальным образованием в области IT? Или грабли начала 90-х - "Писюки - наше фсё" отшибли мозги всем и навсегда? О чем ВЫ спорите? Компиляторы, интерпретаторы? Неуж-то до сих пор в институтах профессура не в состоянии на ПАЛЬТСАХ объяснить студентам простую разницу между процессом компиляции и интетрепации? Видимо эта почетная обязанность выпала мне, хоть я и не проФФЭссор. Итак шо мЫ подразумеваем под понятием "компиляция" - это просто "перевод" с одного языка на другой без потери смысла. "Интерпретация" - это выполнение программы над конкретными данными. Поэтому все абсолютно просто: компиляция - манипулирование кодом программы, интерпретация - манипулирование данными по заданной программе.

//Редкая Птица

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

А что если данные программы применяются для того, сделать ли условный переход? А что если 100% условных переходов осуществляется на основе данных?

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

А еще мне интересно, как может быть так все просто, если даже проблема тождества двух программ алгоритмически неразрешима?

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

Нисколько не пытаясь лезть в строгую науку Computer science, предложу вопрос, который можно задать понтовому анонимусу. Вот у меня имеется исполнимый код на каком-нить упрощенном, но алгоритмически полном языке.

Где описан алгоритм, позволяющий выяснить -- интерпретатор этот код, или нет? Что нам говорит на эту тему строгая наука?

+1

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

Не надо даже, если eval будет принимать, неизвестные на момент компиляции программы данные (ввод с клавиатуры/из файла). Он их потом может откомпилировать во время работы программы. Т.е., если сделать что-то вроде вызова gcc из скомпилированной Си-шной программы она от этого не перестанет быть скомпилированной, даже если потребуется перекомпиляция вызвавшей программы и передача управления в её новый вариант.