Дискуссии об осмысленности XML

>> кстати на прекрасном и мегауниверсальном LISPе вообще что-нибудь кроме динозаврика emacs написано?

> http://en.wikipedia.org/wiki/Common_Lisp#Applications И это только Common Lisp.

ТАК МАЛО !!!!!!!!!!!!
е пр ст, о чем мы говорим ?

> С другой стороны неряшливость в оформлении поколением M$ Word неряшливостью не считается.

docbook позволяет чётко структурировать сам текст. Это вам не дурацкие рюшечки MSWord/LaTeX. :)

> То есть вещь в себе - как суслик, которого не видно но он есть. Только не понятно нафига он нужен.

Я писал для кого он нужен: локализаторов и разработчиков.

> Сильно фанатики "эмуляторов виндовс" достали.

Просто в этом убогом Tk невозможно работать. Некрасиво и неудобно. Фанатичность - она только у любителей LaTeX, Lisp и Tk осталась. :)

> Я не вижу чему это протеворечит в LaTeX.

Может и не противоречит. Ты предлагаешь использовать один инструмент для подготовки изданий для всех процессов и для перевода в том числе. Можно все и в vi набирать. Но usability и эффективность работы?

> Есть команда \include, есть Cut/Paste - это же текст. \include не подходит, потому что на этапе авторинга документ может подвергнуться переработке: поменяется какое-то слово, оставят одно предложение из всего абзаца и т.д.

То есть, когда переводчик возмется за работу, у него уже будет абсолютно новый документ. И translation memory посвященная этой теме (не важно от предыдущей версии, или от другого документа по этому же продукту). Он/она загружает в Translator workbench, и напротив каждого фрагмента видит, перевод если он доступен и оценку его корректности в процентах.

Твой вариант, если я себе его правильно представляю.

Берем документ, который надо первести, такой же документ по предыдущей версии с переводом. Для каждого фрагмента ищем такой же в предыдущей версии (причем как найти фрагмент совпадение которого не 100%, мне не совсем очевидно, в ПО при этом иногда зашивают лингвистические алгоритмы), потом находим его соответствие в переводе и copy/paste? Шутишь?

Полное руководство по Autodesk Architectiral Desktop 2005 занимает 3000 с хером страниц (и это не единственное что идет). Думаю что разница в скорости работы переводчиков будет отличаться в разы.

Когда есть документы над которыми работают 10-15 авторов, несколько редакторов и которые переводятся на 8-10 языков, я думаю у LaTeX-пользователей будут пробемы с производительностью.

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

Близко к этому. Здесь начинается интеграция. Есть хорошие инструменты для authoring'а, для перевода, для организации XML репозиториев, для контроля workflow. Как правило все расширяемые, то есть пишешь плагины, и из редкатора можешь браузить репозиторий документов, check in/out, искать фрагменты на которые ссылаться и т.д.

Достичь предела, ты прав, еще не получилось, пользователи все еще что-то хотят и хотят :), но общий процесс ИМХО выглядит проще в разы.

>>>Фанатичность - она только у любителей LaTeX, Lisp и Tk осталась. :)

Ага, это любители Tk на ЛОРе регулярно holy wars устраивают Gnome vs. KDE.

>> Я как-то видел результат перевода docbook в твёрдую копию. Вроде и люди знали что делали. Книжечка шла с дистрибутивом - за неё были деньги плачены. Если то что там было красивый и удобный справочник, то я папа римский.

>Я не знаю о какой книге ты говоришь, но я думаю, что там за основу были взяты Walsh'евские stylesheets, в которых немного подправили стили. На самом деле там гордится действительно нечем, но там получение коммерческого look'n'feel и не было самоцелью, скорее показать возможности технологии.

Это был хелп, который шёл с одним из дистрибутивов Alt Linux Master. Я был подписан на список расски тех, кто этим занимался и видел что ребята вовсе не бездельничали: hабота просто кипела - народ постоянно менял структуру и улучшал трансляторы. Но от того что вышло просто блевать тянуло. Ну нельзя же так над книгой издеваться. a2ps лучше результат бы дал.

>Ладно (да простит меня мой NDA), если у тебя будет возможность посмотри книги к Autodesk Architectural Desktop 2005 (или другие продукты 2005 года и позже), и скажи свое мнение, нормально оно выглядит или нет.

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

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

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

>В info уже можно показывать скриншоты?

Скриншоты - это для слабоумных. Пейсателей которые суют скриншоты в доки надо истреблять в первом поколении, потом вы уже с ними не справитесь.

>> Так что смысла в такой валидации особо не видно.

> Ну как тебе сказать. Помнишь твой пример о том, что люди не настолько организованны чтобы проставлять ID-шки. Так вот: редактор валидирующий документ при редактировании, не даст тебе создать невалидный документ, если ты даже поломаешь что-то в vi/notepad в обход спецсредств, то XML БД не даст тебе поместить невалидный документ в репозиторий, гарантируя валидность документа на следующем шаге обработки. То есть, смысл в ней все-таки есть.

Правильность структуры гарантируется безпроблемной трансляцией документа. Написать Makefile, который по make release собирает документ и если документ собирается, то отсылает в cvs с соответствующим тегом.Информация о новой версии рассылается по списку рассылки. Просто вариант. Так что это можно делать и другими средствами.

> Другой дело ты прав в том, что структура может быть валидной, а данные внутри тегов corrupted. Вопрос: а уже есть silver bullet? Текстовые файлы и архивы уже защищены от повреждений? Контрольные суммы/дайджесты еще никто не отменял и для XML файлов, в общем-то. Но это уже вопрос протокола, ИМХО.

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

>>> А почему вся документация по KDE в docbook. Да и для остальных серьёзных проектов - также. Где же противопоказания? И где лекарство? :)

>> Мазохисты? Не разобрались в плюсах info и поэтому не поглядели в сторону более приемлимых аналогов? Откуда я знаю какая моча ударила в голову тем, кто принял такое идиотское решение?

>В info уже можно показывать скриншоты?

В man тоже нельзя. Это значит, что у этих форматов нет плюсов. IMHO уж лучше документация была бы в info без скриншортов чем то, что сейчас.

В troff, кстати тоже нет ни формул, ни картинок. Надо объяснять как эта проблема обходится? Я не агетирую за troff - просто указываю, что могут быть более другие решения.

>Ну не знаю, мне за это заплатили, а как ты это называешь это твое личное дело.

ты не обижайся, но (имхо) - это *действительно* очень непродуктивная трата времени :) Видимо, разработчики "коммерческих сайтов", о которых ты говоришь, не в курсе что получить Accept-Language на *порядки* проще, чем городить весь это огород с xml....

>Если я нахожусь в интернет-кафе во Франции, я от этого не начинаю читать по-французки.

Мало того, в этом случае и браузер вряд ли будет _писать_ по-русски... ))

>Конфигурацию пишет пользователь, а не я, ему для этого web GUI скоро будет дан.

Ну вот и поговорили...)) "сайт пишет пользователь, ему для этого web GUI скоро будет дан" ))) [сцалсо падстулом]

>но есть места когда это весьма полезно

ну так и что это за места??? (приминительно к веб)

Испортилось форматирование

\usepackage{parallel} 
... 
\begin{Parallel}{<left-width>}{<right-width} 
 \ParallelLText{left-text} 
 \ParallelRText{right-text} 
 \ParallelPar 
... 
\end{Parallel}

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

Нет, я имел в виду книги, которые идут в коробке с самим продуктом. Тебе нужны не книжные магазины, а там где софт продают :) Но думаю тебе коробку не откроют :)

> Я не спорю, что при серёзных вложениях и желании можно получить качественную печатную продукцию.

Согласен с тобой, что можно достичь маньшими затратами. Но тут масштаб немного не тот. Цель - не получение качественной печатной продукции. А получение качественного процесса создания документации (не только печатной). И повторюсь, без XML технологий, ИМХО, трудозатраты по построению такого процесса были бы выше в разы.

>>>Цель - не получение качественной печатной продукции. А получение качественного процесса создания документации (не только печатной).

Это прекрасно! И должно занять достойное место в lorquotes. Не об этом ли на протяжении всей дискуссии твердил Eugueni? Для зумлеров результат не важен - главное сам процесс!

> Согласен с тобой, что можно достичь маньшими затратами. Но тут масштаб немного не тот. Цель - не получение качественной печатной продукции. А получение качественного процесса создания документации (не только печатной). И повторюсь, без XML технологий, ИМХО, трудозатраты по построению такого процесса были бы выше в разы.

Тогда так и надо говорить xml: нужен для замены закрытых бинарных форматов и для очень больших и толстых корпораций - правда почему я так и не понял.

3000 это действительно не мало. Я только не вижу проблем которые могут возникнуть с эффективностью у LaTeX с книгами такого объёма. Примером, правда TeX-книг является "Исскуство программирование" Кнута - по-моему там за тысячу в каждом из томов и делалось это довольно таки давно, когда процессоры были не настолько быстрыми, а память была не безграничной.

В большинстве своём описания к программным продуктам, особенно таким жирным как Autocad и компания особой сложностью не страдают. Я не вижу технический препятствий организовать то же что мне было описано, но на основе LaTeX. В этом случае из emacs/vi выходить бы вообще не пришлось :)

> Ага, это любители Tk на ЛОРе регулярно holy wars устраивают Gnome vs. KDE.

Нет, это у нас такие потешные бои, когда любителей Tk нет на горизонте. :)

> Скриншоты - это для слабоумных.

Саныч, это для гавриков, которые нас кормят. :)

>> Скриншоты - это для слабоумных.

> Саныч, это для гавриков, которые нас кормят. :)

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

>>>Это у нас такие потешные бои

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

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

кстати, флеймы KDE vs GNOME для меня были самыми безболезненными. Score мне резали и режут за другое

> Видимо, разработчики "коммерческих сайтов", о которых ты говоришь, не в курсе что получить Accept-Language на *порядки* проще, чем городить весь это огород с xml....

Расскажи это разработчикам (навскидку):

- http://www.palm.com - http://www.logitech.com

только cookies почисти если ты их посещал когда-то. Зачем там это?

> Мало того, в этом случае и браузер вряд ли будет _писать_ по-русски... ))

Не утрируй. usability borwser'ов таково, что по внешнему виду любой пользователь найдет поле ввода адреса (если какой-то предыдущий шутник-посетитель не спрятал его, тогда будут проблемы), натопчет там необходимый URL, и нажем enter чтобы попасть на нужную страницу. По иконкам он так же догадается где Stop, а где Reload. Все.

А на каждом из десяти сайтов, которые мне надо посетить, искать нужный мне язык (заметь выбор региона/языка все равно нужен, хотя в твоем варианте получается я вообще не могу перейти на другой язык, если повезет, я смогу в середине URL'а поправить fr/fr на en/us :)), потому что программисты вроде тебя сделали auto detection, это *действительно* non-usable.

> "сайт пишет пользователь, ему для этого web GUI скоро будет дан" ))) [сцалсо падстулом]

Ладно возможно я не правильно выразился, действительно есть два типа пользователей. Один это автор сайта, другие - это посетители сайта.

Такой компонент один на сайте. Ты, как автор сайта, его раз сконфигурировал и все. Есть (точнее, будет) онлайн сервис, где ты, как автор сайта, с помощью web GUI создаешь конфигурацию (регионов/языков, которые поддерживает твой сайт). Создал конфигурацию - скачал архив, в котором есть JS/HTML/PNG необходимые для отображения такой карты. По сути это компонент. Задеплоил к себе на сайт. Посетители твоего сайта, могут им пользоваться для выбора языка. Ты решил добавить поддерживать еще один язык - пришел поменял конфигурацию, скачал новый архив (с новыми картинками, JS, HTML), опять задеплоил, а не пришел к своему дизайнеру, и попросил его нарисовать еще картинки пары регионов, подправить JS и HTML.

Так лучше выглядит? [а недержание надо лечить :)]

> ну так и что это за места??? (приминительно к веб)

Я же говорю, я не есть профессиональный web developer (ногами не пинать), но чем плохо следующее: - когда у меня есть какой-то информационный сайт, например новостная лента (RSS пока не трогаем). - я хочу чтобы она была доступна: с ПК, с КПК, с WAP-клиентов. - храню контент в XML (пусть тот же докбук, для news maker'ов, есть отличные инструменты). - при отдаче страницы использую 3 XSLT, которые генерят два разных HTML (вариант для КПК полегче) и WML.

>> Я как-то видел результат перевода docbook в твёрдую копию. Вроде и люди знали что делали. Книжечка шла с дистрибутивом - за неё были деньги плачены. Если то что там было красивый и удобный справочник, то я папа римский.

> Вы путаете DocBook/XML как исходный формат документации c результатом работы PassiveTeX. Довольно неразумно.

А почему я не могу оценивать качество технологий по результату? У меня тогда чуть икота не случилось когда я увидел ту книгу. Как на счёт морального ущерба?

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

Тааакк... По наболевшеву значить проехались, за живое задели, на святое покусились! (На Tk :) И мстя наша будет страшна... :))

> Я не вижу технический препятствий организовать то же что мне было описано, но на основе LaTeX. В этом случае из emacs/vi выходить бы вообще не пришлось :)

Да можно-можно. Вопрос: за сколько времени ты получишь результат?

Что-то у Кнута (при всем к нему уважении) между изданиями общей сложностью в 3000 страниц, сколько? лет 20 прошло. Я понимаю, что он не только этим занимался, но он и не переводил сам.

А у Autodesk, между продуктами допустим два года, причем цикл разработки документации, от момента когда можно начать документировать до выхода около полугода. При этом нужно успеть написать и отредактировать и перевести и переводы отредактировать. И продуктов десятка два наверное. И что делать?

ИМХО, качественный процесс подразумевает качественные результаты, если у тебя не так, то это не отбирает права у других концентрироваться на процессе.

Качествення печатная продукция, это один из десятка результатов хорошего процесса.

> А почему я не могу оценивать качество технологий по результату?

Потому что, в данном случае результат это не есть олицетворение технологии, а всего не самое удачное ее применение/реализация.

Из автомобиля LADA Kalina, отнюдь не следует, что автомобилестроение как технология - отстой. У кого-то тоже случается икота. Кто-то тоже просит возместить моральный ущерб. А кто-то их использует.

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

Покажите как Lisp справится с: >2. Гипертекстовой документацией

Вот так справится, например (на правах примера): http://www-sop.inria.fr/mimosa/fp/Scribe/

>> В info уже можно показывать скриншоты?

> Скриншоты - это для слабоумных. Пейсателей которые суют скриншоты в доки надо истреблять в первом поколении, потом вы уже с ними не справитесь.

Сомневаюсь, что при личной встрече Вы решитесь сказать мне это в лицо :)

Кстати, схемы и графики тоже вырежем?

> В troff, кстати тоже нет ни формул, ни картинок. Надо объяснять как эта проблема обходится?

Да-да, расскажите, как материал, требующий иллюстрирования, обходится без такового.

> В большинстве своём описания к программным продуктам, особенно таким жирным как Autocad и компания особой сложностью не страдают.

Сложностью чего?

> Я не вижу технический препятствий организовать то же что мне было описано, но на основе LaTeX. В этом случае из emacs/vi выходить бы вообще не пришлось :)

Однако это до сих пор не сделали

>> Вы путаете DocBook/XML как исходный формат документации c результатом работы PassiveTeX. Довольно неразумно.

> А почему я не могу оценивать качество технологий по результату?

Ещё раз для невнимательных: качество препроцессора никаким боком к исходному формату не относится. Сделайте над собой усилие: разделите для себя эти понятия раз и навсегда.

> По наболевшеву значить проехались, за живое задели, на святое покусились! (На Tk :)

Вы же на Qt+Python собрались векторный редактор делать!?

> Вот так справится, например (на правах примера): http://www-sop.inria.fr/mimosa/fp/Scribe/

Мама! Оглавления нет, его функции выполняет глоссарий. Спасибо, лучше сразу повешаться. :)

>> Вот так справится, например (на правах примера): >>http://www-sop.inria.fr/mimosa/fp/Scribe/

>Мама! Оглавления нет, его функции выполняет глоссарий. Спасибо, лучше >сразу повешаться. :)

мдя: Current version is 1.1a, released Dec 2002

>мдя: Current version is 1.1a, released Dec 2002

Да причем тут version? И давность? Вам же интересна была принципиальная возможность процесса? Я показал. Если там есть какие-то недостатки, то это восполняется уже потом.

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

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

А это чего? Или я что-то не так понял?

http://www-sop.inria.fr/mimosa/fp/Scribe/manuals/user/user-3.html#container1136

Желающим взгянуть на то как в Сommon Lisp можно делать документы.

http://www.fractalconcept.com/ex.pdf

>> Я не вижу технический препятствий организовать то же что мне было описано, но на основе LaTeX. В этом случае из emacs/vi выходить бы вообще не пришлось :)

>Да можно-можно. Вопрос: за сколько времени ты получишь результат?

У меня сильное подозрение, что за сильно меньшее число человеко-лет чем в случае описанного вами продукта. Хотя бы в силу того, что твёрдая копия и pdf из LaTeX фактически по определению имеет хорошее качество. Проблемный кусок - трансляция в html - здесь нужны вложения, но в силу того что уже есть и такие инструменты (в том числе и коммерческие) подстроиться под один можно достаточно быстро.

> Что-то у Кнута (при всем к нему уважении) между изданиями общей сложностью в 3000 страниц, сколько? лет 20 прошло. Я понимаю, что он не только этим занимался, но он и не переводил сам.

Сильная задержка случилась между вторым и третим (лет восемь) в силу того что он сильно отвлёкся в том числе на TeX - его не устраивало качество полиграфии. Но уверяю Вас, что время затраченное на вёрстку книги это едва ли проценты от времени, которое ушло на написание в силу выбранного инструмента. Хорошую книгу написать сложно. Ну и четвёртый том он до сих поишет, но вовсе не в силу того, что ему вёрстка мешает.

>А у Autodesk, между продуктами допустим два года, причем цикл разработки документации, от момента когда можно начать документировать до выхода около полугода. При этом нужно успеть написать и отредактировать и перевести и переводы отредактировать. И продуктов десятка два наверное. И что делать?

Что вы хотите от меня услышать? Я вам отвечу: писать в LaTeX формате, а стиливые файлы по ходу доработать можно.

Sun-ch, у людей не та проблематика. Для них главное - как впрячь несколько сотен обезьянок в одну телегу, и при этом сделать так, чтобы обезьянки не разбежались и не отвлекались на близлежащие помойки.

Тебе виднее, конечно. Мне запомнился один из эпизодов, когда удалили твое сообщение - про wine, который победил среди эмуляторы виндовс, потому что KDE из этой категории исключили.

>> В troff, кстати тоже нет ни формул, ни картинок. Надо объяснять как эта проблема обходится?

>Да-да, расскажите, как материал, требующий иллюстрирования, обходится без такового.

Рекомендую: Керниган, Пайк <<Программное окружение UNIX>>

А так man pic, man eqn, man tbl

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

>>> Вы путаете DocBook/XML как исходный формат документации c результатом работы PassiveTeX. Довольно неразумно.

>> А почему я не могу оценивать качество технологий по результату?

>Ещё раз для невнимательных: качество препроцессора никаким боком к исходному формату не относится. Сделайте над собой усилие: разделите для себя эти понятия раз и навсегда.

С какой стати? Мне ведь интересен именно результат, а не процесс. Более того мне интересен результат сейчас, а не когда наступит царствие небесное.

> У меня сильное подозрение, что за сильно меньшее число человеко-лет чем в случае описанного вами продукта.

Категорически не понимаю за счет чего?

За счет времени создания продукта? Дык и на TeX/LaTeX ушло немало времени. Я бы сказал, что добавлять время создания продукта ко времени создания документации неправильно, так как продукт создается один раз, а потом используется, более того, я думаю что в крупных компаниях он окупается за пару лет.

А если рассматривать сичтое время разработки документации, то допустим скорости авторинга будут сопоставимы (по сути одинаковы). А вот со скоростью перевода мне уже не все так очевидно.

> Что вы хотите от меня услышать? Как в TeX-процесс интегрировать средства современного автоматизированного перевода (с базой знаний и пр.).

>Желающим взгянуть на то как в Сommon Lisp можно делать документы.

>http://www.fractalconcept.com/ex.pdf

Знак минус в формуле слишком короткий - так что Сommon Lisp пока учиться и учиться :)

> Конечно, а зачем мне в доке на апач или сендмейл картинки и графики?

И что, теперь всех причешем под Вас? :)

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

Поговорите абстрактно с автором вот этого топика: http://audacityteam.org/forum/thread/1353

:-)

>> У меня сильное подозрение, что за сильно меньшее число человеко-лет чем в случае описанного вами продукта.

>Категорически не понимаю за счет чего?

За счёт использования уже готовой и "взрослой" технологии.

Даже Брукс в конце концов сказал, что пуля таки есть :) - надо использовать то, что уже работает.

> За счет времени создания продукта? Дык и на TeX/LaTeX ушло немало времени. Я бы сказал, что добавлять время создания продукта ко времени создания документации неправильно, так как продукт создается один раз, а потом используется, более того, я думаю что в крупных компаниях он окупается за пару лет.

Чтобы достичь качества TeX/LaTeX на разработку продукта с нуля придётся потратить времени не меньше и ключевой человек должен быть уровня Кнута - чудес не бывает.

>> Что вы хотите от меня услышать?

> Как в TeX-процесс интегрировать средства современного автоматизированного перевода (с базой знаний и пр.).

Я не понимаю что значит слово "современного" - редактировать текст в текстовом редакторе, это современно? Я не понимаю почему доступ к "базе знаний" не встроить, например, в emacs - благо инструменты для этого имеются в избытке и примеров предостаточно.

> С какой стати? Мне ведь интересен именно результат, а не процесс. Более того мне интересен результат сейчас, а не когда наступит царствие небесное.

А интеграция LaTeX в современную среду подготовки документации, хоть эксплуатационной, хоть проектной -- это не "когда наступит царствие небесное"? :)

Есть 2 пути: писать от юзера/гуи (а потом придумать как там внутри зафиксить или увеличить скорость - мёртвый подход - исправить программы очень трудно) либо писать "снизу", чтобы работало максимально быстро, просто и следователно надёжно и расширяемо (пробегала статья о различии юних и виндовс подходов).
Я согласен что многое разрабатываемое от-юзера - будет внешне смотреться лучше и может богаче какие-то годы (на то они и маркетоиды). Но это - временно. Напоминает разработку массового усилителя для консюмера - чтобы в полочку влез (трансисторы прижмём, поставим чуть поменьше, на радиаторах сэкономим. То что плата будет сохнуть, греться - всё равно через 3 года поменяют и даже хорошо).
И - когда разрабативают/покупают профессиональную аппаратуру не говоря о военной. Главное - прочность и запас.
Всё-таки программистский труд очень дёшев, так как позволяет бесконечно копировать раз созданное.
Поэтому если технологии правилные и максимално эффективные - то рано или поздно итерациями юзабилити подтянут. Главное чтобы было надёжно. И максимално эффективно (не только потому что программы становятся медленнее быстрее чем компутеры становятся быстрее, а потому что мы делаем базис на который надо опираться и идти дальше). А неэффективные родившиеся уродами технологии - природа отсеет. Вопрос - когда. Хотя бы потому что они _не_красивы_ (говорил же Ландау о красоте формул;)

Anode

> А это чего? Или я что-то не так понял?

Ага, найти в глоссарии "Table of contents" и перейти по нему? Вообще-то содержание в начале даётся. Но у этих лисперов всё через задницу. :)

> Желающим взгянуть на то как в Сommon Lisp можно делать документы. http://www.fractalconcept.com/ex.pdf

Дальше мультиков дело не идёт? :)