LINUX.ORG.RU

Доказана невозможность статического парсинга Perl 5

 , неразрешимость, ,


0

0

Формально доказана неразрешимость задачи статического синтаксического анализа Perl 5. В опубликованном доказательстве задача парсинга программы на Perl сводится к задаче остановки, которая, как известно любому школьнику, неразрешима.

Этот факт имеет важное практическое значение — он означает что в общем случае выяснить, что будет делать та или иная программа на Perl, возможно только выполнив саму программу. Методы статического анализа бессильны. Возникают ли подобые проблемы в Perl 6 — неизвестно.

Статьи (pdf): [1], [2], [3].

>>> Подробности

Ответ на: комментарий от KRoN73

>Примеры: C++, Visual Basic, Java, Python, Ruby, Perl, Delphi (Pascal), PHP

C все-таки нет :)

spaceblock
()
Ответ на: комментарий от yk4ever

> по причине... роста сложности систем

Вот за такое убивать надо. Людей, которые не ценят простоту и прозрачность систем. Сколько раз встречал бредятину вроде "За 40 лет системы стали гораздо сложнее и умнее, Unix-way больше не катит." Уроды. Мрази.

grusha
()
Ответ на: комментарий от KRoN73

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

Ящзык Си, очевидно, не отсюда.

sv75 ★★★★★
()
Ответ на: комментарий от KRoN73

> Говорю же - вот и выросло...

Не "и выросло", а наконец-то открылись глаза на платье короля. ;)

В конце концов, как в ЯВУ может попасть язык без массивов в качестве First Class Citizen?

sv75 ★★★★★
()
Ответ на: комментарий от Gukl

>Возможность написать чисто процедурную программу

Ты пайтон с жабой не путаешь, не? FYI на нем можно и в процедурном и в функциональном стиле писать.

А еще очки одел :D

anonymous4
()
Ответ на: комментарий от sv75

>В конце концов, как в ЯВУ может попасть язык без массивов

Сколько лет в Си массивами пользовались и не знали, что их там нет... :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Сколько лет в Си массивами пользовались и не знали, что их там нет... :)

Неужто ни разу за много лет не обнаруживали, что a=b массивы не копирует, и что не важно как писать, a[i] или i[a], и функции массивы не возрващают и не получают по значению? %)

sv75 ★★★★★
()
Ответ на: комментарий от chorny

> Perl::Critic вообще рекомендуется каждому.

Да, это единственный способ навязать хоть какой то coding style перл-ковбоям. Хороший модуль. Жаль его не было, когда я начинал работать с перлом. А Perl Best Practices нужно сразу давать программистам как букварь вместо кэмел-бука. Впрочем, проще наверно совсем Перл не использовать без большой нужды.

Hjorn
()
Ответ на: комментарий от Hjorn

> навязать хоть какой то coding style перл-ковбоям

Хм. А зачем кому-то навязывать какой-либо стиль? Мусье фошизд? Впочем, Питон, с единственно возможным форматированием как раз для вас, таки да...

Gukl ★★★
()
Ответ на: комментарий от Gukl

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

Да в Перле столько неявных операций и сайд-эффектов, что бояться неявной передачи ссылки просто смешно :) Ссылки (точнее их отсутствие) - очевидный просчёт в изначальном дизайне, вот и всё. Без всякой философии. Неужели кому то действительно нравится вручную рулить указателями в высокоуровневом языке с GC?

Hjorn
()
Ответ на: комментарий от anonymous4

>А еще очки одел :D

Это не очки!

>FYI на нем можно и в процедурном

Встроенные типы-то все равно объектные.

Gukl ★★★
()
Ответ на: комментарий от Gukl

> Хм. А зачем кому-то навязывать какой-либо стиль? Мусье фошизд?

Мусье никогда не работал в команде? Очень хреновое будет взаимодействие без единого стиля.

> Впрочем, Питон, с единственно возможным форматированием как раз для вас, таки да

Нет, мне лично Питон не нравится. Но для команды, особенно распределённой, его строгий синтаксис - то что доктор прописал. Жаль, Гвидо не пошёл дальше и не сделал обязательными пробелы между токенами. Было бы вообще чудно.

Hjorn
()
Ответ на: комментарий от Hjorn

>Но для команды, особенно распределённой, его строгий синтаксис

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

Gukl ★★★
()
Ответ на: комментарий от Gukl

> Возможность написать чисто процедурную программу (и выиграть в скорости еще больше, чем Перл обычно выигрывает у Питона ;)

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

Это он где выигрывает? Там, где он в семь раз медленнее? Ну-ну.

> что иногда критично)

Вы гидродинамику на скриптовом языке обсчитываете? Бедный...

yk4ever
()
Ответ на: комментарий от grusha

> Вот за такое убивать надо.

Сильно выражаешься, задрот. Хочешь встретиться, попробовать на практике реализовать своё предложение, м? Пока у тебя каникулы-то.

> Людей, которые не ценят простоту и прозрачность систем. Сколько раз встречал бредятину вроде "За 40 лет системы стали гораздо сложнее и умнее, Unix-way больше не катит." Уроды. Мрази.

Мечтатель. Все мы в детстве были такими.

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

А юникс-вэй как сосёт с проглотом последние 20 лет, так и будет продолжать.

yk4ever
()
Ответ на: комментарий от Gukl

Да чего стоит хотя бы пачка глобальных иероглифов, изменяющих поведение ряда встроенных функций. И костыли к ним вроде {local $\; ...}. А ещё контекстная зависимость, переменные по умолчанию, отсутствие формальных параметров у подпрограмм. Мало что ли? Уж неявные ссылки и дополнительный оператор копирования на этом фоне можно было стерпеть. Зато код стал бы чище на порядок, и дурацких багов вроде $list['item'] вместо $list->['item'] стало бы меньше.

Hjorn
()
Ответ на: комментарий от Gukl

> Хм. А зачем кому-то навязывать какой-либо стиль?

Вы эта, когда в последней раз работали в команде более чем из одного человека?

yk4ever
()
Ответ на: комментарий от yk4ever

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

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

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

Gukl ★★★
()
Ответ на: комментарий от Gukl

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

... путём расстрела несогласных.

sv75 ★★★★★
()
Ответ на: комментарий от Hjorn

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

Ну так не трогайте их. В чем проблема?

> И костыли к ним вроде {local $\; ...}

Ну так не трогайте их.

> переменные по умолчанию

Ну так... ну вы поняли.

> отсутствие формальных параметров у подпрограмм

Надо? Задайте.

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

Gukl ★★★
()
Ответ на: комментарий от anonymous4

> Тем более, что это очень даже хорошо!

Хм. Ну вот мне это не нужно. Если мне понадобится объект, я его как-нибудь сам сделаю. А пока не нужен - не желаю жертвовать производительностью.

Gukl ★★★
()
Ответ на: комментарий от anonymous4

>>Неужто ни разу за много лет не обнаруживали, что a=b массивы не копирует

>Внезапно в пайтоне тоже a=b не копирует массивы :)

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

KRoN73 ★★★★★
()
Ответ на: комментарий от sv75

> ... путём расстрела несогласных.

Это к питонерам.

Gukl ★★★
()
Ответ на: комментарий от Gukl

>не желаю жертвовать производительностью.

Наивный, ты думаешь только из-за того факта, что int в пайтоне -- это класс, теряется производительность в вычислениях? Я с вас умиляюсь :)

anonymous4
()
Ответ на: комментарий от yk4ever

> Ой, да вы тоже мечтатель.

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

Gukl ★★★
()
Ответ на: комментарий от anonymous4

> Наивный, ты думаешь только из-за того факта, что int в пайтоне -- это класс, теряется производительность в вычислениях? Я с вас умиляюсь :)

Хм. Я вам, вроде, пока что не тыкал... В Питоне не только int - класс, не?

Gukl ★★★
()
Ответ на: комментарий от anonymous4

> из-за того факта, что int в пайтоне -- это класс

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

Gukl ★★★
()
Ответ на: комментарий от Gukl

> Ну так не трогайте их

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

Hjorn
()
Ответ на: комментарий от Hjorn

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

В Перле есть и свои способы улучшить читабельность, см. выше по треду я писал. Так что все уравновешивается. С другой стороны, почему не пригласить разбирать программу не вас, а другого крутого перлиста Витю? ;)

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

> И write-only его прозвали

Самое смешное, что все эти прозвища ему дали перлисты. Пора вводить тег <irony> ?

Gukl ★★★
()
Ответ на: комментарий от Gukl

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

да может. а перл не может. в девелопменте разбирались как-то раз уже.

stave ★★★★★
()
Ответ на: комментарий от stave

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

> да может

Фанатизм over 9000 detected, все в машину! Вам удалось меня напугать.

Gukl ★★★
()
Ответ на: комментарий от Gukl

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

Ну смотрите. У инженеров есть стандарты - ГОСТ, ISO и проч. Инженера, который делает не по стандарту - сразу шлют нахрен.

Внимание, вопрос: почему у программистов должно быть иначе?

yk4ever
()
Ответ на: комментарий от Gukl

> Фанатизм over 9000 detected, все в машину! Вам удалось меня напугать.

:] я питоновские скрипты всегда читал сходу, даже когда только учил язык.

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

yk4ever
()
Ответ на: комментарий от Gukl

> А пока не нужен - не желаю жертвовать производительностью.

Скажите, а как ООП связано с потерей производительности?

yk4ever
()
Ответ на: комментарий от KRoN73

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

Похаписты не жалуются.

yk4ever
()
Ответ на: комментарий от Gukl

>Фанатизм over 9000 detected, все в машину! Вам удалось меня напугать.Фанатизм over 9000 detected, все в машину! Вам удалось меня напугать.

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

stave ★★★★★
()
Ответ на: комментарий от Gukl

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

Я знаю на местном рынке точку, где неплохой велосипед можно купить совсем задёшево. Вам подсказать или продолжите париться?

yk4ever
()
Ответ на: комментарий от yk4ever

> У инженеров есть стандарты - ГОСТ, ISO и проч. Внимание, вопрос: почему у программистов должно быть иначе?

Питон - стандарт уровня ГОСТ, что ли? Чего вдруг? Несколько разные вещи.

Gukl ★★★
()
Ответ на: комментарий от stave

> если не видишь недостатки того, что защищаешь

Почему не вижу? Вижу я в Перле достаточно недостатков. Ту же работу с utf пора уже делать "за кадром", например.

Gukl ★★★
()
Ответ на: комментарий от yk4ever

> Я знаю на местном рынке точку, где неплохой велосипед

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

Gukl ★★★
()
Ответ на: комментарий от Gukl

> Питон - стандарт уровня ГОСТ, что ли? Чего вдруг?

Есть единые рекомендации.

> Несколько разные вещи.

Следование стандартам - один из критериев, который отличает тру профессионала от всякой хни из-под ногтей.

yk4ever
()
Ответ на: комментарий от Gukl

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

Как у вас специфика проекта может влиять на стиль написания кода?

yk4ever
()
Ответ на: комментарий от anonymous4

> Внезапно в пайтоне тоже a=b не копирует массивы :)

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

sv75 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.