?

Log in

No account? Create an account
"ты, Завалишин, как e в степени x - хоть кол на голове теши" - dz

> Свежие записи
> Архив
> Друзья
> Личная информация
> DZ Online

Апрель 14, 2009


Previous Entry Поделиться Next Entry
06:32 am - "ты, Завалишин, как e в степени x - хоть кол на голове теши"
Наконец, пришли математики с предъявой - чо я тут про ОО, а это частный случай, а они про общий, а я про это молчок.

Пацаны - а знаете анекдот? Как математик идёт мимо камерного театра, замечает вывеску, и заинтересованно заходит внутрь. Через минуту выходит разочарованный со словами "тривиальный случай - ка равно трём"...?

Я вот примерно в этом же ключе случай рассматриваю - частный, тривиальный, но ОЧЕНЬ практичный. А фп мне симпатично, но пока что это и всё. Вы за него сначала сами повоюйте, чтоб хотя бы я начал вас до конца понимать. А то, извините за самомнение, но пока даже я всего не понял, рассчитывать на широкие массы программеров - ну - как бы это сказать - преждевременно.

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

Мысль вот какая. Надо выбирать не самый широкий базис, не самую всеобъемлющую парадигму, а МИНИМАЛЬНО возможный базис. Идеален не тот ЯП, на котором можно написать ЛЮБУЮ программу, а тот, на котором можно написать ЛЮБУЮ НУЖНУЮ тебе программу. То есть - никому не нужны к-мерные театры. Для 3-мерных существ ВПОЛНЕ достаточно 3-мерных, и давать в этом месте гибкость - бессмысленно и ВРЕДНО.

Утверждение: Правильный, хороший ЯП, неполноценен и ИЗБЫТОЧЕН, а полноценный и неизбыточный (лисп, форт, ассемблер стековой машины) - вреден и чрезмерен.

Утверждение: программирование - это НЕ написание программы, а написание ТАКОЙ программы, процесс написания которой позволяет организовывать мышление программиста эффективным с точки зрения формализации предметной области способом. Запуск программы на исполнение - важный, но почти побочный эффект её написания. (это вообще кто-то древний сказал...)

PS: Я прощёлкал - а когда это в течении последних 75 лет присваивание признали функционально кошерным?

PPS: Мне тут ещё фразу подарили: "третий элемент кортежа похож на емейл". Пишу, чтобы не забыть. Очень хочу посмотреть на спеку для ФП-библиотеки функций, в которой говорится, что все функции принимают в качестве параметра кортежи с третьим элементом, похожим на емейл. Сплю и вижу. Сплю, вижу, и фигею, дорогая редакция. /* int [] myfunc( int [] ); third int in array supposed to be x coordinate in inches */

(94 комментария | Оставить комментарий)

Comments:


[User Picture]
From:blacklion
Date:Апрель 14, 2009 01:03 pm
(Link)
\\Я не вижу ни одной причины, по которой запись
Parser.create(bnfString).parse(input);
не является красивой.\\
Ну, оно, конечно, в глазах смотрящего, но во-первых, ваш вариант создаёт парсер в рантайме ;-) во-вторых, редактировать большие строки в тексте программы неудобно. Выносим в отдельный файл? :)
(Удалённый комментарий)
[User Picture]
From:thesz
Date:Апрель 14, 2009 01:55 pm
(Link)
Ну, что ж.

Придётся прочитать ещё одну лекцию.

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

Лекция закончена.

Комбинаторный подход, на который показал blacklion, позволяет внести декларативное описание чего-либо в программу и поддерживать типы данных программы и какую-то специализированную сущность в синхронном состоянии. И гораздо более удобном со всех сторон (кроме быстродействия, но и это решаемо).

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

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

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

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

То, что защищаете вы, разносит источники ошибок и ослабляет их синхронизацию. Вам придётся вносить этап тестирования и увеличивать количество тестов грамматики.

Запретить, однако, не могу. ;)

PS
На комбинаторах я сделал разбор Фортрана за выходные. Разбирались все тексты NAS benchmark. Не более, но и не менее. ;)
PPS
Captch начала повторяться. "marquand to" я уже видел. ;)
(Удалённый комментарий)
[User Picture]
From:thesz
Date:Апрель 14, 2009 07:49 pm
(Link)
Разделение исходного кода на несколько файлов, когда логически они объединены, это либо решение проектировщиков языка, либо от безысходности.

PS
Я помогал учёным в работе над спецвычислителем. На неделе я был занят совсем другим.

> Go to Top
LiveJournal.com