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

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

А как насчёт, например функции, которая для любого действительно числа на заданном отрезке принимает значение 1, если число представимо в виде конечной дроби и 0, если оно иррациональное?

> нравится так доказывать или не нравится так доказывать.

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

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

Можно придраться к словам "новый вариант" :)

В принципе, самомодифицирующиеся програмы на ассемблере тоже сложно куда-либо четко отнести.

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

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

> А как насчёт, например функции, которая для любого действительно числа на заданном отрезке принимает значение 1, если число представимо в виде конечной дроби и 0, если оно иррациональное?

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

Кстати, конструктивизм не приемлет некоорые теоремы из матанализа, считая их недоказанными. Увы, за давностию лет не помню какие.

> динамический линковщик тоже можно посчитать интерпретатором

При желании его можно посчитать белой акулой. Или посчитать 3 раза. Или даже 4 - было бы желание :D

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

>А как насчёт, например функции, которая для любого действительно числа на заданном отрезке принимает значение 1, если число представимо в виде конечной дроби и 0, если оно иррациональное?

Значит так. Я пишу программу, выдающую бесконечную последовательность десятичных цифр (0.ХХХХХХ...), даю тебе ее конечный текст и аргумент, а ты говоришь мне, чему равно значение твой функции на этом числе. Только вот как ты это сделаешь, если неизвестно, будет ли вывод моей программы периодическим? А вопрос -- будет ли он периодичским при любом аргументе -- скорее всего алгоритмически неразрешим (влом щас д-во делать).

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

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

Угу... Л. Э. Я. Брауэр и А. Гейтинг страдали алогичным мышлением, а А. Н. Колмогоров и К. Гёдель зачем-то исследовали их алогичный бред...

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D1%83%D0%B8%D1%86%D0%B8%D0%BE...

>> динамический линковщик тоже можно посчитать интерпретатором

> При желании его можно посчитать белой акулой. Или посчитать 3 раза. Или даже 4 - было бы желание :D

Где строгое определение интерпретируемого языка?

> динамический линковщик тоже можно посчитать интерпретатором

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

а флейм можно развести на более простую тему...

gaa, у тебя был хороший флейм на тему версий библиотек... он исчерпал себя? или все согласились?

> Где строгое определение интерпретируемого языка?

Оно не нужно: интерпретируемых _языков_ не бывает :) - для любого можно написать как компилятор в натив, так и интерпретатор AST. А определение интерпретатора (без претензий на строгость, но достаточное для практики, ИМХО) я давал уже 2 раза.

> А определение интерпретатора (без претензий на строгость, но достаточное для практики, ИМХО) я давал уже 2 раза.

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

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

>> А определение интерпретатора (без претензий на строгость, но достаточное для практики, ИМХО) я давал уже 2 раза.

> А пока строгого определения нет, бесполезно иронизировать над тем, кто что считатет интерпретатором

Я дал свое определение, ты дай свое - может, придем к общему :)

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

Ты не указал ни на какие дыры o_O

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

www_linux_org_ru, ты программист? Если ты программист, то должен понимать, что ВСЕ варианты УСЛОВНЫХ переходов необходимо предусмотреть в программе иначе либо SEGFOLD, либо EXEPTION, и "ващще какой ты нафиг танкист", ты хоть строчку хотя-бы на ВАСИКЕ написал? Или так мимо проходил?

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

> Ты не указал ни на какие дыры

нет строгого определения -- это дыра

______________________________

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

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

>www_linux_org_ru, ты программист? Если ты программист, то должен понимать, что ВСЕ варианты УСЛОВНЫХ переходов необходимо предусмотреть в программе иначе либо SEGFOLD, либо EXEPTION, и "ващще какой ты нафиг танкист", ты хоть строчку хотя-бы на ВАСИКЕ написал? Или так мимо проходил?

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

ПИЛЯТЬ! Пока я тут выпил бокал коньяку между вопросами, пролетела целая ГЛЫБА(пустопородная) флейма, народ опять опьять как усегда занялся выпячиванием собсного ЙЯ, как всегда пиписки свои на аршин приложили, а воз так и по ныне ТАМ (откровенно говоря, в жопе, как и вся отрасль IT)

//Редкая Птица (капча знаковая: shitted)

> откровенно говоря, в жопе, как и вся отрасль IT

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

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

Вообще-то это не моя функция, её придумал Дирихле.

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

Вывод любой программы будет периодическим :)

> Т.е. нельзя считать что твоя функция определена в любой точке.

Тогда считай, что функция sin(x) не определена в точке x=Pi, не находишь это абсурдным?

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

> Угу... Л. Э. Я. Брауэр и А. Гейтинг страдали алогичным мышлением, а А. Н. Колмогоров и К. Гёдель зачем-то исследовали их алогичный бред...

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

> >www_linux_org_ru, ты программист? Если ты программист, то должен понимать, что ВСЕ варианты УСЛОВНЫХ переходов необходимо предусмотреть в программе иначе либо SEGFOLD, либо EXEPTION, и "ващще какой ты нафиг танкист", ты хоть строчку хотя-бы на ВАСИКЕ написал? Или так мимо проходил? Я так ненавязчиво пытался подсказать, что ты не сможешь в общем случае отличить данные от кода.

О МАМАМИА Я с бараном общаюсь? ИШШШШО раз спрашиваю, апеллируя к опыту и здравому смыслу, ЙА СМАГУ отличить КОД от ДАННЫХ, а ТЫ? ПИЛЯТЬ ТЫ хоть понимаш, шо программа МОЖЕТ получать РАЗНЫЕ ДАННЫЕ и не факт, что она, программа, получит то, что в ней предусмотрено и куда ей в етом случае идти,не известно, хотя я знаю наверняка куда ей топать, вместе с афффтаром. И Ышшо данные и код всегда разделены, как бы кто не изгалялся ф своих теоритиских измышлениях.

//Редкая Псиса

> Вывод любой программы будет периодическим :)

Эт... а если она вычисляет последовательные десятичные цифры числа 1.-1./3+1./5-1./7+... ? тоже периодическим?

>> Т.е. нельзя считать что твоя функция определена в любой точке.

>Тогда считай, что функция sin(x) не определена в точке x=Pi, не находишь это абсурдным?

Вот ты тут как раз алогичен. Приведи полную цепочку вывода.

Pi вполне конструктивно. sin(x) тоже. Доказать что sin(Pi)=0 не проблема.

>Любое конкретное действительное число или можно записать в виде дроби или нельзя,

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

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

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

>> динамический линковщик тоже можно посчитать интерпретатором

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

Конструктив тут закончился сообщений 100 назад, теперь я просто наблюдаю за развитием событий. Ну и подкармливаю своими соображениями :)

> gaa, у тебя был хороший флейм на тему версий библиотек... он исчерпал себя? или все согласились?

Да, похоже, что мой оппонент согласен

> SEGFOLD

зач0т!

> Эт... а если она вычисляет последовательные десятичные цифры числа 1.-1./3+1./5-1./7+... ? тоже периодическим?

Конечно, до тех пор пока у тебя конечный объём памяти у компьютера.

> Вот ты тут как раз алогичен. Приведи полную цепочку вывода.

Ты сказал, что функция Дирихле не определена во всех точках, лишь потому что (по твоему) для программы нельзя сказать даёт она периодический вывод или нет. Я всего лишь повторил по аналогии твои рассуждения для sin(x).

> Pi вполне конструктивно. sin(x) тоже. Доказать что sin(Pi)=0 не проблема.

Так доказать, что функция Дирихле D(sqrt(2))=1, а D(3/2)=0 тоже можно. Кстати, вычислить, что sin(pi)=0, строго нулю, уже некоторая проблема, я имею ввиду, что если не позаботиться об этом, то результат вычислений вполне может быть отличным от нуля в пределах погрешности вычислений.

> Число есть, а вычислить его не можем принципиально -- проблема алгоритмически неразрешима.

Какое число ты принципиально вычислить не можешь, я не понял? Или с таким подходом можно сказать, что нельзя вычислить ни sqrt(2), ни srqt(2), ни Pi, ни e, все они на компьютере могут быть вычисленны лишь с какой-то погрешностью, причём результат вычисления всегда будет рациональным.

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

> Щас осталось опредить функцию, невычислимую в каждой точке, и размахивать ей...

С таким подходом дельту-функцию Дирака тоже надо выкинуть? А фракталы?

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

Мы с вами это уже обсуждали:

http://www.linux.org.ru/jump-message.jsp?msgid=2560187&cid=2564131

>> gaa, у тебя был хороший флейм на тему версий библиотек... он исчерпал себя? или все согласились?

>Да, похоже, что мой оппонент согласен

Оппонентам иногда необходим сон.

> А как насчёт, например функции, которая для любого действительно числа на заданном отрезке принимает значение 1, если число представимо в виде конечной дроби и 0, если оно иррациональное?

ЕМНИП, в исчислении Коши-Вейерштрасса таковая штука функцией не является. Это псевдофункции, типа дельта-функции.

> Кстати, конструктивизм не приемлет некоорые теоремы из матанализа, считая их недоказанными. Увы, за давностию лет не помню какие.

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

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

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

>И он всегда даёт оптимальное решение? Слава Роботам уже наступила и людишки не нужны?

Да, потому что не сможешь эффективно оптимизировать код под Intel Core 2 Duo. Будешь месяц ковыряться, а это бабло на твою зарплату. В то же время 99% оптимизаций, будучи включенными в компилятор Sun HotSpot JIT, эффективно оптимизируют большинство критических к производительности мест в большинстве написанных неумелыми программистами программ. А согласись, неумелых программистов намнооооого больше, чем тех, которые пишут JIT в JVM

>Допустим, у тебя функция, у которой есть 3 реализации. Ты смотришь в профилировщик, видишь что её надо оптимизировать. Но параметры функции скачут в runtime, и ты не знаешь, под какой вариант её оптимизировать. JIT же сможет эту информацию собрать, статистически обработать и предложить автоматически нужный сценарий, по эвристикам. Чего в принципе не получится на "Компилируемом языке. где все связи зашиваются на этапе сборки"

Тогда в бинарник будут зашиты все 3 варианта ее исполнения под все параметры. А если вариантов параметров 300, то будут зашиты все 300 вариантов под i386, и под Athlon i686. Займет это.. ну вы поняли, бинарь разрастется до мегабайтов

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

>Да ты чо? А просто думать компьютеры уже умеют, да?

А ты каждый раз думаешь, когда интеграл берешь, да? Или по таблицам Брадиса быстрее находишь? Знаешь, пока такие как ты, думали, выпускники MIT создавали табличные отображения парамеров функций в результаты и вкладывали эти таблицы в ЭВМ. И теперь ИХ ракеты могут сбивать НАШИ ракеты и НАШИ спутники, а такие как ты, продолжают что то там натужно думать, и пытаться за процессор решить, как лучше выровнять слова в памяти, хотя процессор такую операцию по выравниванию сделает в миллион раз быстрее, чем ты.

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

>>Да ты чо? А просто думать компьютеры уже умеют, да?

>А ты каждый раз думаешь, когда интеграл берешь, да?

Причем здесь то, как я беру интегралы? Вопрос был - умеет ли компьютер думать. Ответить "нет" тебе самолюбие не позволяет?

> Знаешь, пока такие как ты, думали, выпускники MIT создавали табличные отображения парамеров функций в результаты и вкладывали эти таблицы в ЭВМ. И теперь ИХ ракеты могут сбивать НАШИ ракеты и НАШИ спутники

Гггг. Да ты не только в CS специалист, но еще и в ПРО. Просто универсальный гений.

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

/me в панике вскакивает и оглядывается по сторонам

> А ты каждый раз думаешь, когда интеграл берешь, да? Или по таблицам Брадиса быстрее находишь? Знаешь, пока такие как ты, думали, выпускники MIT создавали табличные отображения парамеров функций в результаты и вкладывали эти таблицы в ЭВМ. И теперь ИХ ракеты могут сбивать НАШИ ракеты и НАШИ спутники, а такие как ты, продолжают что то там натужно думать, и пытаться за процессор решить, как лучше выровнять слова в памяти, хотя процессор такую операцию по выравниванию сделает в миллион раз быстрее, чем ты.

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

Им я предлагаю подумать: ну вот допустим россия победила в войне и захватиал сша (!). А дальше что? А дальше все равно россия останется в ЖОПЕ. Почему? Пример уже был. В 1945 году россия победила и захватила германию. Наземный берлин был просто кучей битого кирпича от бомбежек. И где щас эти великие победители? Ездят на жигулях, и стоят эти жигули меньше, чем изношенные мерсы побежденного народа германии.

Доходит? И чего празднуют аж 60 лет уже?

> Кстати, вычислить, что sin(pi)=0, строго нулю, уже некоторая проблема, я имею ввиду, что если не позаботиться об этом, то результат вычислений вполне может быть отличным от нуля в пределах погрешности вычислений.

1) мы можем вычислить сколь угодно много цифр числа пи, и дальше эти цифры менятся не будут (man остаточный член в формуле тейлора)

2) мы можем вычислить сколь угодно много цифр числа sin(x), вычислив сколь угодно много цифр числа x, и опять же дальше эти цифры менятся не будут (man остаточный член в формуле тейлора)

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

3) я сказал доказать sin(pi)=0 а не вычислить -- вычисление не поможет

> С таким подходом дельту-функцию Дирака тоже надо выкинуть? А фракталы?

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

В фракталах не специалист.

> В то же время 99% оптимизаций, будучи включенными в компилятор Sun HotSpot JIT, эффективно оптимизируют большинство критических к производительности мест в большинстве написанных неумелыми программистами программ.

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

> И чего празднуют аж 60 лет уже?

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

>> И чего празднуют аж 60 лет уже?

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

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

З.Ы. если я здесь флейм устраиваю, то это не означает что я ребенок :-)

dm>> пакетный менеждер у автора ААА автоматом качает "вышла 1.1" через этот RSS, автор портирует изменения, и сам публикует в RSS анонс-манифест "вышла AAA v 0.1" .
dm>> Для AAA v 0.1 подглючится libjopa v1.1, для BBB в sandbox подключится v1.0. Если BBB обновится на libjopa 1.1, то пакетный менеждер это узнает и сможет прибить libjopa v 1.0 как неиспользующуюся.

gaa>То есть авторы сторонних поделок постоянно должны следить за изменениями в сопутствующих либах. И без этого ну никак не должна апгрейдиться используемая версия библиотеки?

да. Окружение, в котором собирается программа, должно быть воспроизводимым. К чему приводит несоблюдение этого принципа наглядно видно при попытках откомпилировать в новом ядре Линукса старый софт с с куском в виде драйвера, под старую версию gcc/libc/ядра. Он просто не соберётся новым gcc или с новым ведром, в котором старый API выкинули.

по этой же причине в Генте пакеты masked, и не должны затираться с обновлениями.

Как-то все пропустили мой пост про то, что у API, интерфейса есть 2 части: публичная и "особенности реализации", которая может проверяться, например, юнит-тестами, регрес. тестами. Публичная задаёт спецификации, как оно должно быть, а юнит-тестами проверяется конкретное поведение конкретной версии, как есть, та часть API, в той мере, в какой этот API используется конкретным приложением.

Можно бы такие "метаинтерфейсы" и обобщить, и засунуть под версионный контроль и под пакетный менеджер.

gaa>А если автор забъёт на свой продукт? Или под машину попадёт? Или по какой-то другой причине не станет проверять, совместима ли его поделка с новой версией libjopa?

тогда его программа может работать, а может не работать, и автор -- ССЗБ. Нагугли какую-нибудь игрушку под Линукс времён 1999 и попытайся собрать сейчас.

Если автор вдруг неожиданно сдохнет, у нас останутся манифесты-описания build sandbox, достаточные для того, чтобы оно собралось.

Кстати, на твоём примере с tkLOR: если ты написал рецепты сборки на словах, то чайник сможет и не воспроизвести твою мега-программу. А ebuild в этом смысле уже полезней и формальней, и -9999 даже переживёт не один релиз твоей нетлёнки :)

gaa>Ну всё, готовьтесь к увеличению размера установленной системы в 100 раз как минимум. И так сейчас возникают ситуации, когда приходится иметь по паре версий либ(например, у меня стоят одновременно питоны версий 2.4 и 2.5), так, следуя Вашим словам, ещё будут стоять 2.4.1, 2.4.2 и т.д. И конца-края этой помойке не будет :)

ну ты обрисовал венду.НЕТ c его кучами версий. Я тут недавно перегрузился в венду поиграццо, посмотрел места нет, стал смотреть подробнее kdirstat'ом и офигел. Несколько версий фреймворков, целиком, ага.

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

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

//dm

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

поэтому и говорю про уровень пакетного менеджера. Но вместо тестирований в ./configure при установке по 100 раз чего есть, чего нет, проще один раз протестировать и скешировать (а в ./configure останется только минимум "юнит-тестов").

Кстати, в SOM вполне решалась задача совместимости интерфейсов, наследования -- при изменении API отдельные методы (из не сломавшегося API) -- могли грузиться из другой реализации, которая уже есть в системе. Но в SOM было много других проблем. Подозреваю, что и в случае MOP или Смоллтока/ObjectiveC можно написать фреймворки так, чтобы обеспечить макс. совместимость со старыми библиотеками.

>Угу, только вместо одной версии будет лежать 100.

не 100, а по числу имеющихся версий либ/фреймворков. Если юзер ставит 100 программ с фреймворками разных версий -- он ССЗБ. Просто предлагается "кешировать" на уровне отдельных либ/классов, а не фреймворка целиком, и всё под распределённым пакетным менеджером, автоматизированно на нужную макс. "глубину версий".

> Ну ничё, юзер докупит винт побольше, оперативы пару планочек

а если бедный геймер поставит 100 десктоп игрушек на яве, каждую со своим JVM? :P

//dm

FYI, ты в этом топике разговариваешь с 3-4, как минимум, анонимусами. Не путай их.

>Любую либу можно обернуть в ОО интерфейс чисто автоматически, и к этой обертке приделать не-ОО враппер тоже автоматически.

не любую в любой ОО интерфейс. Смотря какая объектная модель используется, и куда она отображается. На уровне препроцессора С можно изобразить любую объектную модель, как тот же GObject или Vala. Но не любые объекты можно отобразить на объектную модель Vala/C# , например.

>И тогда все С либы у нас будут с С++ ОО интерфейсами. АПИ у нас не будет вообще...

Будет у нас и API, и ABI. Кстати, почитай про язык D -- он бинарно совместим с C, и C либы грузятся в D прозрачно. ОО интерфейса у них от этого не появляется, и если бы D не был мультипарадигменным, как С++, а был строго ОО, как например, Ява, то не факт что удалось бы отобразить этот "плоский С-код " в объектную модель Явы (ну получился бы один объект-JNI-блоб, но он не стал бы от этого ОО)

То есть API остаётся все равно, хоть у нас С, хоть ассемблер, хоть шитый код. Вопрос, насколько это API выделено явно или неявно, повторно используемо.

//dm

>Не надо даже, если eval будет принимать, неизвестные на момент компиляции программы данные (ввод с клавиатуры/из файла).

чего и предлагает singularity: тотальная верифицируемость всего и вся. Другое дело, что и у них там остался % untrusted кода.

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

Живой тому пример: есть интерпретируемый встраиваемый PicoLisp, у него в тарболле есть пример, который из лисп-функции (интерпретируемой) генерит C-код, компилирует его gcc-ом (или tcc-ом Ф. Белларда), подменяет лисп-реализацию на откомпилированную С-реализацию и юзает далее откомпилированный "метод". Всё на лету.

Граница с интерпретатором / компилятором там становится совсем размытой.

//dm

>Тогда в бинарник будут зашиты все 3 варианта ее исполнения под все параметры. А если вариантов параметров 300, то будут зашиты все 300 вариантов под i386, и под Athlon i686. Займет это.. ну вы поняли, бинарь разрастется до мегабайтов

знаешь другой способ? Если все эти варианты нужны?

Вот тебе кстати, аналогия "компилируемого языка" с жёсткими связями -- шаблоны С++. Там как раз получится M*N*K вариантов при раскручивании шаблонов 3-го уровня вложенности, где на 1 уровне M, на втором N, на третьем K вариантов.

А в "динамическом" рантайме получилось бы M+N+K.

//dm

>В фракталах не специалист.

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

//dm

>Не надо даже, если eval будет принимать, неизвестные на момент компиляции программы данные (ввод с клавиатуры/из файла). Он их потом может откомпилировать во время работы программы

Экий навороченный плагино-шеллкод получился :) через дыру в абстракциях -- eval $anything. Если же anything не может получиться "с потолка", а берётся из какого-то замыкания, то есть на каждый ввод из клавиатуры/файла есть своё замыкание, то у нас будет исполнение(интерпретация?) откомпилированного заранее конкретного кода(возможно, самомодифицирующегося). По теореме Тьюринга не сможем сказать, зависнет такая программа или не зависнет, но отлаживаться delta-debugging'ом -- вполне :)

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

Ничего мне не придется. Файлы загрузятся on-demand.

>Добавь dlopen на строке прочтенной с терминала и язык С станет почти полностью интерпретируемым.

Не станет.

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

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

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

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

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

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

Предлагаю назвать "интерпретатором" исполнителя, которому доступна родная среда и интерфейсы языка и всей платформы целиком. Если эта среда для каждого приложения разная, без чётких интерфейсов, независимых от приложения, то это мало чем отличается от того же шеллкода в дырявом месте. Вроде бы можно выполнить произвольную откомпилированную функцию -- но надо знать слишком много подробностей о runtime-окружении конкретной программы. Поэтому дырка для инъекции шеллкода -- не интерпретатор, раз нет метаданных о платформе. Конкретный эксплойт -- это способ из откомпилированного кода сделать интерпретатор :)

//dm

> Это да. Отрасль почти нефига не развивается.

Она у тебя в голове не развивается. Ну, типа, с головой проблемы, мало что в нее помещается. А так - развивается и очень даже. Сейчас уже начинают внедрять в практику результаты теоретических разработок десятилетней давности - а это для любой отрасли очень неплохой показатель прогресса, обычно лаг лет в 20-30 типичен (и для IT он был типичен для недавнего времени).

> но все равно не то что хотелось бы.

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