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

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

> Нет, зачем? Один объект может реализовывать несколько интерфейсов разом. Вы знаете про множетсвенно наследование в C++ или про интерфейсы в java?

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

>так как же быть с теми прогами, которые юзают не ОО интерфейсы, а API (например libc API)?

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

>> То что вы называете интерфейсом полностью зовется API.

>API == Application Programming Interface, _интерфейс_ прикладного программирования.

>Так что меньше апломба. любезный :)

Чудненько, а теперь перечитайте, где я сказал, что API это не интерфейс?

> А интерпретация - это исполнение кода без генерации в ходе этого нового "родного" кода процессора.

> Вот как раз такой режим у .NET отсуствует (если верить MS).

Из-за этого называть .NET не-интерпретатором?

А если он при этом болеет ВСЕМИ родовыми болезней интерпретаторов?

Меня честно говоря именно болезни интересуют. Если все болезни интерпретатора есть -- значит интерпретатор, неважно что внутри.

---

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

> а теперь перечитайте, где я сказал, что API это не интерфейс?

Настолько сильно ты не лопухнулся. Однако судя по этим фразам: "ls использует интерфейсы, ну нифига себе" и "С каких то пор в libc появились объекты ООП?" ты не считал API libc интерфейсами.

>Однако судя по этим фразам: "ls использует интерфейсы, ну нифига себе" и "С каких то пор в libc появились объекты ООП?" ты не считал API libc интерфейсами.

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

>> Вот как раз такой режим у .NET отсуствует (если верить MS).

> Из-за этого называть .NET не-интерпретатором?

Да.

> А если он при этом болеет ВСЕМИ родовыми болезней интерпретаторов?

Совсем недавно ты затруднялся провести четкую границу между компиляцией и интерпретацией :) Ну ладно. и какие же "родовые болезни" интерпретаторов есть у .NET?

> А интерпретация - это исполнение кода без генерации в ходе этого нового "родного" кода процессора. Вот как раз такой режим у .NET отсуствует (если верить MS).

Это может быть хорошо, но ТОЛЬКО в том случае, если МС заюзала это ограничения для разных там оптимизаций... а ведь еще может там что-то другое мешает как следюет заюзать это ограничение.

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

>> Однако судя по этим фразам: "ls использует интерфейсы, ну нифига себе" и "С каких то пор в libc появились объекты ООП?" ты не считал API libc интерфейсами.

> Я уже не раз говорил о каких интерфейсах идет речь.

Ну и как совместить это с твоей фразой "где я сказал, что API это не интерфейс?". По ней выходит, что ls таки использует интерфейсы, а libc их содержит.

> Или вам просто хочется потроллить?

Нет, мне просто было интересно, склонен ли ты признавать свои ошибки.

> Совсем недавно ты затруднялся провести четкую границу между компиляцией и интерпретацией :)

Дык это не только я :-)

> Ну ладно. и какие же "родовые болезни" интерпретаторов есть у .NET?

Я сказал "А если ... ?". Может там их и нет... может придет знающий чел и приведет ключики что я просил.

Родовые болезни интерпретаторов: 1) тормоза 2) лишний код, висящий в памяти, который выкинуть нельзя, так как его необходимость неизвестна во время к.

Вопрос был не ко мне, но все равно:

> Нет, мне просто было интересно, склонен ли ты признавать свои ошибки.

Я вот через сутки-другие могу признать, а так сразу буду защищать их как руины сталиграда :-)

>Ну и как совместить это с твоей фразой "где я сказал, что API это не интерфейс?". По ней выходит, что ls таки использует интерфейсы, а libc их содержит.

Но не интерфейсы из ООП, о которых шла речь.

>Нет, мне просто было интересно, склонен ли ты признавать свои ошибки.

Врете ведь.

>> Нет, мне просто было интересно, склонен ли ты признавать свои ошибки.

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

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

> Врете ведь.

>_>

<_<

Oops, you found out... now we have to kill you.

>>Ну и как совместить это с твоей фразой "где я сказал, что API это не интерфейс?". По ней выходит, что ls таки использует интерфейсы, а libc их содержит.

>Но не интерфейсы из ООП, о которых шла речь.

>>Нет, мне просто было интересно, склонен ли ты признавать свои ошибки.

>Врете ведь.

Можно

1) написать скрипт, который делает определение класса со статическими методами, каждый из которых будет функция, продоставляемая не-ОО библиотекой, например libc.

2) для не ОО программ написать к этому классу не ОО враппер.

И забыть о не ОО-интерфейсах...

А проблемы то останутся, так?

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

А по-моему надо просто не подставляться :-)

>Можно

А зачем?

> А если он при этом болеет ВСЕМИ родовыми болезней интерпретаторов?

Лжешь зачем? Нет ничего из свойственного интерпретаторам. Вообще. Если только RTTI не засчитывать, но тогда и C++ интерпретатор.

> Если все болезни интерпретатора есть -- значит интерпретатор, неважно что внутри.

Ты ламер. А ламеры, имеющие наглость иметь мнение, ничего кроме брезгливости вызывать не могут.

> Родовые болезни интерпретаторов: 1) тормоза 2) лишний код, висящий в памяти, который выкинуть нельзя, так как его необходимость неизвестна во время к.

Итак: про интерпретаторы ты не знаешь ВООБЩЕ НИЧЕГО. Фатально.

1) Не обязательно. Кроме того, у .NET тормозов нет.

2) Выкинь libc.so, умник. А то ведь тебе из него только printf нужен.

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

>> А если он при этом болеет ВСЕМИ родовыми болезней интерпретаторов?

> Лжешь зачем? Нет ничего из свойственного интерпретаторам. Вообще. Если только RTTI не засчитывать, но тогда и C++ интерпретатор.

ПОВТОРЯЮ:

Я сказал "А если ... ?". Может там их и нет... может придет знающий чел и приведет ключики что я просил.

>> Если все болезни интерпретатора есть -- значит интерпретатор, неважно что внутри.

> Ты ламер. А ламеры, имеющие наглость иметь мнение, ничего кроме брезгливости вызывать не могут.

А ты что ли спец? Я привел ключики g++ для статической линковки. Где те же ключики для mono/.net, о великий и мудреший ?

А еще ты не читал видимо начало поста. Я гонял маленькую программу на .нет на КПК и видел насколько она тормозила по сравнению с аналогичными.

Давай ключики для МС реализции нет на КПК на АРМ. Попробую их и сравню с аналогичными прогами...

> 1) Не обязательно. Кроме того, у .NET тормозов нет.

Ты подставляешься.

> 2) Выкинь libc.so, умник. А то ведь тебе из него только printf нужен.

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

> А ты что ли спец?

Да. Специалист. В Computer science вообще, и конкретно в языках в частности. А ты - ламер.

> Я привел ключики g++ для статической линковки.

А я приказал тебе признать, что код на Си, слинкованный с libc динамически - интерпретируемый. Раз уж ты такой глупый, то почему бы и не признать ещё одну чушь, следующую непосредственно из твоего бреда?

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

Это твои личные половые трудности и проблемы реализации .NET на этом самом КПК. У меня вот mono на ARM не тормозит, скорость сопоставимая с нативными бинарниками.

>>Можно

>А зачем?

Чтобы ты прекратил отмазки насчет АПИ.

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

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

> Если все болезни интерпретатора есть -- значит интерпретатор, неважно что внутри.

Если все симптомы простуды есть -- значит простуда! И не важно, что это на самом деле: грипп или холера...

Примечание:

Так же как и технология Java, среда разработки .NET создаёт байт-код, предназначенный для исполнения виртуальной машиной. Входной язык этой машины в .NET называется MSIL (Microsoft Intermediate Language), или CIL (Common Intermediate Language, более поздний вариант), или просто IL. Применение байт-кода позволяет получить кроссплатформенность на уровне скомпилированного проекта (в терминах .NET: сборка), а не на уровне исходного текста, как, например, в С. Перед запуском сборки в среде исполнения (CLR) байт-код преобразуется встроенным в среду JIT-компилятором (just in time, компиляция на лету) в машинные коды целевого процессора.

(С) pediwikia

Насчет того что моно не тормозит:

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

> Да. Специалист. В Computer science вообще, и конкретно в языках в частности. А ты - ламер.

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

>> Если все болезни интерпретатора есть -- значит интерпретатор, неважно что внутри.

> Если все симптомы простуды есть -- значит простуда! И не важно, что это на самом деле: грипп или холера...

У нас тут пока два только варианта -- интерпретация или компиляция. Ты еще можешь предложить парочку? А?

Я предложил приблизетельную числовую метрику, типа С это на 1% интерпретация и на 99% компиляция. Но она все равно между этими двумя.

>АПИ у нас не будет вообще...

Вы жжоте.

>У нас тут пока два только варианта -- интерпретация или компиляция

Это у вас тут. А вообще... Я выше все написал. Понятия "байт-код" и "виртуальная машина" какие-нибудь ассоциации вызывают в голове?

>Я предложил приблизетельную числовую метрику, типа С это на 1% интерпретация и на 99% компиляция.

Извини, не знаю кому-как, но по мне так это -- бред какой-то %)

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

Нет слов...

Это подошло бы для квотезов, жаль поймут не все 8)

>Вон printf ИНТЕРПРЕТИРУЕТ форматную строку. И что, после этого С -- интерпретатор?

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

>1) тормоза 2) лишний код, висящий в памяти, который выкинуть нельзя, так как его необходимость неизвестна во время к.

Бред. Код необходимости в котором нет в память не загружается (в разумных пределах естественно).

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

>Нет слов...

Ты уверен что ты понял зачем я это предлагаю? Это для упрощения дискуссии, а не для практической реализации.

>Это для упрощения дискуссии, а не для практической реализации.

И что в данном случае оно упростило в дискуссии? Я наоборот больше запутался.

>>Вон printf ИНТЕРПРЕТИРУЕТ форматную строку. И что, после этого С -- интерпретатор?

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

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

>>Это для упрощения дискуссии, а не для практической реализации.

>И что в данном случае оно упростило в дискуссии? Я наоборот больше запутался.

Тогда предложи что-нить свое чтобы wfrr прекратил отмазки типа "вот у libc не ОО интерфейс, а АПИ, а я говорю только об ОО интерфейсах"

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

>Язык в данном аспекте (к/и) должен рассматриваться только вместе с функциями.

убери #include <stdio.h> и не сможешь использовать printf. При этом язык C останется языком C. Срочно на википедию смотреть определение языка в обобщенном смысле.

>>1) тормоза 2) лишний код, висящий в памяти, который выкинуть нельзя, так как его необходимость неизвестна во время к.

>Бред. Код необходимости в котором нет в память не загружается (в разумных пределах естественно).

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

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

>Тогда предложи что-нить свое чтобы wfrr прекратил отмазки типа "вот у libc не ОО интерфейс, а АПИ, а я говорю только об ОО интерфейсах"

API -- это абстракция. ООП-обертка -- это всего лишь один дополнительный уровень абстракции. Т.е. упрощенный API.

>>Язык в данном аспекте (к/и) должен рассматриваться только вместе с функциями.

>убери #include <stdio.h> и не сможешь использовать printf. При этом язык C останется языком C. Срочно на википедию смотреть определение языка в обобщенном смысле.

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

Сюрприз?

Русская педивикия идёт лесом. На русском языке нормальных источников нет и по определению быть не может.

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

А так, dlopen в руки, и Си становится интерпретатором. Тоже ведь любую функцию по имени взять можно.

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

dlopen, ЕМНИП, -- системный вызов. Исключи #include <dlfcn.h> и не компонуй с -ldl и язык C остается C.

>Сюрприз?

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

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

Ну это неправильно, фильтровать надо сильно конечно, но такое обобщение неверно. Например, работы Колмогорова или Турчина ты тоже нормальными не посчитаешь?

> Например, работы Колмогорова или Турчина ты тоже нормальными не посчитаешь?

Это то конечно более чем нормальные источники. Ок, уточню обобщение - русскоязычных источников после 1990го года надо опасаться, в силу фатального упадка уровня науки в стране.

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

>dlopen, ЕМНИП, -- системный вызов. Исключи #include <dlfcn.h> и не компонуй с -ldl и язык C остается C.

>>Сюрприз?

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

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

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

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

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

> А так, dlopen в руки, и Си становится интерпретатором. Тоже ведь любую функцию по имени взять можно.

C + dlopen уже (почти) болеет всеми болезнями интерпретатора -- поэтому я считаю что его можно считать интерпретатором.

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

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

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

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