Ответ на »сообщение 2641« (Jack Of Shadows)
___________________________

Давно писали, что у них на OberonCore.ru закрытый форум. Тока кто ж Вас туда пустит :-\

Ответ на »сообщение 2640« (>-<)
___________________________

А что у Росы уже появились закрытые форумы ? Нехило :)) Ссылку можно ?

Ответ на »сообщение 2636« (Руслан Богатырев)
___________________________

Начать с чего угодно, только не с реальной работы...

И как Вы хотите привлечь людей, если вся информация по проекту на закрытых форумах, а на открытых одна сплошная "вода"?

Добавочка в "базу знаний"

---

Андрей Юрьевич Андреев
Компилятор "Странник Модула-Си-Паскаль (проект "Русский компилятор").
Статьи
"Современные языки программирования – результаты эволюции" (Мир ПК N 3 за 2001 год)
http://home.perm.ru/~strannik/st_txt_prog_01.html
"Языки программирования: новое поколение. Haskel, Ocaml, Python, Ruby, Perl, Php." (PC Magazin N 10 октябрь 2006 год)
http://home.perm.ru/~strannik/st_txt_prog_07.html

---

IMHO, просматриваются некоторые точки соприкосновения с проектом Роса.
Любопытно отношение к этому явлению.
Можно ли подчерпнуть что-нибудь полезное для Росы?

Ответ на »сообщение 2637« (Руслан Богатырев)
___________________________
Схемы сопряжения ... могут повергаться формальной верификации.

Верификация на соответствие разъёмам блоков? На логические тупики?

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

Ответ на »сообщение 2633« (Beginner)
___________________________

Под схемами сопряжения подразумеваются графические интерактивные чертежи или это фигура речи?

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

Ответ на »сообщение 2632« (Mak)
___________________________

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

С чего начать?

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

2. С выстраивания процесса решения такой задачи. Это новый подход: Open Research Programming.
Изложен здесь: http://rbogatyrev.livejournal.com/2007/07/12/ (+ см. ссылки на предыд. заметки)
Специфика этого подхода будет дополнительно раскрываться через различные публикации (в том числе через мой блог). Этот подход следует приоритету исследований и подразумевает формирование собственной исследовательской группы (исследовательского центра).

3. С формирования костяка команды, который обладает опытом и наработками, которые и будут положены в основу проекта. Это техсовет ("микроядро"). Решение вопросов стратегии -- его компетенция. Кроме того, будет формироваться и ядро команды. Формироваться постепенно. Люди проявляются в конкретных делах. Там будет видно, кто чего стоит.

4. С создания публичности проекта, вплоть до обоснования выбора тех или иных стратегических и проектных решений. Достигается через форумы, списки рассылки, технологические блоги участников, офиц. сайт проекта, публикации и пр. Цель: обмен идеями и создание сообщества вокруг проекта. Это сообщество может подпитывать проект теми или иными ресурсами. Это одно из важных условий выживания проекта.

5. С начала формирования команды, выведения ее на уровень кристаллизации и закладывания основ своей "корпоративной" культуры с соотв. требованиями к ведению и качеству работы. Первый год проекта направлен именно на решение этой задачи.

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

Что-то уже реализовано?

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

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

Чтобы это выяснить, надо сначала проработать систему снизу доверху. Разобрать ее до винтика.

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

Разработка закрытого кода поддержена финансированием и админиспративной организованностью.
У открытого кода преимущество в интеграции в мировое сообщество свободных разработчиков.
Но для использования этого преимущества требуется умение использовать полуфабрикаты не
взирая на идеологические разногласия.

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

Практика показывает, что в корпоративном программировании эффективное время работы -- примерно 2 часа в день. Остальное расходуется впустую (плюс дорога). Если специалисты могут (для себя и высокой задачи) выкроить 1 час в день (работая дистанционно и асинхронно с другими), получится, что они работают фактически в режиме half-time (на "пол-ставки").

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

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

>Простой вопрос: Вы готовы заняться конкретным делом в нашем проекте (речь о Форте)?
В общем годов, на сколько время позволит. Что вы имеете в виду под конкретным делом?

Речь идет, прежде всего, о проработке вопросов использования Форта в качестве языка, обеспечивающего слой между железом (процессором) и ОС. Чтобы говорить более конкретно, надо обсуждать подъезды с обеих сторон (и те процессорные архитектуры, которые мы планируем задействовать, и те подходы к построению ядра и ран-таймов языков, которые уже вырисовываются). Но есть и иные задумки. Однако не дело это обсуждать в публичном форуме. Есть готовность и желание -- я Вам пришлю приглашение вступить в нашу группу. Вы сможете войти в контекст работ и рассмотренных идей, после чего можно будет совместно выработать шаги движения в этом направлении.


На различные обсуждения в форумах тратится немало времени. Если люди его тратят, значит им это нужно/интересно. Можно ли это время тратить более продуктивно без потери пользы/удовольствия от общения? Безусловно. И наш проект -- это шаг в данном направлении. Большую интеллектуальную энергию десятков и сотен человек направить в мирное и полезное русло. Где они будут обогащаться идеями, знаниями и информацией, которую вряд ли где еще могут получить. Формы концентрации этой интеллектуальной энергии могут быть разные (как внутри команды, так и вне ее). Каждый может выбирать то, что ему больше подходит.

В отношении "портрета" участников (тех, кто внутри команды) можно предложить такую условную модель с тремя ярко выраженными мировоззрениями (и мотивацией участия):

1. Разработчики-практики.
Хотят реально программировать, а не ждать у моря погоды.

2. Исследователи и проектировщики.
Хотят изучать и анализировать существующие системы и подходы, а также создавать (проектировать) свои.

3. Мыслители-теоретики.
Хотят найти кардинально новые решения, абстракции и механизмы, способные перевернуть мир.

Все они могут мирно взаимодействовать с пользой друг для друга и для проекта. Но важно, чтобы они разделяли основные положения (цели) проекта и его направленность. Нужен манифест. Чем мы сейчас и занимаемся в параллель с другой работой (обсуждение идей, изучение новых материалов из внутренней библиотеки, разведка, подбор кадров, поиск партнеров и др.).

Ответ на »сообщение 2631« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2630« (Geniepro)
___________________________

Так я ж тоже давно уже предлагал писать Росу на Драконе... :о))

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

Иными словами, их место применения -- либо очень высокоуровневое представление (с высоты птичьего полета), либо очень низкоуровневое (напр., сети Петри). Работа на среднем уровне должна опираться на (текстовый) язык программирования. Активности (выражаемые процедурами, функциями и др.) должны быть компактными -- примерно 1 экран. Комбинирование (состыковка) их -- вот наиболее сложный вопрос. Тут важно не потерять контроль над сложностью. Для этого должны быть средства сопряжения (отлаженные схемы сопряжения) и отдельный инструментарий для их создания и верификации.

Мне кажется, я понял, в чем гносеологические причины всех этих споров.

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

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

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

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

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

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

Для одновременного ввода графики и текста необходимо использовать как текстовый ввод (для конкретизации), так и графические инструменты, которые обеспечивают ввод в документ с программой и текста (синтаксические шаблоны, поиск библиотечных функций, идентификаторов), и графики (включая коммандеры, гиперссылки, фолды, кнопки и прочие "контролы"). Графические элементы в документе с программой способны решить и Вашу проблему:

Активности (выражаемые процедурами, функциями и др.) должны быть компактными -- примерно 1 экран. Комбинирование (состыковка) их -- вот наиболее сложный вопрос. Тут важно не потерять контроль над сложностью. Для этого должны быть средства сопряжения (отлаженные схемы сопряжения) и отдельный инструментарий для их создания и верификации.

Кроме того, графические элементы в тексте программы могут имитировать препроцессорную обработку, ускорять доступ к каким-то кускам кода, скрывать неинтересное, помогать в быстрой настройке шаблонов кода и т.п.

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

Ответ на »сообщение 2633« (Beginner)
___________________________
То есть, скажем, блоки (активности) соединяются с учётом их условий на область определения и область допустимых значений, а связи на чертеже сами индицируют цветом (или миганием в аварийном случае) взаимное непокрытие входа и выхода,привлекая внимание участников проекта к нестыковке. Да и весь проект можно окинуть орлиным взором.

Ответ на »сообщение 2631« (Руслан Богатырев)
___________________________
Комбинирование (состыковка) их -- вот наиболее сложный вопрос. Тут важно не потерять контроль над сложностью. Для этого должны быть средства сопряжения (отлаженные схемы сопряжения) и отдельный инструментарий для их создания и верификации.

Под схемами сопряжения подразумеваются графические интерактивные чертежи или это фигура речи?