О подражании Кнуту
May. 29th, 2007 05:08 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
scholar_vitОдин из распространенных сюжетов в фантастике - это землянин за штурвалом корабля пришельцев. Или наоборот - пришелец за штурвалом корабля землян. Решался он по-разному: от космической оперы ("Джон слегка нажал на педаль, и мощный корабль послушно лег на курс к далекой Земле") до юмористических вещей (масса примеров есть у Шекли, Пола Андерсона и других классиков "золотого века"). Гораздо меньше фантастов задумывалось над тем, что система управления - это отражение нашего мозга, нашей биологии, физиологии, нашей истории. Чужая машина нам будет прежде всего непонятна. Даже если мы сможем как-то заставить её слушаться наших приказов, это будет сопряжено с ежеминутным насилием над собственным мыслительным аппаратом. Нам нужно будет заставлять себя думать как какой-нибудь марсианский богомол.
Но зачем обращаться к фантастике? Разница между людьми тоже немала. В особенности когда речь идёт об "обычных людях" и гениях; я иногда подозреваю, что гении думают не просто лучше нас - а по-другому. Есть тонкая грань между талантом и гением. Талант - это "как мы, только лучше", а гений - это совсем другое, это иное существо. Было бы очень интересно понять, как отличается мое мышление от мышления другого (тем более - гения!) - хоть одним глазом подсмотреть. Но тут есть большая проблема. Дело в том, что каждый человек значительную часть творческих усилий тратит на то, чтобы сделать свою работу понятной для других. По сути убрать особенности своего мышления, привести всё к общему знаменателю. Это очевидно, когда речь идёт об искусстве, о литературе, о преподавании - но это верно и для любой другой творческой деятельности. Когда человек занимается наукой, он пишет статью - то есть "переводит" свои мысли с внутреннего языка на "общечеловеческий". Хороший пример тут - Ньютон, который получал свои результаты при помощи созданного (частично) им же анализа, но излагал их на языке синтетической греческой математики. Это иногда объясняют тем, что Ньютон "не доверял" новым методам. Я позволю себе не поверить в такое объяснение: прекрасно он им доверял - но ему приходилось подлаживаться под стиль мышления аудитории. Позже эти способы стали общим достоянием - но потребовалось несколько веков усилий преподавателей и методистов, чтобы стало возможным излагать их обычным людям. Мы по сути овладели парой правил "грамматики Ньютона" - ценой огромных усилий. Но это, скорее всего, только малая часть того, что понимал Ньютон. Я прошу прощения за избитую ещё в прошлом веке фразу, но наука - это не взаимодействие объекта исследования и его субъекта, это взаимодействие объекта, субъекта и третьего - студента, ученика, читателя. Как и литература, искусство. И поэтому заглянуть в мозг автора сложно: он показывает не то, что он думает, а то, что он хочет показать.
На первый взгляд кажется, что с компьютерным программированием иначе. Программирование - это ведь взаимодействие человека с машиной, так? Но на самом деле программисты уже очень давно пишут в основном для других программистов. Собственно, технологии программирования направлены на облегчение понимания программ людьми. Это - целевая аудитория программиста; а то, что машины тоже понимают эти тексты - эффект, скорее, побочный. Так что из из программ мы не поймём, как "на самом деле" думает программист.
У меня очень давно зреет мысль, что TeX - одно из исключений из этого правила. Дональд Кнут - один из последних великих программистов героического периода. В те времена писали "для машины", оптимизируя код (см. знаменитую "Историю Мела, настоящего программиста"). Кнут поначалу с подозрением отнесся к идее Дейкстры о структурном программировании. Позже он занялся проблемой понимания кода человеком и предложил своё решение: literate programming. Это очень интересная идея; как-нибудь я напишу о том, почему она не получила большого распространения. И самое главное - Кнут, на мой взгляд, ЗА той гранью, которая отделяет талант от гения.
Статьи Кнута о ранней истории TeXа несколько противоречивы. С одной стороны, он подчеркивает, что изначально писал TeX для себя, точнее, для набора одной книги (The Art of Computer Programming), и что его не перестаёт удивлять, что так много людей использует его программы. С другой - программа написана в стиле literate programming (собственно, TeX и Metafont - это два наиболее характерных примера lp), то есть он заботился о том, чтобы программа была понятна другим?
Моя гипотеза состоит в том, что изначально TeX предназначался для "внутреннего пользования". Ещё в то время, когда Кнут полагал, что ему хватит одного sabbatical, чтобы написать систему. Но потом, когда этот проект занял на порядок больше усилий, а масса людей заинтересовалась, Кнут переориентировал его на систему общего назначения. Это иллюстрирует история перехода к TeX3, когда Кнута убедили добавить серьёзную интернационализацию к системе.
Если это так, то дизайн TeXа отражает способ мышления Кнута более точно, чем другие его вещи. И боже мой, насколько этот дизайн не похож на "нормальное человеческое" мышление!
Оговорюсь, что следует различать две вещи: интерфейс TeXа для авторов (математик, пишущий статью в TeXе) и интерфейс для TeXников (программист, создающий стиль верстки для журнала). Первый довольно естественен. Хотя мне больше нравится LaTeXовский стиль в тех местах, где он отличается от TeXовского: почему-то \frac{a}{b} мне кажется понятнее, чем {a \over b}. Но второй - это совсем другое дело. Некоторые думают, что всё дело в том, что Кнут выбрал расширяемый макроязык. Возможно, это и правда. Но есть разные макроязыки. Я программировал в maximе и lispе - нельзя сказать, чтобы это было просто, но это неизмеримо яснее, чем TeX - и это при том, что я очень неплохо знаю TeX. Чисто программистские примитивы в TeXе поражают. Почему автор выбрал эти \futurelet, \afterassignment и т.д.? С другой стороны, почему цикл - не примитив, а вовсе макро (кстати, слегка по-разному определенный в plain и в LaTeXе)? И совсем безумная идея поиска закрывающего \fi - см. раздел 13.8.4 в книге Victor Eijkhout, Tex by Topic. Я позволю себе привести цитату из этой книги:
В результате вот как выглядит программа, делающая "лексикографическое сравнение" двух строк (из той же книжки):TeX's matching of \if, \else, and \fi is easily upset. For instance, the TеXbook warns you that you should not say
\let\ifabc=\iftrueinside a conditional, because if this text is skipped TеX sees at least one \if to be matched.The reason for this is that when TеX is skipping it recognizes all \if..., \or, \else, and \fi tokens, and everything that has been declared a synonym of such a token by \let. In \let\ifabc=\iftrue TеX will therefore at least see the \iftrue as the opening of a conditional, and, if the current meaning of \ifabc was for instance \iffalse, it will also be considered as the opening of a conditional statement.
As another example, if
\csname if\sometest\endcsname \someaction \fiis skipped as part of conditional text, the \fi will unintentionally close the outer conditional. It does not help to enclose such potentially dangerous constructs inside a group, because grouping is independent of conditional structure. Burying such commands inside macros is the safest approach.
\let\ex=\expandafter
\def\ifbefore
#1#2{\ifallchars#1$\are#2$\before}
\def\ifallchars#1#2\are#3#4\before
{\if#1$\say{true\ex}\else
\if#3$\say{false\ex\ex\ex}\else
\ifnum#1>#3 \say{false%
\ex\ex\ex\ex\ex\ex\ex}\else
\ifnum#1<#3 \say{true%
\ex\ex\ex\ex\ex\ex\ex
\ex\ex\ex\ex\ex\ex\ex\ex}\else
\ifrest#2\before#4\fi\fi\fi\fi}
\def\ifrest#1\before#2\fi\fi\fi\fi
{\fi\fi\fi\fi
\ifallchars#1\are#2\before}
\def\say#1{\csname if#1\endcsname}
Человек, для которого такое естественно, определенно мыслит иначе, чем
мы. И это НЕ особенно патологический образчик; посмотрите на
продвинутые пакеты на CTAN!
Собственно, совершенно неудивительно, что эти пакеты часто написаны в
стиле, близком к literate programming (единственное известное мне
массовое применение этого метода - а по-другому писать их будет совсем
непонятно!)
Мне приходилось писать программы (не тексты, а именно программы!) на TeXе. И всякий раз начиная это делать после долгого перерыва, ощущаешь всю неестественность этого занятия. Как сесть за штурвал звездолета пришельцев с Альфы Водолея. Потом начинаешь работать быстрее: мозг переходит на другие рельсы. В какой-то момент вдруг TeXовские хаки кажутся самоочевидными. Естественными. Хочется думать, что в этот момент ты видишь что-то, что видит Кнут. Но у меня это состояние редко, и его надо вызывать специальными методами. Если моя гипотеза верна, то Кнут в таком находится если не всегда, то часто. Это его образ мышления.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-05-29 09:48 pm (UTC)Спасибо за пост
Date: 2007-05-29 09:54 pm (UTC)"понять, как отличается мое мышление от мышления другого " - это мечта моя давняя.
Re: Спасибо за пост
Date: 2007-05-29 10:37 pm (UTC)Время
Date: 2007-05-29 09:59 pm (UTC)А общепринятые концепции сформировались почти случайно, и повернись история каким-то другим боком -- они нам сейчас казались бы тоже дикими.
Re: Время
Date: 2007-05-29 10:31 pm (UTC)Re: Время
Date: 2007-05-29 10:41 pm (UTC)Re: Время
Date: 2007-05-29 10:41 pm (UTC)Re: Время
Date: 2007-05-29 11:00 pm (UTC)Re: Время
Date: 2007-05-30 03:39 am (UTC)... В действительности всё было не так, как на самом деле ...
no subject
Date: 2007-05-29 11:02 pm (UTC)no subject
Date: 2007-05-29 11:31 pm (UTC)Впрочем, бывает и obfuscated TeX code. Вот это написал David Carlisle:
\let~\catcode~`76~`A13~`F1~`j00~`P2jdefA71F~`7113jdefPALLF
PA''FwPA;;FPAZZFLaLPA//71F71iPAHHFLPAzzFenPASSFthP;A$$FevP
A@@FfPARR717273F737271P;ADDFRgniPAWW71FPATTFvePA**FstRsamP
AGGFRruoPAqq71.72.F717271PAYY7172F727171PA??Fi*LmPA&&71jfi
Fjfi71PAVVFjbigskipRPWGAUU71727374 75,76Fjpar71727375Djifx
:76jelse&U76jfiPLAKK7172F71l7271PAXX71FVLnOSeL71SLRyadR@oL
RrhC?yLRurtKFeLPFovPgaTLtReRomL;PABB71 72,73:Fjif.73.jelse
B73:jfiXF71PU71 72,73:PWs;AMM71F71diPAJJFRdriPAQQFRsreLPAI
I71Fo71dPA!!FRgiePBt'el@ lTLqdrYmu.Q.,Ke;vz vzLqpip.Q.,tz;
;Lql.IrsZ.eap,qn.i. i.eLlMaesLdRcna,;!;h htLqm.MRasZ.ilk,%
s$;z zLqs'.ansZ.Ymi,/sx ;LYegseZRyal,@i;@ TLRlogdLrDsW,@;G
LcYlaDLbJsW,SWXJW ree @rzchLhzsW,;WERcesInW qt.'oL.Rtrul;e
doTsW,Wk;Rri@stW aHAHHFndZPpqar.tridgeLinZpe.LtYer.W,:jbye
Попробуйте догадайтесь, что этот код делает (plain TeX)
no subject
Date: 2007-05-30 12:01 am (UTC)"Фауста" Гёте: 767 chars vs 878 chars.no subject
Date: 2007-05-30 01:50 am (UTC)no subject
Date: 2007-05-30 06:19 am (UTC)http://www.cpan.org/misc/japh
no subject
Date: 2007-05-29 11:07 pm (UTC)Продолжая про дилетантов. Ситуация делали-делали-ой-йопть-что-же-получилось возникает сплошь и рядом, достаточно рассмотреть управленческие решения. От управления IT-проектами (включая преподавание программирования, до сих пор базирующееся на героизме) до административно-бюрократических. По извилистому пути панического исправления ошибок исходного проекта (тоже писанного из зауженного опыта, очень для себя) часто нетрудно представить себе стиль мышления участников. Конечно, ТеХ и программирование в частности - замечательный пример почти прямой доставки смысла в голову, но и в ситуации живого языка восстановить цепочку рассуждений иногда возможно.
По поводу марсианскости TeXа --- +1. Но вот вы поражаетесь стилю программирования пакетов к ТеХу, а я скорее удивляюсь силе авторитета и готовности пойти за марсианином. Ведь из достаточно простых примеров ТеХовского кода лезут ушки ООП (я тоже писал и пишу под ТеХ, увы), но где ж волна "а давайте наведем порядок". Скорее идет волна "как здорово, а давайте секретаршу научим"... И наступают люди на те же самые грабли по 33 раза за день, как лемминги. Ведь текущая архитектура (оставим в сторону марсианскость) вынуждает каждого автора текстов чуть-чуть становиться программистом и даже не всякий профессор математики готов продемонстрировать опыт понимания марсианина, куда там секретаршам. Избежать этого можно в подавляющем числе случаев простой сменой архитектуры. И попытки разговора "а давайте переделаем" приводят лишь к замыканию обсуждения по кругу. Что лишь подчеркивает разницу в мышлении и узость круга пользователей: математики не знают программирования (которое не информатика), программисты почти никогда не сталкивались с ТеХом.
no subject
Date: 2007-05-29 11:41 pm (UTC)Это очень сложно. TeX - это одна из самых сложных программ в мире. Её очень трудно изменить. И "сила авторитета" тут не при чём: о недостатках TeXа для программирования все прекрасно знают. Почитайте, например, вот тут: http://www.tug.org/interviews/interview-files/david-kastrup.html. Учтите, что интервьюируемый - один из самых уважаемых TeXпертов на сегодняшний день.
no subject
Date: 2007-05-30 12:54 am (UTC)Что ответить... я далек от героизма. Сложность и практически невозможность впихнуть в один проект все возможные случаи использования производных ТеХа - осознаю. Как и то, что попытка переписать уже существующее очевидно несет провал: в лучшем случае получится более замудренное старое. Однако считаю возможным существование синтаксиса и среды, _упрощающих_ как сам код, так и усилия потребителя. Ведь в этом природа развития, предлагать достаточно простое решение более сложных проблем. Но в любом случае все это в стороне от темы вашего эссе. Скорее мне интересно что вы думаете насчет профессионализма и дилетантства.
no subject
Date: 2007-05-30 02:17 am (UTC)no subject
Date: 2007-05-30 03:16 am (UTC)Подавляющее большинство проектов страдают от недооценки масштаба работы и закладываемых в проект требований (аудитория может расшириться и заложенных возможностей не хватит, как с TeXом). Это достаточно естественно, к сожалению. В этом смысле Кнут тогда поступил как дилетант поступит сейчас. Можно ли это считать негативной оценкой ему? Ответ нет, конечно. Вы начали обсуждение некоторого явления, я привел дихотомию в рамках которой, возможно, лежит обсуждаемый вами случай.
Мне кажется, вы меня приняли за тех, кто требуют обсуждать учение Дарвина наравне с крецианизмом (см. интервью с Зализняком). Отнюдь. Мое уважение к науке глубоко, тем более я сам ей занимаюсь (пытаюсь). (Надеюсь, это чуть сбавит градус патетики)
Идея же проста: более удобный язык дает более удобный инструмент, и им орудовать проще. Смена языка случалась в истории неоднократно, вы вот только что приводили пример Ньютона. В промышленном программировании доминирующий язык программирования сменился несколько раз. То же самое может быть применимо и к ТеХу, разве нет?
no subject
Date: 2007-05-30 05:28 am (UTC)Что касается "современного промышленного программирования", то к ситуации Кнута оно действительно не имеет отношения. Современное промышленное программирование - это способ организовать кучу посредственных программистов, чтобы они написали какой-нибудь код. Оно образовалось благодаря исторической случайности: резкого увеличения потребности в компьютерных людях, за которой не успевали университеты, а теперь самоподдерживается, как клавиатура QWERTY. Задача Кнута была совсем другой: как написать безошибочный код, имея одного гения и некоторое количество очень талантливых аспирантов.
no subject
Date: 2007-05-30 10:27 am (UTC)no subject
Date: 2007-05-30 06:43 am (UTC)По поводу промышленного программирования и смены языка -- во многом это веяния моды а не удобства... Я с ужасом наблюдаю довольно регулярно вычислительные программы на С или Дельфи (и что только народ не сделает, чтоб Фортран не изучать)...
Опять-таки, что есть "промышленное программирование"? По-моему стоит всегда подбирать инструмент (язык) под задачу. Рассуждая о том же Фортране, я с не меньшим ужасом рассматривал встреченные мною библиотеки для написания графики, или, того хуже, графического интерфейса на Фортране... Но это так, лирика.
no subject
Date: 2007-05-30 10:22 am (UTC)Возможность появления вдов и сирот накладывается на проблему постраничного вывода на драйвер (нет глобальной оптимизации разбиения на строки). Результат: нужно сначала потратить время на верстку страниц так 50-100, чтобы упереться в принципиально неразруливаемую проблему из-за вдовы/сироты (любая попытка решения на данной странице создает другую запрещаемую правилами верстки ситуацию), для исправления нужно откатиться назад на много страниц назад и принять другое решение (например, там абзац "втягивали", теперь наоборот).
Выставить бесконечно большие штрафы решение плохое: в окрестности такого штрафа алгоритм разбиения на строки иногда начинает себя вести неадекватно (\infty + \epsilon сравнимо с \infty, но не \epsilon). Имей алгоритм разбиения представление о жестко запретных ситуациях, не было бы проблемы. В данном примере возможно другое решение - отменить локальную (постраничную) оптимизацию разбиения на строки.
В ситуации "текст принесли, правки не надо, только сверстать" вам не нужен итеративный процесс работы "быстро скомпиллировал, посмотрел, исправил, все повторил", идеальным является: прошелся один раз по тексту, расставил разметку где она нужна, поставил машину на счет, через несколько часов выплюнула верстку. Бóльшая часть типографских правил формализуема, а остальные и так с компьютеризацией де-факто не выполняются (например, нередко встречаются книги с "лесенкой"). Так что движение к этому идеалу оправдано и, мне кажется, имеет шанс успеха.
Как продукт и инструмент, ТеХ стоит на одной полке с другими: его используют чтобы решить утилитарную задачу. Справляется - хорошо, нет - увы. Мне кажется недопустимым отказ от критики его как инструмента лишь в уважение к труду создателей. Тут могла бы быть критика меня ("сделай - посмотрим"), но пока налицо пытытка запретить обсуждение в целом. Это странно. Словом, мне кажется вы (и автор журнала) обиделись, хотя тут нет причины.
no subject
Date: 2007-05-30 10:38 am (UTC)С большим интересом прочитал ваши замечания... Собственно ситуацию вдовы-сироты я обычно решаю сверху вниз, иногда добавляя дополнительный отступ после разделов...
Ещё вопросы имеются:
1) Вы можете предложить алгоритмизируемый механизм решения указанных проблем?
2) Увеличение растяжимости/сжимаемости межстрочного клея не помогает вам?
no subject
Date: 2007-05-30 10:55 am (UTC)1. а если у вас разделы встречаются редко? Раз в страниц 50-100?
2. пробел между заголовком и абзацным блоком должен быть унифицирован по всему тексту
3. строчки обязаны иметь фиксированный клей. Хотите сделать пробел - он будет длины \baselineskip. Причина: возьмите старую книгу и посмотрите один листик на просвет: строчки с двух сторон листа сливаются по базовой линии. Тот же графический эффект обязан иметь место для любых двух страниц (вы когда глазами по строке водите, невольно задеваете кусок соседней страницы, графический разнобой заметен).
4. да, алгоритмизируемый механизм возможен. Для проблемы со вдовами-сиротами уже сказан: полумера - отказ от локальной оптимизации, настоящее решение - механизм оптимизации штрафов с исключениями (жесткими ограничениями не в терминах штрафов). Пример когда это нужно - запрет ставить заглавный предлог в конце строчки (бубубубу. А [перенос] граф считал...). Если вам интересно, думаю следует продолжить обсуждение в другом месте.
no subject
Date: 2007-05-30 11:08 am (UTC)2. После предыдущего раздела перед новым заголовком
3. Ещё раз показывает, сколь далёк я от серьёзного издательства :)
4. Насколько алгоритм штрафов глубоко запрятан в код? Вопрос в том, надо форкать проект или просто дописывать алгоритм?
no subject
Date: 2007-05-30 03:31 pm (UTC)no subject
Date: 2007-05-31 05:30 am (UTC)no subject
Date: 2007-05-30 03:54 pm (UTC)no subject
Date: 2007-05-30 04:10 pm (UTC)На самом деле корень Ваших проблем - пункт 3. Это знаменитый typesetting to the grid. Когда в тексте много выключных формул, typesetting to the grid не годится - возможно, поэтому Кнут его и не сделал. Но в традиционной типографии он очень нужен. В принципе typesetting to the grid в TeXе возможно: в недавнем TUGboat была статья на эту тему:
@Article{Bazargan07:VertStretch, author = {Kaveh Bazargan and CV Radhakrishnan}, title = {Removing Vertical Stretch---Mimicking Traditional Typesetting with {\TeX}}, journal = {TUGboat}, year = 2007, volume = 28, number = 1, pages = {133--136}, note = {\url{https://www.tug.org/members/TUGboat/tb28-1/tb88bazargan.pdf}} }К сожалению, в онлайновом доступе эти статьи появляются для не-членов TUG только через год после публикации; если у Вас нет доступа к журналу, напишите, что-нибудь придумаем.Но из-за того, что разбиение на строки и разбиение на страницы в TeXе расцеплены, возникают проблемы вдов и сироt. Хитрый Кава о них ничего не пишет.
no subject
Date: 2007-05-30 03:37 pm (UTC)no subject
Date: 2007-05-30 03:35 pm (UTC)Я очень прошу прощения, если Вам показалось, что я обиделся, или если Вам покажется после этого ответа - но Вы, как мне представляется, не совсем понимаете, что TeX может, а что нет.
Описанная Вами проблема есть, но она НЕ связана с алгоритмом разбиения на строки. TeX прекрасно понимает, что такое "бесконечный штраф". Если Ваши результаты "странные", значит либо Вы неправильно задали штрафы (не в соответствии с Вашими интуитивными представлениямия о красоте) или же у Вас неверно задана таблица переносов.
Проблема в другом. Разбивая на строчки, TeX держит в памяти весь абзац - в этом смысле алгоритм оптимален и глобален. Но разбивая на страницы, TeX держит в памяти только одну страницу. Этот алгоритм локален. Это крайне неудачное решение. Понятно, почему оно было принято: удержать в памяти большую книгу невозможно и на современных компьютерах, а в 80-е годы тем более. Но в результате получается, что невозможно "слегка ухудшить" разбиение на страницы в районе стр. 5, с тем, чтобы сильно улучшить его на стр. 329. К моменту верстки стр. 329 страница номер 5 уже "shipped out". David Kastrup столкнулся с вызванными этим трудностями, когда писал bigfoot. В принципе паллиатив состоит в том, чтобы делать несколько проходов, обрабатывая промежуточные файлы вне TeXа; но это ужасно громоздкое решение.
Ещё одна неудачная оптимизация связана с тем, что алгоритмы разбиения на строки и страницы делаются раздельно. Поэтому со вдовами и сиротами TeX борется, изменяя расстояния между строками, а не изменяя разбивку на строки. Это непригодно для традиционного typesetting to the grid.
Я согласен с тем, что написал в своё время Kastrup, и что я цитировал выше: TeX был написан со вполне определенной целью: набрать книгу Кнута. Мы его используем не по назначению. Если бы у нас была система получше, мы бы её использовали. Увы, её пока нет. Хотя последние результаты ребят из команды eTeXа дают надежду: они успешно исправили несколько явных недостатков TeXа, и возможно, смогут создать новую систему. Просто задача чудовищно сложна.
no subject
Date: 2007-05-30 04:34 pm (UTC)Я разве говорил, что ТеХ не знает бесконечных штрафов? Я лишь говорил что при использовании бесконечного штрафа алгоритм оптимизации штрафов иногда перестает вести себя разумно. Под рукой к сожалению нет готовых примеров, но в моей практике (небольшой) они были. Таблица переносов стандартная для релиза типа MikTeX 2.4, стандартные штрафы задавал в пределах разумного, ну а статистическое исследование входного текста для выбора оптимальных штрафов, размера страницы , кегля и всех-всех значений мелких параметров, доставляющих минимум отклонений от идеала верстки при компилляции с заданными требованиями к макету - моя мечта. Если вы знаете пакет, реализующий такую многофакторную оптимизацию - был бы счастлив. А пока я бы оставил осуждать чью-либо интуицию, она единственный рулевой.
Говоря об алгоритме разбиения на строки, под глобальным я имел ввиду отказ от постраничного вывода на драйвер до конца прохода по всему коду исходника. Сначала разбить на строки, потом понять: возможно ли текущий список строк безконфликтно разбить на страницы? Сейчас это проблема пользователя и я не понимаю, почему я как пользователь должен тратить человекодни на выполнение легко автоматизируемой операции, на исправление которой можно потратить порядка человекомесяц (это того стоит, ибо каждый рано или поздно с проблемой сталкивается и в сумме теряется величина на порядки бОльшая).
Да, я знаю что в 80-х была проблема памяти, и даже в начале 90-х. Более того, она никуда не делась для тех кто занимается символьными вычислениями (там есть экспоненциальный рост данных). Но я надеюсь, что современной персоналке хватит памяти для глобальной оптимизации одного документа страниц в 500.
Очевидно, что если проблему можно решить на уровне ядра, то ее надо решать там. Иначе придется вместо нормального языка высокого уровня использовать марсианский интерпретируемый код. Вместо нескольких дней (ну, месяц) на добавление в ядре, кто-то будет тратить несколько месяцев на марсианский код для реализации многопроходой компилляции. Что лучше? Ответ очевиден. Надеюсь, команда eTeXa имеет ввиду еще и эту проблему.
У меня нет доступа к TUG. Можно ли получить доступ к статье? Хотя я вряд ли узнаю что-то принципиально новое - я уже верстал несколько книг в этом режиме (typesetting to the grid) и, очевидно, изобрел для этого свой велосипед. Интересно узнать как проблему решали другие.
Есть ряд других проблем верстки, которые не ограничиваются лишь версткой в сетке и разбиением на строки (автоматическая игра с кернингом, подбор оптимальных параметров верстки, автоматическое удовлетворение ряду типографских требований и т.п). Если есть где это обсудить предметнее, давайте обменяемся координатами.
no subject
Date: 2007-05-30 08:47 pm (UTC)2. Возможно, диссертация того же Hàn Thế Thành ответит на вопросы по поводу игр с кернингом и других микротипографских расширений. Это, кстати, очень интересная работа. Она есть в открытом доступе вот тут: http://www.tug.org/TUGboat/Articles/tb21-4/tb69thanh.pdf
3. Бросьте мне Ваш e-mail комментарием к самой первой записи в моём дневнике (там комментарии скрыты). Пришлю то, что у меня есть.
no subject
Date: 2007-05-30 02:28 am (UTC)Э, это как? По моему, почти-что аксиоматическим определением успешного программного продукта является "такой продукт, о котором через десятилетия ещё помнят и вкладывают ресурсы в его развитие".
Возьмем любой успешный продукт - ну хотя бы Microsoft Office. Сколько лет назад появились Word, Excel и так далее? Или Google - скоро исполнится десять лет с тех пор как я впервые воспользовался его поисковой системой.
Может быть нужно уложиться в месяцы от задумки до первого (beta) релиза. Но с первым релизом жизнь проекта только начинается.
Видимо, в том и состоит гений Кнута, что он для достаточно нетривиальной области сумел разработать формализацию, которая лучше ОО. ОО - слишком общая формализация, которая может хреновенько всё, но ничего - хорошо.
Как только в какой-то конкретной области появляется гений, он разрабатывает там свою формализацию, которая оказывается лучше. Вот Кодд придумал реляционные БД. И Codasil умер. Все попытки вендоров втащить в базы данных объекты обратно заканчиваются пшиком. Народ всё равно пользуется SQL.
no subject
Date: 2007-05-30 03:09 am (UTC)Конечно я имел ввиду идею из "мифического человеко-месяца", когда утверждается что в среднем время разработки успешного проекта - три месяца (по памяти повторяю). Речь о разработке, а не сроке эксплуатации. Так что давайте я не буду отвечать на остальное, чтобы не начиналось обсуждение третьестепенных деталей (тем более что по большинству из вами сказанного остается лишь поставить "+1").
no subject
Date: 2007-05-30 03:37 am (UTC)Причем в процессе жизни продукт может измениться до неузнаваемости. Вон, вспомним Microsoft Word 5.0 - если считать по номерам версий (нынче у нас 12), то половина жизненного цикла была уже позади. Но то была программа под DOS, и что общего было с нынешним Word сказать трудно. Даже разворачивающихся меню в CUA-стиле ещё не было, они появились в версии 5.5. Не было ни unicode, ни OLE, ни XML, ни тулбаров. А продукт-то тот же самый.
Да и Бэкус, пожалуй, в Fortran 2003 свое детище бы не узнал.
no subject
Date: 2007-05-30 03:37 am (UTC)Прошу прощения, я не совсем в теме и даже не знаю что такое Codasil, но объекты в СУБД прекрасно живут, например, в InterSystems Cache. FYI онли, без претензий.
no subject
Date: 2007-05-30 07:58 am (UTC)Весь дизайн, вся структуризация программ — структурное программирование, ООП, ФП, application frameworks — направлены именно на преодоление этого барьера. На то, чтобы одновременно человек работал (программист читал/писал код) с участием только 5-7 объектов на каждом уровне абстракции.
Допускаю, что Кнуту это не нужно.
У Вернера Винжда в "Глубине в небе" программисты, которым искусственно "сфокусировали" мозг исключительно на работе, писали программы, нечитабельные для нормального человека. Думаю, именно потому, что не заботились инкапсуляцией, low-coupling-high-cohencion и т.п., а стремились прямо у функциональности. Или у них предел восприятия стоял не на 7 объектах, а на 700.
no subject
Date: 2007-05-30 09:25 am (UTC)no subject
Date: 2007-05-31 12:38 pm (UTC)no subject
Date: 2007-06-09 03:02 pm (UTC)Та же проблема с ифами, если я её правильно понял, объясняется совершенно просто и имеет отчётливые технические причины. Когда интерпретатор встречает слово \if, он на самом деле передаёт управление на кусок кода, описанный в определении слова \if, который читает с входного потока условие, исполняет его, а дальше в зависимости от результата исполняет или пропускает все последующие слова до появления слова \fi. Сам интерпретатор ничего о семантике слова \if не знает. Такой подход позволяет очень быстро и просто оную семантику добавить, но значительно усложняет код \if-а, если хочется корректно парсить вложенные ифы и другие семантические конструкции, так что Кнут, по всей видимости, посчитал, что оно того не стоит. К тому же, не знаю как в ТеХе, а в форте ещё одна проблема появляется: ифоподобные конструкции должны работать по разному в состоянии интерпретации и компиляции (определении нового макроса, то есть), так что сложность добавления нетривиального поведения удваивается.
Тем не менее, если понимать принцип работы всей этой системы, то ничего удивительного в таких вот забавных особенностях нет, в некотором смысле они как раз естественны, в отличие от более сложного поведения.
no subject
Date: 2007-06-10 06:08 am (UTC)Knuth - роман "Приключение"
Date: 2008-04-29 06:08 pm (UTC)Я на него наткнулся потому что тема Кнута на днях пролетела по всему ЖЖ - кто-то где-то выволок интервью, и понеслось.
Один интересный комментарий к "понять как он думает" - рассмотреть идею "литературного программирования"
http://community.livejournal.com/ru_perl/249441.html
.. а потом прочитать литературный труд Кнута, "Приключение" ("Adventure") - вы удивитесь, но это действительно рассказ, и он действительно описывает приключения:
www.literateprogramming.com/adventure.pdf
Не поленитесь пролистать хотя бы пару страниц ;))
Re: Knuth - роман "Приключение"
Date: 2008-04-29 10:39 pm (UTC)