[docs] docs status

[Vadim Vinichenko]

Alex Ott пишет:
 >> On Wed, Nov 13, 2002 at 08:51:20AM +0200, Michael Shigorin wrote:
 >>
 >>> Ну, industry standard, в своем роде.  Или кто-то будет про ruby
 >>> писать _сейчас_? :-)
 >>
 >> Юра Лейкинд переводит документацию по Ruby _сейчас_. Плюс мы
 >> работаем над учебным курсом по этому языку. Наверное, какие-то
 >> моменты можно из него взять. К тому же, в известном учебнике по
 >> информатике оный тоже используется и описан, учебник под GNU GFDL.
 >
 > Это было бы хорошо - что-нибудь не слищком длинное
 >
 >
 >> Говорить о Python как industry standard я бы не стал.
 >
 > Это да - у всех разные industry standard, вот ява - это точно
 > стандарт для многих приложений, или перл....

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

По языкам я бы считал разумным иметь одну обзорную статью, кратко 
характеризующую языки (по крайней мере, основные), входящие в 
дистрибутив, и _круг задач_, для которых применим (оптимален) каждый из 
них. По-моему, делать это нужно. Много ли счастливых обладателей Мастера 
знают, что такое Ocaml и для чего он может быть полезен? Пара абзацев на 
язык, возможно, для каждого языка - отсылки на дальнейшую информацию. В 
идеале - еще соображения о возможных вариантах "сцепления" нескольких 
языков в рамках проектов. В сравнения, особенно для языков с близкими 
нишами, по возможности, не вдаваться.

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

Все остальные разделы - ориентироваться не на языки, а инструменты 
разработчика, входящие в дистрибутив. Понятно, что граница между языками 
и инструментами условна (язык, строго говоря, - тоже инструмент), но в 
качестве ориентира использоваться может. Например, не введение в Java, а 
текст про использование пакетов для Emacs, которые могут использоваться 
для разработки на Java, с акцентом на совместное использование 
нескольких пакетов, и эффективные приемы работы (а не просто 
перечисление функций по пакетам). Не C++, а KDevelop какой-нибудь, или 
Анюта, или кто там еще... Ну, или как уже сделано, не формат 
Type1-шрифтов (тоже язык), а редактор pfaedit. На этом пути, по-моему, 
пересечений с работой издательств будет гораздо меньше.

Все сказанное, разумеется, - некие общие соображения на перспективу.

--
С уважением,
Вадим