ZXNet эхоконференция «code.zx»

Hello, fk0 Офттоп пошёл! ;( Станислав правильно поднял тему, если такая бурная реакция! С самого начала, что хочется сказать - тема готового набора процедур не на нулевой точке (хотя и не очень далека от неё) - тот же пример с BGE - там почти весь GUI был в виде библиотек зарелизен. Другой вопрос - достаточно серьёзный - что подавляющее большинство библиотек слабо или вообще не документируется (например: идёт библиотека с функцией call_addr_2_file - что бы это значило???). Если вы откроете открытый код Linux, Unix и т.п., то увидите, что там половина или даже две трети исходников расходуется на комментарии. К сожалению я ни разу такого не видел в исходниках, выложенных для общего пользования на ZX (хотя я не отрицаю что они возможно есть). Это достаточно серьёзное забивание на описание команд и их роли внутри процедуры/функции приводит к собственно малопонятному способу запуска, который, автор, конечно же, неплохо знает, однако я (не автор) разбираться с этим не хочу и как правильно уже подметили форумчане и не буду. И как закономерный результат - то что такой набор библиотек поддерживается/развивается только автором. Поэтому я считаю очень важным вопрос правильного документирования и объяснения кода - и внутри самого кода - и в виде дополнительной документации ОБЯЗАТЕЛЬHО с примерами. С такими библиотеками будет очень просто работать - с одной стороны - кодеры, которые захотят как либо улучшить код - могу без проблем разобраться с ним - и добавить что либо там где надо будет очень просто. С другой стороны - программист которые не собирается вмешиваться в код - просто берёт библиотеки - печатает пример их использования - и пользует их на полную катушку. Если смотреть как обычно организованы функции/процедуры - и их наборы - в других программно/аппаратных системах, то можно увидеть что их названия вообще то достаточно хорошо коррелируют (я бы даже больше сказал :D) с теми функциями которые они собственно и выполняют. Т.о. предлагается например для работы с памятью (кстати ведь есть вроде универсальный драйвер для всех типов памяти - однако где его взять в виде готового тулкита?) называть все процедуры mem_* Для работы с файлами - дисковая подсистема - iofile_* И т.п. Т.о. я хочу с самого при разработке такого набора универсальных утилит (которых кстати я никогда не использовал :D) с самого начала сделать упор именно на ФОРМУ, а не на содержание, которое как мне кажется при хорошей форме - оформлении кодов и примеров пользования - будет так или иначе развиваться - охочие найдутся, даже я ;))). Hасчёт руководителя. Я согласен с CityAceE что без руководителя проект встрянет. Прежде всего по "непринципиальным" вопросам - вот хотя бы посмотреть чуток выше как люди чуть не в драку готовы идти по в принципе не важным вопросам. Роль лидера в этом смысле в том, что он будет брать на себя тяжесть выбора того или иного решения/подхода, а все остальные будут тянуться за ним - и реализовывать предложенный им подход. И вполне естественно, что какой то части этот выбор будет не нравится. В коммерческом проекте есть принцип - "тебе платят - ты работаешь", здесь же такой принцип малоприменим (? совсем не применим), потому человек, который будет руководить этим проектом должен уметь с одной стороны внятно и доступно объяснить для чего было выбрано то или иное решение и с другой стороны, люди, которые работают в команде, должны значительно уважать его авторитет, чтобы при первом же такого рода конфликте интересов не убежать сказав "здесь работаюти кодят одни ...ки, мне с ними не по пути." P.S. Мне кажется экономить на исходниках глупо... одного диска TR-DOS хватит на очень большой набор библиотек, если же использовать псевдообъектный код, то на ещё большее. Подавляющее большинство более менее современных компиляторов поддерживают компиляцию/сборку с диска (даже мой любимый GENS). В крайнем можно ведь и на несколько дисков раскидать, потому размер файлов-исходников я считаю параметр, важность которого я оцениваю как "1" только от конца ;)