Pull to refresh

Comments 27

> Потому что на языке А можно написать интерпретатор для языка Б
Уже неверное, например, для Perl — «Only Perl can parse Perl».
Собсно, этот абзац уже неверен.
Я же знал, что кто-нибудь так напишет :) Поэтому P.S. написал!
Ну а толку от вашего общего случая, если вы во втором абзаце утверждаете следующее:

«Вы удивитесь, но, оказывается, если взять 2 языка программирования, назовём их А и Б, то существует константа, которая составляет разницу между длинами кодов этих двух языков для всех программ.»

Собственно, я привел пример, когда ваше утверждение неверное, следовательно дальнейшие выводы тоже неверны, так как работают только на некотором подмножестве языков. А это не общий, а как раз частный случай.
«Only Perl can parse Perl»

Ага, а собаки не могут смотреть вверх и 2+2=5.
Не собаки, а свиньи. А по поводу перла советую погулить и почитать, начать хотя бы с английской википедии.
На любом turing-complete языке можно написать интерпретатор языка Perl, если не огибаюсь :)
Я опоздал немного, но тем не менее)
Человек все правильно написал, различайте evaluate и parse. Статический парсинг перла невозможен.
А в чём разница? Разве evaluate не включает в себя parse?
В том-то и дело, что evaluate включает parse, но не наборот. Вот вам пример известный пример:
whatever / 25 ; # / ; die "this dies!";

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

Anyway, с ограничениями которые вы предлагаете — распарсить не получится.
Как часть лексического анализа — да.
Изначально ведь имелось ввиду, что интерпретатор написать можно, а вот простой парсер нет. Человек выше написал, что «Only perl (интерпретатор) can parse Perl (язык)». Parse, а не evaluate. Парсинг не подразумевает исполнение.
Естественно. Я просто сразу не понял что вы подразумеваете под «простым парсером».
UFO just landed and posted this here
Не все математики же, хотел написать как понятнее для всех. Да и программистам 1С так понятнее :)
>> Да и программистам 1С так понятнее

Мощный аргумент :)
UFO just landed and posted this here
А можно конкретнее?
Например, сравнить PHP5 и MVC ASP.NET 3.5

Вообще, сравнивать по длине кода некорректно.
Корректно по скорости решения задачи

Например, сферический конь в вакууме средний программист решит задачу на языке А за столько-то времени, на языке В за столько-то
Если смотреть на скорость, то существует другая константа, которую нужно не прибавлять, а умножать.
Интересно, как вы собираетесь сравнивать язык даже не с фреймворком, а с надстройкой над ним.
Я не знаю как сравнить
Просто я предложил конкретику в плане ASP.NET
Я просто не знаю фреймворков для PHP
Длину кода (вроде как о ней говорится) некорректно сравнивать по длине кода, но корректно по скорости решения задачи?

Подозреваю, что Вы сами себе додумали вывод, что «чем короче программа, тем лучше» и решили, что сравнивается «хорошесть» языков на основании длины кода. Если так, то нет, это Вы сами додумали. Но если говорить и «хорошести», то во-первых, «хорошесть» — понятие субъективное и без конкретной задачи смысла не имеет, а во-вторых, Ваш критерий тоже не универсален, программу ещё потом читать, отлаживать и улучшать, причём зачастую куда большую часть времени.
Вы удивитесь, но, оказывается, если взять 2 языка программирования, назовём их А и Б, то существует константа, которая составляет разницу между длинами кодов этих двух языков для всех программ.


В этом какая-нибудь практическая польза есть или просто замечание вида «если сложить коды всех букв алфавита, то получится число больше ста!»? :)
Sign up to leave a comment.

Articles