Comments 27
99-bottles-of-beer.net/ — добро пожаловать
> Потому что на языке А можно написать интерпретатор для языка Б
Уже неверное, например, для Perl — «Only Perl can parse Perl».
Собсно, этот абзац уже неверен.
Уже неверное, например, для Perl — «Only Perl can parse Perl».
Собсно, этот абзац уже неверен.
Я же знал, что кто-нибудь так напишет :) Поэтому P.S. написал!
Ну а толку от вашего общего случая, если вы во втором абзаце утверждаете следующее:
«Вы удивитесь, но, оказывается, если взять 2 языка программирования, назовём их А и Б, то существует константа, которая составляет разницу между длинами кодов этих двух языков для всех программ.»
Собственно, я привел пример, когда ваше утверждение неверное, следовательно дальнейшие выводы тоже неверны, так как работают только на некотором подмножестве языков. А это не общий, а как раз частный случай.
«Вы удивитесь, но, оказывается, если взять 2 языка программирования, назовём их А и Б, то существует константа, которая составляет разницу между длинами кодов этих двух языков для всех программ.»
Собственно, я привел пример, когда ваше утверждение неверное, следовательно дальнейшие выводы тоже неверны, так как работают только на некотором подмножестве языков. А это не общий, а как раз частный случай.
«Only Perl can parse Perl»
Ага, а собаки не могут смотреть вверх и 2+2=5.
Ага, а собаки не могут смотреть вверх и 2+2=5.
На любом turing-complete языке можно написать интерпретатор языка Perl, если не огибаюсь :)
Я опоздал немного, но тем не менее)
Человек все правильно написал, различайте evaluate и parse. Статический парсинг перла невозможен.
Человек все правильно написал, различайте evaluate и parse. Статический парсинг перла невозможен.
А в чём разница? Разве evaluate не включает в себя parse?
В том-то и дело, что evaluate включает parse, но не наборот. Вот вам пример известный пример:
Без выполнения кода (чтобы узнать прототип whatever) нельзя сказать, как отработает этот код.
whatever / 25 ; # / ; die "this dies!";
Без выполнения кода (чтобы узнать прототип whatever) нельзя сказать, как отработает этот код.
Я, к сожалению, не знаю перла. Вопрос в том что мы понимаем под словом parse — разбиение на лексемы, построение синтаксического дерева или таки предсказание результата? В последнем случае это таки evaluate.
parse — статический (без построения синтаксического дерева) парсинг исходника (например, на регулярных выражениях).
Впервые встречаю такую интерпретацию. Вики говорит что синтаксические деревья — это тоже часть парсинга.
Anyway, с ограничениями которые вы предлагаете — распарсить не получится.
Anyway, с ограничениями которые вы предлагаете — распарсить не получится.
Как часть лексического анализа — да.
Изначально ведь имелось ввиду, что интерпретатор написать можно, а вот простой парсер нет. Человек выше написал, что «Only perl (интерпретатор) can parse Perl (язык)». Parse, а не evaluate. Парсинг не подразумевает исполнение.
Изначально ведь имелось ввиду, что интерпретатор написать можно, а вот простой парсер нет. Человек выше написал, что «Only perl (интерпретатор) can parse Perl (язык)». Parse, а не evaluate. Парсинг не подразумевает исполнение.
UFO just landed and posted this here
А можно конкретнее?
Например, сравнить PHP5 и MVC ASP.NET 3.5
Вообще, сравнивать по длине кода некорректно.
Корректно по скорости решения задачи
Например,сферический конь в вакууме средний программист решит задачу на языке А за столько-то времени, на языке В за столько-то
Например, сравнить PHP5 и MVC ASP.NET 3.5
Вообще, сравнивать по длине кода некорректно.
Корректно по скорости решения задачи
Например,
Если смотреть на скорость, то существует другая константа, которую нужно не прибавлять, а умножать.
Интересно, как вы собираетесь сравнивать язык даже не с фреймворком, а с надстройкой над ним.
Длину кода (вроде как о ней говорится) некорректно сравнивать по длине кода, но корректно по скорости решения задачи?
Подозреваю, что Вы сами себе додумали вывод, что «чем короче программа, тем лучше» и решили, что сравнивается «хорошесть» языков на основании длины кода. Если так, то нет, это Вы сами додумали. Но если говорить и «хорошести», то во-первых, «хорошесть» — понятие субъективное и без конкретной задачи смысла не имеет, а во-вторых, Ваш критерий тоже не универсален, программу ещё потом читать, отлаживать и улучшать, причём зачастую куда большую часть времени.
Подозреваю, что Вы сами себе додумали вывод, что «чем короче программа, тем лучше» и решили, что сравнивается «хорошесть» языков на основании длины кода. Если так, то нет, это Вы сами додумали. Но если говорить и «хорошести», то во-первых, «хорошесть» — понятие субъективное и без конкретной задачи смысла не имеет, а во-вторых, Ваш критерий тоже не универсален, программу ещё потом читать, отлаживать и улучшать, причём зачастую куда большую часть времени.
Ладно бы мерились у кого длиннее ))
Вы удивитесь, но, оказывается, если взять 2 языка программирования, назовём их А и Б, то существует константа, которая составляет разницу между длинами кодов этих двух языков для всех программ.
В этом какая-нибудь практическая польза есть или просто замечание вида «если сложить коды всех букв алфавита, то получится число больше ста!»? :)
Sign up to leave a comment.
Языки программирования — У кого короче код?